Een klant stuurde me vorige maand een screenshot: LCP 6,8 seconde op mobiel. Hij had al van alles geprobeerd — een nieuwe hero-afbeelding, een compressie-plugin, een CDN-abonnement dat hij nooit had ingesteld. Mijn eerste vraag was simpel: welk element veroorzaakt die 6,8 seconde? Stilte.
Dat is waar de meeste pagespeed-trajecten ontsporen. Niet door een gebrek aan tools, maar door een gebrek aan volgorde. Mensen optimaliseren wat ze toevallig tegenkomen, meestal in de volgorde waarin een blogpost uit 2019 het noemt. Ondertussen blijft de echte bottleneck staan. In datzelfde geval bleek 4,1 seconde van de 6,8 te komen van één niet-geoptimaliseerde afbeelding bovenaan de pagina, en 1,3 seconde van een TTFB die nooit iemand had gemeten. Twee ingrepen, geen redesign, LCP naar 2,1 seconde.
Hieronder de volgorde die ik zelf aanhoud, met de reden erachter.
Eerst meten, en dan field data — niet lab data
PageSpeed Insights geeft je twee dingen door elkaar: labdata uit een gesimuleerde run en fielddata uit de Chrome UX Report. Die laatste is wat Google daadwerkelijk gebruikt voor Core Web Vitals. Het verschil is groot. Ik heb sites gezien die in de labtest 98 scoorden en in het veld zakten op INP, simpelweg omdat echte gebruikers op een drie jaar oude Android met vier tabbladen open klikken.
Begin dus met fielddata, per pagina-type, niet voor de hele site. Je homepage, je belangrijkste landingspagina en je categorie- of productpagina hebben vaak verschillende problemen. Kijk daarna pas in de labdata om te zien wélk element het probleem veroorzaakt. Lighthouse wijst het LCP-element letterlijk aan; dat scheelt je een dag giswerk.
Eén waarschuwing vooraf: optimaliseer niet op de score. Die 100 is een intern getal van Lighthouse op een gesimuleerde verbinding. Je bezoeker heeft daar niets aan. Optimaliseer op LCP, INP en CLS in het veld, en op het gevoel dat de pagina snel is.
De fix-volgorde: van server naar pixel
De logica achter deze volgorde is simpel: elke stap kost meer werk dan de vorige, dus je wilt de goedkope winst er eerst uithalen. Sla je een stap over, dan meet je daarna het effect van je dure werk door een laag goedkope rommel heen.
Stap 1: TTFB onder de 200 milliseconden
Als de server twee seconden nodig heeft om het eerste byte te sturen, kan geen enkele afbeeldingsoptimalisatie dat redden. Meet TTFB met WebPageTest of je eigen RUM-data. Zit je boven de 500 milliseconden, kijk dan in deze volgorde: hosting, database-queries, caching.
Concreet: een WordPress-site zonder object caching doet honderd queries per pagina. Met Redis en full-page caching zakte er bij een recent project 1,4 seconde van de TTFB af zonder één regel themacode aan te passen. Bij een Next.js-site is het vaak het tegenovergestelde probleem: dynamische rendering waar statische had gekund.
Stap 2: afbeeldingen, en dan echt
Afbeeldingen zijn in de praktijk verantwoordelijk voor het grootste deel van de traagheid. Dit is ook de stap waar het meest half werk wordt gedaan. Format naar WebP of AVIF is stap één, maar het is niet genoeg.
- Serveer op de daadwerkelijke weergavegrootte. Een 2400px-afbeelding in een 400px-container is 36 keer te veel pixels.
- Gebruik
loading="lazy"voor alles behalve het LCP-element. Dat ene element wil je juistfetchpriority="high"geven en preloaden. - Zet expliciete
widthenheightop elke afbeelding. Zonder die twee getallen verschuift je layout en zak je op CLS. - Controleer of je CDN het juiste formaat levert aan de juiste browser, in plaats van alles naar JPEG te converteren.
Stap 3: render-blokkerende CSS en JavaScript
Elke stylesheet in de <head> houdt het renderen tegen tot hij binnen is. Elke synchrone script-tag doet hetzelfde. Bij sites met drie CSS-bestanden en zes scripts betekent dat een pagina die pas na twee seconden iets laat zien, ook al is alle content al binnen.
De aanpak: critical CSS inline voor wat above-the-fold nodig is, de rest asynchroon laden. Scripts krijgen defer, tenzij ze echt direct moeten draaien — en dat is bijna nooit zo. Splits daarnaast je bundel. Een homepage die 800 KB JavaScript laadt waarvan 600 KB voor een chatwidget is, laadt 600 KB te veel.
Stap 4: fonts
Dit is de kleinste stap met de meest onderschatte impact. Een custom font zonder font-display: swap maakt je tekst onzichtbaar tot het bestand binnen is. Gebruik swap, preload het font-bestand dat je écht boven de fold gebruikt, en host het zelf of via een partij die geen extra DNS-lookup en TLS-handshake kost. Subset daarnaast: een volledig Latijns font van 180 KB terugbrengen naar 30 KB is een uur werk.
Stap 5: third-party scripts
Loop je <head> door en vraag bij elk script: wat levert dit op, en wat kost het? Ik kom regelmatig pagina's tegen met vier varianten van Google Analytics, twee chatwidgets en een heatmap-tool die niemand meer bekijkt. Elk daarvan kost 100 tot 400 milliseconden aan netwerk, parse en execute.
Wat je houdt, laad je async of via een tag manager met delay. Wat je niet gebruikt, verwijder je. Dat is geen optimalisatie, dat is opruimen — en het werkt meestal beter.
Stap 6: caching en CDN
Pas nu. Caching-headers met een lange max-age en immutable bestandsnamen, een CDN voor statische assets, en compressie via Brotli. Dit is de stap die iedereen als eerste noemt, terwijl het de stap is die de minste relatieve winst geeft als de rest nog niet klopt.
Wat je niet moet doen
Herbouwen is de duurste vorm van pagespeed-optimalisatie en zelden de oplossing. Ik heb twee trajecten meegemaakt waarbij een volledige rebuild werd aangekondigd, en in beide gevallen zat de traagheid in middelen die net zo goed op de oude site te fixen waren. Een nieuwe site met dezelfde twaalf third-party scripts is net zo traag.
Drie dingen die ik actief afraad:
Alles tegelijk aanpakken. Dan weet je niet wat werkte, en bij regressie weet je niet waar je moet kijken. Werk in stappen van één of twee ingrepen, meet na elke stap.
Blind een plugin of optimalisatietool installeren. Die dingen doen vaak drie nuttige en vijf schadelijke dingen. Ze zijn een prima hulpmiddel, geen strategie.
Een perfecte Lighthouse-score najagen. 100 in de labtest met een slechte veldscore is theater.
Wat het oplevert, en waarom het verder reikt dan conversie
De directe winst is conversie. Bij een e-commercesite waar we LCP van 4,2 naar 2,0 brachten, ging de mobiele conversieratio met 14 procent omhoog over een kwartaal. Dat is geen lineair verband dat je op elke site terugziet, maar de richting klopt altijd.
Er is een tweede effect dat minder mensen op hun netvlies hebben. Crawlers — van Google én van AI-partijen — hebben een beperkt budget. Een server die traag antwoordt, levert minder opgehaalde pagina's en meer time-outs. Dat raakt je indexatie, en daarmee indirect hoe goed AI-systemen je content kennen. Ik heb dat uitgewerkt in Core Web Vitals en AI-crawlers, inclusief wat GPTBot en PerplexityBot precies ophalen en waar ze afhaken.
Dat betekent niet dat pagespeed je GEO-strategie is. Het is de ondergrens. Een snelle site met zwakke content wordt nog steeds niet geciteerd. Maar een trage site met sterke content wordt het ook niet — hij wordt domweg minder vaak opgehaald.
Zo pak je het deze week aan
Concreet, in vier blokken van een halve dag:
- Meten. PageSpeed Insights op je drie belangrijkste pagina's, fielddata bovenaan. Noteer LCP-element, TTFB en het aantal scripts.
- De grootste afbeelding fixen. Formaat, afmetingen, preload voor het LCP-element. Dit is vaak de helft van je probleem.
- De
<head>opschonen. Critical CSS,deferop scripts, fonts metswap, en elk third-party script dat niets oplevert eruit. - Opnieuw meten. Fielddata heeft twee tot vier weken nodig om te verschuiven, labdata is direct.
Verwacht je nu een nieuw platform nodig te hebben? Meestal niet. Maar als je site architectonisch vastloopt — geen caching-laag, geen invloed op de <head>, een page builder die 400 KB aan CSS meestuurt — dan is de vraag niet meer hoe je optimaliseert, maar of je fundament nog klopt. Daar gaat AI-native website laten maken over: niet over sneller maken wat er staat, maar over een basis neerzetten die van zichzelf snel is.
Tot die tijd: begin bij die ene afbeelding.