Herstel & Identificeer Largest Contentful Paint (LCP) problemen

Een gids voor consultants voor het diagnosticeren en oplossen van LCP

Mijn naam is Arjen Karel en ik ben een pagespeed consultant. In de loop der jaren heb ik honderden websites geaudit, en een van de meest hardnekkige uitdagingen is Largest Contentful Paint (LCP). In deze gids deel ik de exacte methodologie die ik gebruik om LCP-problemen te diagnosticeren en op te lossen. Je zult vermeldingen zien van CoreDash, een RUM-tool die ik heb gemaakt om de precieze gegevens te krijgen die nodig zijn voor dit proces. De principes hier zijn universeel, maar ik geloof in het tonen van echte voorbeelden van de tools die ik bouw en dagelijks gebruik.

Het verbeteren van LCP is een systematisch eliminatieproces. Door een duidelijke methodologie te volgen, kun je effectief de knelpunten in je laadproces diagnosticeren en gerichte oplossingen toepassen om de prestaties en gebruikerservaring van je site te verbeteren.

De diagnostische methodologie: Field Data eerst, Lab Data als tweede

Om effectief te optimaliseren, moet je een diagnostische workflow in twee stappen hanteren. Dit zorgt ervoor dat je problemen oplost waar je gebruikers daadwerkelijk mee te maken hebben, en niet alleen maar scores najaagt in een lab-omgeving.

1. Field Data (RUM & CrUX) laat je zien WAT er gebeurt. Field data wordt verzameld van echte gebruikers die je site bezoeken [1]. Het vertelt je of je een LCP-probleem hebt, welke pagina's worden beïnvloed en welke gebruikers (mobiel of desktop) het ervaren. Je moet altijd hier beginnen om te bevestigen dat er een echt probleem bestaat.
2. Lab Data (Lighthouse, DevTools) helpt je te diagnosticeren WAAROM het gebeurt. Lab data wordt verzameld in een gecontroleerde, gesimuleerde omgeving [2]. Zodra je field data een probleem op een specifieke pagina heeft bevestigd, kun je lab-tools gebruiken om het probleem consistent te repliceren en het laadproces te ontleden om de hoofdoorzaak te vinden.

Beginnen met field data zorgt ervoor dat je optimalisatie-inspanningen gericht zijn op veranderingen die een meetbare impact zullen hebben op je werkelijke gebruikers.

Stap 1: Identificeer LCP-problemen met Field Data

Je eerste taak is om gegevens van echte gebruikers te gebruiken om te bevestigen welke pagina's, indien aanwezig, een slechte LCP hebben.

Een toegankelijk startpunt: Google Search Console

Een geldige plek om te beginnen is het Core Web Vitals-rapport in Google Search Console. Log in, navigeer naar het rapport en bekijk de mobiele en desktopgrafieken. Als Google URL's markeert met "LCP-probleem: langer dan 2,5s", heb je bevestiging uit het Chrome User Experience (CrUX) Rapport dat een percentage van je gebruikers een slechte ervaring heeft.

Hoewel Search Console van onschatbare waarde is voor het bevestigen van een probleem, is het traag met updaten en groepeert het gegevens op URL-patronen. Voor directere en gedetailleerdere inzichten is een speciale RUM-tool vereist.

Een diepere blik: Real User Monitoring (RUM)

Om de waarheid te achterhalen, kun je LCP volgen voor elke gebruiker bij elke paginaweergave met behulp van een Real User Monitoring (RUM) oplossing. Hoewel je er zelf een kunt bouwen door gebruik te maken van de [url=https://github.com/GoogleChrome/web-vitals]web-vitals bibliotheek[/url] om gegevens naar je analytics-backend te sturen, kan dit een aanzienlijke technische inspanning zijn.

Als alternatief zijn er speciale RUM-tools voor dit doel ontworpen. Tools zoals CoreDash zijn gebouwd om deze gegevens direct te leveren. Het instellen ervan omvat meestal het toevoegen van een klein JavaScript-fragment aan de header van je site. Eenmaal geïnstalleerd, begint het prestatiegegevens te verzamelen van elke echte bezoeker.

Een goede RUM-tool helpt je verder te kijken dan URL-groepen om te begrijpen:

• Je precieze LCP-score voor elke specifieke URL.
• Een uitsplitsing van elk LCP-element (bijv. een afbeelding, een kop) en welke het vaakst geassocieerd worden met een trage LCP.
• De exacte timing voor elk van de vier LCP-fasen voor elke paginaweergave, waarbij het knelpunt wordt aangewezen.

Tijdens een recente audit voor een e-commerceklant zagen we hoge LCP-waarden op productpagina's ondanks een volledig geoptimaliseerde hero-afbeelding. Onze RUM-gegevens onthulden dat de vertraging niet de afbeelding zelf was, maar een client-side A/B-testscript dat de producttitel, die het LCP-element was, dynamisch veranderde. Dit script blokkeerde het renderen lang genoeg om LCP in de categorie "slecht" te duwen. Het pauzeren van de test loste het probleem onmiddellijk op, wat bewijst dat LCP-optimalisatie vereist dat er verder wordt gekeken dan alleen het LCP- element zelf.

In CoreDash kun je bijvoorbeeld naar de LCP-pagina navigeren en een gegevenstabel bekijken die je traagste LCP-elementen toont. Door op een specifiek element te klikken (zoals een bepaalde CSS-klasse voor een hero- afbeelding), kun je alle statistieken filteren om de prestatiegegevens te zien voor alleen pagina's waar dat element de LCP was.

Of je nu een aangepaste oplossing gebruikt of een tool zoals CoreDash, het doel is hetzelfde: gebruik field data om je traagste pagina te vinden en het meest voorkomende LCP-element te identificeren. Zodra je dat doel hebt, ben je klaar om te diagnosticeren.

Stap 2: Diagnoseer het knelpunt met Lab Tools

Nu je weet welke pagina je moet repareren, is het tijd om uit te zoeken waarom deze traag is. Dit is waar een lab-tool zoals PageSpeed Insights of het Lighthouse-paneel in Chrome DevTools essentieel wordt [3].

Voer een test uit op je doel-URL. Scroll in het rapport naar de sectie "Diagnostiek" en zoek de audit "Largest Contentful Paint-element". Deze watervalgrafiek splitst je LCP-tijd op in zijn vier subonderdelen. Je RUM-tool zou een vergelijkbare uitsplitsing moeten tonen op basis van je field data.

Je doel is om de langste fase in deze uitsplitsing te vinden. Dat is je primaire knelpunt, en daarop moet je je optimalisatie-inspanningen als eerste richten.

Stap 3: Het echte knelpunt begrijpen

In de meeste real-world scenario's komen de belangrijkste en meest hardnekkige LCP-problemen voort uit een van de andere drie fasen.

• Time to First Byte (TTFB): Dit is de niet over te slaan basis. Een trage server- reactie is een directe, milliseconde-voor-milliseconde toevoeging aan je LCP. Voordat je ook maar één afbeelding optimaliseert, moet je ervoor zorgen dat je server snel reageert.
• Resource Load Delay: Dit is het "ontdekkingsprobleem" en een van de meest voorkomende problemen. De browser kan een bron die hij niet kent niet downloaden. Als je LCP-afbeelding verborgen is in een CSS- of JavaScript-bestand, of zelfs als deze in de HTML staat maar andere bronnen eerst worden aangevraagd, vindt de browser deze te laat, wat kostbare tijd verspilt.
• Element Render Delay: Dit is het "te druk om te schilderen" probleem. Het LCP-afbeeldings- bestand is misschien volledig gedownload, maar als de main thread van de browser wordt geblokkeerd door zware JavaScript- uitvoering, kan hij er gewoon niet aan toekomen om de afbeelding op het scherm te schilderen.

De volgende gids is gestructureerd om deze fasen in een logische volgorde aan te pakken. Begin altijd met ervoor te zorgen dat je TTFB snel is en je LCP-bron vindbaar is voordat je doorgaat naar bestandsgrootte en render- optimalisaties.

Stap 4: Voer de oplossing uit

Met het knelpunt geïdentificeerd, kun je gerichte optimalisaties toepassen. De manier waarop je deze oplossingen implementeert, hangt sterk af van de architectuur van je site. We behandelen eerst de universele principes voor elke fase, en geven vervolgens specifiek advies voor WordPress en moderne JavaScript-frameworks.

1. Optimaliseren van Time to First Byte (TTFB)

Als je TTFB traag is (een goed doel is onder de 800ms [4]), legt dit een hoge basis voor je LCP. Het verbeteren van TTFB zal elke andere laadmetriek verbeteren. Dit is de tijd die de browser nodig heeft om de eerste byte HTML van je server te ontvangen.

Universele TTFB-oplossingen

• Schakel caching in: Dit is een van de meest effectieve manieren om TTFB te verbeteren. Caching genereert en slaat een kopie van de pagina op zodat deze direct kan worden geserveerd zonder te wachten tot de server deze bij elk bezoek helemaal opnieuw opbouwt.
• Gebruik een CDN: Een Content Delivery Network serveert je inhoud vanaf een server fysiek dicht bij je gebruiker, wat de netwerklatentie vermindert [5]. Het cachen van je volledige HTML-pagina's aan de edge van het CDN is een krachtige strategie voor een snelle, wereldwijde TTFB.
• Gebruik Brotli- of Gzip-compressie: Zorg ervoor dat je server op tekst gebaseerde activa zoals HTML, CSS en JavaScript comprimeert. Brotli biedt betere compressie dan Gzip en moet de voorkeur krijgen.
• Gebruik HTTP/3 met 0-RTT: Zorg ervoor dat je server is geconfigureerd om HTTP/3 te gebruiken. Het biedt aanzienlijke prestatievoordelen, waaronder betere multiplexing. Cruciaal is dat het 0-RTT (Zero Round Trip Time Resumption) ondersteunt, wat de verbindingsopbouwtijd voor terugkerende bezoekers elimineert, wat een directe TTFB-boost geeft [6].
• Gebruik 103 Early Hints: Voor een geavanceerde boost, gebruik de 103 Early Hints status- code. Hiermee kan je server of CDN hints over kritieke CSS- en JS-bestanden naar de browser sturen terwijl deze nog steeds het volledige HTML-document voorbereidt, waardoor downloads nog eerder kunnen beginnen [7]. Dit is een krachtige functie op serverniveau die elk platform ten goede kan komen.

Platform-specifieke TTFB-oplossingen

Op WordPress:

• Investeer in kwaliteitshosting: Op WordPress is trage TTFB vaak gerelateerd aan de hostingsomgeving. Goedkope, gedeelde hosting kan een knelpunt zijn. Overweeg een beheerde WordPress- host die is geoptimaliseerd voor prestaties.
• Gebruik een caching-plug-in: Een caching-plug-in van hoge kwaliteit (bijv. WP Rocket, W3 Total Cache) is ononderhandelbaar. Het verwerkt het genereren van statische HTML-bestanden voor je, wat de kern is van effectieve caching op dit platform.

Op een JS-framework:

• Kies het juiste hostingplatform: Voor Node.js-applicaties zijn platforms zoals Vercel of Netlify sterk geoptimaliseerd voor SSR/SSG-frameworks en bieden ze intelligente caching en serverless functie-uitvoering out of the box.
• Implementeer SSR-caching: Als je Server-Side Rendering gebruikt, cache de gerenderde pagina's dan op de server (bijv. met Redis of een in-memory cache) om opnieuw renderen bij elk verzoek te voorkomen.
• Pas op voor Serverless Cold Starts: Als je serverless functies gebruikt voor rendering, wees je er dan van bewust dat een "koude start" (het eerste verzoek na een periode van inactiviteit) een hoge TTFB kan hebben. Gebruik provisioned concurrency of keep-alive strategieën om dit te verminderen.

2. Resource Load Delay verminderen

Dit is vaak het grootste knelpunt. Het betekent dat de browser klaar was om te werken, maar dat hij je hoofdafbeelding of lettertypebestand niet meteen kon vinden. Deze vertraging wordt meestal veroorzaakt door een van de twee problemen: de bron wordt laat ontdekt, of hij krijgt een lage downloadprioriteit.

Universele Load Delay Oplossingen

De universele oplossing voor Resource Load Delay is om ervoor te zorgen dat je LCP-bron zowel vindbaar is in de initiële HTML-markup als een hoge prioriteit krijgt van de browser. Hier is hoe je dat bereikt:

• Maak de LCP-bron vindbaar: De belangrijkste stap is ervoor te zorgen dat je LCP-element aanwezig is in de HTML die de server verzendt. Browsers gebruiken een snelle "preload scanner" om vooruit te kijken in de ruwe HTML naar bronnen zoals afbeeldingen en scripts om te downloaden. Als je LCP-afbeelding wordt geladen via een CSS `background-image` of wordt geïnjecteerd met JavaScript, is deze onzichtbaar voor deze scanner, wat een grote vertraging veroorzaakt. De meest robuuste oplossing is altijd om een standaard <img>-tag te gebruiken met een `src`-attribuut in je door de server gerenderde HTML.
• Bepaal de laadvolgorde met `preload`: Als je de LCP-bron niet direct vindbaar kunt maken (een veelvoorkomend probleem met lettertypen of CSS-achtergrondafbeeldingen), is de op één na beste oplossing om <link rel="preload"> te gebruiken. Deze tag fungeert als een expliciete instructie in je HTML <head>, die de browser vertelt om te beginnen met het downloaden van een kritieke bron veel eerder dan hij deze op natuurlijke wijze zou hebben gevonden. Dit is essentieel voor het wijzigen van de absolute laadvolgorde, zodat je LCP-afbeelding of lettertype in de wachtrij wordt geplaatst vóór minder kritieke bronnen zoals asynchrone JavaScript-bestanden.
• Zorg voor hoge prioriteit met `fetchpriority`: Zelfs wanneer een bron vindbaar is, geeft de browser deze misschien niet de hoogste downloadprioriteit. Het toevoegen van fetchpriority="high" aan je <img>-tag of je <link rel="preload">-tag is een krachtige hint voor de browser dat deze specifieke bron de belangrijkste is voor de gebruikerservaring, waardoor het de race om bandbreedte wint tegen andere bronnen [8].

Platform-specifieke Load Delay Fixes

Op WordPress:

• Vermijd Page Builder Achtergrondafbeeldingen: Veel paginabouwers maken het gemakkelijk om een hero-afbeelding in te stellen als een CSS `background-image` op een `div`. Dit maakt het onzichtbaar voor de preload scanner van de browser. Gebruik indien mogelijk een standaard ``-blok. Zo niet, heb je misschien een plug-in of aangepaste code nodig om die specifieke afbeelding te `preloaden`.
• Schakel Lazy-Loading uit voor de LCP-afbeelding: Veel optimalisatie-plug-ins zullen automatisch alle afbeeldingen lazy-loaden. Je moet de instelling in je plug-in vinden om de LCP- afbeelding (en vaak de eerste paar afbeeldingen op de pagina) uit te sluiten van lazy-loading.

Op een JS-framework:

• Gebruik Server-Side Rendering (SSR): Dit is vaak de meest impactvolle oplossing. Een standaard Client-Side Rendered (CSR) React-app verzendt minimale HTML, en het LCP-element bestaat alleen nadat een grote JS-bundel is gedownload en uitgevoerd. SSR-frameworks zoals Next.js of Remix leveren de volledige HTML, inclusief de ``-tag, zodat de browser deze onmiddellijk kan ontdekken.
• Gebruik Framework-specifieke afbeeldingscomponenten: Frameworks zoals Next.js bieden een ` `-component met een `priority`-prop. Gebruik ` ` past automatisch `fetchpriority="high"` en andere optimalisaties toe op je LCP-afbeelding.

3. Resource Load Time verminderen

Ervoor zorgen dat je LCP-bron zo klein mogelijk is, is nog steeds een cruciaal onderdeel van het proces. Deze fase gaat over hoe lang het duurt om het LCP-bronbestand over het netwerk te downloaden.

Universele Load Time Oplossingen

• Verminder bestandsgrootte met moderne formaten en responsive afbeeldingen: De meest directe manier om de downloadtijd te verkorten, is door het bestand kleiner te maken. Voor afbeeldingen betekent dit het gebruik van moderne, zeer efficiënte formaten zoals AVIF of WebP [9]. Cruciaal is dat je ook responsive afbeeldingen serveert met behulp van het <picture>-element of de srcset en sizes-attributen. Dit zorgt ervoor dat een gebruiker op een mobiel apparaat een afbeelding ontvangt die passend is afgestemd op zijn kleinere scherm, in plaats van te worden gedwongen een enorme afbeelding op desktopformaat te downloaden. Een mobiel scherm van 400 pixels breed heeft gewoon geen afbeeldings- bestand van 2000 pixels breed nodig. Voor op tekst gebaseerde LCP's, zorg ervoor dat je lettertypen in het efficiënte WOFF2-formaat zijn en zijn gesubset om ongebruikte tekens te verwijderen.
• Verminder netwerkstrijd: De LCP-bron moet concurreren om de beperkte netwerkbandbreedte van de gebruiker. Het uitstellen van niet-kritieke bronnen, zoals analysescripts of CSS voor inhoud onder de vouw, maakt bandbreedte vrij zodat de browser zich kan concentreren op het downloaden van de LCP- bron sneller.
• Host kritieke bronnen op je hoofddomein: Vermijd het laden van je LCP-bron van een ander domein indien mogelijk. Het opzetten van een nieuwe verbinding met een andere server voegt tijdrovende DNS-lookups en handshakes toe.

Platform-specifieke Load Time Fixes

Op WordPress:

• Gebruik een afbeeldingsoptimalisatie-plug-in: Tools zoals ShortPixel of Smush kunnen afbeeldingen automatisch comprimeren bij het uploaden, ze converteren naar moderne formaten zoals WebP/AVIF, en responsive `srcset`-formaten genereren.
• Handmatig formaat wijzigen afbeeldingen: Formaat wijzigen afbeeldingen voordat je ze uploadt, zodat ze niet groter zijn dan ze moeten zijn. Upload geen afbeelding van 4000px breed voor een ruimte die slechts 1200px breed is op de grootste schermen.

Op een JS-framework:

• Gebruik een Image CDN: Dit is een krachtige oplossing. Diensten zoals Cloudinary, Imgix, of Akamai's Image & Video Manager kunnen het hele optimalisatieproces automatiseren. Je uploadt één afbeelding van hoge kwaliteit, en zij leveren een perfect op maat gemaakte, gecomprimeerde en geformatteerde versie aan elke gebruiker via een snel CDN.
• Gebruik bouwtools: Wanneer je een afbeelding `import` in een component in een modern framework, kan de bouwtool (zoals Webpack of Vite) het bestand automatisch hashen en optimaliseren als onderdeel van het bouwproces.

4. Verkorten van Element Render Delay

De bron is gedownload, maar staat nog niet op het scherm. Dit betekent dat de main thread van de browser bezig is met andere taken en het element niet kan schilderen. Dit is een ander heel gewoon en belangrijk knelpunt.

Universele Render Delay Oplossingen

• Unused JavaScript uitstellen of verwijderen: Elke JS die niet essentieel is voor rendering van het initiële, zichtbare deel van de pagina moet worden uitgesteld met behulp van de defer of async attributen.
• Gebruik Critical CSS: Een grote, render-blocking stylesheet kan het renderen vertragen. De critical CSS-techniek omvat het extraheren van de minimale CSS die nodig is om de boven-de-vouw inhoud te stylen, deze inlined in de <head>, en laadt de rest van de stijlen asynchroon [10].
• Breek lange taken op: Een langlopend script kan de main thread blokkeren voor een langere periode, waardoor rendering wordt voorkomen. Dit is ook een hoofdoorzaak van slechte Interaction to Next Paint (INP). Breek je code op in kleinere, asynchrone brokken die teruggeven aan de main thread.

Platform-specifieke Render Delay Fixes

Op WordPress:

• Audit van je plug-ins: Te veel plug-ins, vooral zware zoals sliders of complexe paginabouwers, kunnen aanzienlijke CSS en JS toevoegen die de main thread blokkeren. Deactiveer plug-ins één voor één om prestatievreters te identificeren.
• Gebruik een lichtgewicht thema: Een opgeblazen thema met tientallen functies die je niet gebruikt kan een belangrijke bron zijn van render-blocking code. Kies een prestatiegericht thema.
• Gebruik Plugin Asset Managers: Tools zoals Asset CleanUp of Perfmatters stellen je in staat om voorwaardelijk CSS en JS van specifieke plug-ins uit te schakelen op pagina's waar ze niet nodig zijn.

Op een JS-framework:

• Code Splitting is de sleutel: Verzend niet al je app's JavaScript in één gigantische bundel. Splits je code per route (zodat gebruikers alleen de code downloaden voor de pagina die ze bezoeken) en per component.
• Lazy Load Components: Gebruik `React.lazy` en `Suspense` om componenten lazy-loaden die niet onmiddellijk zichtbaar zijn (bijv. componenten onder de vouw of in modals). Dit houdt ze uit de initiële bundel.

Geavanceerd: LCP optimaliseren voor volgende navigaties

Het repareren van de initiële LCP is cruciaal, maar je kunt een dramatisch snellere ervaring voor gebruikers creëren als ze door je site bladeren door te optimaliseren voor volgende pagina-ladingen.

Zorg ervoor dat pagina's in aanmerking komen voor de Back/Forward Cache (bfcache)

De bfcache is een browseroptimalisatie die een volledige momentopname van een pagina in het geheugen opslaat wanneer een gebruiker wegnavigeert. Als ze op de terugknop klikken, kan de pagina onmiddellijk worden hersteld, wat resulteert in een bijna-nul LCP. Veel pagina's komen niet in aanmerking voor deze cache vanwege zaken als `unload` event listeners. Gebruik de Lighthouse "bfcache" audit om je pagina's te testen en blokkerende functies te verwijderen [11].

Gebruik de Speculation Rules API voor Prerendering

De Speculation Rules API is een nieuwe, krachtige tool waarmee je de browser declaratief kunt vertellen naar welke pagina's een gebruiker waarschijnlijk als volgende zal navigeren. De browser kan deze pagina's dan ophalen en pre-renderen op de achtergrond. Wanneer de gebruiker op een link naar een prerendered pagina klikt, is de navigatie onmiddellijk, wat leidt tot een fenomenale gebruikerservaring en een bijna-nul LCP [12]. Je kunt definiëren deze regels in een `<script type="speculationrules">`-tag in je HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Dit voorbeeld vertelt de browser om te zoeken naar links op de huidige pagina die naar productpagina's gaan en om te beginnen met het prerenderen ervan wanneer een gebruiker over de link zweeft.

Door methodisch deze vier fasen te doorlopen en geavanceerde navigatie-optimalisaties te overwegen, kun je de exacte oorzaak van je LCP-problemen opsporen en de juiste, high-impact fix toepassen.

Referenties

1. [url=https://web.dev/articles/lab-and-field-data]web.dev: Lab and field data[/url]
2. [url=https://developer.chrome.com/docs/devtools/performance/debug-web-vitals]Chrome for Developers: Debug Web Vitals in the field[/url]
3. [url=https://web.dev/articles/optimize-lcp]web.dev: Optimize Largest Contentful Paint[/url]
4. [url=https://web.dev/articles/optimize-ttfb]web.dev: Optimize for a good TTFB[/url]
5. [url=https://www.cloudflare.com/learning/cdn/what-is-a-cdn/]Cloudflare: What is a CDN?[/url]
6. [url=https://web.dev/articles/http3]web.dev: HTTP/3[/url]
7. [url=https://web.dev/articles/103-early-hints]web.dev: Slower is faster? Sending an HTTP 103 response to speed up your site[/url]
8. [url=https://web.dev/articles/lcp-fetchpriority]web.dev: Optimize LCP with fetchpriority[/url]
9. [url=https://web.dev/articles/serve-images-in-modern-formats]web.dev: Use modern image formats[/url]
10. [url=https://web.dev/articles/extract-critical-css]web.dev: Extract critical CSS[/url]
11. [url=https://web.dev/articles/bfcache]web.dev: Back/forward cache[/url]
12. [url=https://web.dev/articles/speculation-rules]web.dev: Speculation Rules API[/url]