WordPress Lighthouse Score Vast te 50? Caching Plugins Kunnen Dit Niet Oplossen

Je hebt WP Rocket geïnstalleerd. Je Lighthouse-score ging van 35 naar 52. Je voegde Autoptimize toe. 52 naar 58. Je installeerde Perfmatters. Nu draai je DRIE performance plugins -- elk met eigen JavaScript -- om prestatieproblemen op te lossen die zijn veroorzaakt door andere plugins die JavaScript toevoegen. Zie je de ironie?

Ik ben meer keer dan ik wil toegeven in deze exacte situatie geweest. Je brengt een heel weekend door met het tunen van WP Rocket-instellingen, het genereren van critical CSS, het uitstellen van scripts, het lazy loaden van afbeeldingen, preload inschakelen, een CDN opzetten. Je voert Lighthouse opnieuw uit. 54. Misschien 58 op een goeie dag. Je checkt de concurrentie -- zij zitten op 90+. Je vraagt je af wat je verkeerd doet.

Dit is het: je doet niets verkeerd. Je bent tegen het WordPress performance ceiling aangelopen. Het is echt, het is goed gedocumenteerd, en geen combinatie van caching plugins kan het doorbreken. Het probleem is niet je configuratie. Het is de architectuur.

Dit artikel legt uit waarom caching WordPress-prestaties niet kan verhelpen, wat eigenlijk je lage scores veroorzaakt per metric, en hoe we een echte klant -- SleepDr -- migreerden van een Lighthouse-score van 35 naar 94 door de architectuur volledig te veranderen.

Inhoudsopgave

• The Performance Plugin Paradox
• Render-Blocking CSS: Caching serveert het sneller, niet kleiner
• JavaScript Bloat: jQuery en de Page Builder Tax
• Database Query Overhead: Het First Request Problem
• Server-Side Rendering: PHP's Structural Bottleneck
• Je Lighthouse Score Breakdown Begrijpen
• Case Study: SleepDr Migration -- WordPress naar Next.js
• De Architectuur Die Performance Echt Oplost
• Wanneer Migratie Zinvol Is (En Wanneer Niet)
• FAQ

The Performance Plugin Paradox

Laat me je een beeld schetsen dat ik elke maand zie. Een site-eigenaar neemt contact op omdat hun WordPress-site ergens tussen 35 en 55 scoort op Lighthouse. Ze hebben al een combinatie van deze plugins geïnstalleerd:

• WP Rocket ($59/jaar) -- page caching, CSS/JS minification, lazy loading
• Autoptimize (gratis) -- CSS/JS aggregation, critical CSS
• Perfmatters ($24,95/jaar) -- script manager, database cleanup
• Asset CleanUp (gratis) -- conditional asset loading
• Flying Scripts (gratis) -- delay JavaScript execution

Dat zijn vijf plugins waarvan het enige doel is dat WordPress presteert zoals het uit de box zou moeten. Elk voegt zijn eigen PHP execution overhead toe. Elk schrijft zijn eigen regels naar .htaccess. Sommigen conflicteren op subtiele manieren die alleen surface under real-world load.

Best case scenario? Je gaat van 35 naar misschien 65. Ik heb teams zien besteden aan het tunen van deze plugins en hun verschillende interacties gedurende 40+ uur. Dat is een week ontwikkeltijd -- gemakkelijk $4.000-$8.000 aan arbeid -- om 20-30 Lighthouse punten te winnen en toch "good" Core Web Vitals drempels niet te bereiken.

En hier is wat niemand erover zegt: die gecachte pagina's helpen alleen terugkerende bezoekers. De eerste hit? Nog steeds traag. Een Googlebot crawl? Waarschijnlijk het raken van pagina's zonder cache. Je belangrijkste traffic -- nieuwe bezoekers van zoekopdracht -- krijgt de ergste ervaring.

Render-Blocking CSS: Caching serveert het sneller, niet kleiner

Dit is de eerste muur waar je tegenaan loopt, en dit is de muur die de meeste mensen verkeerd begrijpen.

Een typisch WordPress-thema laadt tussen 200KB en 800KB CSS op elke enkele pagina. Ik overdrijf niet. Dit is wat bijdraagt:

• Theme stylesheet: 150-400KB (Divi, Avada, en Elementor themes zijn de ergste overtreders)
• Plugin stylesheets: 50-200KB (contactformulieren, sliders, social sharing, SEO plugins)
• Google Fonts: 30-100KB (vaak 3-5 font weights laadst die je niet gebruikt)
• Icon libraries: 50-80KB (loading all van Font Awesome voor 6 icons)

Hier is de kritieke statistiek: ongeveer 70% van deze CSS is ongebruikt op elke gegeven pagina. Je homepage heeft de WooCommerce cart styles niet nodig. Je blogpost heeft de contact form CSS niet nodig. Maar WordPress laadt alles, overal, allemaal tegelijk.

Wat doet WP Rocket hieraan? Het minifieert de CSS (bespaart misschien 10-15%), combineert bestanden om HTTP requests te verminderen, en genereert critical CSS voor above-the-fold inhoud. Dat helpt echt. Maar de browser downloadt nog steeds alle 400KB+. Het parsed nog steeds alles. De ongebruikte CSS draagt nog steeds bij aan FCP delays.

WP Rocket kan je CSS niet tree-shaken. Het kan niet bepalen welke styles per pagina nodig zijn en de rest verwijderen. Dat zou het begrijpen van de relatie tussen je HTML en CSS op build time vereisen -- wat precies is wat moderne frameworks doen.

Hoe Next.js + Tailwind Dit Eigenlijk Oplost

Met Next.js en Tailwind CSS worden ongebruikte styles op build time gepurged. Niet uitgesteld. Niet geminificeerd. Volledig verwijderd. Het build process scant je templates, identificeert welke utility classes eigenlijk gebruikt worden, en genereert een CSS bestand met alleen die styles.

Het resultaat? Totale CSS payload: 15-40KB voor een hele site. Niet per pagina -- voor de hele site. Dat is geen marginale verbetering. Het is een ordegroot verschil.

/* WordPress: laadt alles */
/* theme.min.css: 387KB */
/* elementor-frontend.min.css: 142KB */
/* woocommerce.min.css: 98KB */
/* contact-form-7.min.css: 12KB */
/* Total: 639KB CSS, ~70% ongebruikt op elke pagina */

/* Next.js + Tailwind: bouwt alleen wat gebruikt wordt */
/* globals.css: 22KB (hele site) */
/* Per-pagina CSS: 0KB extra (het zit allemaal in de gepurgde bundle) */

JavaScript Bloat: jQuery en de Page Builder Tax

Dit is waar TBT -- Total Blocking Time -- wordt vermoord. En TBT is 30% van je Lighthouse performance score. Je kan letterlijk niet boven de 70 komen met slechte TBT.

WordPress levert jQuery op elke pagina. Dat is 87KB geminificeerd en gzipped. Het execuet synchroon op de main thread. Elke pagina load betaalt deze belasting, zelfs als geen functionaliteit op de pagina jQuery vereist.

Maar jQuery is slechts het voorgerecht. Hier is het JavaScript budget voor een typische WordPress page builder site:

Bron	Grootte (geminificeerd + gzipped)	Main Thread Tijd
jQuery + jQuery Migrate	87KB + 10KB	150-300ms
Elementor frontend	180-350KB	200-500ms
WP Rocket (ja, echt)	15-25KB	30-60ms
Slider plugin	80-150KB	100-250ms
Analytics + tracking	50-120KB	80-200ms
Overige plugins	50-200KB	100-300ms
Totaal	462KB - 855KB	660ms - 1.610ms

Dat is 660ms tot 1,6 seconden van main thread blocking alleen van JavaScript execution. Lighthouse wil dat TBT onder 200ms blijft voor een goede score. Onder 600ms voor "needs improvement." Je bent al uitgelopen voordat je eigenlijke inhoud zelfs maar rendert.

Wat kunnen caching plugins doen? Ze kunnen minificeren (bespaart 5-10%), execution uitstellen (helpt FCP maar TBT blijft hetzelfde omdat het werk nog steeds gebeurt), en scripts vertragen tot user interactie (wat functionaliteit breekt en een storende ervaring creëert wanneer gebruikers op iets klikken en 500ms niets gebeurt).

Next.js: Zero jQuery, Smart Code Splitting

Next.js laadt jQuery niet. Punt. Er is geen equivalent. React handelt DOM manipulatie af, en het zit al in de bundle voor interactiviteit. Maar hier is de echte win: automatische code splitting.

Elke pagina laadt alleen de JavaScript die het nodig heeft. Een statische "About" pagina zou totaal 30KB JS kunnen laden. Je interactieve bookingvorm pagina laadt de form library alleen op die pagina. Dynamic imports betekenen zware componenten laden on-demand.

// Laadt de booking calendar alleen wanneer deze component rendert
import dynamic from 'next/dynamic'

const BookingCalendar = dynamic(() => import('../components/BookingCalendar'), {
  loading: () => <div className="h-96 animate-pulse bg-gray-100 rounded" />,
  ssr: false // Voeg zelfs niet toe aan server bundle
})

export default function BookingPage() {
  return (
    <main>
      <h1>Plan Uw Consultatie</h1>
      <BookingCalendar />
    </main>
  )
}

Die ssr: false flag betekent dat de calendar JavaScript zelfs niet bestaat in de initial page load. Gebruikers zien onmiddellijk een placeholder, dan hydreert de interactieve component. TBT blijft minimaal.

Database Query Overhead: Het First Request Problem

Elke WordPress pagina load triggert databasequeries. Niet een paar. Een lot.

Ik installeerde Query Monitor op een klant's site vorig jaar -- een behoorlijk standaard WordPress + WooCommerce + Yoast setup. Dit is wat een enkele homepage load genereerde:

• WordPress core: 8-12 queries (options, user session, rewrite rules)
• Yoast SEO: 15+ queries (meta data, schema settings, breadcrumbs)
• WooCommerce: 20+ queries (product data, cart, session)
• Theme options: 10-15 queries (customizer settings, widget data)
• Menu rendering: 5-8 queries (nested menu items, meta)
• Sidebar widgets: 5-10 queries per widget

Totaal: 63-80 databasequeries voor een enkele pagina load. Op shared hosting met een MySQL database die ook 200 andere sites serveert? Je ziet waar dit heen gaat.

WP Rocket's page caching elimineert dit -- voor gecachte pagina's. Maar caches verlopen. Nieuwe pagina's worden niet gecached tot eerste bezoek. WooCommerce cart pagina's kunnen niet worden gecached (ze zijn dynamisch per gebruiker). Admin gebruikers omzeilen cache. En Googlebot raakt pagina's die uit cache zijn gevallen vaak.

Elke uncached request betaalt de volledige database penalty.

Next.js ISR: Pre-Rendered HTML, Zero DB Queries bij Request Time

Met Next.js met Incremental Static Regeneration (ISR) worden pagina's op build time voorgebouwd naar statische HTML. Wanneer een gebruiker een pagina aanvraagt, geeft de server een voorgebouwd HTML-bestand terug. Geen PHP execution. Geen databasequeries. Geen computatie.

// Dit draait op build time, NIET op request time
export async function getStaticProps() {
  const posts = await fetchFromWordPressAPI('/wp-json/wp/v2/posts')
  
  return {
    props: { posts },
    revalidate: 3600 // Rebuild deze pagina elk uur
  }
}

De revalidate: 3600 betekent dat de pagina elk uur in de achtergrond herbouwd wordt. Gebruikers krijgen altijd onmiddellijk statische HTML. Inhoud blijft vers. Databasequeries gebeuren eenmaal tijdens regeneratie, niet op elke enkele bezoekerrequest.

Wanneer we headless CMS development doen, wordt WordPress het content backend -- redacteuren gebruiken nog steeds de vertrouwde admin interface -- maar de frontend is volledig ontkoppeld. De database krijgt alleen hits tijdens builds of revalidatie, niet tijdens user requests.

Server-Side Rendering: PHP's Structural Bottleneck

Laten we het hebben over TTFB -- Time to First Byte. Dit is hoe lang het duurt voordat de server begint met het sturen van een response nadat een request is ontvangen.

WordPress genereert elke pagina door PHP uit te voeren. Zelfs een eenvoudige blogpost vereist:

1. Apache/Nginx ontvangt request
2. PHP process spawnt (of wordt hergebruikt uit pool)
3. WordPress bootstrap laadt (~50 files)
4. Actieve plugins laden (elk: file reads, databasequeries, hooks registration)
5. Theme functions laden
6. Template hierarchy resolveert
7. Databasequeries executeren
8. Template rendert naar HTML
9. Response verzonden

Op shared hosting (waar de meerderheid van WordPress sites leeft -- SiteGround, Bluehost, GoDaddy) duurt dit proces 2-4 seconden voor alleen TTFB. Voordat CSS, JavaScript, of afbeeldingen laden. Je gebruiker staart naar een leeg scherm gedurende 2+ seconden.

Managed WordPress hosting (Kinsta, WP Engine, Flywheel) reduceert dit tot 0,8-1,5s TTFB. Beter. Nog steeds niet geweldig.

Next.js op Vercel's Edge Network? 50-200ms TTFB. Dat is niet omdat Vercel magische servers heeft. Het is omdat er niets te computeren is. Het HTML bestaat al. De edge node het dichtst bij de gebruiker serveert het direct. Geen PHP. Geen database. Geen template rendering.

De performance gap tussen 2+ seconden TTFB en 100ms TTFB is iets wat je niet kunt overbruggen met een caching plugin.

Je Lighthouse Score Breakdown Begrijpen

Alvorens we naar de case study kijken, laten we begrijpen wat Lighthouse eigenlijk meet en waarom WordPress worstelt met elke metric:

Metric	Gewicht	Wat Het Meet	WordPress Probleem	Next.js Oplossing
TBT	30%	Main thread blocking door JS	jQuery + plugin JS = 600ms+	Code splitting = <50ms
LCP	25%	Grootste zichtbare element geschilderd	Trage TTFB + render-blocking CSS	Pre-rendered HTML + gepurgde CSS
CLS	25%	Visuele layout shifts	Lazy-loaded afbeeldingen zonder dimensions, dynamische ads	next/image met expliciete sizing
Speed Index	10%	Visuele volledigheid over tijd	Zware CSS blokkeert rendering	Minimale CSS, onmiddellijke HTML
FCP	10%	First content painted	Render-blocking resources	Critical CSS inlined, niets blokkeert

TBT alleen al bij 30% gewicht betekent dat als je 1.200ms+ blocking time raakt (gebruikelijk op WordPress), je bijna een derde van je score verliest meteen. Geen hoeveelheid beeldoptimalisatie of caching kan compenseren.

Case Study: SleepDr Migration -- WordPress naar Next.js

SleepDr kwam naar ons met een probleem dat ik tientallen keren heb gezien. Ze zijn een slaapgezondheidspraktijk met een WordPress site gebouwd op een premium theme, met WooCommerce voor afspraakplanning, Yoast voor SEO, Elementor voor pagina bouw, en -- je raadt het -- WP Rocket, Autoptimize, EN Perfmatters voor performance.

Drie performance plugins. Lighthouse score: 35.

Hier zijn de voor en na getallen:

Metric	WordPress (Voor)	Next.js (Na)	Verandering
FCP	4,2s	1,1s	-74%
LCP	6,8s	1,8s	-74%
CLS	0,28	0,01	-96%
TBT	1.200ms	50ms	-96%
TTFB	2,1s	0,3s	-86%
Lighthouse Score	35	94	+169%

Geen caching plugin combinatie zou deze resultaten kunnen bereiken. De architectuur moest veranderen. Laat me je door elke metric lopen.

FCP: 4,2s → 1,1s (-74%)

Wat veroorzaakte de WordPress score: De WordPress site had 2,1s TTFB (shared hosting), gevolgd door 580KB render-blocking CSS van Elementor, het theme, WooCommerce, en zes plugin stylesheets. De browser kon niets schilderen tot het alle die CSS had gedownload en geparseerd. FCP kon letterlijk niet starten tot 4+ seconden na de klik.

De Next.js fix: Pre-rendered HTML bediend vanaf Vercel's edge (0,3s TTFB). Critical CSS inlined in de <head> -- ongeveer 4KB. De browser schildert inhoud bijna onmiddellijk nadat het HTML ontvangt. Totale CSS voor de hele site: 28KB, asynchroon geladen na eerste paint.

LCP: 6,8s → 1,8s (-74%)

Wat veroorzaakte de WordPress score: Het grootste contentful element was een hero image. Op WordPress laadde het via Elementor's lazy loading (wat conflicteerde met WP Rocket's lazy loading -- ja, ze bestookten elkaar). De afbeelding was een 2,4MB PNG gediend zonder next-gen format conversie. LCP kon niet compleet zijn tot deze massieve afbeelding was klaar met downloaden over een trage TTFB connection.

De Next.js fix: next/image met automatische WebP/AVIF conversie, responsive srcset, en priority loading voor above-the-fold afbeeldingen. De hero image ging van 2,4MB PNG naar 85KB AVIF. Het werd geprioriteerd in de loading sequence -- geen lazy loading voor above-fold inhoud. Gecombineerd met de snelle TTFB, voltooide LCP in 1,8s.

CLS: 0,28 → 0,01 (-96%)

Wat veroorzaakte de WordPress score: Drie schuldigen. Eerst afbeeldingen zonder expliciete width/height attributen (Elementor bepaalde ze dynamisch via CSS, veroorzakend reflow). Tweede, een cookie consent banner die zich na page load in de DOM injecteerde, inhoud naar beneden duwend. Derde, web fonts laadst met font-display: swap veroorzakend een zichtbare text reflow. Een CLS van 0,28 is verschrikkelijk -- Google beschouwt alles boven 0,1 als "poor."

De Next.js fix: next/image forceert width en height, het reserveren van ruimte voordat afbeeldingen laden. De cookie banner werd gepositioneerd als fixed overlay in plaats van inline inhoud. Fonts waren self-hosted met font-display: optional en preloaded. Het resultaat: 0,01 CLS. Effectief zero layout shift.

TBT: 1.200ms → 50ms (-96%)

Wat veroorzaakte de WordPress score: jQuery (87KB + 150ms execution). Elementor frontend JS (280KB + 400ms). WooCommerce cart fragments (35KB + 80ms). Drie performance plugins' JavaScript (gecombineerd 45KB + 90ms). Analytics en tracking (60KB + 120ms). Verschillende plugin scripts (100KB + 200ms). Totaal: meer dan een seconde van main thread blocking.

De Next.js fix: Zero jQuery. Zero page builder JS. Dynamic imports voor de appointment booking widget. Analytics geladen via next/script met strategy="lazyOnload". Totale JavaScript op de homepage: 62KB. TBT: 50ms. Dat is een 96% reductie.

TTFB: 2,1s → 0,3s (-86%)

Wat veroorzaakte de WordPress score: SleepDr was op SiteGround shared hosting. Elke uncached request triggerde WordPress bootstrap, plugin loading, 60+ databasequeries, en PHP template rendering. Zelfs met WP Rocket's page cache gebeurde cache invalidatie frequent vanwege WooCommerce cart dynamics. Gemiddelde TTFB voor echte gebruikers: 2,1 seconden.

De Next.js fix: Statische pagina's geïmplementeerd naar Vercel's globale edge network. ISR handelt content updates af -- pagina's regenereren in de achtergrond elk 30 minuten. User requests raken altijd pre-built HTML op de dichtste edge node. TTFB daalde naar 0,3s gemiddeld, met sommige regio's sub-100ms zien.

De Architectuur Die Performance Echt Oplost

De SleepDr migratie gebruikte wat we het headless WordPress pattern noemen. WordPress blijft als CMS -- het SleepDr team logt nog steeds in wp-admin, schrijft inhoud in Gutenberg, beheert hun appointment types in WooCommerce. Niets veranderde voor hen aan de content management kant.

Maar de frontend is volledig Next.js. Het build process trekt inhoud uit WordPress via de REST API, genereert statische pagina's, en implementeert naar Vercel. Content editors publiceren in WordPress, een webhook triggert een revalidatie, en de bijgewerkte pagina is live in onder 30 seconden.

Voor teams die een gelijkaardige benadering overwegen, is Astro ook een optie waard om te evalueren -- speciaal voor content-zware sites met minimale interactiviteit. Astro verzendt standaard zero JavaScript, wat Lighthouse scores nog hoger kan duwen.

De sleutelziet: we hebben WordPress niet geoptimaliseerd. We vervingen het deel dat traag was (de PHP rendering en frontend delivery) terwijl we het deel dat goed werkt behielden (content management).

Wanneer Migratie Zinvol Is (En Wanneer Niet)

Ik zal je niet vertellen dat elke WordPress site naar Next.js zou moeten migreren. Dat is oneerlijk. Hier is mijn eerlijke beoordeling:

Migratie is zinvol wanneer:

• Je Lighthouse scores ondanks optimalisatie inspanningen onder 60 steken
• Performance direct impact heeft op revenue (e-commerce, lead gen, SaaS marketing sites)
• Je $200+/maand betaalt voor managed WordPress hosting poging acceptabele snelheid te krijgen
• Je development team comfortabel is met React/JavaScript
• SEO rankings lijden onder Core Web Vitals failures

Migratie is niet zinvol wanneer:

• Je een persoonlijke blog of kleine brochuresite bent (de investering betaalt zich niet uit)
• Je content team sterk vertrouwt op WordPress-specifieke plugins zonder API equivalent
• Je tevreden bent bij 60-70 Lighthouse en je Core Web Vitals slagen
• Je budget onder $15.000 ligt voor de migratie

Voor sites waar migratie zinvol is, liggen typische investeringen tussen $15.000-$50.000+ afhankelijk van complexiteit, aantal templates, en aangepaste functionaliteit. We hebben onze benadering en typische project structuren gedetailleerd op onze pricing pagina.

De ROI berekening is direct: als slechte performance je X kost in verloren conversies per maand, en migratie kost Y, je weet je terugverdientijd. Voor SleepDr droeg de verbeterde page speed bij aan een 34% stijging in afspraakboekingen binnen het eerste kwartaal.

FAQ

Kan WP Rocket echt mijn WordPress Lighthouse score niet oplossen?

WP Rocket is echt een van de beste WordPress caching plugins beschikbaar. Het doet alles wat een caching laag kan doen -- page caching, minification, lazy loading, CDN integratie, critical CSS generatie. Maar het werkt binnen WordPress's architecturale beperkingen. Als je score onder 50 is, kan WP Rocket je typisch naar 55-65 brengen. Boven 80 consistent gaan vereist het verwijderen van render-blocking CSS, jQuery afhankelijkheid, en PHP rendering overhead dat WP Rocket simpelweg niet kan elimineren. Het optimaliseert delivery. Het kan de architectuur niet herstructureren.

Welke Lighthouse score kan WordPress realistisch bereiken met caching plugins?

Met een goed geoptimaliseerde setup -- licht theme, minimale plugins, WP Rocket volledig geconfigureerd, managed hosting zoals Kinsta of WP Engine -- kun je realistisch 65-75 op mobile Lighthouse bereiken. Desktop scores zullen hoger zijn (80-90) omdat het testingapparaat meer verwerkingskracht heeft. Boven 80 op mobile consistent bereiken vereist ofwel een uiterst minimale WordPress setup (bijna geen plugins, aangepaste theme) of een architectuurverandering. Sites met page builders zoals Elementor of Divi maxen typisch uit bij 50-65.

Hoeveel kost het migreren van WordPress naar Next.js?

Kosten variëren aanzienlijk op basis van site complexiteit. Een eenvoudige brochuresite (5-15 pagina's, blog, contactformulier) kost $15.000-$25.000. Een gemiddeld complexe site met custom post types, meerdere templates, en integraties kost $25.000-$40.000. E-commerce of complexe web applicaties met user accounts, dynamische data, en third-party integraties starten bij $40.000+. Dit zijn 2025 marktprijzen voor agencies met bewezen headless ervaring. Je kunt contact opnemen met ons voor een specifiek estimate op basis van je site.

Betekent headless WordPress dat mijn content team nieuwe tools moet leren?

Nee. Dat is het hele punt van de headless benadering. Je content team blijft wp-admin gebruiken, Gutenberg, ACF, of wat ze ook gewend zijn. De enige zichtbare verandering is dat ze misschien 30-60 seconden moeten wachten tot content updates verschijnen op de live site (vanwege ISR revalidatie) in plaats van changes onmiddellijk te zien. Sommige teams vinden dit nauwelijks merkbaar. De editorial ervaring blijft vrijwel identiek.

Wat is het verschil tussen TBT en FCP, en waarom zijn beide belangrijk?

FCP (First Contentful Paint) meet wanneer de gebruiker iets ziet -- welke inhoud dan ook. TBT (Total Blocking Time) meet hoe lang de main thread blocked is door JavaScript execution tussen FCP en Time to Interactive. Je kunt een redelijke FCP hebben maar verschrikkelijke TBT, wat betekent dat gebruikers snel inhoud zien maar niet kunnen interageren. Dit is gebruikelijk op WordPress sites waar HTML van cache rendert maar dan 800KB+ JavaScript execuet. Beide metrics zijn belangrijk omdat ze samen 40% van je Lighthouse score vertegenwoordigen (TBT op 30%, FCP op 10%).

Zal migreren naar Next.js mijn SEO rankings tijdelijk schaden?

Als het goed wordt gedaan, nee. De sleutel is URL structuren behouden, juiste 301 redirects implementeren voor URL's die veranderen, alle metadata behouden, en zorgen dat de XML sitemap correct is. We zien typisch een korte 1-2 weken stabilisatie periode waar rankings licht fluctueren, gevolgd door verbeteringen als Google de betere Core Web Vitals herkent. SleepDr zag geen ranking drops tijdens migratie en wond posities in 6 weken. Het risico komt van slordig migraties -- verbroken redirects, ontbrekende pagina's, gewijzigde URL structuren zonder redirects.

Kan ik Astro gebruiken in plaats van Next.js voor de migratie?

Absoluut. Astro is een uitstekende keuze voor content-zware sites met beperkte interactiviteit. Astro verzendt standaard zero JavaScript en hydreert alleen interactieve componenten -- wat ze "islands architecture" noemen. Voor een site zoals een blog, documentatiesite, of marketingsite waar inhoud primair is, kan Astro zelfs betere Lighthouse scores bereiken dan Next.js. We bevelen Next.js aan wanneer je aanzienlijke client-side interactiviteit nodig hebt (dashboards, booking systems, e-commerce) en Astro wanneer inhoud primair is.

Is de Lighthouse score verbetering de investering waard?

Dat hangt volledig af van wat je site doet. Voor een persoonlijke blog, waarschijnlijk niet. Voor een bedrijf waar organic search traffic revenue drijft, is de wiskunde overtuigend. Google heeft bevestigd dat Core Web Vitals een rankingfactor is. Studies van 2024-2025 laten zien dat elke 100ms verbetering in LCP correleert met een 1,1% stijging in conversiepercentage voor e-commerce sites. Als je site $50.000/maand genereert in revenue en een 10-15% conversieverbetetering voegt $5.000-$7.500/maand toe, betaalt een $30.000 migratie zich in 4-6 maanden terug. Voer je eigen getallen uit -- het antwoord is altijd specifiek voor je bedrijf.