Wat laat dit Core Web Vitals-rapport zien?
Vul een domein of één URL in, kies mobiel of desktop, en het rapport haalt 25 weken aan field data op uit Google's CrUX History API. Je krijgt een wekelijkse grafiek voor LCP, INP en CLS, plus TTFB en FCP. Je LCP kan nooit sneller zijn dan een van beide. Het werkt voor elke site met genoeg Chrome-verkeer, ook die van een concurrent.
Onder de laadgrafieken is de LCP opgesplitst in vier onderdelen. Verderop vind je CLS en INP door de tijd heen, en daarna apparaten en navigatietypes. Die laatste twee, en het aandeel afbeelding of tekst in de LCP, gelden voor alle apparaten samen, welke toggle je ook hebt gekozen.
Zo lees je de wekelijkse CrUX-grafieken
Eén balk is één week. Hover eroverheen voor de p75 van die week en het aandeel goede, matige en slechte page loads.
De p75 is het getal waar Google je op beoordeelt: drie op de vier page loads waren minstens zo goed.
- LCP is goed tot 2,5 s en slecht boven 4 s
- INP is goed tot 200 ms en slecht boven 500 ms
- CLS is goed tot 0,1 en slecht boven 0,25
Zijn ze op de p75 alle drie goed, dan haal je de Core Web Vitals.
De badge op elke metric-kaart geeft de richting aan van een rechte lijn door alle weken. De samenvatting bovenaan vergelijkt de gemiddelde p75 van de oudere helft van de weken met de nieuwere helft. De UX happiness score daarnaast is mijn eigen getal: het aandeel goede page loads in de laatste week, gemiddeld over LCP, INP, CLS, FCP en TTFB. Google gebruikt het niet, en er is sowieso geen officiële Core Web Vitals-score.
Waar komt de CrUX-data vandaan?
Uit Chrome op Android en desktop, van gebruikers die hun geschiedenis synchroniseren en gebruiksstatistieken delen met Google. Chrome op iPhone zit er niet in. Edge ook niet.
Elk wekelijks punt beslaat de 28 dagen ervoor, dus de punten overlappen. Zet je op dinsdag een fix live, dan duurt het zo'n vier punten voor die volledig zichtbaar is.
Google voegt elke maandag een nieuw punt toe met data tot de zaterdag ervoor, dus op maandag is het nieuwste punt twee dagen oud. Die 28 dagen geven aan hoe breed elk venster is, en daarom is de vertraging van 28 dagen een mythe.
Dit is wat bezoekers op hun eigen apparaten kregen. PageSpeed Insights draait Lighthouse één keer, vanaf een Google-server, met een trage telefoon en een traag netwerk gesimuleerd. Lighthouse klikt nergens op en heeft dus helemaal geen INP. Een 98 in Lighthouse en een rode INP-lijn hier kunnen allebei kloppen.
Wat is het verschil met het Core Web Vitals-rapport in Search Console?
Search Console leest dezelfde CrUX-data uit, maar alleen voor je eigen sites. Het groepeert URL's die zich hetzelfde gedragen en labelt elke groep op basis van de slechtste metric over de afgelopen 28 dagen.
Search Console laat zien welke groep pagina's zakt. De wekelijkse balken hier helpen je de week te vinden waarin het begon, en van daaruit de release.
Wat je checkt als een metric verslechtert
Blijf eerst op mobiel (daar opent het rapport mee): dat is bijna altijd de slechtste van de twee. Kijk daarna naar de vorm van de lijn.
Een deploy zie je terug als een stijging over zo'n vier weken die daarna afvlakt: een nieuw thema, een tag die is toegevoegd in Tag Manager, een hero image die loading="lazy" kreeg. Zoek op wat er live ging in de week waarin de stijging begint.
Een lijn die maandenlang blijft oplopen, wijst meestal op third-party scripts die zich opstapelen.
Open voor LCP de breakdown-grafiek en kijk welk deel gegroeid is. Deze telt alleen page loads waarin het LCP-element een afbeelding is. Een hogere TTFB wijst naar de server of de cache. Een langere load delay betekent dat de browser de LCP-afbeelding te laat vindt. Een langere load duration is een zwaardere afbeelding of een trage verbinding naar waar die gehost wordt. Een toenemende render delay betekent dat CSS of JavaScript de paint tegenhoudt.
Wat CrUX-geschiedenis je niet vertelt
Kleine sites krijgen geen data. Google heeft flink wat Chrome-bezoeken nodig en zegt niet hoeveel. Pagina's met een noindex of een status anders dan 200 worden ook weggelaten. Is je URL leeg? Probeer het hele domein. Het rapport probeert het voor je met en zonder www.
Zelfs met data krijg je per week maar één p75 per metric voor het hele domein of één populaire URL. CrUX vertelt je niet welk template traag is, welk element verschuift of welk script de klik tegenhoudt.
Daar heb je real user monitoring op je eigen site voor nodig. Ik heb er CoreDash voor gebouwd: de page loads op je eigen site, met het LCP-element en de trage interactie eraan gekoppeld, zodat je een fix binnen een paar uur ziet werken.
