Optimaliseer de laadvertraging van de LCP-resource

Deze gids is onderdeel van de Largest Contentful Paint (LCP) hub. Resource Load Delay is vaak de grootste oorzaak van een slechte LCP-score, vooral bij SPA-sites! 

Optimaliseer de LCP Resource Load Delay

Largest Contentful Paint (LCP) is een van de vier LCP-subfasen: TTFB, Resource Load Delay, Resource Load Duration en Element Render Delay. 

Een snelle tip: als je LCP een afbeelding is, is deze bijna altijd slechter dan tekst. Je moet de typen LCP-elementen bijhouden in je RUM-data, anders vlieg je blind.

Wat is Resource Load Delay?

Resource Load Delay is de tijd tussen TTFB en het moment waarop de browser start met het downloaden van de LCP-resource. In de basis moet een browser een LCP-resource (bijvoorbeeld de LCP-afbeelding)  zo snel mogelijk in de wachtrij zetten. Gebeurt dit niet zo snel mogelijk, dan komt dat meestal doordat de browser de resource niet direct kan ontdekken of deze niet als belangrijk genoeg herkent.

Een hoge waarde duidt hier op een architecturaal probleem (waarbij de browser de resource-URL niet kan vinden in de initiële HTML-payload). Deze resource load delay kun je zien als de tijd die de browser nodig heeft om te bepalen dat de LCP-resource nodig is en te besluiten deze op te halen.

Het is ook belangrijk om te begrijpen dat de resource load delay plaatsvindt voordat de resource daadwerkelijk wordt geladen. Daarom heeft dit niets te maken met responsieve afbeeldingen of nieuwe afbeeldingsformaten zoals WebP of AVIF.

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

Hoe vindt een browser het LCP-element?

Om Resource Load Delay te verminderen, moet je begrijpen hoe browsers resources ontdekken (of in ieder geval het LCP-element ontdekken). Browsers gebruiken twee mechanismen: een snelle route en een trage route. Eerst moet je ervoor zorgen dat het LCP-element zich 'in de snelle route' bevindt.

• De DOM-parser (Trage route): Dit is de hoofdparser van de browser en het is een beest. Deze bouwt de volledige pagina  op door de HTML en stylesheets te lezen en interactie te hebben met JavaScript. Dit is de trage route omdat deze vertraagd en gestopt kan worden door andere bestanden die eerst downloaden en uitvoeren. Dit creëert een afhankelijkheidsketen die vertraging oplevert.
• De Preload Scanner (De snelle route): Omdat de DOM-parser (relatief) traag is, hebben browsers een bliksemsnelle secundaire scanner die de pagina razendsnel scant op downloadbare resources. Deze scanner laat zich door niets stoppen. Als deze <script>-, niet-lazy <img>- of <link>-tags vindt, zet hij deze direct in de wachtrij voor download. Dit gebeurt nog voordat CSS wordt geparst of JavaScript wordt uitgevoerd. Dit is de optimale route voor elke kritieke resource.

De volledige strategie voor het optimaliseren van Resource Load Delay is gebaseerd op één principe: zorg ervoor dat de LCP-resource-URL zo vroeg mogelijk ontdekt kan worden door de preload scanner.

Dat betekent 2 dingen voor een LCP-element:

1. Zorg ervoor dat de preload scanner het kan vinden door een normale image-tag te gebruiken die niet de eigenschap loading="lazy" heeft.
2. Zorg ervoor dat de preload scanner niet te veel minder belangrijke resources prioriteert.

Waarom Load Delay belangrijk is voor de Core Web Vitals

Beginnende developers denken vaak dat LCP een "bestandsgrootte"-probleem is. Dit leidt ertoe dat teams zich richten op afbeeldingscompressie, moderne afbeeldingsformaten en responsieve afbeeldingen. Dit is een fout. Ons eigen Core Web Vitals-onderzoek toont aan dat de grootste bottleneck in de LCP de TTFB is (48%), gevolgd door Load delay (24%). Load time neemt slechts 10% in beslag, gevolgd door Render delay met 17%.

De crux is nu dat load delay vrijwel volledig op te lossen is, terwijl TTFB altijd zal blijven bestaan. Dat maakt de Load delay het element met de hoogste potentie voor optimalisatie.

Hoe detecteer je Resource Load Delay

Om Resource Load Delay te fixen, moet je het eerst nauwkeurig meten. De workflow is altijd: check met CrUX om eerst het probleem te definiëren met echte gebruikersdata (RUM), en ga pas daarna naar Chrome DevTools voor een diepe analyse.

Stap 1: Check met CrUX.

CrUX is de openbaar beschikbare echte field data van Google, afkomstig van in aanmerking komende Chrome-gebruikers. Het biedt een voortschrijdend overzicht van 28 dagen van je Core Web Vitals op het 75e percentiel. Het vertelt je of een getal goed of slecht is, maar het zegt niet wie, wat of waarom. Aangezien Google vertrouwt op CrUX-data, is dit je beste bron van waarheid als startpunt.

Ga naar cruxvis.withgoogle.com, vul je website in, navigeer naar Loading Performance en klik op  Largest Contentful Paint (LCP) image subparts

Stap 2: Analyseer field data (RUM)

RUM verzamelt Core Web Vitals van al je echte gebruikers en geeft je een veel specifieker, gedetailleerder beeld. Het vertelt je wie en wat, gesegmenteerd zoals jij dat wilt (en die informatie is goud waard), maar niet waarom.

Dit CoreDash-screenshot toont je bijvoorbeeld welke URL's last hebben van Resource Load Delay (in het groen)

Stap 3: Diagnoseer met DevTools

Zodra je RUM-data een doelpagina en LCP-element heeft geïdentificeerd, gebruik je Chrome DevTools om de oorzaak te diagnosticeren. Het doel hier is om het probleem te reproduceren en de LCP-subfasen te meten om een exacte Resource Load Delay-waarde te krijgen. DevTools is ook de plek waar je een main thread-analyse uitvoert om precies te zien welke taken draaien en mogelijk het renderproces blokkeren.

Stap-voor-stap gids: we hebben een volledige handleiding geschreven voor deze workflow: Diagnosticeer LCP met het Chrome DevTools Performance panel. Het behandelt de throttling-setup, het opnemen van een trace en het aflezen van de exacte Resource Load Delay-waarde uit de LCP-breakdown insight.

Veelvoorkomende oorzaken en high-impact oplossingen

Een hoge Resource Load Delay wordt veroorzaakt door een van deze twee dingen: de LCP-resource wordt te laat ontdekt, of krijgt een lage fetch prioriteit. Hier zijn de meest voorkomende architecturale fouten en hun oplossingen.

Oorzaak: LCP geladen via CSS

Het probleem: De preload scanner parst geen CSS-bestanden. Wanneer je LCP-afbeelding is gedefinieerd met een CSS background-image, is de URL onzichtbaar voor deze supersnelle scanner. De browser kan de afbeelding pas ontdekken na het downloaden van de HTML, het vinden van de CSS-link, het downloaden van het CSS-bestand, het bouwen van de CSSOM en daarna pas het 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 correcte implementatie is om background-image te vermijden voor elk kritiek LCP-element. Gebruik in plaats daarvan een standaard <img>-tag. Dit plaatst de image-URL direct in de HTML, waar de preload scanner hem direct kan vinden. Je bereikt exact hetzelfde visuele resultaat met CSS.

Implementatievoorbeeld:

Antipatroon (doe dit niet):

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

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

Best Practice (doe dit wel):

    <!-- 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 imiteert background-size: cover */
      z-index: -1; /* Plaatst de afbeelding achter andere content */
    }
    

Deze implementatie geeft hetzelfde visuele resultaat, maar maakt de LCP-afbeelding zo vroeg mogelijk ontdekbaar. Dit minimaliseert de load delay.

Oorzaak: Client-side rendering en JavaScript-injectie

Het probleem: Applicaties die gebruikmaken van client-side rendering (CSR) frameworks zoals React of Vue serveren vaak een minimale HTML-shell. De daadwerkelijke content, inclusief de LCP <img>-tag, wordt pas in de DOM geïnjecteerd door JavaScript nadat grote framework-bundels zijn gedownload, geparst en uitgevoerd. Dit proces verbergt de LCP-resource fundamenteel voor de preload scanner, wat zorgt voor een hoge latency in de ontdekking.

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

• Server-Side Rendering (SSR) of Static Site Generation (SSG): Architectuurpatronen zoals SSR of SSG genereren de volledige HTML op de server. De browser ontvangt een compleet document met de <img>-tag en zijn src-attribuut. Hierdoor is de LCP-resource direct ontdekbaar voor de preload scanner. Dit is de vereiste architectuur voor elke prestatiekritieke pagina.
• Framework-specifieke optimalisaties: Moderne frameworks bieden ook ingebouwde optimalisaties. De Next.js <Image>-component heeft bijvoorbeeld een priority-eigenschap. Als je deze op true instelt, geef je het framework de opdracht om automatisch de juiste <link rel="preload">- en fetchpriority="high"-attributen toe te voegen. Zo wordt de afbeelding met de juiste prioriteit ontdekt en opgehaald.

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

Het probleem: Dit is een veelvoorkomende 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 de viewport is. Hoewel dit de juiste optimalisatie voor below-the-fold afbeeldingen is, werkt dit averechts voor een above-the-fold LCP-element. De preload scanner van de browser is ontworpen om afbeeldingen met loading="lazy" te negeren. Dit garandeert een late ontdekking en een hoge Resource Load Delay.

De oplossing: De oplossing vereist nauwkeurigheid.

• Verwijder loading="lazy" van de LCP-afbeelding: Elke afbeelding die waarschijnlijk het LCP-element is, mag het loading="lazy"-attribuut niet hebben. Het standaardgedrag van de browser is loading="eager". Dit is de correcte instelling voor kritieke, above-the-fold content. Het volledig weglaten van het loading-attribuut heeft hetzelfde effect.
• Audit en configureer tools van derden: Je moet ook tools van derden controleren. Veel CMS-platformen zoals WordPress en diverse plugins voor afbeeldingsoptimalisatie 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. Vaak betekent dit dat je een uitzonderingsregel moet maken voor de eerste een 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 resources, zoals header-iconen of chat-widget scripts, hoger in de <body> staan dan het LCP-element, worden ze als eerste ontdekt en in de wachtrij geplaatst voor download. Dit verbruikt 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 data chunk zit die de browser ontvangt (rond de 14KB), loopt de ontdekking minstens één netwerk round-trip vertraging op.

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

• Herschik de HTML: Zorg er waar mogelijk voor dat de <img>-tag of het tekstblok voor het LCP-element zo vroeg mogelijk binnen de <body>-tag verschijnt.
• Deprioriteer niet-kritieke afbeeldingen: Pas loading="lazy" toe op niet-essentiële afbeeldingen die vroeg in de HTML-bron moeten staan (zoals iconen in een header). Dit vertelt de preload scanner om ze over te slaan, wat de downloadwachtrij vrijhoudt voor het LCP-element.
• Stel niet-essentiële scripts uit: Scripts voor analytics, ads of social media widgets zijn zelden kritiek voor de initiële render. Verplaats deze <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 prioriteit met resource hints

Zodra de LCP-resource ontdekbaar is in de HTML, kun je resource hints gebruiken om de browser explicietere instructies te geven over hoe deze moet worden opgehaald. Deze hints bieden gedetailleerde controle over ontdekking en prioriteit.

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

<link rel="preload"> is geen hint; het is een richtlijn. Het dwingt de browser om een resource met hoge prioriteit te downloaden, zelfs als deze nog niet ontdekbaar is door de hoofdparser. Dit in de <head> van je HTML plaatsen is de meest directe manier om problemen met late ontdekking op te lossen voor resources zoals lettertypen, CSS background-images, of LCP-afbeeldingen die diep in de DOM verborgen zitten. Voor volledige implementatiedetails en voorbeelden, zie onze toegewijde gids over hoe je de LCP-afbeelding preloadt.

Mechanisme

Wanneer een preload-link in de <head> van het HTML-document wordt geplaatst, identificeert de preload scanner deze en zet hij de gespecificeerde resource onmiddellijk in de wachtrij voor download. Dit is ideaal voor resources zoals lettertypen die via @font-face in een extern stylesheet worden geladen, 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 kritiek implementatiedetail is vereist bij het preloaden van responsieve afbeeldingen. Om ervoor te zorgen dat de browser de juist geschaalde afbeelding voor de viewport van de gebruiker preloadt en een verspillende dubbele download voorkomt, moet de <link rel="preload">-tag imagesrcset- en imagesizes-attributen bevatten die perfect overeenkomen met de attributen op de corresponderende <img>-tag.

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">
    

Potentiële valkuil

Preloading lost de fetch timing (Load Delay en Load Duration) op, maar niet de paint timing. Als de main thread wordt geblokkeerd door zware JavaScript of render-blocking CSS op het moment dat de gepreloade afbeelding binnenkomt, moet de afbeelding alsnog wachten om gerenderd te worden. Dit kan de bottleneck verplaatsen van Load Delay naar Element Render Delay.

fetchpriority="high" en de prioriteitenwachtrij van de browser

Het fetchpriority-attribuut is een hint die het relatieve belang van een resource download aangeeft. Hiermee beïnvloed je de prioriteit van een resource in de downloadwachtrij van de browser.

Hoe browserprioriteit werkt

Wanneer de browser resources ontdekt tijdens het laden van de pagina, krijgt elke resource een intern prioriteitsniveau. Standaard starten afbeeldingen in de viewport met een "Low" prioriteit en worden later geüpgraded naar "High" zodra de browser de lay-out voltooit en bepaalt dat ze zichtbaar zijn. Deze upgrade vereist dat de browser eerst CSS downloadt en parst. Dit zorgt voor vertraging. Het fetchpriority="high"-attribuut omzeilt dit proces volledig door de afbeelding op "High" prioriteit te zetten vanaf het moment dat deze wordt ontdekt. Dit is met name impactvol voor LCP-afbeeldingen, omdat het de vertraging van de prioriteitsupgrade elimineert.

preload vs. fetchpriority

Deze twee hints dienen verschillende maar complementaire doelen. preload beïnvloedt wanneer een resource wordt ontdekt en aan de wachtrij wordt toegevoegd. fetchpriority beïnvloedt het prioriteitsniveau zodra het zich in de wachtrij bevindt. Het begrijpen van dit onderscheid is cruciaal: preload lost late ontdekking op, terwijl fetchpriority lage prioriteit oplost. Voor veel LCP-afbeeldingen die al in de HTML staan, kan fetchpriority alleen 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 er eerst voor dat deze vroeg wordt ontdekt door de <img>-tag vroeg in de HTML te plaatsen of door preload te gebruiken. Voeg vervolgens fetchpriority="high" direct toe aan de <img>-tag (en de preload-link, indien gebruikt). Deze combinatie zorgt ervoor dat de resource niet alleen vroeg wordt ontdekt, maar ook de hoogst mogelijke prioriteit krijgt. Zo wint het de strijd om netwerkbandbreedte van andere resources zoals stylesheets of lettertypen.

Voorbeeld:

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

Wanneer gebruik je fetchpriority="low"

Het fetchpriority-attribuut is niet alleen om prioriteit te verhogen. Je kunt fetchpriority="low" ook gebruiken om niet-kritieke resources te deprioriteren die concurreren om bandbreedte met de LCP-afbeelding. Veelvoorkomende kandidaten zijn above-the-fold afbeeldingen die niet het LCP-element zijn (zoals kleine iconen of avatars in de header), en gepreloade resources die wel nodig zijn maar geen haast hebben. Door expliciet de prioriteit van deze concurrerende resources te verlagen, creëer je meer bandbreedte-headroom voor de LCP-afbeelding.

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

<!-- Niet-kritieke above-the-fold afbeelding: lage prioriteit -->
<img src="avatar.jpg" fetchpriority="low" alt="Auteursavatar" width="48" height="48">

Bewezen impact

In een casestudy met Google Flights zorgde het toevoegen van fetchpriority="high" aan de LCP background-image voor een verbetering van de LCP-tijd van 2,6 seconden naar 1,9 seconden, een winst van 700 milliseconden.

Optimaliseren van third-party verbindingen: preconnect en dns-prefetch

Het probleem

Als je LCP-resource gehost wordt op een third-party domein, zoals een image-CDN of een font provider zoals Google Fonts, moet de browser een nieuwe netwerkverbinding opzetten met dat domein. Dit proces omvat een DNS-lookup, een TCP-handshake en een TLS-onderhandeling. Al deze stappen moeten voltooid zijn voordat de eerste byte van de resource kan worden gedownload. Deze verbindingstijd draagt direct bij aan Resource Load Delay voor cross-origin assets.

De oplossingen

• preconnect: Deze hint geeft de browser de opdracht om de volledige verbinding (DNS, TCP en TLS) naar een gespecificeerde third-party origin alvast op de achtergrond op te zetten. Wanneer de resource daadwerkelijk wordt opgevraagd, is de verbinding al warm. Dit elimineert de setup-latency. Dit is uiterst effectief en wordt aanbevolen voor de één of twee meest kritieke third-party domeinen die LCP-resources 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 bredere browserondersteuning. Het is nuttig als fallback of voor minder kritieke third-party domeinen.

Implementatie best practice

Zorg voor maximale compatibiliteit door beide hints op te geven. De browser gebruikt preconnect indien ondersteund, en valt anders terug op dns-prefetch. Het crossorigin-attribuut is essentieel voor resources die via 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 onderstaande tabel een vergelijkende samenvatting.

Holistische en toekomstgerichte strategieën

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

De rol van een modern CDN

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

• Verminderen van connection overhead: Door assets te distribueren over een wereldwijd netwerk van servers plaatst een CDN content 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. Dit zijn allemaal onderdelen van de setup-tijd. Voor een LCP-afbeelding die op een CDN wordt gehost, verlaagt dit direct de load delay.
• Image CDN's: Gespecialiseerde Image CDN's bieden een dubbel voordeel. Ze leveren het nabijheidsvoordeel van een standaard CDN, maar automatiseren tegelijkertijd veel complexe optimalisaties die Resource Load Duration verminderen. Denk aan on-the-fly schalen, comprimeren en converteren van afbeeldingen naar moderne formaten zoals AVIF en WebP.
• Geavanceerde protocollen: Veel moderne CDN's gebruiken HTTP/3, wat draait op QUIC in plaats van TCP. HTTP/3 vermindert de setup-tijd en mitigeert head-of-line blocking. Dit leidt globaal tot een snellere en efficiëntere aflevering van resources.

Delay volledig elimineren met Speculation Rules

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

Mechanisme

Met deze API kunnen developers de browser declaratief informeren over welke URL's een gebruiker waarschijnlijk als volgende gaat bezoeken. Op basis van deze regels kan de browser ervoor kiezen om een doelpagina te prerenderen in een verborgen achtergrondtabblad, nog voordat de gebruiker op de link klikt.

Impact op LCP

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

Voorbeeld use case

Op een e-commerce categoriepagina kun je speculation rules gebruiken om de productdetailpagina's van de eerste paar items in de lijst te prerenderen. Zodra een gebruiker op een van deze producten klikt, verschijnt de pagina direct.

Casestudy synthese: van theorie naar praktijk

Deze optimalisaties hebben een meetbare impact in de praktijk.

• Case 1: De transformatieve kracht van preloading: Een experiment van DebugBear op een pagina met een hoge load delay geeft een spectaculair voorbeeld. De LCP-afbeelding zat verborgen in een request chain, waardoor de Resource Load Delay verantwoordelijk was voor maar liefst 75% van de totale LCP-tijd. Door één enkele <link rel="preload">-hint te implementeren om de afbeelding vroeg ontdekbaar te maken, daalde de Resource Load Delay naar slechts 2% van de LCP-tijd. Dit laat zien hoe een simpele architecturale aanpassing een massale performance bottleneck kan oplossen.
• Case 2: Het echte loading="lazy" antipatroon: Een developer op Stack Overflow meldde een desktop LCP met een onbegrijpelijke 1.430ms load delay, ondanks een snel netwerk. De oorzaak bleek een afbeeldingsoptimalisatie-plugin die onterecht 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, zodat het eager werd ontdekt en geladen. Dit illustreert hoe third-party tools onbedoeld zware load delays kunnen introduceren.
• Case 3: De fetchpriority performance boost: De Google Flights casestudy levert helder bewijs voor de impact van expliciete prioritering. Door simpelweg fetchpriority="high" toe te voegen aan de LCP background-image van de pagina, verbeterde de LCP-score met 700ms en daalde van 2,6 seconden naar 1,9 seconden. Dit toont aan dat, zelfs als een resource ontdekbaar is, het aangeven van het hoge belang ervan aan de browser een kritieke stap is in het winnen van de strijd om netwerkbandbreedte.

Network Inspection in Chrome DevTools: Gebruik de sneltoets Ctrl + Shift + I om Chrome's Developer Tools te openen, selecteer het "Network"-tabblad en herlaad de pagina. Kijk naar de laadvolgorde. Je LCP-resource moet een van de eerste items in de downloadwachtrij zijn. Als deze achterblijft bij andere elementen, heb je een resource load delay probleem. Hieronder zie je een voorbeeld van een site waar de resource load delay niet geoptimaliseerd is.

Gebruik Real User Monitoring (RUM) data: Real User Monitoring tools loggen vaak LCP-attributiedata. Met RUM kun je de breakdown van LCP-subfasen visualiseren (over tijd of per pagina). Dit geeft je een helder beeld van de load delay voor LCP-elementen over je hele site of per pagina. Het onderstaande voorbeeld toont een globale LCP-breakdown samen met de bijbehorende load delay.

Hoe verbeter je Load Delay

Een resource load delay ontstaat wanneer de downloadvolgorde en timing van resources niet optimaal zijn. Er zijn in essentie twee directe manieren om dit op te lossen: prioriteer de LCP-resource of deprioriteer non-LCP resources. Laten we enkele veelvoorkomende patronen verkennen:

LCP tip: Begrijp de preload scanner: Moderne browsers gebruiken een mechanisme genaamd de preload scanner, die razendsnel de HTML scant en resources in de wachtrij zet voor download. Als een resource niet in de wachtrij kan worden geplaatst door de preload scanner, moet deze wachten op de tragere DOM-parser. Dit resulteert in vertragingen. Ervoor zorgen dat je LCP-resources ontdekbaar zijn door de preload scanner kan een enorm verschil maken bij het verlagen van de load delay.

1. Optimaliseer de HTML-structuur

De browser (of de preload scanner) verwerkt je HTML van boven naar beneden en plaatst resources in de wachtrij in de volgorde waarin ze verschijnen. Dit betekent: hoe hoger het LCP-element in de HTML staat, hoe sneller het in de wachtrij komt. Optimaliseer dit door onnodige resources bovenaan in de HTML te verwijderen of uit te stellen:

• Lazy load onbelangrijke of verborgen afbeeldingen: Soms staan afbeeldingen (bijvoorbeeld vlaggetjes voor taalspecifieke versies van je site of afbeeldingen in het menu) helemaal bovenaan de HTML van je site. Deze afbeeldingen zijn lang niet zo belangrijk als het LCP-element. Door lazy loading toe te passen op deze afbeeldingen worden ze overgeslagen door de preload scanner en pas 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 render naar de onderkant van de pagina om te voorkomen dat ze kritieke resources vertragen. Bijvoorbeeld een chat-widget. Nog nooit in de geschiedenis van het internet heeft iemand hoeven chatten voordat de pagina zichtbaar was!

2. Vermijd achtergrondafbeeldingen

Achtergrondafbeeldingen zijn onzichtbaar voor de preload scanner. Dat betekent dat ze altijd pas in de wachtrij worden gezet door de veel tragere DOM-parser. Om deze vertraging te vermijden, gebruik je in plaats daarvan een normale <img>-tag, gecombineerd met de CSS-eigenschap object-fit: cover om de uitstraling van een achtergrondafbeelding na te bootsen. Op deze manier kan de preload scanner de afbeelding direct detecteren en in de wachtrij zetten.

3. Gebruik Fetch Priority

Voeg het fetchpriority="high"-attribuut toe aan je LCP-element om de browser een hint te geven dat deze resource vanaf de start geprioriteerd moet worden. Normaal gesproken laden afbeeldingen met een standaard lage of gemiddelde prioriteit. Tijdens de lay-outfase upgradet de browser zichtbare elementen naar een hoge prioriteit. Door fetchpriority="high" in te stellen, start de download direct met een hoge prioriteit. Dit garandeert een snellere LCP.

Fetchpriority is doorgaans minder ingrijpend (en minder effectief) dan preloading. Het stelt namelijk de relatieve prioriteit van een element in (in dit geval is de afbeelding relatief belangrijker dan andere afbeeldingen), maar het maakt de resource 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. Zet de <link rel="preload">-tag in de head van de pagina om de browser de opdracht te geven kritieke resources, zoals de LCP-afbeelding, zo vroeg mogelijk op te halen. Preloads kunnen worden gebruikt om resources te preloaden die pas later in de HTML worden genoemd (en daardoor later in de wachtrij komen) of zelfs voor resources die nog helemaal niet in de HTML staan (zoals bij sommige sliders). Voor maximale effectiviteit raden we aan preloads ná stylesheets en vóór scripts in de head van de pagina te plaatsen.

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

5. Optimaliseer Styles

Stylesheets komen normaal gesproken vóór de LCP-resource in de wachtrij, en dat heeft een goede reden. Zonder stylesheets weet de browser niet hoe de pagina eruit komt te zien en kan de renderfase niet starten. Een buitensporige CSS-bestandsgrootte en een teveel aan stylesheets concurreren echter wel met de LCP-resource om de eerste bandbreedte.

6. Implementeer efficiënte lazy loading

Het loading-attribuut kan een tweesnijdend zwaard zijn. Gebruik loading="eager" (of laat het attribuut simpelweg weg, aangezien "eager" de browser default is) voor je LCP-resource, en pas loading="lazy" toe op offscreen afbeeldingen.

• Eager load het LCP-element: Als het LCP-element lazy-loaded is, wordt het niet in de wachtrij geplaatst door de preload scanner en laadt het veel later. Dit heeft een negatieve impact op de performance.
• Lazy-load viewport afbeeldingen: Voor afbeeldingen die wel in de zichtbare viewport staan maar geen LCP-resources zijn, gebruik je loading="lazy" om ze iets later in de downloadwachtrij te zetten. Dit vermindert bandbreedte-competitie met de LCP-resource.
• Vermijd lazy loading van offscreen afbeeldingen: Afbeeldingen die niet in de zichtbare viewport staan, triggeren helemaal geen download. Dit elimineert bandbreedte-competitie volledig.

7. Browser caching

Met browser caching kun je netwerkrequests overslaan voor resources die al lokaal op het apparaat van de gebruiker zijn opgeslagen. Hoewel dit de eerste pageview niet versnelt, verbetert het wel de laadtijden voor volgende pageviews en terugkerende bezoekers. Dit is hoe browser caching helpt bij resource load delay:

• Cache concurrerende resources: Hoewel het cachen van de LCP-resource zelf een uitstekende strategie is, verbetert browser caching LCP resource load delays door netwerkresources op te slaan die mogelijk met de LCP-resource concurreren of deze vertragen, zoals scripts, stylesheets en afbeeldingen.
• Verlaag de server load: Caching vermindert het aantal requests dat naar je server wordt gestuurd. Dit kan de performance van andere resources verbeteren door bandbreedte vrij te maken en de CPU-belasting van de server te verlagen.

8. Gebruik Speculation Rules

Speculation Rules stellen browsers in staat om webpagina's te pre-fetchen of te prerenderen op basis van verwachte gebruikersnavigatie. Prefetching elimineert de Time to First Byte subfase van de LCP effectief en heeft geen impact op de resource load delay. Prerendering rendert de volgende pagina in een verborgen tabblad en downloadt alle pagina-resources. Dit elimineert alle load delays voor het LCP-element, zoals je kunt zien in deze voorbeeld LCP-breakdown van een geprerenderde pagina.

9. Vermijd client-side rendering

Volgende stappen: Blijf LCP optimaliseren

Resource Load Delay is een van de vier LCP-fasen. Zodra je de ontdekkingslatency geminimaliseerd hebt, ga je verder met deze gidsen:

• Fix &amp;amp; identificeer LCP issues: De complete diagnostische methode voor het vinden en oplossen van alle LCP-problemen.
• Optimaliseer de LCP-afbeelding: Afbeeldingsformaat selecteren, responsieve afbeeldingen, preloading en veelgemaakte afbeeldingsfouten.
• Resource Load Duration: Zodra de browser de resource heeft ontdekt, verlaag je de downloadtijd via compressie, moderne formaten en CDN-optimalisatie.
• Element Render Delay: Nadat de resource is gedownload, zorg je ervoor dat de browser deze onmiddellijk kan paint-en door de main thread vrij te maken.