Afgelopen kwartaal werkten we aan een project dat perfect illustreert waarom WordPress niet altijd het juiste gereedschap voor de klus is. SleepDr.com — een website over slaapgezondheid met 228 blogposts, een contactformulier en een mobiele Lighthouse-score van 35 — kwam bij ons aan met een wanhopig verzoek om snelheid. Hun organische verkeer was maandenlang aan het kelderen. Google's Core Update van maart 2026, die holistische Core Web Vitals-scoring op siteniveau introduceerde, had hen hard geraakt. Elke trage blogpost sleepte het hele domein naar beneden.

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

Inhoudsopgave

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94)

De Situatie Daarvoor: Waarom WordPress SleepDr Saboteerde

De WordPress-opstelling van SleepDr was een schoolvoorbeeld van opgehoopte technische schuld. Gedurende drie jaar hadden ze 34 plugins geïnstalleerd. Het thema laadde jQuery plus twee extra JavaScript-bibliotheken. Elke paginaverzoeking raakte een MySQL-database, genereerde HTML op het moment en serveerde niet-geoptimaliseerde afbeeldingen via een gedeeld hostingplan dat al onder druk stond.

Hier is hoe de eerste Lighthouse-audit op mobiel eruitzag:

  • Algehele Score: 35 (rood, niet geslaagd)
  • FCP: 4,2 seconden
  • LCP: 6,8 seconden — bijna drie keer de "Goed"-drempel
  • CLS: 0,28 — layout sprong overal door advertenties, afbeeldingen zonder dimensies en weblettertypeloading
  • TBT: 1.200ms — de main thread was meer dan een seconde geblokkeerd
  • TTFB: 2,1 seconden — de server zelf was traag voordat er überhaupt iets werd weergegeven

De site was niet alleen traag. Het was actief vijandig tegenover 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 meemaken.

Na Google's Core Update van maart 2026, die holistische CWV-scoring introduceerde — door performance te aggregeren op het hele domein in plaats van per pagina — waren SleepDr's 228 trage blogposts hun rankings site-breed aan het vergiftigen. Vroege gegevens van de uitrol toonden 20-35% verkeersdalingen voor getroffen sites. SleepDr zag ongeveer een 30% daling.

Er moest iets veranderen.

De Migratiestapel: Waarom We Deze Keuzes Maakten

We hebben deze stapel niet gekozen omdat het trendy is. We hebben het gekozen omdat elk onderdeel 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 kerngebied — we hebben via onze Next.js-ontwikkelingspraktijk tientallen projecten erop gebouwd.
  • Payload CMS 3: Zelf gehoste headless CMS die SleepDr's contentteam dezelfde bewerkingservaring gaf als met WordPress, minus de ballast. We voeren veel headless CMS-implementaties uit en Payload 3 is ons go-to voor content-zware sites geworden.
  • Supabase: PostgreSQL-database met real-timemogelijkheden. Afgehandeld contact-formulierinzendingen, analyticsgebeurtenissen en eventuele dynamische gegevens.
  • Vercel: Edge deployment. De site wordt vanuit het knooppunt dat het dichtst bij de gebruiker ligt. TTFB wordt bijna verwaarloosbaar.

De totale migratie duurde 7 weken. Content-migratie — alle 228 posts met hun afbeeldingen, metagegevens en URL-structuren — duurde ongeveer 2 weken daarvan. We schreven een aangepast script om content via de WordPress REST API op te halen, te transformeren en in Payload CMS in te voeren.

Voor en Na: De Getallen

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

Metriek Daarvoor (WordPress) Erna (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% reductie)
Total Blocking Time (TBT) 1.200ms 50ms -1.150ms (96% reductie)
Time to First Byte (TTFB) 2,1s 0,3s -1,8s (85% sneller)
Algehele Mobiele Score 35 94 +59 punten
Algehele Desktop Score 61 99 +38 punten

Ik wil duidelijk zijn: dit zijn geen selectief gekozen getallen van een enkele pagina. We voerden Lighthouse uit op 20 representatieve pagina's en gemiddelde de resultaten. De mobiele score varieerde van 91 tot 97 over alle geteste pagina's. Desktop was 97 tot 100.

Nu loop ik je stap voor stap door hoe we elk van deze verbeteringen hebben bereikt.

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94) - architecture

Optimalisatie 1: Afbeeldingsoptimalisatie (LCP -3s)

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

Wat We Deden

next/image voor elke afbeelding gebruiken. Dit component 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 // Boven de vouw hero: laad het vooraf
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Hier is wat next/image automatisch afhandelt:

  • Formaatconversie: Serveert WebP (of AVIF waar ondersteund) in plaats van PNG/JPEG. Dit alleen snijdt afbeeldingsgroottes met 60-80%.
  • Responsieve srcset: Genereert meerdere grootten zodat mobiele gebruikers niet desktop-grote afbeeldingen downloaden.
  • Lazy loading standaard: Afbeeldingen onder de vouw laden pas wanneer de gebruiker ernaartoe scrolt.
  • Expliciete dimensies: De width- en height-props reserveren ruimte in de lay-out, wat rechtstreeks CLS herstelt.

Het Sleutelaspect: Priority Loading voor LCP-elementen

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

We controleerden elke paginasjabloon, identificeerden het LCP-element en markeerden het met priority. Blogpostpagina's gebruikten de aanbevolen afbeelding. De homepage gebruikte de hero banner. Eenvoudig, maar het maakte een verschil van 3 seconden in LCP.

Afbeeldingen CDN

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

Netto impact: LCP daalde van 6,8s naar ongeveer 3,8s van afbeeldingsoptimalisatie alleen. De resterende LCP-winsten kwamen uit TTFB-verbeteringen en lettertypeloading.

Optimalisatie 2: Lettertypeoptimalisatie (FCP -1.5s)

SleepDr's WordPress-thema laadde drie Google Fonts via externe stylesheetlinks. Elk was een render-blokkerend verzoek aan fonts.googleapis.com, gevolgd door nog een verzoek aan fonts.gstatic.com voor de daadwerkelijke lettertypebestanden. Dat zijn zes netwerkrondreizen voordat de browser tekst kon renderen.

Wat We Deden

Zelf-gehoste lettertypen met 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 lettertypebestanden: Geen externe netwerkverzoeken. De lettertypen zijn gebundeld met de build en worden vanuit dezelfde CDN bediend.
  • Automatisch subsetting: Alleen de tekensets die je daadwerkelijk nodig hebt. De Latin-subset van Inter is ongeveer 20KB in plaats van het volledige 100KB+ bestand.
  • display: 'swap': Tekst wordt onmiddellijk weergegeven met een fallback-lettertype, dan schakelt over naar het weblettertype wanneer het is geladen. Geen onzichtbare tekst. Geen flash van ongestijlde inhoud die FCP blokkeert.
  • CSS-variabeleinjectie: Het lettertype wordt toegepast via CSS custom properties, wat betekent nul lay-outshift wanneer het lettertype schakelt omdat we de fallback-lettertypemetriek zorgvuldig hebben aangepast.

We druppelden ook het derde lettertype helemaal. De oude site gebruikte een decoratief lettertype voor kopjes dat visuele ruis zonder verbeterde leesbaarheid toevoegde. Twee lettertypen. Dat is het.

Netto impact: FCP verbeterde met ongeveer 1,5 seconden door render-blokkeringslettertypeverzoeken te elimineren.

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 volledige seconde werd geblokkeerd — de gebruiker kon niet klikken, scrollen of op iets interactief reageren tijdens die tijd.

Waar Kwam Al Die JavaScript Vandaan?

De WordPress-site laadde:

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

Totale JavaScript bij paginalading: ongeveer 1,8MB. Op een vertraagde mobiele verbinding kost het parseren en uitvoeren daarvan ruim meer dan een seconde.

Wat We Deden

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

Nul plugins. Elke functie werd herbouwd als een op maat gemaakt component:

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

Dynamische imports voor alles onder de vouw:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Laadt alleen op client, alleen wanneer nodig
);

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

React Server Components afgehandeld het meeste van de rendering. Blogpost-inhoud, headers, footers, navigatie — alles server-gerendered met nul client-side JavaScript. Alleen interactieve elementen (de mobiele menu-schakelaar, contactformulier, nieuwsbrief signup) stuurde JS naar de browser.

Totale JavaScript bij paginalading na migratie: ongeveer 85KB. Dat is een 95% reductie.

Netto impact: TBT daalde van 1.200ms naar 50ms. De main thread is in feite gratis.

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

TTFB meet hoe lang het duurt voordat de server begint met het verzenden van de eerste byte van het antwoord. De WordPress-site van SleepDr had op mobiel een TTFB van 2,1 seconden. Dat betekent dat voordat iets kon gebeuren — voordat afbeeldingen laadden, voordat lettertypen downloaden, voordat JavaScript werd uitgevoerd — de gebruiker naar een leeg scherm staarde en meer dan twee seconden wachtte op het serverantwoord.

Waarom WordPress zo Traag Was

Elke paginaverzoeking op WordPress:

  1. Raakte de gedeelde hostingserver (al traag)
  2. Laadde PHP
  3. Voerde WordPress core uit
  4. Rende door 34 plugin hooks
  5. Verzoeken naar MySQL meerdere keren
  6. Gegenereerde HTML dynamisch
  7. Stuurde het antwoord

Zelfs met WP Super Cache geïnstalleerd, was de cache-hitrate inconsistent en de server zelf onderbemand.

Wat We Deden

Statische generatie voor alle 228 blogposts. Bij buildtijd pre-rendert Next.js elke blogpost naar statische HTML. Het resultaat is een reeks .html-bestanden op Vercel's Edge Network — gedistribueerd over 80+ wereldwijde locaties.

Wanneer een gebruiker een blogpost aanvraagt, krijgt deze een vooraf gebouwd HTML-bestand vanuit het dichtstbijzijnde edge-knooppunt. Geen databasequery. Geen server-side-verwerking. Alleen een bestandslezen uit 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 deze dynamisch gedrag nodig had. Maar zelfs SSR op Vercel's Edge Functions wordt uitgevoerd in minder dan 100ms omdat de berekening aan de edge gebeurt, niet in een gecentraliseerd datacenter.

Netto impact: TTFB daalde van 2,1s naar 0,3s — een verbetering van 85%. Bij herhaalde bezoeken met caching is het dichter bij 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-opnamescript en een cookie-consentmanager — alles render-blokkerend in de <head>.

Wat We Deden

Next.js biedt de next/script-component met laadstrategieën. We gebruikten ze opzettelijk:

import Script from 'next/script';

{/* Analytics: laad nadat de pagina interactief wordt */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Cookie consent: laad wanneer browser inactief is */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

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

We vervingen ook Google Analytics door Plausible (< 1KB, privacy-gericht, geen cookie consent nodig in de meeste rechtsgebieden). Hotjar volledig verwijderd — SleepDr controleerde de opnames eigenlijk niet. De Facebook-pixel verwijderd omdat ze zes maanden eerder waren gestopt met het uitvoeren van Facebook-advertenties.

Het doden van onnodige scripts van derden is de gemakkelijkste prestatiewinst in webontwikkeling. Ik zeg dit steeds. De meeste sites laden scripts voor services die niemand in het team actief gebruikt.

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

SleepDr's WordPress-thema leverde ongeveer 800KB CSS. Dat omvatte de stylesheet van het thema, stylesheets van plugins, een volledig Bootstrap-rastersysteem (ongebruikt) en Font Awesome (voor ongeveer 12 pictogrammen).

Wat We Deden

Tailwind CSS met automatische verwijdering. Tailwind scant je sjabloonbestanden bij buildtijd en genereert CSS alleen voor de utility-classes die je daadwerkelijk gebruikt. Onze production CSS-bundel: 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 pictogrambibliotheek. Elke SVG is ongeveer 500 bytes. Totale pictogramgewicht: ~6KB versus Font Awesome's 70KB+.

Het resultaat is nul render-blokkeringsCSS-verzoeken. De output van Tailwind wordt inline geplaatst in de initiële HTML-payload door Next.js, dus de browser kan onmiddellijk beginnen met renderen.

Netto impact: CSS gereduceerd met 96%, draagt bij aan zowel FCP- als TBT-verbeteringen.

De Stap-voor-Staplijst

Als je gelijkaardige prestatieproblemen te maken hebt, hier is de volgorde waarin ik dingen zou aanpakken. Dit is geprioriteerd op impact-op-inspanning-verhouding.

Fase 1: Snelle Winsten (Week 1)

  • Voer Lighthouse uit op je 10 pagina's met het meeste verkeer (mobiele modus)
  • Identificeer LCP-elementen op elke 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 ongebruikts
  • Verplaats resterende scripts van derden naar async of defer

Fase 2: Lettertypen en CSS (Week 2)

  • Zelf-host weblettertypen (elimineer externe lettertypeverzoeken)
  • Voeg font-display: swap toe aan alle @font-face-declaraties
  • Subset-lettertypen naar alleen nodig tekensets
  • Controleer CSS — verwijder ongebruikte stylesheets
  • Vervang icoontlettertypen door inline SVG's

Fase 3: JavaScript (Week 3)

  • Bundle-analyse voor identificatie van grootste JS-afhankelijkheden
  • Verwijder jQuery als mogelijk
  • Dynamische import voor niet-kritieke componenten
  • Defer niet-essentieel JavaScript
  • Implementeer codesplitsen per route

Fase 4: Infrastructuur (Week 4+)

  • Evalueer CDN/edge deployment-opties
  • Implementeer statische generatie voor contentpagina's
  • Zet passende cache-headers in
  • Overweeg volledige migratie naar een modern framework als WordPress de bottleneck is

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

Wat de Core Web Vitals van 2026 Betekenen 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 enkele trage paginasjabloon die door 200 blogposts wordt gebruikt, zal je hele site's rankings kapotmaken
  • High-traffic-pagina's hebben meer gewicht in de totaalscore
  • Je kunt niet zomaar je homepage optimaliseren en het voor gezien houden

Vroege gegevens van de uitrol tonen sites met slechte CWV ervaarden 20-35% verlies van organisch verkeer. Sommigen zagen verlies van meer dan 50%. De sites die het snelst herstelden waren die welke performance op infrastructuurniveau aanpakten — niet door individuele pagina's aan te passen, maar door de onderliggende architectuur op te lossen.

Dit is precies waarom SleepDr's migratie zo effectief was. We optimaliseerden niet 228 individuele WordPress-pagina's. We herbouwden het hele bezorgingssysteem zodat elke pagina standaard snel is.

Voor sites die niet klaar zijn voor een volledige migratie, bieden frameworks als Astro een ander overtuigend pad — vooral voor content-zware sites waar je standaard bijna nul JavaScript wilt.

Aanpak Typische Kosten Timeline Verwachte Lighthouse-toename
WordPress-plugin-optimalisatie (WP Rocket, ShortPixel) €100-500/jr 1-2 weken +10-20 punten
WordPress-themavervangng €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 platformherbouw €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 content-overdracht van alle 228 posts, CMS-setup, custom-componenten en performance-optimalisatie. Vercel-hosting kost €20/maand op het Pro-plan. Dat is ruwweg €740/jaar hosting versus de €300/jaar die ze voor shared hosting betaalden die TTFB niet onder 2 seconden kon houden.

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

Veelgestelde Vragen

Hoe lang duurt het voordat Core Web Vitals-verbeteringen Google-rankings beïnvloeden? Naar onze ervaring met SleepDr en vergelijkbare projecten, begint Search Console bijgewerkte CWV-gegevens binnen 28 dagen na deployment weer te geven. Ranking-verbeteringen volgen typisch 2-3 maanden later. Google moet je pagina's opnieuw crawlen, verse veldgegevens verzamelen van echte Chrome-gebruikers (CrUX-gegevens) en dat in algoritmen voor ranking opnemen. Verwacht niet onmiddellijke resultaten — maar wel verwacht meetbare verbetering binnen een kwartaal.

Is een Lighthouse-score van 94 daadwerkelijk bereikbaar voor een echte productiesite? Ja, maar dit vereist opzettelijke architectuurkeuzes van het begin. Labscores boven 90 op mobiel zijn bereikbaar met moderne frameworks als Next.js of Astro wanneer je je scripts van derden controleert, afbeeldingen op de juiste manier optimalisert en op een edge-network implementeert. De sleutel is dat elke component performance-bewust moet zijn. Één slechte embed of niet-geoptimaliseerd widget van derden kan je terug naar de 70's laten zakken.

Moet ik weg van WordPress gaan 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-bloat en thema-overhead. Als je onder 50 bent, plugin-optimalisatie alleen zal je waarschijnlijk niet boven 75 brengen. Een headless-aanpak — waarbij WordPress als content API fungeert terwijl een frontend-framework rendering afhandelt — is vaak het middengrondenpad om te verkennen.

Wat is het verschil tussen Lighthouse-scores en echte Core Web Vitals-gegevens? Lighthouse is een labbuurk — het simuleert een middelklasse-telefoon op vertraagde 4G en geeft je synthetische scores. Core Web Vitals in Search Console zijn veldgegevens — echte metingen van echte Chrome-gebruikers die je site over een rolling venster van 28 dagen bezoeken. Google gebruikt veldgegevens voor ranking-signalen, niet labscores. 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 op de juiste manier sizen, het in WebP/AVIF-formaat serveren, fetchpriority="high" toevoegen en ervoor zorgen dat het niet lazy-laadt zal typisch LCP met 2-4 seconden snijden. Op SleepDr stond afbeeldingsoptimalisatie alleen voor ongeveer 3 seconden 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 individueel te evalueren. High-traffic-pagina's hebben meer gewicht in de berekening. Dit betekent een trage blog-archiefsjabloon die op honderden pagina's wordt gebruikt, zal je homepage-rankings ook naar beneden slepen. De fix is architecturaal — je hebt nodig dat elke paginasjabloon CWV-drempels haalt, niet alleen je sleutelpagina's.

Hoeveel kost een WordPress-naar-Next.js-migratie typisch? Voor een contentsite gelijk aan SleepDr (200+ pagina's, standaardlay-out bloggen, 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. Huisvestingen op Vercel Pro is €20/maand. De ROI hangt af van hoeveel organisch verkeer waard is voor je bedrijf, maar voor sites die verkeersdalingen ervoeren van slechte CWV, betaalt de migratie zich typisch binnen 3-6 maanden terug.

Moet ik me op mobiel of desktop Lighthouse-scores richten? Mobiel. Altijd mobiel eerst. Google gebruikt mobile-first-indexering en Lighthouse-mobielscore is aanzienlijk strenger dan desktop omdat het een beperkt apparaat en netwerk simuleert. Als je mobiele score 94 is, zal je desktop-score bijna zeker 95+ zijn. SleepDr's desktop-score van 99 vereiste nul extra werk naast wat we deden voor mobiele optimalisatie.