Optimaliseer de LCP Resource Load Duration

Optimaliseer de LCP Resource Load Duration

Largest Contentful Paint (LCP) is 1 van de 3 Core Web Vitals prestatie-metrieken die je online gebruikerservaring meten. De LCP registreert de tijd die het kost voor het grootste content-element (een afbeelding, video of tekstblok) om zichtbaar te worden in de viewport. De Resource load Duration is een sub-onderdeel van de LCP dat aangeeft hoeveel tijd er verloren gaat aan het ophalen van de netwerkbron voor het LCP-element.  Laten we diep in het resource load duration aspect van LCP duiken en de impact en optimalisatiestrategieën verkennen.

Wat is Resource Load Duration in LCP?

Resource Load Duration, vaak Load Duration genoemd, verwijst naar de tijd die de browser nodig heeft om de netwerkbron te downloaden (bijv. een afbeelding) die uiteindelijk het LCP-element zal worden. Voor afbeeldingen en video's omvat deze duur de tijd vanaf het moment dat de afbeelding begint met downloaden tot wanneer de browser het downloaden voltooit. Voor tekstgebaseerde LCP-elementen is de laadduur doorgaans nul.

Resource Load Duration wordt gemeten vanaf het moment dat de browser begint met het downloaden van de LCP-bron totdat deze het downloaden heeft voltooid. Deze meting is cruciaal omdat deze direct beïnvloedt hoe snel gebruikers de hoofdinhoud van een webpagina kunnen zien en ermee kunnen interageren. De resource load duration kan worden beïnvloed door verschillende factoren, waaronder:

• Bestandsgrootte: Grotere bestanden vereisen langere downloadtijden.
• Netwerksnelheid: Tragere verbindingen verlengen uiteraard de laadduur.
• Server Responsiviteit: Vertragingen in serverrespons vertragen het ophalen van bronnen.
• Gelijktijdige Downloads: Bronnen die tegelijkertijd worden gedownload, strijden om bandbreedte, wat de laadtijden kan verhogen.

Hoe resource load Duration te detecteren

Er zijn twee effectieve manieren om resource load duration te identificeren en te meten:

Network Inspection in Chrome DevTools: Gebruik de Ctrl + Shift + I sneltoets om Chrome's Developer Tools te openen, selecteer vervolgens het "Network" tabblad en herlaad de pagina. Zoek het LCP-element op in de netwerkverzoeken (als je het LCP-element wilt weten, probeer dan de Core Web Visualizer). De netwerk-inspector laat je zien hoe lang het duurde om de bron te downloaden.

Pro Tip: Schakel grote verzoekrijen in om extra details te zien zoals LCP-latentie, overgedragen grootte en werkelijke grootte.

Benut Real User Monitoring (RUM) Data: 

RUM-tools loggen vaak LCP-attributiedata. Attributie data voor de Largest Contentful Paint bevat informatie over de resource load delay. Deze data maakt visualisaties van laadduurtrends in de tijd of per pagina mogelijk, wat een duidelijk beeld geeft van laadtijden over de hele site. Door deze patronen te analyseren, is het mogelijk om elementen te identificeren die laadtijden kunnen vertragen en gerichte kansen voor snellere, soepelere prestaties te ontdekken.

Hoe LCP Load Duration te verbeteren

Resource load vertragingen treden op wanneer bronnen in een suboptimale volgorde of grootte worden gedownload. Twee hoofdbenaderingen om dit aan te pakken: data-grootte verminderen of data-levering optimaliseren. Hier zijn effectieve technieken en patronen om de LCP resource load duration te verbeteren:

1. Optimaliseer bestandsgrootte:

Optimaliseren van bestandsgrootte vermindert de hoeveelheid bytes die over het netwerk verzonden moet worden. Minder data betekent meestal minder downloadtijd.

Gebruik Moderne Afbeeldingsformaten: AVIF en WebP lopen voorop in compressie. AVIF biedt met name uitgebreide compressiemogelijkheden, vaak met bestandsgroottes tot 50% kleiner in vergelijking met WebP, waardoor het ideaal is voor complexe foto's zonder kwaliteitsverlies. WebP behoudt echter sterke compatibiliteit met een breder scala aan browsers en is vooral effectief voor eenvoudigere afbeeldingen.

Responsieve Afbeeldingen: Het <picture> element en srcset-attribuut maken op maat gemaakte afbeeldingen mogelijk op basis van schermgrootte, waardoor kleinere afbeeldingsversies voor mobiel en hoge-resolutie versies voor grotere schermen mogelijk zijn. Hier is een voorbeeldopstelling:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" loading="lazy" alt="Beschrijving">
</picture>

Juiste Afbeeldingsafmetingen: Responsieve afbeeldingen zijn slechts een deel van de oplossing omdat responsief niet betekent dat ze de juiste grootte hebben. Afbeeldingsafmetingen afstemmen op hun weergavegrootte is een van de meest voorkomende fouten die ik zie. Het serveren van een 2000px-brede afbeelding voor een 500px weergavegebied verspilt bandbreedte en kan laadtijden merkbaar vertragen.

2. Verbeter netwerkprestaties: 

Zodra netwerkgroottes van bronnen geoptimaliseerd zijn, is de volgende stap het maximaliseren van de netwerksnelheid—of zelfs het volledig omzeilen van het netwerk. Dit kan worden bereikt door:

Omzeil Netwerkbehoeften: Er is geen snellere netwerkverbinding dan een overgeslagen netwerkverbinding. Browsers hebben de optie om statische (onveranderlijke) inhoud zoals afbeeldingen, scripts en stylesheets direct vanuit de lokale browsercache te serveren. Configureer de server om de juiste caching-instructies naar de browser te sturen. Bijvoorbeeld met de expires header.

De meest effectieve set-up om een Cache-Control header te sturen is als volgt:

Cache-Control: public, max-age=31536000, immutable

• public: Staat toe dat de bron gecacht wordt door zowel browsers als tussenliggende caches.
• max-age=31536000: Stelt de maximale tijd dat de bron als vers wordt beschouwd in op één jaar (31.536.000 seconden).
• immutable: Geeft aan dat de bron in de loop van de tijd niet zal veranderen, wat onnodige revalidatieverzoeken voorkomt.

HTTP/3: Het nieuwste HTTP/3 protocol kan netwerkprestaties verbeteren door latentie te verminderen en packet loss efficiënter af te handelen dan traditionele TCP. (HTTP/3 heeft nog meer voordelen, vooral als het gaat om de Time to Fist Byte) 

Om te controleren of HTTP/3 is ingeschakeld, inspecteer je eenvoudig je netwerk met de Ctrl-Shift-I sneltoets. Selecteer het netwerk-tabblad, klik met de rechtermuisknop op de netwerkkolommenkoppen en zorg ervoor dat 'protocol' is ingeschakeld. Herlaad de pagina en controleer het protocol. Voor HTTP/3 moet het protocol 'h3' aangeven

Self-Hosting van Bronnen: Belangrijke en/of vroege netwerkbronnen moeten standaard altijd gehost worden op de origin server.  Self-hosting omzeilt de noodzaak om verbinding te maken met servers van derden, wat aanzienlijke vertraging kan veroorzaken door extra DNS-lookups, SSL-onderhandelingen en verbindingsopzet. Self-hosting zorgt voor hergebruik van een enkele, al open verbinding en vermindert de overhead van het opzetten van afzonderlijke verbindingen. Self-hosted bronnen maken ook volledige controle over compressie en cachebeleid mogelijk.

Gebruik een CDN: Een Content Delivery Network (CDN) is een netwerk van gedistribueerde servers die statische bronnen zoals afbeeldingen, CSS en JavaScript cachen en serveren vanaf locaties dichter bij de gebruiker. Dit vermindert de datareistijd (de round-trip-time) wat direct invloed heeft op de Resource Load Duration. Daarnaast bieden veel CDN's ook meer voordelen zoals beeldcompressie, superieure netwerkconfiguraties (zoals HTTP/3 & 0-RTT) en nog veel meer. Gespecialiseerde Image CDN's kunnen dit verder brengen door automatische, real-time optimalisaties te bieden zoals formaatconversie, resizing en compressie.

3. Optimaliseer Bronprioritering

Na het trimmen van de brongrootte en het optimaliseren van het netwerk is er ook de kwestie van netwerkcompetitie. Wanneer meerdere bronnen tegelijkertijd worden aangevraagd onder slechte netwerkomstandigheden, kan dit de downloadtijd van bronnen aanzienlijk vertragen. Daarom is het zinvol om netwerkcompetitie te minimaliseren door het downloaden van bronnen te plannen.

Prioriteer Kritieke Bronnen: Markeer essentiële bronnen, zoals hero-afbeeldingen of above-the-fold CSS, met fetchpriority="high". Dit signaleert de browser om deze assets eerst te downloaden, zodat ze niet worden opgehouden door scripts, widgets of elementen van derden die niet direct geladen hoeven te worden. Het prioriteren van deze kritieke bronnen vermindert de laadtijd voor de inhoud waar je gebruikers het meest om geven. De combinatie van preload (om late ontdekking op te lossen) en fetchpriority="high" (om netwerkconflict op te lossen) is de krachtigste techniek om ervoor te zorgen dat de LCP-bron zo vroeg en zo snel mogelijk wordt opgehaald.

<!-- Voor LCP-afbeeldingen zichtbaar in de initiële HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Om ontdekking te verbeteren  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Verminder Netwerkconflict: Stroomlijn initiële downloads door niet-essentiële assets uit te stellen of lui te laden (lazy-loading). Stel het laden uit voor afbeeldingen of video's die niet direct zichtbaar zijn, evenals achtergrond- of secundaire elementen. Het gebruik van loading="lazy" voor offscreen media is een goede plek om te beginnen, terwijl het verder uitstellen van andere niet-essentiële scripts en assets bandbreedte vrijmaakt en eventuele concurrentie met je kritieke bronnen vermindert, waardoor de hoofdinhoud van je pagina snel laadt en wordt weergegeven. Pas nooit loading="lazy" toe op je LCP-afbeelding; dit is een kritiek anti-patroon dat je score zal schaden.

4. Stel speculatieregels in

Speculation Rules stelt browsers in staat om webpagina's vooraf te halen (prefetch) of vooraf te renderen (prerender) op basis van voorspelde gebruikersnavigatie. Prefetching elimineert effectief het Time to First Byte sub-onderdeel van de LCP en heeft geen impact op de resource load duration. Prerendering rendert de volgende pagina in een verborgen tabblad en downloadt alle paginabronnen.  Dit elimineerde de meeste laadduur voor het LCP-element zoals getoond in dit voorbeeld LCP-breakdown van een vooraf gerenderde pagina.