Core Web Vitals: LCP, INP en CLS

Module 4: Snelheid, mobiel en https · Leestijd: 13 minuten

Leerdoel: Na deze les kun je de drie Core Web Vitals uitleggen met hun grenswaarden, het verschil tussen velddata en labdata benoemen, een meting met PageSpeed Insights lezen, de belangrijkste oorzaken van een slechte score aanpakken, en eerlijk inschatten hoe zwaar snelheid weegt in de zoekresultaten.

Kernbegrippen: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75e percentiel, velddata (CrUX), labdata (Lighthouse), PageSpeed Insights, rapport Core Web Vitals in Search Console, TTFB, compressie, width en height bij afbeeldingen, loading="lazy", pagina-ervaring

Snelheid in drie getallen

"Is mijn site snel?" is een vage vraag. Google en de makers van Chrome hebben er drie meetbare vragen van gemaakt, de Core Web Vitals:

Een paar dingen om goed te begrijpen:

• LCP meet het moment waarop het grootste zichtbare element verschijnt. Dat is meestal een grote foto bovenaan (de "hero") of een groot tekstblok. Bij Bloemenatelier Lotte is het de foto van het bloemstuk op de homepage.
• INP kijkt naar alle klikken, tikken en toetsaanslagen tijdens het bezoek en rapporteert (bijna) de traagste reactie. INP verving op 12 maart 2024 de oudere meting FID (First Input Delay), die alleen naar de eerste klik keek en alleen naar het wachten vóór de verwerking. Kom je in een oud artikel FID tegen, dan is dat achterhaald.
• CLS is geen tijd maar een score zonder eenheid. Hij wordt hoger als dingen verschuiven terwijl je leest: je wilt op een knop tikken en op dat moment schuift er een banner boven, zodat je iets anders aantikt.

Het 75e percentiel

Een pagina "haalt" de Core Web Vitals als 75 procent van de bezoeken goed scoort op alle drie, apart gemeten voor mobiel en desktop. Dat heet het 75e percentiel. Het betekent: niet je eigen snelle computer op glasvezel telt, maar de ervaring van de meeste bezoekers, ook die met een oudere telefoon op 4G.

Velddata en labdata

Er zijn twee soorten metingen, en ze geven vaak verschillende getallen.

• Velddata komt van echte bezoekers. Chrome verzamelt (bij gebruikers die dat toestaan) anoniem hoe snel pagina's waren, in het Chrome User Experience Report (CrUX). PageSpeed Insights toont de velddata van de afgelopen 28 dagen. Het rapport Core Web Vitals in Search Console gebruikt dezelfde bron. Heeft je pagina te weinig bezoekers, dan toont PageSpeed Insights de cijfers van je hele site (de "origin"), en heeft die ook te weinig, dan is er geen velddata.
• Labdata komt van een gesimuleerde test met Lighthouse: één keer laden op een nagebootste middelmatige telefoon en verbinding. Lighthouse kan geen INP meten (er klikt niemand), en geeft daarom andere getallen, zoals Total Blocking Time, die wel een aanwijzing voor INP zijn.

Velddata is wat telt voor de beoordeling. Labdata is handig om oorzaken te vinden en om na een verbetering meteen te zien of het helpt, zonder 28 dagen te wachten.

Hoe zwaar weegt het?

Hier wordt veel overdreven. Wat Google er zelf over zegt, in de documentatie over pagina-ervaring:

• "Core Web Vitals are used by our ranking systems": ze tellen dus mee.
• Er is geen apart "pagina-ervaringssignaal". Andere onderdelen van een goede pagina-ervaring (https, geen opdringerige pop-ups, mobiel bruikbaar) helpen je volgens Google niet rechtstreeks hoger te komen, maar ze maken je site wel prettiger.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Een trage pagina met het beste antwoord kan dus gewoon bovenaan staan.
• Een perfecte score halen alleen voor SEO is volgens Google "misschien niet de beste besteding van je tijd".

Conclusie: zorg dat je in het groene of op zijn minst het oranje gebied zit, vooral omdat bezoekers op een trage of verspringende pagina afhaken. Van 90 naar 100 punten in Lighthouse jagen levert in de zoekresultaten weinig op.

De oorzaken die je zelf kunt aanpakken

Een trage eerste reactie (TTFB)

Alles begint met het moment waarop de eerste byte van de HTML binnenkomt, de Time to First Byte. TTFB is zelf geen Core Web Vital, maar een trage TTFB maakt een goede LCP bijna onmogelijk. web.dev noemt als richtwaarde: goed is 0,8 seconde of minder, slecht is meer dan 1,8 seconde. Oorzaken volgens web.dev: te weinig rekenkracht bij de hosting, geen cache (elke pagina wordt opnieuw opgebouwd, typisch bij WordPress zonder cacheplugin), doorsturingen (les 4.1) en een server ver weg zonder CDN.

Compressie hoort erbij: de server hoort HTML, CSS en JavaScript ingepakt te versturen met gzip of Brotli. Je ziet dat aan de kopregel Content-Encoding: gzip of br. Bijna elke hosting doet dat standaard, maar een verkeerde instelling of een oude server kan het uitzetten.

Afbeeldingen

Afbeeldingen zijn de meest voorkomende oorzaak van een slechte LCP en CLS:

1. Te groot. Een foto van 4.000 pixels breed en 5 MB voor een vak van 800 pixels. Verklein vóór het uploaden en gebruik een modern formaat zoals WebP of AVIF.

2. Geen breedte en hoogte. Zonder width en height weet de browser niet hoeveel ruimte de afbeelding nodig heeft, en verspringt de tekst eronder zodra hij binnen is. web.dev raadt aan width en height op elke <img> te zetten:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. De belangrijkste foto lui laden. loading="lazy" laat een afbeelding pas laden als hij in beeld komt. Prima voor foto's verderop, maar web.dev zegt duidelijk: laad afbeeldingen die bij het openen al in beeld zijn, en zeker de LCP-afbeelding, níet lui. Anders wacht de browser met juist de foto die je LCP bepaalt.

Verspringende inhoud en trage reacties

Andere oorzaken van CLS volgens web.dev: lettertypen die bij het laden van grootte veranderen, advertenties en ingesloten widgets die zichzelf groter maken, en inhoud die later boven de bestaande inhoud wordt ingevoegd (zoals een cookiebalk die de pagina naar beneden duwt in plaats van eroverheen te liggen). Een slechte INP komt bijna altijd door te veel JavaScript: zware thema's, sliders, chatwidgets en trackers van derden. Kijk kritisch naar elke plugin of ingesloten dienst; minder is hier echt meer.

In de praktijk: meten met PageSpeed Insights

Ga naar pagespeed.web.dev, vul het adres van je homepage in en klik op Analyseren. Je krijgt twee tabbladen (Mobiel en Desktop). Bovenaan staat de beoordeling van de Core Web Vitals op basis van velddata, als die er is. Daaronder de Lighthouse-test met een score en een lijst "Diagnose" met concrete punten, bijvoorbeeld over afbeeldingen die groter zijn dan nodig of een LCP-afbeelding die lui wordt geladen (de precieze namen veranderen met nieuwe versies van Lighthouse). Begin bij Mobiel: daar is het meestal slechter, en Google kijkt mobiel eerst (les 4.2).

Heb je je site in Search Console (module 2), kijk dan ook bij Ervaring, Core Web Vitals. Daar zie je groepen van vergelijkbare pagina's met hun status, ook voor pagina's die je zelf niet had getest.

Een site van de AI Builder zet breedte en hoogte bij afbeeldingen waarvan de maat bekend is, laadt de eerste foto van de pagina direct en met voorrang (fetchpriority="high") en de rest lui, en maakt bij het publiceren een variant van 800 pixels breed van grote foto's. In WordPress helpen een cacheplugin en het verkleinen van afbeeldingen het meest; de WordPress-cursus gaat daar in module 6 dieper op in. Bij andere websitebouwers en hostingbedrijven werkt het vergelijkbaar: de knoppen verschillen, de oorzaken zijn dezelfde.

Samenvatting

• De Core Web Vitals zijn LCP (goed tot 2,5 s), INP (goed tot 200 ms, sinds maart 2024 in plaats van FID) en CLS (goed tot 0,1), gemeten op het 75e percentiel per apparaatsoort.
• Velddata (CrUX, 28 dagen) bepaalt de beoordeling; labdata (Lighthouse) helpt oorzaken vinden.
• Google gebruikt de Core Web Vitals in de rangschikking, maar relevantie gaat voor: een perfecte score is geen doel op zich.
• Grootste winst: snelle serverreactie met cache en compressie, kleine afbeeldingen met width en height, de belangrijkste foto niet lui laden, minder JavaScript van derden.

Quiz

Opdracht

Opdracht A4.3: Snel antwoord en lichte afbeeldingen. Vul het adres van een pagina in. Het programma meet drie keer de tijd tot de eerste byte (TTFB) vanaf onze server en neemt het middelste getal, kijkt of de HTML gecomprimeerd wordt verstuurd (gzip, Brotli of zstd), telt de afbeeldingen zonder width en height, en kijkt of de belangrijkste afbeelding bovenaan niet met loading="lazy" wordt geladen. Let op: dit is een meting vanaf één plek, geen meting van je bezoekers. Geen eigen site? Gebruik www.wikipedia.org.

Opdracht D4.3: Je Core Web Vitals. Draai PageSpeed Insights op je homepage en op één andere belangrijke pagina, eerst op Mobiel. Noteer per pagina: is er velddata (pagina of hele site), de LCP, INP en CLS uit de velddata, de Lighthouse-score, en het element dat Lighthouse als LCP-element aanwijst. Kies de één verbetering die volgens jou het meeste oplevert, en leg uit waarom.

Verder lezen

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• PageSpeed Insights lezen: Core Web Vitals in gewone taal
• Mijn website is traag of gebruikt te veel CPU: zo maak je hem sneller
• Gratis WordPress-cursus 6.1: Wat maakt een site traag, en hoe meet je het?
• Gratis WordPress-cursus 6.3: Afbeeldingen, PHP en andere snelheidswinst