Lighthouse vs field data: controleer of je fix werkt

Lighthouse zegt dat het gefixt is. Waarom is Search Console nog rood?

Lighthouse laadt je pagina één keer, op één gesimuleerde telefoon, en rapporteert de LCP en CLS voor die laadbeurt. Je Core Web Vitals zijn field data: het 75e percentiel van 28 dagen aan echte Chrome-bezoeken, op snelle en trage telefoons en netwerken, met lege en volle caches, inclusief elke klik. Een fix kan vandaag dus slagen in Lighthouse en pas over vier weken zichtbaar zijn in Search Console. Vergelijk drie Lighthouse-runs en houd daarna je field data in de gaten.

Hoe draai je Lighthouse zodat je voor en na kunt vergelijken?

Draai Lighthouse voor en na de wijziging op dezelfde manier:

1. Leeg de caches. Leeg de cache van je caching-plugin en je CDN na de wijziging, anders test Lighthouse de oude pagina.
2. Kies één tool en blijf daarbij. Zonder code: PageSpeed Insights, op het tabblad Mobiel. Als developer: het Lighthouse-paneel in Chrome DevTools met Device op Mobile, in een incognitovenster, omdat browserextensies hun eigen scripts aan de pagina toevoegen.
3. Test de URL met de melding. Zat de wijziging in het producttemplate, test dan een productpagina.
4. Draai hem drie keer en neem het middelste resultaat.
5. Kijk eerst naar de melding en de bijbehorende metric. De melding verhuist naar Passed audits en de metric waar het om ging (LCP, CLS, Total Blocking Time) daalt. De score komt pas als laatste.

Waarom verandert de score als er niets is gewijzigd?

Elke run is één laadbeurt, en geen twee laadbeurten zijn hetzelfde: de server reageert sneller of trager, het netwerk varieert, en advertenties, consent banners en A/B-tests kunnen per run verschillen. Op een van mijn testpagina's verscheen de eerste tekst of afbeelding (FCP) in de ene run 1,5 s eerder dan in de andere, en op een tweede pagina kwam de score uit op 96 of 80 zonder dat er iets veranderd was. Een paar punten winst na een fix zegt weinig tot je de middelste van drie runs vergelijkt.

Zes runs achter elkaar op dezelfde URL, www.bbc.com, scoorden binnen twee minuten 38, 44, 41, 73, 60 en 53. Lighthouse 13.5.0, mobiel, gesimuleerde throttling zoals in PageSpeed Insights.

Een trace opnemen in DevTools

Open de pagina in Chrome, open DevTools en ga naar het Performance-paneel. Zet in Capture settings (het tandwielicoon) Network op Slow 4G en CPU op 4x slowdown, dicht bij wat Lighthouse op mobiel simuleert, en klik op Record en reload. Het tabblad Insights in de zijbalk toont dezelfde inzichten als Lighthouse, elk met de requests en elementen die erachter zitten. Nog voor je opneemt toont het paneel je eigen LCP, CLS en INP al live (INP zodra je op de pagina klikt). Klik onder Field metrics op Set up en de CrUX-cijfers van je echte bezoekers voor dezelfde URL staan er direct naast.

Waarom zegt Lighthouse het een en Search Console het ander?

Lighthouse geeft je lab data: één laadbeurt van je pagina op een gesimuleerde middenklasse telefoon via een trage 4G-verbinding, met een lege cache. Het stopt kort na het laden en scrollt, tikt of opent dus nooit een tweede pagina. Je krijgt de LCP en CLS voor die ene laadbeurt, en geen INP, want voor INP is een bezoeker nodig die klikt.

Field data is wat Chrome heeft gemeten bij je echte bezoekers: snelle en trage telefoons, goede en slechte netwerken, een eerste bezoek met een lege cache en het tiende met alles in de cache, scrollen, tikken, van pagina naar pagina gaan. Google verzamelt dit in het Chrome UX Report (CrUX), via Chrome-gebruikers op Android en desktop die hun gebruiksstatistieken delen. Je Core Web Vitals zijn die bezoeken over de afgelopen 28 dagen, per metric op het 75e percentiel (p75): drie van de vier bezoeken waren minstens zo goed.

Google rankt op de field data. Lighthouse is er om te achterhalen waarom een pagina traag is en of een wijziging helpt. Komen de twee niet overeen, dan hebben ze andere laadbeurten gemeten. Een groene Lighthouse-score met slechte field data wijst vaak op telefoons die trager zijn dan de simulatie, trage reacties op klikken (INP) of content die verschuift terwijl bezoekers scrollen. Een rode score met goede field data betekent vaak dat je bezoekers snellere telefoons en netwerken hebben dan de trage 4G van Lighthouse, en terugkomen met je bestanden al in hun cache.

Eén PageSpeed Insights-rapport voor www.bbc.com op mobiel, 26 oktober 2026. De echte bezoeken slagen voor alle drie de Core Web Vitals met een LCP van 1,2 s; de Lighthouse-run in hetzelfde rapport scoort 37 met een LCP van 9,5 s.

PageSpeed Insights toont de field data voor de geteste URL als die URL genoeg bezoeken heeft, en onder Origin voor de hele site als dat niet zo is. Search Console verdeelt vergelijkbare URL's in groepen en beoordeelt elke groep op zijn slechtste metric.

Waar zie je wat je bezoekers kregen?

Vier gratis tools tonen CrUX, de field data die Google gebruikt:

• PageSpeed Insights: het bovenste deel, "Ontdek wat je echte gebruikers ervaren", met LCP, INP en CLS op p75 over de afgelopen 28 dagen, voor de URL of de origin.
• Search Console: het Core Web Vitals-rapport voor mobiel en desktop laat zien welke groepen vergelijkbare URL's over de hele site slecht scoren.
• CrUX History report: een balk per week voor je site of een URL, zodat je de trend ziet.
• DevTools: het Performance-paneel zet dezelfde cijfers naast je eigen laadbeurt (eenmalig instellen).

Een site met te weinig Chrome-bezoeken heeft geen CrUX-data: PageSpeed Insights toont dan "No Data" in het bovenste deel. CoreDash meet die bezoeken wel.

CoreDash: welke pagina, welk element

CrUX, de field data van Google, geeft je één p75 per URL of per site. CoreDash, de real user monitoring die ik heb gebouwd, is een script op je pagina's dat elk bezoek meet en het element achter elke LCP, INP en CLS aanwijst. Je filtert op pagina, device en element, en een wijziging zie je vanaf de eerstvolgende bezoeken terug in de tijdreeks. Voeg het script toe voor je iets wijzigt, zodat je voor en na kunt vergelijken.

CoreDash, acme-pagespeed.com, mobiel, p75 per pagina: één pagina heeft een CLS van 0,92 waar de rest op 0 staat.

Hoe lang duurt het voor Search Console je fix toont?

PageSpeed Insights en Search Console tonen de afgelopen 28 dagen, en dat venster schuift elke dag op. In PageSpeed Insights is de data ongeveer twee dagen oud, in Search Console een paar dagen ouder. Twee weken na je fix is de helft van de bezoeken in dat venster nog steeds van vóór de fix. Pas na vier weken bevat het alleen nog bezoeken van na de fix. Het venster van 28 dagen, van dag tot dag toont de volledige tijdlijn.

Search Console, Core Web Vitals-rapport, mobiel, op 26 oktober 2026: laatst bijgewerkt op 21 oktober.

Het CrUX History report toont hetzelfde venster per week: elke balk beslaat de 28 dagen ervoor, dus het duurt zo'n vier balken voordat een fix volledig zichtbaar is.

CrUX History report voor ado-goldkante.de, telefoons, LCP: het aandeel goed, verbetering nodig en slecht per week. Na een wijziging half augustus klimt het aandeel goed over vier balken van 59% naar 76%, 83%, 90% en 93%, en daalt de p75 LCP van 3,6 s naar 1,5 s.

Staat de fix live, open dan het probleem in het Core Web Vitals-rapport van Search Console en klik op Start Tracking (ook wel Validate fix genoemd). Dat start de eigen controle van 28 dagen van Search Console voor elke URL met dat probleem, op dezelfde field data. Zolang die controle loopt is de status Started, en daarna Looking good zodra elke tot dan toe gecontroleerde URL in orde is. Het eindigt op Passed als geen enkele URL het probleem 28 dagen lang heeft gehad, of op Failed als er nog steeds eentje tussen zit; die fix je dan en je klikt op Start new validation.

Hoe weet je of een fix heeft gewerkt voor echte bezoekers?

Controleer in deze volgorde, de snelste eerst:

1. De wijziging staat live. Bekijk de paginabron, of zoek het bestand of de header op in het Network-paneel van DevTools. Zie je nog steeds de oude versie, dan serveert een caching-plugin of het CDN nog de oude pagina.
2. Lighthouse slaagt. Mobiel, drie runs, de middelste (zoals hierboven): de melding verhuist naar Passed audits.
3. Je bezoekers krijgen de fix. In CoreDash, vanaf de eerstvolgende bezoeken: filter op de pagina of het template dat je hebt gewijzigd, zet device op mobiel en volg de metric per dag en het element dat erachter zit.
4. CrUX volgt. De field data in PageSpeed Insights en de balken in het CrUX History report verschuiven stapje voor stapje. Het volledige effect zie je pas na vier weken (waarom het zo lang duurt).
5. Search Console bevestigt het. Klik in het Core Web Vitals-rapport op Start Tracking bij het probleem en wacht op Passed.

Slaagt Lighthouse, zijn er vier weken voorbij en beweegt je field data nog steeds niet? Dan zijn die trage bezoeken laadbeurten die Lighthouse nooit uitvoert: een goedkopere telefoon, een trage klik, een verschuiving halverwege de pagina. In een Core Web Vitals power hour loop ik samen met jou door je field data, paginagroep voor paginagroep, tot we weten welke pagina en welk element je p75 tegenhouden.