Diagnosticeer de LCP met het Chrome DevTools Performance Panel

Deze gids is onderdeel van de Largest Contentful Paint (LCP)-hub. Het behandelt één tool: het Chrome DevTools Performance-paneel. Je neemt een gethrottelde trace op, leest de vier LCP-onderdelen, en weet daarna precies welke je als eerste moet oplossen.

DevTools komt als laatste, niet als eerste

Het Performance-paneel is een labtool. Het meet één paginalading, op één apparaat, op één netwerk: dat van jou. Dat maakt het de verkeerde plek om te beginnen en de juiste plek om te eindigen.

Begin met field data. CrUX vertelt je of de LCP überhaupt een probleem is. RUM-data vertelt je welke pagina's en welke elementen traag zijn voor je echte gebruikers. Die workflow wordt stap voor stap behandeld in Fix & Identify LCP Issues. DevTools beantwoordt daarna de enige overgebleven vraag: waarom.

Als je de field data overslaat, optimaliseer je de pagina die je toevallig test op de verbinding die je toevallig hebt. Dit is het patroon dat ik bij bijna elke audit zie: de machine van de developer slaagt, de CrUX p75 faalt, en iedereen is in de war. Je hebt een snelle laptop op glasvezel gemeten. Je gebruikers zitten in een trein met een mid-range Android.

De live metrics-weergave

Open DevTools (Ctrl+Shift+I op Windows en Linux, Cmd+Option+I op Mac) en ga naar de Performance-tab. Het paneel opent niet langer leeg. Voordat je iets opneemt toont het een live metrics-weergave met de LCP, CLS en INP van de pagina waar je je bevindt, lokaal gemeten terwijl je browst.

Drie dingen in deze weergave zijn nuttig voor LCP-werk. Ten eerste benoemt het het LCP-element, en erover hoveren markeert het element op de pagina. Je hoeft dus niet te raden welke afbeelding of koptekst de browser heeft gekozen. Ook kun je field data inschakelen in deze weergave. DevTools haalt dan de CrUX-cijfers op voor de URL en origin en toont ze naast je lokale waarden. Als je lokale LCP 0,8 seconden is en de field p75 3,1 seconden is, is dat gat je eerste bevinding: je machine is niet representatief en throttling is niet optioneel.

Een snelle tip: als je het LCP-element op een willekeurige pagina wilt markeren zonder DevTools te openen, gebruik dan onze gratis Core Web Vitals Visualizer Chrome-extensie.

Throttle voordat je opneemt

Een niet-gethrottelde trace op een developer-machine is nagenoeg waardeloos. De cijfers zullen geweldig zijn en geen enkele zal overeenkomen met wat je gebruikers ervaren. Stel zowel CPU- als netwerk-throttling in in het paneel voordat je opneemt.

• CPU throttling: gebruik standaard 4x vertraging voor mobiel testen. 20x benadert een low-end apparaat. Recente Chrome-versies kunnen ook presets kalibreren op je specifieke machine: de Calibrate-optie genereert low-tier en mid-tier mobiele presets gebaseerd op hoe snel je eigen hardware is. Dat is belangrijk omdat 4x op een snelle desktop een heel ander apparaat is dan 4x op een oude laptop.
• Network throttling: gebruik Slow 4G. Dit is de preset die vroeger Fast 3G heette voordat Chrome het hernoemde, en het is wat Lighthouse simuleert voor mobiel. Fast 4G is de lichtere optie voor het testen van betere verbindingen.

Wanneer field data is ingeschakeld, kan DevTools zelfs een throttling-preset aanbevelen die overeenkomt met wat je echte gebruikers ervaren. Gebruik het. Voor de volledige redenatie achter deze instellingen, zie onze gids over de beste DevTools-netwerkinstellingen voor de Core Web Vitals.

Neem een paginalading op

Klik op de "Record and reload"-knop. Chrome navigeert naar een lege pagina, start de trace, laadt je pagina, en stopt de opname zelf een paar seconden nadat het laden voltooid is. Voor LCP hoef je tijdens de opname niets aan te raken. Blijf met je handen van de pagina af.

Een snelle tip: neem op in een incognitovenster met extensies uitgeschakeld. Extensies injecteren scripts in elke pagina, en die scripts verschijnen in je trace als long tasks die niets met je site te maken hebben.

Lees het LCP breakdown-inzicht

Nadat de trace is voltooid, somt de Insights-zijbalk aan de linkerkant op wat DevTools heeft gevonden. Degene die je wilt hebben is LCP breakdown (oudere Chrome-versies noemen het LCP by phase). Het splitst de LCP-tijd op in zijn vier onderdelen:

Voor een tekst-LCP zonder webfont valt er niets te downloaden, dus zijn de twee resource-onderdelen nul en is het hele verhaal TTFB plus render delay.

Hover over een onderdeel in het inzicht en DevTools markeert dat exacte tijdvak in de tijdlijn. Klik erop en de tijdlijn zoomt in, zodat je kunt zien welke requests en taken binnen dat tijdvak vallen. En als je field data hebt ingeschakeld, toont het inzicht de CrUX p75-waarde naast elk lab-onderdeel (wanneer CrUX afbeelding-LCP-data voor je site heeft). Die vergelijking is de meest ondergewaardeerde feature in het paneel. Het vertelt je of de trace waar je naar staart lijkt op wat je gebruikers daadwerkelijk ervaren, voordat je een middag besteedt aan het oplossen ervan.

Hoe zou een gezonde breakdown eruit moeten zien? Het advies van Google is dat de twee delay-onderdelen dicht bij nul moeten zijn (elk onder 10% van de LCP), waarbij bijna alle tijd naar TTFB en de daadwerkelijke download gaat. Ons eigen Core Web Vitals-onderzoek over miljoenen paginaladingen toont hoe ver de realiteit daarvan af staat: TTFB neemt 48% in, load delay 24%, load duration slechts 10% en render delay 17%. Lees dat nog eens: op de mediane site verspillen de twee wachtfases samen vier keer meer tijd dan de download zelf. Er downloadt niets tijdens die fases. Er rendert ook niets. De browser wacht op werk dat hij eerder had kunnen starten, en daarom zijn deze twee onderdelen de eerste plek om naar winst te zoeken.

Het LCP request discovery-inzicht

Wanneer de LCP een afbeelding is, is er een tweede inzicht dat de moeite waard is om te openen: LCP request discovery. Het voert drie checks uit op de LCP-request:

• Is fetchpriority="high" toegepast op de afbeelding (of de preload ervan)?
• Is de request ontdekbaar in het initiële HTML-document?
• Is lazy loading correct niet toegepast op de afbeelding?

Elke gefaalde check wijst op een discovery-probleem. Het inzicht annoteert de tijdlijn ook met het moment waarop de afbeelding had kunnen beginnen met downloaden en een schatting van de tijd die je verliest. Elk van deze drie fouten heeft een concrete fix, en ze worden allemaal behandeld in de Resource Load Delay-gids.

De tijdlijn zelf lezen

De inzichten dekken de veelvoorkomende gevallen. Voor al het andere lees je de trace direct. Drie tracks zijn belangrijk voor de LCP.

De Timings-track toont markers voor FCP, LCP, DCL en het load-event. De LCP-marker is het moment waarop het element werd gerenderd. Alles wat je aan het diagnosticeren bent gebeurt aan de linkerkant ervan.

De Network-track toont elke request. Zoek de LCP-resource en kijk wanneer deze start, niet alleen hoe lang deze duurt. Een request die start op 2,5 seconden bij een LCP van 3 seconden is een discovery-probleem, en geen enkele hoeveelheid afbeeldingscompressie gaat dat redden. Als je die afbeelding vanaf de eerste HTML-bytes ontdekbaar had gemaakt, zou de download al gestart zijn terwijl de browser de head nog aan het parsen was.

De Main-track toont main thread werk. Long tasks worden gemarkeerd met een rode driehoek in de hoek. Het patroon om naar te zoeken: de LCP-resource is klaar met downloaden, maar de LCP-marker staat honderden milliseconden verder naar rechts. Dat gat is element render delay, en een van die gemarkeerde tasks is er meestal verantwoordelijk voor. Hover over de task om te zien welk script erachter zit. In mijn ervaring is het veel vaker een tag manager of een consent-script dan je eigen code.

Los op wat je hebt gevonden

Het grootste onderdeel in de breakdown bepaalt waar je vervolgens heen gaat: TTFB, Resource Load Delay, Resource Load Duration of Element Render Delay. Als het LCP-element een afbeelding is, snijdt de Optimize the LCP Image-gids door alle vier heen.

Een afsluitende opmerking: een geprerenderde pagina toont alle vier de onderdelen op bijna nul, omdat de browser al het werk deed voordat de gebruiker klikte. Als je LCP-probleem op navigaties binnen je site zit in plaats van op landingspagina's, kunnen speculation rules de hele diagnose overslaan.