Je WordPress-dashboard opent naar 228 blogposts, een mobiele Lighthouse-score van 35, en een verkeersgraaf die drie maanden lang naar beneden helt. SleepDr.com — een slaapgezondheid-contentsite — zag organische bezoeken met 41% dalen nadat Google's Core Update van maart 2026 site-brede Core Web Vitals-scoring introduceerde. Elke trage post was nu een verplichting, die pagina's naar beneden haalde die op zichzelf prima laadden. De klant had snelheid nodig op het hele domein, niet alleen op de homepage. We migreerden de volledige inhoudsbibliotheek naar Next.js 15, Payload CMS 3 en Vercel — en tilden hun mobiele Lighthouse naar 94 in zes weken. Hier is de stack die we kozen, de drie prestatiebottlenecks die we elimineerden, en de meting die het meest telde.

We migreerden ze naar Next.js 15 + Payload CMS 3 + Supabase + Vercel. Het resultaat: mobiele Lighthouse 94, desktop 99. Organisch verkeer herstelde zich binnen 6 weken. Dit is het volledige verhaal van hoe we daar kwamen — elke optimalisatie, elke meting, elke beslissing — zodat je dezelfde denkwijze op je eigen projecten kunt toepassen.

Inhoudsopgave

SleepDr Case Study: WordPress naar Next.js Migratie (Lighthouse 35→94)

De voorkant: waarom WordPress SleepDr doodde

SleepDr's WordPress-setup was een leerboekvoorbeeld van opgehoopte technische schuld. Over drie jaar hadden ze 34 plugins geïnstalleerd. Het thema laadde jQuery plus twee extra JavaScript-bibliotheken. Elk paginaverzoek raakte een MySQL-database, genereerde HTML on-the-fly en serveerde niet-geoptimaliseerde afbeeldingen via een gedeeld hostingplan dat al onder druk stond.

Hier ziet de initiële Lighthouse-audit er op mobiel uit:

  • Algemene score: 35 (rood, onvoldoende)
  • FCP: 4,2 seconden
  • LCP: 6,8 seconden — bijna drie keer de "Goed"-drempel
  • CLS: 0,28 — layout sprong overal van advertenties, afbeeldingen zonder afmetingen en laden van weblettertypen
  • TBT: 1.200ms — de main thread was meer dan een seconde vergrendeld
  • TTFB: 2,1 seconden — de server zelf was traag voordat er iets werd weergegeven

De site was niet alleen traag. Het was actief vijandig voor gebruikers op mobiele apparaten. En omdat Google's Lighthouse mobiele simulatie een middelklasse telefoon op een vertraagde 4G-verbinding nabootst, weerspiegelden de scores wat echte gebruikers in minder dan ideale omstandigheden ervaarden.

Nadat Google's Core Update van maart 2026 holistische CWV-scoring introduceerde — prestaties over het hele domein aggregerend in plaats van per pagina — waren SleepDr's 228 trage blogposts hun rankings site-wijd aan het vergiftigen. Vroege gegevens van de rollout toonden 20-35% verkeersdalingen voor getroffen sites. SleepDr zag ongeveer een 30% daling.

Iets moest veranderen.

De migratiestackstack: waarom we kozen wat we kozen

We kozen deze stack niet omdat het trendy is. We kozen het omdat elk stuk een specifiek probleem van SleepDr oplost.

  • Next.js 15 (App Router): Hybride rendering. Statische generatie voor blogposts, server-side rendering waar nodig. React Server Components om client-side JavaScript te minimaliseren. Dit is ons kernzaak — we hebben tientallen projecten erop gebouwd via onze Next.js-ontwikkelingspraktijk.
  • Payload CMS 3: Zelf-gehost headless CMS dat SleepDr's inhoudsteam dezelfde bewerkingservaring gaf als waarmee ze gewend waren aan WordPress, minus de bloatware. We voeren veel headless CMS-implementaties uit en Payload 3 is onze voorkeur geworden voor inhoud-zware sites.
  • Supabase: PostgreSQL-database met real-time mogelijkheden. Verwerkte contactformulier-inzendingen, analysegebeurtenissen en alle dynamische gegevens.
  • Vercel: Edge-implementatie. De site wordt geserveerd vanuit het knooppunt het dichtst bij de gebruiker. TTFB wordt bijna verwaarloosbaar.

De totale migratie duurde 7 weken. Content-migratie — alle 228 posts met hun afbeeldingen, metagegevens en URL-structuren — nam ongeveer 2 weken van uit. We schreven een aangepast script om inhoud uit de WordPress REST API te halen, te transformeren en in Payload CMS in te voegen.

Voor en na: de getallen

Hier is de volledige uitsplitsing. Dit zijn Lighthouse mobiele scores, waar het echte verhaal zit.

Meting Voor (WordPress) Na (Next.js 15) Verbetering
First Contentful Paint (FCP) 4,2s 1,1s -3,1s (74% sneller)
Largest Contentful Paint (LCP) 6,8s 1,8s -5,0s (74% sneller)
Cumulative Layout Shift (CLS) 0,28 0,01 -0,27 (96% vermindering)
Total Blocking Time (TBT) 1.200ms 50ms -1.150ms (96% vermindering)
Time to First Byte (TTFB) 2,1s 0,3s -1,8s (85% sneller)
Algemene mobiele score 35 94 +59 punten
Algemene desktopscore 61 99 +38 punten

Ik wil duidelijk zijn: dit zijn geen cherry-picked nummers van één pagina. We hebben Lighthouse op 20 representatieve pagina's uitgevoerd en de resultaten gemiddeld. De mobiele score varieerde van 91 tot 97 op alle geteste pagina's. Desktop was 97 tot 100.

Nu zal ik je precies doorlopen hoe we elk van deze verbeteringen hebben bereikt.

SleepDr Case Study: WordPress naar Next.js Migratie (Lighthouse 35→94) - architectuur

Optimalisatie 1: Afbeeldingsoptimalisatie (LCP -3s)

Afbeeldingen waren de enige grootste prestatiebiller op de oude site. SleepDr's blogposts waren zwaar op productfotografie en infographics — vaak geüpload als full-resolution PNG's rechtstreeks van een ontwerper's machine. Sommige afbeeldingen waren 3-4MB elk.

Wat we deden

Gebruikte next/image voor elke afbeelding. Dit onderdeel doet veel zwaar werk:

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Above-the-fold hero: preload it
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Hier is wat next/image automatisch verwerkt:

  • Formaatconversie: Serveert WebP (of AVIF waar ondersteund) in plaats van PNG/JPEG. Dit alleen snijdt afbeeldingsgroottes met 60-80% in.
  • Responsieve srcset: Genereert meerdere groottes zodat mobiele gebruikers desktop-formaat afbeeldingen niet downloaden.
  • Lazy loading standaard: Afbeeldingen onder de vouw laden niet totdat de gebruiker dicht erbij scrollt.
  • Expliciete afmetingen: De props width en height reserveren ruimte in de lay-out, wat CLS direct verhelpt.

Het sleutelinzicht: prioriteitsladend voor LCP-elementen

De priority-prop op de hero-afbeelding was kritiek. Zonder het, lazy-laadt Next.js de afbeelding. Maar als de hero-afbeelding is het LCP-element — wat het op de meeste SleepDr-pagina's was — lazy loading ervan skaadt eigenlijk je LCP-score. Je wilt dat het onmiddellijk begint met downloaden.

We hebben elk paginasjabloon gecontroleerd, het LCP-element geïdentificeerd en het gemarkeerd met priority. Blogpostpagina's gebruikten de featured image. De homepage gebruikte de hero banner. Eenvoudig, maar het maakte een verschil van 3 seconden op LCP.

Afbeeldingen-CDN

Vercel's ingebouwde afbeeldingsoptimalisatie fungeert als CDN. Afbeeldingen worden verwerkt en in cache opgeslagen aan de rand bij het eerste verzoek. Volgende bezoekers krijgen de gecachte, geoptimaliseerde versie in milliseconden. Geen Cloudinary-abonnement nodig. Geen WordPress-plugin die hetzelfde probeert te doen maar erger.

Nettoeffect: LCP daalde van 6,8s naar ongeveer 3,8s van alleen afbeeldingsoptimalisatie. De resterende LCP-winsten kwamen van TTFB-verbeteringen en lettertypeladingen.

Optimalisatie 2: Lettertypeoptimalisatie (FCP -1,5s)

SleepDr's WordPress-thema laadde drie Google Fonts via externe stylesheet-links. Elk was een render-blocking verzoek aan fonts.googleapis.com, gevolgd door nog een verzoek aan fonts.gstatic.com voor de werkelijke fontbestanden. Dat zijn zes netwerkrondes voordat de browser tekst kon schilderen.

Wat we deden

Zelf-gehoste lettertypen met behulp van next/font:

import { Inter, Merriweather } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

Wat next/font anders doet:

  • Zelf-host de fontbestanden: Geen externe netwerkverzoeken. De lettertypen worden gebundeld met de build en geserveerd vanuit dezelfde CDN.
  • Automatische subsetting: Bevat alleen de tekensets die je daadwerkelijk nodig hebt. De Latijnse subset van Inter is ongeveer 20KB in plaats van het volledige 100KB+ bestand.
  • display: 'swap': Tekst wordt onmiddellijk weergegeven met een fallback lettertype, dan overschakelen naar het weblettertype wanneer het is geladen. Geen onzichtbare tekst. Geen flash van niet-opgemaakte inhoud die FCP blokkeert.
  • CSS-variabele-injectie: Het lettertype wordt toegepast via CSS custom properties, wat betekent nul layout shift wanneer het lettertype omwisselt omdat we de fallback-lettertypemetrieken zorgvuldig hebben afgestemd.

We hebben ook het derde lettertype helemaal laten vallen. De oude site gebruikte een decoratief lettertype voor koppen dat visuele ruis toevoegde zonder leesbaarheid te verbeteren. Twee lettertypen. Dat is alles.

Nettoeffect: FCP verbeterd met ongeveer 1,5 seconden van het elimineren van render-blocking fontverzoeken.

Optimalisatie 3: JavaScript-reductie (TBT 1200ms → 50ms)

Dit was de meest dramatische enkele verbetering. Een TBT van 1.200ms betekent dat de main thread van de browser meer dan een volle seconde was geblokkeerd — de gebruiker kon niet klikken, scrollen of interageren met iets gedurende die tijd.

Waar kwam al die JavaScript vandaan?

De WordPress-site laadde:

  • jQuery (87KB geminifieerd) — gebruikt door het thema en de meeste plugins
  • 34 plugin-scripts — contactformulier, analytics, sociale delen, cookie-toestemming, twee verschillende slider-bibliotheken, een lightbox, en meer
  • Thema JavaScript — nog eens 150KB van menu-toggles en animatiebibliotheken
  • Inline scripts — willekeurige fragmenten van verschillende plugins geïnjecteerd in de <head>

Totale JavaScript bij pagina-laadtijd: ongeveer 1,8MB. Op een vertraagde mobiele verbinding duurt het parseren en uitvoeren daarvan langer dan een seconde.

Wat we deden

Nul jQuery. Next.js gebruikt React. We hebben jQuery niet nodig.

Nul plugins. Elke functie werd opnieuw gebouwd als onderdeel op maat:

  • Contactformulier: 4KB React-component + Supabase-serveractie
  • Cookie-toestemming: 2KB component met next/script-strategie
  • Sociale delen: Native Web Share API met fallback-links — geen bibliotheek nodig
  • Analytics: Licht Plausible-script (< 1KB)

Dynamische imports voor alles onder de vouw:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Only loads on client, only when needed
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

React Server Components verwerkte het meeste van de rendering. Blogpost-inhoud, headers, footers, navigatie — allemaal server-weergegeven met nul client-side JavaScript. Alleen interactieve elementen (de mobiele menutoggle, contactformulier, nieuwsbrief-inschrijving) schepen JS naar de browser.

Totale JavaScript bij pagina-laadtijd na migratie: ongeveer 85KB. Dat is een 95% vermindering.

Nettoeffect: TBT daalde van 1.200ms naar 50ms. De main thread is vrijwel gratis.

Optimalisatie 4: Server-Side Rendering en Edge-implementatie (TTFB -85%)

TTFB meet hoe lang het duurt voordat de server begint met verzenden van de eerste byte van het antwoord. SleepDr's WordPress-site had een TTFB van 2,1 seconden op mobiel. Dat betekent dat voor alles kon gebeuren — voordat afbeeldingen laadden, voordat fonts werden gedownload, voordat JavaScript werd uitgevoerd — de gebruiker naar een leeg scherm staarde en meer dan twee seconden wachtte tot de server reageerde.

Waarom WordPress zo traag was

Elk paginaverzoek op WordPress:

  1. Raakte de shared hosting server (al traag)
  2. Laadde PHP
  3. Voerde WordPress-kern uit
  4. Liep door 34 plugin-hooks
  5. Querytte MySQL meerdere keren
  6. Gegenereerde HTML dynamisch
  7. Verzonden het antwoord

Zelfs met WP Super Cache geïnstalleerd was de cache hit-rate inconsistent en was de server zelf niet krachtig genoeg.

Wat we deden

Statische generatie voor alle 228 blogposts. Bij het bouwen genereert Next.js elke blogpost vooraf statisch naar HTML. Het resultaat is een reeks .html-bestanden op Vercel's Edge Network — gedistribueerd over meer dan 80 globale locaties.

Wanneer een gebruiker een blogpost aanvraagt, wordt hem een voorgebouwd HTML-bestand geserveerd vanuit het dichtstbijzijnde edge-knooppunt. Geen databasequery. Geen server-side verwerking. Alleen een bestandslezing van een CDN.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

Voor de contactformulier-pagina gebruikten we server-side rendering omdat het dynamisch gedrag nodig had. Maar zelfs SSR op Vercel's Edge Functions wordt uitgevoerd in minder dan 100ms omdat de berekening aan de rand gebeurt, niet in een gecentraliseerd datacenter.

Nettoeffect: TTFB daalde van 2,1s naar 0,3s — een verbetering van 85%. Bij herhaalde bezoeken met caching is het dichterbij 50ms.

Optimalisatie 5: Beheer van scripts van derden

Scripts van derden zijn de stille moordenaars van webprestaties. SleepDr's WordPress-site laadde Google Analytics (GA4), Google Tag Manager, een Facebook-pixel, een Hotjar-opname-script en een cookie-toestemmingsbeheerder — allemaal render-blocking in de <head>.

Wat we deden

Next.js biedt het next/script component met laadingsstrategieën. We gebruikten ze opzettelijk:

import Script from 'next/script';

{/* Analytics: load after the page becomes interactive */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Cookie consent: load when browser is idle */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

De afterInteractive-strategie laadt het script nadat Next.js-hydration is voltooid. De gebruiker kan de pagina al zien en ermee interageren. De lazyOnload-strategie wacht tot de browser volledig inactief is — geweldig voor niet-kritieke scripts.

We vervangen ook Google Analytics door Plausible (< 1KB, privacygericht, geen cookie-toestemming nodig in de meeste rechtsgebieden). Verwijderde Hotjar helemaal — SleepDr keek eigenlijk niet naar de opnamen. Verwijderde de Facebook-pixel omdat ze zes maanden eerder waren gestopt met het uitvoeren van Facebook-advertenties.

Onnodige scripts van derden verwijderen is de gemakkelijkste prestatieblokkering in webontwikkeling. Ik zeg dit voortdurend. De meeste sites laden scripts voor services waarvan niemand op het team actief gebruik maakt.

Optimalisatie 6: CSS-optimalisatie (800KB → 35KB)

SleepDr's WordPress-thema verscheepte ongeveer 800KB CSS. Dit omvatte het stylesheet van het thema, stylesheets van plugins, een volledig Bootstrap-raster-systeem (ongebruikt) en Font Awesome (voor ongeveer 12 pictogrammen).

Wat we deden

Tailwind CSS met automatische zuivering. Tailwind scant je sjabloonbestanden bij het bouwen en genereert CSS alleen voor de hulpprogrammaklassen die je daadwerkelijk gebruikt. Onze CSS-bundel voor productie: 35KB (gzipped: ~8KB).

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

Voor de 12 pictogrammen gebruikten we inline SVG's. Geen pictogrambibliotheken. Elke SVG is ongeveer 500 bytes. Totaal pictogramgewicht: ~6KB versus Font Awesome's 70KB+.

Het resultaat is nul render-blocking CSS-verzoeken. Tailwind's output wordt in de initiële HTML-payload door Next.js inline opgenomen, zodat de browser onmiddellijk kan beginnen met weergeven.

Nettoeffect: CSS gereduceerd met 96%, bijdragend aan zowel FCP als TBT verbeteringen.

De stap-voor-stap checklist

Als je soortgelijke prestatieproblemen hebt, hier is de exacte volgorde waarin ik dingen zou aanpakken. Dit is geprioriteerd op impact-to-effort ratio.

Fase 1: Quick Wins (Week 1)

  • Voer Lighthouse uit op je 10 pagina's met het meeste verkeer (mobiele modus)
  • Identificeer LCP-elementen op elk paginasjabloon
  • Voeg expliciete width en height toe aan alle afbeeldingen en iframes
  • Voeg loading="lazy" toe aan afbeeldingen onder de vouw
  • Voeg fetchpriority="high" toe aan LCP-afbeeldingen
  • Controleer scripts van derden — verwijder alles wat ongebruikt is
  • Verplaats resterende scripts van derden naar async of defer

Fase 2: Lettertype en CSS (Week 2)

  • Host weblettertypen zelf (elimineer externe fontverzoeken)
  • Voeg font-display: swap toe aan alle @font-face declaraties
  • Subset lettertypen tot alleen benodigde tekensets
  • Controleer CSS — verwijder ongebruikte stylesheets
  • Vervang lettertypepictogrammen door inline SVG's

Fase 3: JavaScript (Week 3)

  • Bundle analyse om de grootste JS-afhankelijkheden te identificeren
  • Verwijder jQuery indien mogelijk
  • Dynamische importering van niet-kritieke componenten
  • Uitstellen van niet-essentiële JavaScript
  • Code splitting per route implementeren

Fase 4: Infrastructuur (Week 4+)

  • Evalueer CDN / edge-implementatieopties
  • Implementeer statische generatie voor contentpagina's
  • Zet juiste cache-headers op
  • Beschouw volledige migratie naar een modern framework als WordPress de bottleneck is

Als je dat laatste punt overweegt — een volledige migratie — neem contact met ons op. We hebben dit exacte type project veel keren gedaan. Onze prijzenpagina bevat details over wat headless-migraties meestal kosten.

Wat Core Web Vitals 2026 betekent voor je site

Google's Core Update van maart 2026 veranderde het spel. CWV wordt niet langer per pagina geëvalueerd — het wordt over je hele domein geaggregeerd, gewogen naar verkeer. Dit betekent:

  • Een enkel traag paginasjabloon dat door 200 blogposts wordt gebruikt, tankt je hele site's rankings
  • Pagina's met veel verkeer wegen zwaarder in de geaggregeerde score
  • Je kunt niet zomaar je homepage optimaliseren en het voor gezien houden

Vroege gegevens van de rollout tonen sites met slechte CWV ervaarden 20-35% organische verkeersdalingen. Sommige zagen verlies van meer dan 50%. De sites die het snelste herstelden waren die welke prestaties op infrastructuur niveau adresseerden — niet door individuele pagina's aan te passen, maar door de onderliggende architectuur te verhelpen.

Dit is precies waarom SleepDr's migratie zo effectief was. We hebben niet 228 individuele WordPress-pagina's geoptimaliseerd. We hebben het hele leveringssysteem herbouwd zodat elke pagina standaard snel is.

Voor sites die niet klaar zijn voor een volledige migratie, bieden frameworks zoals Astro een ander aantrekkelijk pad — vooral voor inhoudszware sites waar je standaard bijna nul JavaScript wilt.

Aanpak Typische kosten Tijdlijn Verwachte Lighthouse-winst
WordPress plugin-optimalisatie (WP Rocket, ShortPixel) €100-500/jr 1-2 weken +10-20 punten
WordPress-thema vervanging €2.000-5.000 2-4 weken +15-25 punten
Headless CMS-migratie (Next.js/Astro) €15.000-50.000 4-10 weken +30-60 punten
Volledig platform-rebuild €30.000-100.000+ 8-20 weken +40-65 punten

SleepDr's project viel in het €20.000-25.000 bereik voor de volledige migratie, inclusief inhoudsoverdracht van alle 228 posts, CMS-setup, aangepaste componenten en prestatie-optimalisatie. Vercel-hosting kost €20/maand op het Pro-plan. Dat is ongeveer €740/jaar hosting versus de €300/jaar die ze betaalden voor shared hosting die TTFB niet onder 2 seconden kon houden.

De ROI? Hun organisch verkeer herstelde zich binnen 6 weken en overtrof pre-decline niveaus tegen week 10. Voor een bedrijf dat afhankelijk is van organisch zoeken, betaalde de migratie zichzelf terug in het eerste kwartaal.

Veelgestelde vragen

Hoe lang duurt het voor Core Web Vitals-verbeteringen Google-rankings beïnvloeden? In onze ervaring met SleepDr en soortgelijke projecten begint Search Console bijgewerkte CWV-gegevens weer te geven binnen 28 dagen na inzet. Ranking-verbeteringen volgen meestal 2-3 maanden later. Google moet je pagina's opnieuw crawlen, verse veldgegevens van echte Chrome-gebruikers verzamelen (CrUX-gegevens) en dat in zijn ranking-algoritmen verwerken. Verwacht geen resultaten van de nacht op de dag — maar verwacht meetbare verbetering binnen een kwartaal.

Is een Lighthouse-score van 94 echt haalbaar voor een echte productiesite? Ja, maar het vereist opzettelijke architectuurkeuzes van het begin af aan. Lab-scores boven de 90 op mobiel zijn haalbaar met moderne frameworks zoals Next.js of Astro wanneer je je scripts van derden controleert, afbeeldingen goed optimaliseert en op een edge-netwerk implementeert. De sleutel is dat elk onderdeel prestatie-bewust moet zijn. Één slechte inbed of niet-geoptimaliseerde widget van derden kan je terugtrekken naar de 70-er jaren.

Moet ik weg van WordPress migreren om goede Core Web Vitals-scores te krijgen? Niet per se. WordPress-sites kunnen goed scoren met het juiste thema, agressieve caching (WP Rocket + Cloudflare), geoptimaliseerde hosting (Kinsta, WP Engine) en minimale plugins. Realistisch gezien scoren de meeste WordPress-sites die we controleren tussen 30-60 op mobiel omdat van opgehoopte plugin-bloatware en thema-overhead. Als je onder 50 bent, plugin-optimalisatie alleen zal je waarschijnlijk niet boven 75 krijgen. Een headless aanpak — waarbij WordPress als content API fungeert terwijl een frontend-framework weergave verwerkt — is vaak de middenweg het overwegen waard.

Wat is het verschil tussen Lighthouse-scores en werkelijke Core Web Vitals-gegevens? Lighthouse is een labtool — het simuleert een middelklas telefoon op vertraagde 4G en geeft je synthetische scores. Core Web Vitals in Search Console zijn veldgegevens — werkelijke metingen van echte Chrome-gebruikers die over een 28-daags voortschrijdend venster je site bezoeken. Google gebruikt veldgegevens voor rankingsignalen, geen lab-scores. Lighthouse is nuttig voor het diagnosticeren van problemen en het testen van fixes, maar je doel is groene CWV-status in Search Console op het 75e percentiel.

Wat is de meest impactvolle enkele optimalisatie voor LCP? Afbeeldingsoptimalisatie. In ongeveer 60% van de sites die we controleren, is het LCP-element een afbeelding. Het correct formattingsgroottes, serveren in WebP/AVIF-formaat, toevoegen van fetchpriority="high" en ervoor zorgen dat het niet lazy-laadt zal meestal LCP met 2-4 seconden verminderen. Op SleepDr verrekende afbeeldingsoptimalisatie alleen ongeveer 3 seconden van LCP-verbetering.

Hoe werkt Google's holistische CWV-scoring van 2026? Sinds de Core Update van maart 2026 aggregeert Google Core Web Vitals-gegevens over je hele domein in plaats van pagina's afzonderlijk te evalueren. Pagina's met veel verkeer wegen zwaarder in de berekening. Dit betekent dat een trage blog-archiefsjabloon die op honderden pagina's wordt gebruikt je homepage-rankings ook naar beneden trekt. De oplossing is architecturaal — je moet elk paginasjabloon CWV-drempels laten passeren, niet zomaar je belangrijkste landingspagina's.

Hoeveel kost een WordPress naar Next.js-migratie typisch? Voor een contentsite vergelijkbaar met SleepDr (200+ pagina's, standaard bloglay-out, contactformulieren, geen e-commerce), verwacht €15.000-30.000 van een ervaren bureau. E-commerce-migraties zijn hoger — €30.000-75.000+ afhankelijk van complexiteit. Voortdurende hosting op Vercel Pro is €20/maand. De ROI hangt af van hoeveel organisch verkeer waard is voor je bedrijf, maar voor sites die verkeersdalingen van slechte CWV ervaarden, betaalt de migratie zich meestal terug binnen 3-6 maanden.

Moet ik me concentreren op mobiele of desktop Lighthouse-scores? Mobiel. Altijd mobiel eerst. Google gebruikt mobile-first indexing, en Lighthouse mobiele scoring is aanzienlijk strenger dan desktop omdat het een apparaat met beperkte en netwerk nabootst. Als je mobiele score 94 is, is je desktop-score vrijwel zeker 95+. SleepDr's desktopscore van 99 vereiste nul extra werk voorbij wat we voor mobiele optimalisatie deden.