De LCP Resource Load Delay optimaliseren

Deze gids maakt deel uit van de Largest Contentful Paint (LCP) hub. Resource Load Delay is vaak de grootste individuele veroorzaker van een slechte LCP-score. De meeste teams richten zich op het comprimeren van afbeeldingen, terwijl het eigenlijke probleem is dat de browser de afbeelding te laat heeft gevonden.

De LCP Resource Load Delay optimaliseren

Largest Contentful Paint (LCP) bestaat uit vier fasen: TTFB, Resource Load Delay, Resource Load Duration en Element Render Delay. Ontwikkelingsinspanningen richten zich vaak op het verminderen van de Load Duration via bestandscompressie, maar dit ziet de Resource Load Delay over het hoofd, wat vaak een grotere bron van latentie is. Deze vertraging voordat de download begint, kan honderden milliseconden toevoegen aan uw LCP, waardoor deze de 'Goede' drempel van 2,5 seconden overschrijdt.

Een korte tip: als uw LCP een afbeelding is, zal het bijna altijd slechter zijn dan tekst. U moet uw LCP-elementtypen bijhouden in uw RUM-data, anders werkt u in het duister.

Precieze definitie: het kritieke wachten voor de download

Resource Load Delay is de tijd tussen de TTFB en het moment waarop de browser begint met het downloaden van de LCP-resource. Het is niet de downloadtijd; het is de ontdekkingslatentie (discovery latency) die optreedt voordat de fetch begint. Een hoge waarde hier duidt op een architectonisch probleem waarbij de browser de resource-URL niet kan vinden in de initiële HTML-payload. Deze resource load delay kan worden gezien als de tijd die de browser besteedt aan het vaststellen dat de LCP-resource nodig is en het besluit om deze op te halen.

Voor LCP-elementen die op tekst gebaseerd zijn en gerenderd worden met een systeemlettertype, is deze resource load delay doorgaans nul, omdat er geen externe bron hoeft te worden opgehaald. Hogere waarden voor de resource load delay zijn specifiek voor LCP-elementen die afhankelijk zijn van een externe netwerkbron, zoals een afbeelding of een videobestand.

De ontdekkingsmotor: Preload Scanner vs. DOM Parser

Om de Resource Load Delay te verminderen, moet u begrijpen hoe browsers bronnen ontdekken. De efficiëntie van dit ontdekkingsproces is de belangrijkste factor die de latentie bepaalt. Browsers gebruiken twee mechanismen: een snel pad en een langzaam pad.

• De Preload Scanner (het snelle pad): Dit is een secundaire parser op hoge snelheid die de ruwe HTML scant op resource-URL's, zoals die in <img>- of <link>-tags. Het plaatst ze onmiddellijk in de wachtrij voor download, nog voordat de CSS is geparst of JavaScript is uitgevoerd. Dit is het optimale pad voor elke kritieke bron.
• De DOM Parser (het langzame pad): Dit is de hoofd-parser die het volledige Document Object Model (DOM) en CSS Object Model (CSSOM) opbouwt. Bronnen die niet in de initiële HTML worden gevonden, zoals een CSS background-image of een door JavaScript geïnjecteerd element, worden alleen door deze parser ontdekt. Dit is het langzame pad omdat het afhankelijk is van het eerst downloaden en uitvoeren van andere bestanden, wat een keten van afhankelijkheden creëert die hoge latentie introduceert.

De gehele strategie voor het optimaliseren van de Resource Load Delay is gebaseerd op één principe: zorg ervoor dat de LCP resource-URL ontdekt kan worden door de preload scanner. Elk patroon dat de URL verbergt voor het initiële HTML-document dwingt de browser om het langzame ontdekkingspad te gebruiken. Deze wachtperiode vertaalt zich direct in Resource Load Delay. Elke effectieve optimalisatie gaat over het architectureren van uw HTML om de LCP-resource op het snelle pad te plaatsen. Voor een volledige gids over de prioritisering van browserbronnen, zie ons artikel over resource prioritization.

Waarom Load Delay belangrijk is

Een veelvoorkomend misverstand is dat een trage LCP een "bestandsgrootte"-probleem is. Dit leidt ertoe dat teams zich alleen richten op beeldcompressie om de Resource Load Duration te verkorten. Hoewel de optimalisatie van assets een factor is, laat analyse van praktijkgegevens uit het veld zien dat voor veel sites met een slechte LCP de Resource Load Delay de primaire bottleneck is, niet de Resource Load Duration.

Veldgegevens laten zien dat de gemiddelde site met een slechte LCP-score een Resource Load Delay van 1,3 seconde heeft. Dat is meer dan de helft van het gehele budget van 2,5 seconde voor een 'Goede' LCP-score, allemaal verbruikt voordat de download van de LCP-resource zelfs maar begint. De gegevens geven aan dat deze sites bijna vier keer zo lang wachten op het begin van de download als dat ze aan de download zelf besteden.

Deze gegevens leggen een frequente verkeerde focus van de ontwikkelingsinspanning bloot. Teams kunnen weken besteden aan het verwijderen van kilobytes uit afbeeldingen om de Load Duration met een paar milliseconden te verkorten, terwijl een architectonisch probleem dat een Load Delay van 1,5 seconde veroorzaakt, onbehandeld blijft. LCP is een sequentieel proces; een vertraging in een vroege fase kan niet worden ingehaald door een latere fase te optimaliseren. Als een fetch meer dan een seconde vertraging oploopt, is een verschil van 100 ms in downloadtijd irrelevant voor de uiteindelijke LCP-score. De optimalisaties met de grootste impact omvatten architectonische wijzigingen, zoals het verbeteren van de ontdekbaarheid van bronnen, en niet alleen compressie van assets. De focus moet verschuiven van het kleiner maken van assets naar ervoor zorgen dat ze eerder worden ontdekt.

Hoe Resource Load Delay te detecteren

Om de Resource Load Delay te verhelpen, moet u deze eerst nauwkeurig meten. De professionele workflow is om eerst het probleem te definiëren met echte gebruikersgegevens (RUM), en pas daarna over te stappen op Chrome DevTools voor diepgaande analyse.

Stap 1: Analyseer veldgegevens (RUM)

Veldgegevens, of Real User Monitoring (RUM), worden verzameld uit daadwerkelijke gebruikerssessies. RUM-tools, zoals het publieke Chrome User Experience Report (CrUX) of mijn eigen tool, CoreDash, beantwoorden de vraag: Wat gebeurt er in de echte wereld? Een volwaardige RUM-tool biedt ook een uitsplitsing van de LCP-subonderdelen, waarbij u de mediane Resource Load Delay voor uw gebruikers te zien krijgt. Deze gegevens valideren dat er een LCP-probleem bestaat, laten zien welke URL's worden beïnvloed en onthullen de veelvoorkomende LCP-elementen die uw gebruikers daadwerkelijk zien. U moet hier beginnen om te bevestigen dat u een echt probleem aan het oplossen bent.

Stap 2: Diagnose stellen met DevTools

Zodra uw RUM-gegevens een doelpagina en LCP-element hebben geïdentificeerd, gebruikt u Chrome DevTools om de oorzaak te diagnosticeren. Het doel hier is om het probleem te reproduceren en de LCP-subonderdelen te meten om een nauwkeurige waarde voor de Resource Load Delay te krijgen. DevTools is ook de plek waar u een Main Thread Analyse uitvoert om precies te zien welke taken er draaien en mogelijk het renderproces blokkeren.

Een stapsgewijze handleiding voor het Chrome DevTools Performance-paneel

Het Performance-paneel in Chrome DevTools is een onmisbaar hulpmiddel voor het ontleden van LCP en het kwantificeren van laadvertraging.

1. Opzet en configuratie:

• Open Chrome DevTools door met de rechtermuisknop op de pagina te klikken en "Inspecteren" te selecteren of door de sneltoets Ctrl+Shift+I (Windows/Linux) of Cmd+Option+I (Mac) te gebruiken.
• Navigeer naar het tabblad Performance.
• Zorg ervoor dat het selectievakje Web Vitals is ingeschakeld in de opname-instellingen. Dit zal Core Web Vitals-informatie over de performance-trace leggen.
• Configureer Throttling: Om een mobiele ervaring op een desktop-machine te simuleren, stelt u CPU-throttling in op "4x slowdown" en Network-throttling op "Fast 3G" of "Slow 3G". Dit is cruciaal omdat Load Delay vaak groter wordt op tragere verbindingen waar de ontdekking van bronnen meer tijd in beslag neemt.

2. De trace opnemen:

• Klik op het pictogram "Reload" (de ronde pijl) in het Performance-tabblad. Dit zal de pagina verversen en de performance-gegevens vastleggen vanaf het begin van de navigatie.
• Wacht tot de pagina volledig is geladen en de trace is verwerkt.

3. De resultaten analyseren:

• Zoek de "Interactions" en "Network" tracks in de trace.
• Zoek in de track "Network" de resource die is geïdentificeerd als het LCP-element.
• Klik op het LCP-markeringspunt in de track "Timings". Hierdoor wordt het tabblad "Summary" onderaan gevuld met een gedetailleerde uitsplitsing van de LCP-timing.
• Zoek naar de waarde "Load Delay". Dit is de tijd die u wilt minimaliseren.

Veelvoorkomende oorzaken van Resource Load Delay en hun oplossingen

Verschillende patronen in webontwikkeling kunnen onbedoeld de LCP-resource verbergen voor de browser, wat leidt tot aanzienlijke vertragingen.

Oorzaak: CSS Background-Images

Het probleem: Browsers geven de hoogste prioriteit aan bronnen die direct in de HTML worden ontdekt (zoals <img>-tags) door hun preload scanner. Wanneer een afbeelding wordt geladen via een CSS background-image, is de URL onzichtbaar voor deze snelle scanner. De browser kan de afbeelding pas ontdekken na het downloaden van de HTML, het vinden van de CSS-bestandslink, het downloaden van het CSS-bestand, het opbouwen van het CSSOM en het vervolgens toepassen van de stijl. Deze afhankelijkheidsketen veroorzaakt direct een hoge Resource Load Delay. Voor meer informatie over dit patroon, zie onze gids over het uitstellen van achtergrondafbeeldingen.

De oplossing: De juiste implementatie is om het gebruik van background-image te vermijden voor kritieke LCP-elementen. Gebruik in plaats daarvan een standaard <img>-tag. Dit plaatst de afbeelding-URL direct in de HTML waar de preload scanner deze onmiddellijk kan vinden. U kunt hetzelfde visuelle resultaat bereiken met CSS.

Implementatievoorbeeld:

Anti-patroon (doe dit niet):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Best Practice (doe dit in plaats daarvan):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Een beschrijvende alt-tekst voor de hero-afbeelding"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Paginatitel</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; \/* Gelijk aan top: 0; right: 0; bottom: 0; left: 0; *\/
      width: 100%;
      height: 100%;
      object-fit: cover; \/* Deze eigenschap bootst background-size: cover na *\/
      z-index: -1; \/* Plaatst de afbeelding achter andere inhoud *\/
    }
    

Deze implementatie levert hetzelfde visuele resultaat op, maar zorgt ervoor dat de LCP-afbeelding op het vroegst mogelijke moment ontdekt kan worden, wat de laadvertraging minimaliseert.

Oorzaak: Client-Side Rendering en JavaScript-injectie

Het probleem: Applicaties die client-side rendering (CSR) frameworks zoals React of Vue gebruiken, serveren vaak een minimale HTML-shell. De eigenlijke inhoud, inclusief de LCP <img>-tag, wordt pas door JavaScript in de DOM geplaatst nadat grote framework-bundles zijn gedownload, geparst en uitgevoerd. Dit proces verbergt de LCP-resource fundamenteel voor de preload scanner, wat zorgt voor een hoge ontdekkingslatentie.

De oplossing: De meest effectieve oplossing is om de initiële rendering van de client naar de server te verplaatsen.

• Server-Side Rendering (SSR) of Static Site Generation (SSG): Architecturale patronen zoals SSR of SSG genereren de volledige HTML op de server. De browser ontvangt een compleet document met de <img>-tag en het bijbehorende src-attribuut, waardoor de LCP-resource onmiddellijk ontdekt kan worden door de preload scanner. Dit is de vereiste architectuur voor elke prestatiekritieke pagina.
• Framework-specifieke optimalisaties: Moderne frameworks bieden ook ingebouwde optimalisaties. Het Next.js <Image>-component heeft bijvoorbeeld een priority-property. Door dit op true in te stellen, krijgt het framework de instructie om automatisch de juiste <link rel="preload">- en fetchpriority="high"-attributen toe te voegen, zodat de afbeelding wordt ontdekt en opgehaald met de juiste prioriteit.

Oorzaak: Het gebruik van loading="lazy" op de LCP-afbeelding

Het probleem: Dit is een veel voorkomende fout met een grote impact. Het loading="lazy"-attribuut is een directe instructie aan de browser om het ophalen van een afbeelding uit te stellen totdat deze dicht bij het viewport is. Hoewel dit de juiste optimalisatie is voor afbeeldingen "onder de vouw" (below-the-fold), is het toepassen ervan op een LCP-element "boven de vouw" contraproductief. De preload scanner van de browser is ontworpen om afbeeldingen met loading="lazy" te negeren, wat een late ontdekking en een hoge Resource Load Delay garandeert.

De oplossing: De oplossing vereist nauwkeurigheid.

• Verwijder loading="lazy" van de LCP-afbeelding: Elke afbeelding die waarschijnlijk het LCP-element is, mag niet het loading="lazy"-attribuut hebben. Het standaardgedrag van de browser is loading="eager", wat de juiste instelling is voor kritieke inhoud boven de vouw. Het volledig weglaten van het loading-attribuut heeft hetzelfde effect.
• Controleer en configureer tools van derden: U moet ook tools van derden controleren. Veel CMS-platforms zoals WordPress en diverse plugins voor beeldoptimalisatie passen automatisch lazy loading toe op alle afbeeldingen. Het is essentieel om deze tools zo te configureren dat ze de LCP-afbeelding uitsluiten van dit gedrag. Dit houdt vaak in dat u een uitsluitingsregel maakt voor de eerste één of twee afbeeldingen op de pagina.

Oorzaak: Suboptimale HTML-structuur en grote documenten

Het probleem: De preload scanner verwerkt het HTML-document van boven naar beneden. Als niet-kritieke maar bandbreedte-intensieve bronnen, zoals header-iconen of chat-widget scripts, hoger in de <body> worden geplaatst dan het LCP-element, worden ze als eerste ontdekt en in de wachtrij geplaatst voor download. Dit verbruikt de initiële netwerkbandbreedte en kan de download van de LCP-resource vertragen. Een groot HTML-document kan ook een probleem zijn; als het LCP-element niet in de eerste databrok zit die de browser ontvangt (ongeveer 14KB), wordt de ontdekking ervan met ten minste één netwerk-round-trip vertraagd.

De oplossing: Optimaliseer de structuur en prioriteit van de inhoud binnen de HTML.

• Herschik de HTML: Zorg er indien mogelijk voor dat de <img>-tag of het tekstblok voor het LCP-element zo vroeg mogelijk in de <body>-tag verschijnt.
• Geef niet-kritieke afbeeldingen een lagere prioriteit: Voor niet-essentiële afbeeldingen die vroeg in de HTML-bron moeten verschijnen (zoals iconen in een header), past u loading="lazy" toe. Dit vertelt de preload scanner om ze over te slaan, waardoor de downloadwachtrij voor het LCP-element behouden blijft.
• Stel niet-essentiële scripts uit: Scripts voor analytics, advertenties of social media widgets zijn zelden kritiek voor de initiële rendering. Verplaats hun <script>-tags naar het einde van de <body> of gebruik het defer-attribuut. Dit voorkomt dat ze de parser blokkeren of concurreren om netwerkbandbreedte met de LCP-resource.

Geavanceerde prioritisering met Resource Hints

Zodra de LCP-resource ontdekt kan worden in de HTML, kunt u resource hints gebruiken om de browser explicietere instructies te geven over hoe deze moet worden opgehaald. Deze hints bieden fijnmazige controle over ontdekking en prioritisering.

Vroege ontdekking forceren met <link rel="preload">

<link rel="preload"> is geen hint; het is een richtlijn (directive). Het dwingt de browser om een bron met hoge prioriteit te downloaden, zelfs als deze nog niet ontdekt kan worden door de hoofd-parser. Het plaatsen ervan in de <head> van uw HTML is de meest directe manier om problemen met late ontdekking op te lossen voor bronnen zoals lettertypen, CSS background-images of LCP-afbeeldingen die zich diep in de DOM bevinden. Voor volledige implementatiedetails en voorbeelden, zie onze speciale gids over hoe de LCP-afbeelding te preloaden.

Mechanisme

Wanneer een preload-link in de <head> van het HTML-document wordt geplaatst, identificeert de preload scanner deze en plaatst de gespecificeerde bron onmiddellijk in de downloadwachtrij. Dit is ideaal voor bronnen zoals lettertypen die worden geladen via @font-face in een externe stylesheet, CSS background-image LCP's (hoewel het gebruik van een <img>-tag de voorkeur heeft), of een LCP-afbeelding die zich diep in een complexe DOM-structuur bevindt.

Responsieve preloading

Een cruciaal implementatiedetail is vereist bij het preloaden van responsieve afbeeldingen. Om ervoor te zorgen dat de browser de afbeelding met de juiste afmetingen voor het viewport van de gebruiker preloadi en een verspillende dubbele download voorkomt, moet de <link rel="preload">-tag de attributen imagesrcset en imagesizes bevatten die perfect de attributen op de bijbehorende <img>-tag spiegelen.

Voorbeeld van responsieve preloading:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="Een beschrijvende alt-tekst"
     fetchpriority="high"
     width="1200" height="675">
    

Valkuil

Preloading lost de fetch-timing op (Load Delay en Load Duration), maar niet de paint-timing. Als de main thread wordt geblokkeerd door zware JavaScript of render-blocking CSS wanneer de gepreloade afbeelding arriveert, moet de afbeelding nog steeds wachten om gerenderd te worden, wat de bottleneck kan verschuiven van Load Delay naar Element Render Delay.

fetchpriority="high" en de prioriteitswachtrij van de browser

Het fetchpriority-attribuut is een hint die de relatieve belangrijkheid van de download van een bron aangeeft. Hiermee kunt u de prioriteit van een bron binnen de downloadwachtrij van de browser beïnvloeden.

Hoe browserprioriteit werkt

Wanneer de browser bronnen ontdekt tijdens het laden van de pagina, kent hij aan elke bron een intern prioriteitsniveau toe. Standaard beginnen afbeeldingen in het viewport met een "Lage" prioriteit en worden ze later geüpgraded naar "Hoog" zodra de browser de layout voltooit en vaststelt dat ze zichtbaar zijn. Voor deze upgrade moet de browser eerst de CSS downloaden en parsen, wat voor vertraging zorgt. Het attribuut fetchpriority="high" omzeilt dit proces volledig door de afbeelding vanaf het moment van ontdekking op "Hoge" prioriteit in te stellen. Dit heeft vooral impact op LCP-afbeeldingen omdat het de vertraging voor de prioriteitsupgrade wegneemt.

preload vs. fetchpriority

Deze twee hints dienen verschillende maar complementaire doelen. preload beïnvloedt wanneer een bron wordt ontdekt en aan de wachtrij wordt toegevoegd. fetchpriority beïnvloedt het prioriteitsniveau zodra deze in de wachtrij staat. Het begrijpen van dit onderscheid is cruciaal: preload lost late ontdekking op, terwijl fetchpriority lage prioritisering oplost. Voor veel LCP-afbeeldingen die al in de HTML staan, kan fetchpriority alleen al voldoende zijn. Voor een volledige gids over hoe deze op elkaar inwerken, zie ons artikel over resource prioritization.

Best Practice voor LCP

Voor de LCP-afbeelding is de optimale strategie om ze samen te gebruiken. Zorg eerst voor vroege ontdekking, ofwel door de <img>-tag vroeg in de HTML te plaatsen, ofwel door preload te gebruiken. Voeg ten tweede fetchpriority="high" direct toe aan de <img>-tag (en de preload-link, indien gebruikt). Deze combinatie zorgt ervoor dat de bron niet alleen vroeg wordt ontdekt, maar ook de hoogst mogelijke prioriteit krijgt om de strijd om netwerkbandbreedte te winnen van andere bronnen zoals stylesheets of lettertypen.

Voorbeeld:

<img src="lcp-image.jpg" fetchpriority="high" alt="Een kritieke hero-afbeelding">

Wanneer fetchpriority="low" te gebruiken

Het fetchpriority-attribuut is niet alleen voor het verhogen van de prioriteit. U kunt ook fetchpriority="low" gebruiken om niet-kritieke bronnen die met de LCP-afbeelding om bandbreedte concurreren, een lagere prioriteit te geven. Veelvoorkomende kandidaten zijn afbeeldingen boven de vouw die niet het LCP-element zijn (zoals kleine iconen of avatars in de header), en gepreloade bronnen die wel nodig zijn maar niet urgent. Door expliciet de prioriteit van deze concurrerende bronnen te verlagen, creëert u meer bandbreedteruimte voor de LCP-afbeelding.

<!-- LCP-afbeelding: hoge prioriteit -->
<img src="hero.jpg" fetchpriority="high" alt="Hero-afbeelding" width="1200" height="600">

<!-- Niet-kritieke afbeelding boven de vouw: lage prioriteit -->
<img src="avatar.jpg" fetchpriority="low" alt="Auteur avatar" width="48" height="48">

Bewezen impact

In een case study met betrekking tot Google Flights verbeterde het toevoegen van fetchpriority="high" aan de LCP-achtergrondafbeelding de LCP-tijd van 2,6 seconden naar 1,9 seconden, een verbetering van 700 ms.

Verbindingen met derden optimaliseren: preconnect en dns-prefetch

Het probleem

Als uw LCP-resource wordt gehost op een domein van een derde partij, zoals een image CDN of een lettertypeprovider zoals Google Fonts, moet de browser een nieuwe netwerkverbinding met dat domein tot stand brengen. Dit proces omvat een DNS-lookup, een TCP-handshake en een TLS-onderhandeling, die allemaal voltooid moeten zijn voordat de eerste byte van de bron kan worden gedownload. Deze verbindingstijd draagt direct bij aan de Resource Load Delay voor assets van andere herkomst (cross-origin).

De oplossingen

• preconnect: Deze hint instrueert de browser om de volledige verbindingsopbouw (DNS, TCP en TLS) voor een gespecificeerde herkomst van een derde partij op de achtergrond en van tevoren uit te voeren. Wanneer de bron daadwerkelijk wordt aangevraagd, is de verbinding al warm, waardoor de latentie bij het opzetten wordt geëlimineerd. Dit is zeer effectief en aanbevolen voor de één of twee meest kritieke domeinen van derden die LCP-bronnen serveren.
• dns-prefetch: Dit is een lichtere hint die alleen de DNS-lookup voor een domein uitvoert. Het bespaart minder tijd dan preconnect, maar heeft een bredere browserondersteuning en is nuttig als fallback of voor minder kritieke domeinen van derden.

Best Practice voor implementatie

Om een maximale compatibiliteit te garanderen, biedt u beide hints aan. De browser zal preconnect gebruiken indien ondersteund en terugvallen op dns-prefetch indien niet. Het crossorigin-attribuut is essentieel voor bronnen die met CORS worden opgehaald, zoals lettertypen.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabel: Vergelijking van Resource Hints voor LCP-optimalisatie

Om misbruik te voorkomen en de verschillende rollen van deze krachtige hints te verduidelijken, biedt de volgende tabel een vergelijkend overzicht.

Holistische en toekomstgerichte strategieën

Naast resource hints kunnen bredere architecturale beslissingen de Resource Load Delay nog verder verminderen.

De rol van een moderne CDN

Een Content Delivery Network (CDN) is een fundamentele technologie voor webperformance die indirect maar significant de Resource Load Delay vermindert, vooral voor LCP-resources.

• Verbindings-overhead verminderen: Door assets te distribueren over een wereldwijd netwerk van servers, plaatst een CDN inhoud geografisch dichter bij de gebruiker. Dit vermindert inherent de round-trip time (RTT) die nodig is voor de DNS-lookup, TCP-handshake en TLS-onderhandeling, wat allemaal componenten zijn van de verbindingstijd. Voor een LCP-afbeelding gehost op een CDN vermindert dit direct de laadvertraging.
• Beeld-CDN's (Image CDN's): Gespecialiseerde Beeld-CDN's bieden een dubbel voordeel. Ze bieden het nabijheidsvoordeel van een standaard CDN terwijl ze ook veel complexe optimalisaties automatiseren die de Resource Load Duration verminderen, zoals on-the-fly beeldschaling, compressie en conversie naar moderne formaten zoals AVIF en WebP.
• Geavanceerde protocollen: Veel moderne CDN's gebruiken HTTP/3, dat QUIC gebruikt in plaats van TCP. HTTP/3 vermindert de tijd voor het opzetten van de verbinding en beperkt head-of-line blocking, wat leidt tot een snellere en efficiëntere levering van bronnen in het algemeen.

Vertraging volledig elimineren met Speculation Rules

De Speculation Rules API kan de LCP-vertraging volledig elimineren voor volgende navigaties.

Mechanisme

Met deze API kunnen ontwikkelaars de browser declaratief informeren over naar welke URL's een gebruiker waarschijnlijk als volgende zal navigeren. Op basis van deze regels kan de browser ervoor kiezen om een doelpagina te prerenderen in een verborgen achtergrondtabblad voordat de gebruiker zelfs maar op de link klikt.

Impact op LCP

Wanneer de gebruiker op een link naar een geprerenderde pagina klikt, is de navigatie vrijwel onmiddellijk. De pagina is al volledig geladen en gerenderd op de achtergrond. Voor deze navigatie worden de TTFB, Resource Load Delay, Resource Load Duration en Element Render Delay vanuit het perspectief van de gebruiker effectief tot bijna nul gereduceerd.

Voorbeeld van use case

Op een e-commerce categoriepagina kunnen speculation rules worden gebruikt om de productdetailpagina's voor de eerste paar items in de lijst te prerenderen. Wanneer een gebruiker op een van deze producten klikt, verschijnt de pagina onmiddellijk.

Synthese van de Case Study: van theorie naar praktijk

Deze optimalisaties hebben een meetbare impact in de echte wereld.

• Case 1: De transformerende kracht van Preloading: Een experiment uitgevoerd door DebugBear op een pagina met een hoge laadvertraging biedt een spectaculair voorbeeld. De LCP-afbeelding was verborgen in een verzoekketen, waardoor de Resource Load Delay goed was voor een onthutsende 75% van de totale LCP-tijd. Door een enkele <link rel="preload">-hint te implementeren om de afbeelding vroeg ontdekbaar te maken, werd de Resource Load Delay teruggebracht tot slechts 2% van de LCP-tijd. Dit laat zien hoe een eenvoudige architecturale fix een enorme performance-bottleneck kan oplossen.
• Case 2: De Real-World loading="lazy" Anti-patroon: Een ontwikkelaar op Stack Overflow meldde een desktop-LCP met een verbijsterende laadvertraging van 1.430 ms ondanks een snel netwerk. De oorzaak bleek een plugin voor beeldoptimalisatie te zijn die ten onrechte lazy loading toepaste op de LCP-afbeelding door het src-attribuut te vervangen door een transparante placeholder SVG. De definitieve oplossing was om dit gedrag voor het LCP-element uit te schakelen, waardoor het ontdekt en gretig (eagerly) geladen kon worden. Dit illustreert hoe tools van derden onbedoeld ernstige laadvertragingen kunnen introduceren.
• Case 3: De fetchpriority Performance Boost: De Google Flights case study biedt duidelijk bewijs voor de impact van expliciete prioritisering. Door simpelweg fetchpriority="high" toe te voegen aan de LCP-achtergrondafbeelding van de pagina, verbeterde de LCP-score met 700 ms, van 2,6 seconden naar 1,9 seconden. Dit toont aan dat zelfs wanneer een bron ontdekt kan worden, het aangeven van de hoge belangrijkheid aan de browser een cruciale stap is in het winnen van de strijd om netwerkbandbreedte.

Netwerkinspectie in Chrome DevTools: Gebruik de sneltoets Ctrl + Shift + I om de Developer Tools van Chrome te openen, selecteer vervolgens het tabblad "Network" en ververs de pagina. Kijk naar de volgorde van laden. Uw LCP-resource zou een van de eerste items moeten zijn die in de wachtrij voor download worden geplaatst. Als deze achterblijft bij andere elementen, is er een probleem met de resource load delay. Hieronder ziet u een voorbeeld van een site waar de resource load delay niet is geoptimaliseerd.

Gebruik Real User Monitoring (RUM) Data: Real User Monitoring-tools leggen vaak LCP attribution data vast. Met RUM kunt u de uitsplitsing van LCP-subonderdelen visualiseren (over de tijd of per pagina), waardoor u een duidelijk beeld krijgt van de laadvertraging voor LCP-elementen over uw gehele site of per pagina. Het onderstaande voorbeeld laat een globale LCP-uitsplitsing zien samen met de bijbehorende laadvertraging.

Hoe laadvertraging te verbeteren

Een resource load delay treedt op wanneer de downloadvolgorde en timing van bronnen niet optimaal zijn. Er zijn in wezen twee directe manieren om dit op te lossen: prioriteit geven aan de LCP-resource of prioriteit ontnemen aan niet-LCP-bronnen. Laten we enkele veelvoorkomende patronen verkennen:

LCP Tip: Begrijp de Preload Scanner: Moderne browsers gebruiken een mechanisme genaamd de preload scanner, die snel de HTML scant en bronnen in de wachtrij plaatst voor download. Als een bron niet door de preload scanner in de wachtrij kan worden geplaatst, moet deze wachten op de tragere DOM-parser, wat tot vertragingen leidt. Ervoor zorgen dat uw LCP-bronnen ontdekt kunnen worden door de preload scanner kan een groot verschil maken in het verminderen van laadvertraging.

1. Optimaliseer de HTML-structuur

De browser (of de preload scanner) verwerkt uw HTML van boven naar beneden, waarbij bronnen in de wachtrij worden geplaatst in de volgorde waarin ze verschijnen. Dit betekent dat hoe hoger de LCP-resource in de HTML verschijnt, hoe eerder deze in de wachtrij komt te staan. Om dit te optimaliseren, verwijdert u onnodige bronnen bovenaan de HTML of stelt u deze uit:

• Lazy-Load Onbelangrijke of Verborgen Afbeeldingen: Soms bevinden afbeeldingen (bijvoorbeeld vlaggen voor taalspecifieke versies van uw site of afbeeldingen in het menu) zich helemaal bovenaan de HTML van uw site. Deze afbeeldingen zijn lang niet zo belangrijk als het LCP-element. Door deze afbeeldingen te lazy-loaden worden ze overgeslagen door de preload scanner en iets later tijdens het laadproces in de wachtrij geplaatst.
• Verplaats onbelangrijke scripts naar de onderkant van de pagina: Verplaats scripts die absoluut onbelangrijk zijn voor de initiële lading naar de onderkant van de pagina om te voorkomen dat ze kritieke bronnen vertragen. Bijvoorbeeld een chat-widget. Niemand in de geschiedenis van het internet heeft ooit hoeven chatten voordat de pagina zichtbaar was!

2. Vermijd achtergrondafbeeldingen

Achtergrondafbeeldingen zijn onzichtbaar voor de preload scanner, wat betekent dat ze altijd in de wachtrij worden geplaatst door de veel tragere DOM-parser. Om deze vertraging te voorkomen, gebruikt u in plaats daarvan een gewone <img>-tag, gecombineerd met de CSS-eigenschap object-fit: cover om het uiterlijk van een achtergrondafbeelding na te bootsen. Op deze manier kan de preload scanner de afbeelding onmiddellijk detecteren en in de wachtrij plaatsen.

3. Gebruik Fetch Priority

Voeg het attribuut fetchpriority="high" toe aan uw LCP-element om de browser aan te geven dat deze bron direct vanaf het begin prioriteit moet krijgen. Normaal gesproken laden afbeeldingen met een standaard lage of gemiddelde prioriteit. Tijdens de layout-fase upgradet de browser zichtbare elementen naar een hoge prioriteit. Door fetchpriority="high" in te stellen, begint de download onmiddellijk met een hoge prioriteit, wat zorgt voor een snellere LCP.

Fetchpriority is doorgaans minder ingrijpend (en minder effectief) dan preloading omdat het de relatieve prioriteit van een element instelt (in dit geval is de afbeelding relatief belangrijker dan andere afbeeldingen), maar het maakt het niet belangrijker dan bijvoorbeeld stylesheets of non-blocking scripts.

<img src="hero-image.jpg" alt="Hero-afbeelding" fetchpriority="high">

4. Implementeer Preloading

Preloading verandert de volgorde waarin de preload scanner bestanden in de wachtrij plaatst. Plaats de <link rel="preload">-tag in de head van de pagina om de browser de opdracht te geven kritieke bronnen, zoals de LCP-afbeelding, zo vroeg mogelijk op te halen. Preloads kunnen worden gebruikt om bronnen te preloaden waarnaar later in de HTML wordt verwezen (en die dus later in de wachtrij worden geplaatst) of zelfs om bronnen te preloaden waarnaar nog niet in de HTML wordt verwezen (zoals bij sommige sliders). Voor maximale effectiviteit wordt aanbevolen om preloads na stylesheets en voor scripts in de head van de pagina te plaatsen.

<link rel="preload" as="image" href="hero-image.jpg">

5. Optimaliseer Styles

Stylesheets worden normaal gesproken voor de LCP-resource in de wachtrij geplaatst en dat is met een goede reden. Zonder stylesheets weet de browser niet hoe de pagina eruit zal zien en kan hij niet beginnen met de rendering-fase. Een buitensporige CSS-omvang en een overmatig aantal stylesheets zullen echter concurreren met de LCP-resource om de initiële bandbreedte.

6. Implementeer efficiënte Lazy-Loading

Het loading-attribuut kan een tweesnijdend zwaard zijn. Gebruik loading="eager" (of laat het attribuut gewoon weg, aangezien "eager" de browserstandaard is) voor uw LCP-resource, terwijl u loading="lazy" toepast voor afbeeldingen buiten het scherm (offscreen).

• Eager Load het LCP-element: Als het LCP-element lazy-loaded is, wordt het niet in de wachtrij geplaatst door de preload scanner und zal het veel later laden, wat de prestaties negatief beïnvloedt.
• Lazy-Load Viewport Afbeeldingen: Voor afbeeldingen die zich in het zichtbare viewport bevinden maar geen LCP-bronnen zijn, gebruikt u loading="lazy" om ze iets later in de wachtrij te plaatsen voor download. Dit vermindert de bandbreedtecompetitie met de LCP-resource.
• Vermijd Lazy Loading van afbeeldingen buiten het scherm: Afbeeldingen die zich niet in het zichtbare viewport bevinden, zullen helemaal geen download triggeren, waardoor bandbreedtecompetitie volledig wordt geëlimineerd.

7. Browser Caching

Browser-caching stelt u in staat om netwerkverzoeken over te slaan voor bronnen die al lokaal op het apparaat van de gebruiker zijn opgeslagen. Hoewel het de eerste paginaweergave niet zal versnellen, zal het de laadtijden verbeteren voor volgende paginaweergaven en terugkerende bezoekers. Hier ziet u hoe browser-caching helpt bij de resource load delay:

• Cache concurrerende bronnen: Hoewel het cachen van de LCP-resource zelf een geweldige strategie is, verbetert browser-caching de LCP resource load delays door netwerkbronnen op te slaan die zouden kunnen concurreren met de LCP-resource of deze zouden kunnen vertragen, zoals scripts, stylesheets en afbeeldingen.
• Serverbelasting verminderen: Caching vermindert het aantal verzoeken dat naar uw server wordt verzonden, wat de prestaties van andere bronnen kan verbeteren door bandbreedte vrij te maken en server-CPU-cycli te verminderen.

8. Gebruik Speculation Rules

Speculation Rules stellen browsers in staat om webpagina's te prefetchen of te prerenderen 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 delay. Prerendering rendert de volgende pagina in een verborgen tabblad en downloadt alle paginabronnen. Dit elimineert alle laadvertragingen voor het LCP-element, zoals getoond in dit voorbeeld van een LCP-uitsplitsing van een geprerenderde pagina.

9. Vermijd Client-Side Rendering

Volgende stappen: Ga door met het optimaliseren van LCP

Resource Load Delay is een van de vier LCP-fasen. Zodra u de ontdekkingslatentie heeft geminimaliseerd, kunt u verder gaan met deze gidsen:

• LCP-problemen oplossen en identificeren: De complete diagnostische methodologie voor het vinden en oplossen van alle LCP-problemen.
• De LCP-afbeelding optimaliseren: Selectie van beeldformaten, responsieve afbeeldingen, preloading en veelvoorkomende beeldfouten.
• Resource Load Duration: Nadat de browser de bron heeft ontdekt, vermindert u de tijd die nodig is om deze te downloaden via compressie, moderne formaten en CDN-optimalisatie.
• Element Render Delay: Zorg er na de download van de bron voor dat de browser deze onmiddellijk kan tekenen (painten) door de main thread vrij te maken.