Optimaliseer de laadvertraging van de LCP-resource

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

Optimaliseer de LCP Resource Load Delay

Largest Contentful Paint (LCP) bestaat uit 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 LCP-elementtypes bijhouden in je RUM-data, anders vlieg je blind.

Wat is Resource Load Delay?

Resource Load Delay is de tijd tussen de TTFB en het moment waarop de browser start met het downloaden van de LCP-bron. Kort gezegd moet een browser een LCP-bron (zoals de LCP-afbeelding) zo snel mogelijk in de wachtrij plaatsen. Als dat niet gebeurt, komt dat meestal doordat de browser de bron niet direct kan vinden of deze niet belangrijk genoeg vindt.

Een hoge waarde hier wijst op een structureel probleem waarbij de browser de URL van de bron niet kan vinden in de initiële HTML-payload. Deze Resource Load Delay is de tijd die de browser nodig heeft om te bepalen dat de LCP-bron nodig is en te besluiten deze op te halen.

Het is ook belangrijk om te begrijpen dat Resource Load Delay plaatsvindt voordat de bron daadwerkelijk wordt geladen. Daarom heeft het niets te maken met responsive afbeeldingen of nieuwe afbeeldingsformaten zoals WebP of AVIF.

Voor LCP-elementen die op tekst zijn gebaseerd en een systeemlettertype gebruiken, is de Resource Load Delay meestal nul omdat er geen externe bron hoeft te worden opgehaald. Hogere waarden voor Resource Load Delay komen specifiek voor bij LCP-elementen die afhankelijk zijn van een externe netwerkbron, zoals een afbeelding of een videobestand.

Hoe vindt een browser het LCP-element?

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

• De DOM-parser (langzaam pad): 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 het langzame pad omdat het kan worden vertraagd en stilgelegd door andere bestanden die eerst worden gedownload en uitgevoerd, wat een keten van afhankelijkheden creëert die vertraging veroorzaakt.
• De preload-scanner (het snelle pad): Omdat de DOM-parser (relatief) langzaam is, hebben browsers een razendsnelle secundaire scanner die de pagina heel snel scant op downloadbare bronnen en door niets wordt tegengehouden. Als deze <script>-, niet-lazy <img>- of <link>-tags vindt, plaatst hij ze direct in de wachtrij voor download, nog voordat CSS is geparseerd of JavaScript is uitgevoerd. Dit is het optimale pad voor elke kritieke bron.

De hele strategie voor het optimaliseren van Resource Load Delay is gebaseerd op één principe: zorg ervoor dat de URL van de LCP-bron zo vroeg mogelijk vindbaar is voor de preload-scanner.

Dit betekent twee dingen voor een LCP-element:

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

Waarom Load Delay belangrijk is voor de Core Web Vitals

Beginnende ontwikkelaars denken vaak dat LCP een probleem met de bestandsgrootte is. Hierdoor focussen teams zich op beeldcompressie, moderne afbeeldingsformaten en responsive afbeeldingen. Dit is een fout. Ons eigen onderzoek naar Core Web Vitals laat zien dat de grootste bottleneck binnen LCP de TTFB is (48%), gevolgd door Load Delay (24%). Load Time neemt slechts 10% in beslag, gevolgd door Render Delay met 17%.

De truc is dat Load Delay bijna volledig oplosbaar is, terwijl TTFB altijd zal blijven bestaan. Dat maakt de Load Delay het element met het grootste optimalisatiepotentieel.

Hoe ontdek je Resource Load Delay

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

Stap 1: Controleer met CrUX.

CrUX is Google's openbaar beschikbare field data van geschikte Chrome-gebruikers, gepresenteerd als een voortschrijdend gemiddelde over 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. Omdat Google vertrouwt op CrUX-data, is dit je beste startpunt als bron van waarheid.

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 specifiekere, gedetailleerdere weergave. Het vertelt je wie en wat, gefilterd op elke gewenste manier (en die informatie is goud waard), maar niet waarom.

Stap 3: Diagnose stellen met DevTools

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

Een stappenplan voor het Performance-paneel in Chrome DevTools

Het Performance-paneel in Chrome DevTools is een onmisbare tool om de LCP te ontleden en Load Delay te kwantificeren.

1. Setup en configuratie:

• Open Chrome DevTools door met de rechtermuisknop op de pagina te klikken en "Inspecteren" te selecteren, of gebruik de sneltoets Ctrl+Shift+I (Windows/Linux) of Cmd+Option+I (Mac).
• Navigeer naar het tabblad Performance.
• Zorg ervoor dat het selectievakje Web Vitals is ingeschakeld in de opname-instellingen. Dit toont de Core Web Vitals-informatie als een overlay op de tijdlijn van de prestaties.
• Simuleer realistische gebruikersomstandigheden door CPU- en netwerk-throttling toe te passen. Een "4x slowdown" voor de CPU en een "Fast 3G"- of "Slow 4G"-netwerkprofiel zijn veelgebruikte startpunten voor mobiele tests.

2. Een Performance-profiel opnemen:

• Klik op de knop "Record and reload page" (een pictogram met een cirkelvormige pijl) in het Performance-paneel. Dit start een opname, herlaadt de pagina en stopt de opname zodra de pagina volledig is geladen.

3. Analyse en interpretatie:

• Timings-spoor: Zoek in de hoofdtijdlijnweergave naar het Timings-spoor. Je ziet een markering met het label LCP. Als je over deze markering beweegt, wordt het bijbehorende LCP-element in de schermafbeelding van de hoofd-viewport gemarkeerd en wordt de totale LCP-tijd weergegeven.
• LCP-analyse per fase: Klik op de LCP-markering in het Timings-spoor. In het tabblad Summary onderaan het paneel vind je een gedetailleerde uitsplitsing van de LCP-timing. Deze uitsplitsing toont expliciet de duur van elk van de vier subfasen, inclusief Load Delay, gemeten in milliseconden. Deze waarde is de meest directe en nauwkeurige meting van de Resource Load Delay voor die specifieke paginalading.
• Main Thread-analyse: Bekijk tijdens het bestuderen van de tijdlijn het Main-spoor op eventuele long tasks (blokken van activiteit gemarkeerd met een rode driehoek). Als deze long tasks plaatsvinden nadat de LCP-bron is geladen maar vóór de LCP-markering, dragen ze waarschijnlijk bij aan Element Render Delay, een gerelateerd maar apart probleem.

Veelvoorkomende oorzaken en oplossingen met hoge impact

Een hoge Resource Load Delay wordt door één van twee dingen veroorzaakt: de LCP-bron wordt te laat ontdekt, of krijgt een lage prioriteit bij het ophalen. Dit zijn de meest voorkomende structurele fouten en hun oplossingen.

Cause: LCP geladen via CSS

Het probleem: De preload-scanner parset 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 link naar het CSS-bestand, het downloaden van het CSS-bestand, het bouwen van het CSSOM en het toepassen van de stijl. Deze afhankelijkheidsketen veroorzaakt direct een hoge Resource Load Delay. Zie voor meer informatie over dit patroon onze handleiding over het uitstellen van achtergrondafbeeldingen.

De oplossing: De juiste aanpak is om geen background-image te gebruiken voor een kritiek LCP-element. Gebruik in plaats daarvan een standaard <img>-tag. Dit plaatst de URL van de afbeelding direct in de HTML, waar de preload-scanner deze meteen kan vinden. Je kunt hetzelfde visuele resultaat bereiken met CSS.

Implementatievoorbeeld:

Anti-pattern (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 content */
    }
    

Deze implementatie geeft hetzelfde visuele resultaat, maar zorgt ervoor dat de LCP-afbeelding op het vroegst mogelijke moment vindbaar is, wat de laadvertraging minimaliseert.

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 inhoud, inclusief de LCP-<img>-tag, wordt pas door JavaScript in de DOM ingevoegd nadat grote framework-bundles zijn gedownload, geparseerd en uitgevoerd. Dit proces verbergt de LCP-bron fundamenteel voor de preload-scanner, wat leidt tot een hoge ontdekkingsvertraging.

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

• Server-Side Rendering (SSR) of Static Site Generation (SSG): Structurele patronen zoals SSR of SSG genereren de volledige HTML op de server. De browser ontvangt een compleet document met de <img>-tag en het src-attribuut, waardoor de LCP-bron direct vindbaar is 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-property. Door deze op true in te stellen, voegt het framework automatisch de juiste <link rel="preload">- en fetchpriority="high"-attributen toe, zodat de afbeelding met de juiste prioriteit wordt ontdekt en opgehaald.

Oorzaak: loading="lazy" gebruiken op de LCP-afbeelding

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

De oplossing: Dit vraagt om zorgvuldigheid.

• Verwijder loading="lazy" van de LCP-afbeelding: Elke afbeelding die waarschijnlijk het LCP-element is, mag het attribuut loading="lazy" niet hebben. Het standaardgedrag van de browser is loading="eager", wat de juiste instelling is voor kritieke content boven de vouw. Het volledig weglaten van het loading-attribuut heeft hetzelfde effect.
• Audit en configureer externe tools: Je moet ook externe tools controleren. Veel CMS-platforms zoals WordPress en verschillende plug-ins voor afbeeldingsoptimalisatie passen automatisch lazy loading toe op alle afbeeldingen. Het is essentieel om deze tools zo te configureren dat ze de LCP-afbeelding hiervan uitsluiten. Dit houdt vaak in dat je een uitsluitingsregel maakt voor de eerste of eerste 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-pictogrammen of scripts voor een chatwidget, hoger in de <body> staan dan het LCP-element, worden ze als eerste ontdekt en in de wachtrij geplaatst voor download. Dit verbruikt de initiële netwerkbandbreedte en kan het downloaden van de LCP-bron vertragen. Een groot HTML-document kan ook een probleem zijn; als het LCP-element zich niet in de eerste datachunk bevindt die de browser ontvangt (ongeveer 14 KB), wordt de ontdekking ervan met minimaal één netwerkrondreis (round trip) vertraagd.

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

• Pas de volgorde van de HTML aan: Zorg er indien mogelijk voor dat de <img>-tag of het tekstblok voor het LCP-element zo vroeg mogelijk binnen de <body>-tag staat.
• De-prioriteer niet-kritieke afbeeldingen: Pas voor niet-essentiële afbeeldingen die vroeg in de HTML-bron moeten verschijnen (zoals pictogrammen in een header) loading="lazy" toe. Dit vertelt de preload-scanner om ze over te slaan, waardoor de downloadwachtrij beschikbaar blijft voor het LCP-element.
• Stel niet-essentiële scripts uit: Scripts voor analytics, advertenties of socialmedia-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-bron.

Geavanceerde prioritering met resource hints

Zodra de LCP-bron vindbaar 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 fijnmazige controle over ontdekking en prioritering.

Vroegtijdige ontdekking afdwingen met <link rel="preload">

<link rel="preload"> is geen hint, maar een instructie (directive). Het dwingt de browser om een bron met hoge prioriteit te downloaden, zelfs als deze nog niet vindbaar is voor de hoofdparser. Het plaatsen hiervan in de <head> van je HTML is the meest directe manier om late ontdekkingsproblemen op te lossen voor bronnen zoals lettertypen, CSS-achtergrondafbeeldingen of LCP-afbeeldingen die diep in de DOM staan. Zie voor volledige implementatiedetails en voorbeelden onze specifieke handleiding 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 plaatst de opgegeven bron direct in de wachtrij voor download. 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.

Responsive preloading

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

Voorbeeld van responsive 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">
    

Mogelijke valkuil

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

fetchpriority="high" en de prioriteitenwachtrij van de browser

Het attribuut fetchpriority is een hint die de relatieve prioriteit van de download van een bron aangeeft. Hiermee kun je de prioriteit van een bron binnen de downloadwachtrij van de browser beïnvloeden.

Hoe de prioriteit van de browser 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 de viewport met de prioriteit 'Low' en worden ze later opgewaardeerd naar 'High' zodra de browser de lay-out voltooit en vaststelt dat ze zichtbaar zijn. Deze opwaardering vereist dat de browser eerst CSS downloadt en parset, wat vertraging veroorzaakt. Het attribuut fetchpriority="high" omzeilt dit proces volledig door de afbeelding vanaf het moment van ontdekking in te stellen op de prioriteit 'High'. Dit is vooral effectief voor LCP-afbeeldingen omdat het de vertraging van de prioriteitsopwaardering wegneemt.

preload versus fetchpriority

Deze twee hints dienen verschillende maar aanvullende doelen. preload beïnvloedt wanneer een bron wordt ontdekt en aan de wachtrij wordt toegevoegd. fetchpriority beïnvloedt het prioriteitsniveau als de bron eenmaal in de wachtrij staat. Het is cruciaal om dit onderscheid te begrijpen: preload lost een late ontdekking op, terwijl fetchpriority een lage prioritering oplost. Voor veel LCP-afbeeldingen die al in de HTML staan, kan fetchpriority alleen al voldoende zijn. Zie ons artikel over resource prioritization voor een volledige handleiding over hoe deze twee samenwerken.

Best practice voor LCP

Voor de LCP-afbeelding is de optimale strategie om ze samen te gebruiken. Zorg ten eerste voor een vroege ontdekking door de <img>-tag vroeg in de HTML te plaatsen of door preload te gebruiken. Voeg ten tweede fetchpriority="high" rechtstreeks 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 gebruik je fetchpriority="low"

Het attribuut fetchpriority is niet alleen bedoeld om de prioriteit te verhogen. Je kunt ook fetchpriority="low" gebruiken om niet-kritieke bronnen die concurreren om bandbreedte met de LCP-afbeelding te de-prioriteren. Veelvoorkomende kandidaten zijn afbeeldingen boven de vouw die niet het LCP-element zijn (zoals kleine pictogrammen of avatars in de header) en gepreloade bronnen die wel nodig zijn maar geen haast hebben. Door de prioriteit van deze concurrerende bronnen expliciet te verlagen, creëer je meer bandbreedte 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="Avatar van de auteur" width="48" height="48">

Bewezen impact

In een case study over 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 externe partijen optimaliseren: preconnect en dns-prefetch

Het probleem

Als je LCP-bron op een extern domein wordt gehost, zoals een CDN voor afbeeldingen of een font-provider zoals Google Fonts, moet de browser een nieuwe netwerkverbinding met dat domein opzetten. Dit proces omvat een DNS-lookup, een TCP-handshake en een TLS-onderhandeling, die allemaal moeten worden voltooid voordat de eerste byte van de bron kan worden gedownload. Deze tijd voor het opzetten van de verbinding draagt rechtstreeks bij aan de Resource Load Delay voor cross-origin assets.

De oplossingen

• preconnect: Deze hint geeft de browser de opdracht om het volledige proces voor het opzetten van de verbinding (DNS, TCP en TLS) vooraf op de achtergrond uit te voeren voor een specifieke externe origin. Wanneer de bron daadwerkelijk wordt opgevraagd, is de verbinding al warm, wat de vertraging bij het opzetten wegneemt. Dit is zeer effectief en wordt aanbevolen voor de een of twee meest kritieke externe domeinen 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 externe domeinen.

Best practice voor implementatie

Bied beide hints aan om maximale compatibiliteit te garanderen. De browser gebruikt preconnect als dit wordt ondersteund, en valt anders terug op dns-prefetch. Het attribuut crossorigin 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 structurele beslissingen de Resource Load Delay nog verder verminderen.

De rol van een modern CDN

Een Content Delivery Network (CDN) is een basistechnologie voor webprestaties die indirect, maar aanzienlijk, de Resource Load Delay vermindert, vooral voor LCP-bronnen.

• Verbindingsoverhead verminderen: Door assets over een wereldwijd netwerk van servers te verspreiden, plaatst een CDN content geografisch dichter bij de gebruiker. Dit verkort inherent de round-trip time (RTT) die nodig is voor de DNS-lookup, TCP-handshake en TLS-onderhandeling, wat allemaal onderdelen zijn van de tijd om een verbinding op te zetten. Voor een LCP-afbeelding die op een CDN wordt gehost, vermindert dit direct de laadvertraging.
• Afbeeldings-CDN's: Gespecialiseerde afbeeldings-CDN's bieden een dubbel voordeel. Ze leveren het voordeel van nabijheid van een standaard CDN, terwijl ze ook veel complexe optimalisaties automatiseren die de Resource Load Duration verkorten, zoals on-the-fly formaataanpassingen van afbeeldingen, 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 verkort de tijd voor het opzetten van de verbinding en vermindert 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 LCP-vertraging volledig wegnemen voor volgende navigaties.

Mechanisme

Met deze API kunnen ontwikkelaars de browser declaratief informeren naar welke URL's een gebruiker waarschijnlijk hierna zal navigeren. Op basis van deze regels kan de browser ervoor kiezen om een doelpagina te prerenderen in een verborgen tabblad op de achtergrond, nog voordat de gebruiker überhaupt op de link klikt.

Impact op LCP

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

Voorbeeld van een use case

Op een e-commerce categoriepagina kunnen Speculation Rules worden gebruikt om de productdetailpagina's van de eerste paar items in de lijst te prerenderen. Wanneer een gebruiker op één van deze producten klikt, verschijnt de pagina direct.

Synthese van case studies: van theorie naar praktijk

Deze optimalisaties hebben een meetbare impact in de praktijk.

• Case 1: De transformerende kracht van preloading: Een experiment uitgevoerd door DebugBear op een pagina met een hoge laadvertraging geeft een spectaculair voorbeeld. De LCP-afbeelding was verborgen in een request-keten, waardoor de Resource Load Delay maar liefst 75% van de totale LCP-tijd in beslag nam. Door een enkele <link rel="preload">-hint te implementeren om de afbeelding vroeg vindbaar te maken, werd de Resource Load Delay teruggebracht tot slechts 2% van de LCP-tijd. Dit laat zien hoe een simpele structurele aanpassing een enorme prestatie-bottleneck kan oplossen.
• Case 2: Het loading="lazy" anti-pattern in de praktijk: Een ontwikkelaar op Stack Overflow rapporteerde een LCP op desktop met een verbijsterende laadvertraging van 1.430 ms, ondanks een snel netwerk. De oorzaak werd herleid naar een plug-in voor afbeeldingsoptimalisatie 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 uit te schakelen voor het LCP-element, waardoor het vroeg ontdekt en eager geladen kon worden. Dit illustreert hoe externe tools onbedoeld voor ernstige laadvertragingen kunnen zorgen.
• Case 3: De prestatieverbetering door fetchpriority: De case study van Google Flights levert duidelijk bewijs voor de impact van expliciete prioritering. Door simpelweg fetchpriority="high" toe te voegen aan de LCP-achtergrondafbeelding van de pagina, verbeterde de LCP-score met 700 ms; deze daalde van 2,6 seconden naar 1,9 seconden. Dit toont aan dat zelfs als een bron vindbaar is, het aangeven van het grote belang ervan aan de browser een cruciale stap is om de strijd om netwerkbandbreedte te winnen.

Netwerkinspectie in Chrome DevTools: Gebruik de sneltoets Ctrl + Shift + I om Chrome's Developer Tools te openen, selecteer vervolgens het tabblad 'Network' en herlaad de pagina. Kijk naar de volgorde van het laden. Je LCP-bron moet een van de eerste items zijn die in de wachtrij worden geplaatst om te downloaden. Als deze achterloopt op andere elementen, is er een probleem met de Resource Load Delay. Hieronder zie je een voorbeeld van een site waar de Resource Load Delay niet is geoptimaliseerd.

Gebruik Real User Monitoring (RUM)-data: Real User Monitoring-tools loggen vaak LCP-attributiedata. Met RUM kun je de uitsplitsing van LCP-subfasen visualiseren (in de loop van de tijd of per pagina), waardoor je een duidelijk beeld krijgt van de laadvertraging voor LCP-elementen op je hele site of per pagina. Het onderstaande voorbeeld toont een wereldwijde LCP-uitsplitsing met de bijbehorende laadvertraging.

Hoe verbeter je Load Delay

Een Resource Load Delay ontstaat wanneer de downloadvolgorde en timing van bronnen niet optimaal zijn. Er zijn in wezen twee directe manieren om dit op te lossen: prioriteer de LCP-bron of de-prioriteer niet-LCP-bronnen. Laten we een paar veelvoorkomende patronen bekijken:

LCP-tip: begrijp de preload-scanner: Moderne browsers gebruiken een mechanisme genaamd de preload-scanner, die de HTML snel 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 vertragingen oplevert. Zorgen dat je LCP-bronnen vindbaar zijn voor de preload-scanner kan een groot verschil maken bij het verminderen van de laadvertraging.

1. Optimaliseer de HTML-structuur

De browser (of de preload-scanner) verwerkt je HTML van boven naar beneden en plaatst bronnen in de wachtrij in de volgorde waarin ze verschijnen. Dit betekent: hoe hoger de LCP-bron in de HTML staat, hoe eerder deze in de wachtrij wordt geplaatst. Om dit te optimaliseren, verwijder of stel je overbodige bronnen uit vanaf de bovenkant van de HTML:

• Lazy-load onbelangrijke of verborgen afbeeldingen: Soms staan er afbeeldingen (zoals vlaggetjes voor taalspecifieke versies van je site of afbeeldingen in het menu) helemaal bovenaan in de HTML van je 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 and iets later in het laadproces in de wachtrij geplaatst.
• Verplaats onbelangrijke scripts naar de onderkant van de pagina: Verplaats scripts die absoluut niet belangrijk zijn voor de initiële laadtijd naar de onderkant van de pagina om te voorkomen dat ze kritieke bronnen vertragen. Denk bijvoorbeeld aan een chatwidget. 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, gebruik je in plaats daarvan een normale <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 direct detecteren en in de wachtrij plaatsen.

3. Gebruik Fetch Priority

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

Fetch Priority is meestal 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 niet-blokkerende 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 te instrueren kritieke bronnen, zoals de LCP-afbeelding, zo vroeg mogelijk op te halen. Preloads kunnen worden gebruikt om bronnen te laden waarnaar later in de HTML wordt verwezen (en die dus later in de wachtrij worden geplaatst) of zelfs om bronnen te laden waarnaar nog helemaal niet in de HTML wordt verwezen (zoals bij sommige sliders). Voor maximale effectiviteit wordt aanbevolen om preloads na stylesheets en vóór scripts in de head van de pagina te plaatsen.

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

5. Optimaliseer stijlen

Stylesheets worden normaal gesproken vóór de LCP-bron in de wachtrij geplaatst, en met een goede reden. Zonder stylesheets weet de browser niet hoe de pagina eruit zal zien en kan deze niet beginnen met de renderingfase. Een buitensporige CSS-grootte en een te groot aantal stylesheets zullen echter concurreren met de LCP-bron om de initiële bandbreedte.

6. Implementeer efficiënte lazy loading

Het loading-attribuut kan een tweesnijdend zwaard zijn. Gebruik loading="eager" (or laat het attribuut gewoon weg, aangezien 'eager' de standaardwaarde van de browser is) voor je LCP-bron, terwijl je loading="lazy" toepast op afbeeldingen buiten het scherm.

• Laad het LCP-element eager: Als het LCP-element lazy-loaded is, wordt het niet door de preload-scanner in de wachtrij geplaatst en laadt het veel later, wat de prestaties negatief beïnvloedt.
• Lazy-load viewport-afbeeldingen: Gebruik voor afbeeldingen die zich in de zichtbare viewport bevinden maar geen LCP-bronnen zijn, loading="lazy" om ze iets later in de downloadwachtrij te plaatsen. Dit vermindert de concurrentie om bandbreedte met de LCP-bron.
• Vermijd het direct laden van afbeeldingen buiten het scherm: afbeeldingen die zich niet in de zichtbare viewport bevinden, zullen helemaal geen download activeren, wat de concurrentie om bandbreedte volledig elimineert.

7. Browsercaching

Browsercaching stelt je in staat om netwerkverzoeken over te slaan voor bronnen die al lokaal op het apparaat van de gebruiker zijn opgeslagen. Hoewel het de eerste paginalading niet zal versnellen, verbetert het de laadtijden voor volgende paginabezoeken en terugkerende bezoekers. Dit is hoe browsercaching helpt bij Resource Load Delay:

• Cache concurrerende bronnen: Hoewel het cachen van de LCP-bron zelf een uitstekende strategie is, vermindert browsercaching de Resource Load Delay door netwerkbronnen op te slaan die kunnen concurreren met of vertraging kunnen veroorzaken voor de LCP-bron, zoals scripts, stylesheets en afbeeldingen.
• Verminder de serverbelasting: Caching vermindert het aantal verzoeken dat naar je 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 stelt browsers in staat om webpagina's te prefetchen of prerenderen op basis van voorspelde gebruikersnavigatie. Prefetching elimineert effectief de Time to First Byte-subfase van de LCP en heeft geen invloed 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 te zien is 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 één van de vier LCP-fasen. Zodra je de ontdekkingsvertraging hebt geminimaliseerd, kun je verdergaan met deze handleidingen:

• LCP-problemen identificeren en oplossen: De volledige diagnostische methodologie om alle LCP-problemen te vinden en op te lossen.
• Optimaliseer de LCP-afbeelding: Selectie van afbeeldingsformaten, responsive afbeeldingen, preloading en veelvoorkomende afbeeldingsfouten.
• Resource Load Duration: Nadat de browser de bron heeft ontdekt, verkort je de downloadtijd via compressie, moderne formaten en CDN-optimalisatie.
• Element Render Delay: Zorg er na het downloaden van de bron voor dat de browser deze direct kan renderen door de main thread vrij te maken.