Core Web Vitals verbeteren: de volgorde die echt helpt

Een cachingplugin inschakelen is de eerste stap en vaak de enige die wordt gezet. Daarna staat de waarde op ‘verbetering nodig’ en blijft ze daar. De reden: de drie cijfers meten drie verschillende dingen, en caching helpt maar bij één daarvan echt.

De drie waarden, elk in één zin

Daaruit volgt de volgorde: eerst afbeeldingen, dan scripts, dan de lay-out. Caching werkt vooral op de servertijd — dus op een deel van LCP, en op INP vrijwel niet.

Stap 1: de grootste afbeelding

Op de meeste pagina's is de hero-afbeelding de LCP-kandidaat. Drie dingen helpen meteen, in deze volgorde:

1. Verkleinen tot de werkelijk benodigde grootte — een foto van 4000 pixels breed in een vlak van 1200 pixels breed is de meest voorkomende afzonderlijke oorzaak.
2. Omzetten naar een modern formaat (WebP of AVIF), met een fallback voor oude browsers.
3. NIET lazy loaden. De afbeelding helemaal bovenaan moet meteen worden geladen — Lazy-Load maakt de waarde hier slechter in plaats van beter.

Controleer waar de omzetting plaatsvindt. Sommige plugins sturen je afbeeldingen daarvoor naar een dienst van de fabrikant. Wie dat niet wil, heeft een tool nodig die lokaal omzet — dan duurt de eerste ronde langer, maar er gaat niets de deur uit.

Stap 2: het JavaScript

INP is de waarde waarbij caching niet helpt. Die meet hoe lang de browser nodig heeft om op een klik te reageren — en de browser wordt geblokkeerd door scripts die op precies dat moment aan het werk zijn.

De effectiefste maatregel is weglaten: een slider die niemand bedient; een chatvenster op elke pagina; drie lettertypefamilies waarvan er twee niet opvallen. Pas daarna loont het om defer te gebruiken, samen te voegen en uit te stellen tot de eerste interactie.

Stap 3: het verspringen stoppen

• Elke afbeelding heeft width en height in de markup nodig — dan houdt de browser de ruimte vrij
• Ingesloten content in een kader met een vaste hoogte plaatsen
• Lettertypen lokaal uitleveren en met font-display sturen, in plaats van ze van buitenaf te laden
• Cookiebanners en meldingsbalken zo inbouwen dat ze over de content heen liggen in plaats van die weg te duwen

Pas dan: caching, Minify, Preload

Een paginacache bespaart het genereren van de pagina — dat is veel als de server traag is, en weinig als hij snel is. Minify bespaart bytes en is de meest voorkomende oorzaak van kapotte pagina's na een optimalisatie. Preload is een opdracht, geen verzoek: te veel daarvan verdringen precies wat als eerste nodig is.

Schakel Minify afzonderlijk in en controleer telkens een formulierpagina, het winkelwagentje en een pagina met een video. Wie alles tegelijk inschakelt, zoekt bij een fout tussen tien schakelaars.

Goed meten

Twee soorten metingen moet je uit elkaar houden. Een labtest meet onder vaste omstandigheden en is goed om voor en na te vergelijken. Velddata komen van echte bezoekers met echte apparaten en verbindingen — die bepalen hoe Google de pagina beoordeelt.

Daarom: altijd onder dezelfde omstandigheden meten, drie keer in plaats van één keer — en velddata hebben weken nodig voordat een wijziging zichtbaar wordt. Wie na een uur kijkt en niets merkt, heeft niet te weinig geoptimaliseerd, maar te vroeg gekeken.

Wanneer de plugin niet meer helpt

Er is een grens waarbij geen enkele cachingplugin nog verder komt: een overladen paginabouwer met dertig scripts, een hostingprovider met een hoge basislast, een thema dat op elke pagina alles laadt. Als de serverrespons zonder content al traag is, ligt het niet aan de plugin.

Veelgestelde vragen