Optimaliseer de LCP Resource Load Duration

Deze handleiding is onderdeel van de Largest Contentful Paint (LCP)-sectie in ons Core Web Vitals-kenniscentrum. Resource Load Duration is de derde van vier opeenvolgende LCP-fasen en meet hoelang het duurt om de LCP-resource via het netwerk te downloaden. Hoewel Resource Load Delay vaak een groter deel van de LCP-tijd opslokt, blijft het optimaliseren van de downloadduur essentieel voor een goede LCP-score.

Optimaliseer de LCP Resource Load Duration

Largest Contentful Paint (LCP) is een van de drie Core Web Vitals-prestatiemetrics die je online gebruikerservaring meten. De LCP meet hoelang het duurt voordat het grootste inhoudelijke element (een afbeelding, video of tekstblok) zichtbaar is in de viewport. De Resource Load Duration is een subonderdeel van de LCP dat aangeeft hoeveel tijd er opgaat aan het ophalen van de netwerk-resource voor het LCP-element.

Wat is Resource Load Duration binnen LCP?

Resource Load Duration, vaak Load Duration genoemd, is de tijd die de browser nodig heeft om de netwerk-resource (zoals een afbeelding) te downloaden die uiteindelijk het LCP-element wordt. Bij afbeeldingen en video's loopt deze duur vanaf de start van de download totdat de browser de download afrondt. Bij LCP-elementen van tekst is de laadduur meestal nul. Google's LCP-optimalisatiehandleiding splitst LCP op in vier opeenvolgende subonderdelen. Resource Load Duration is daarin de tijd die opgaat aan het downloaden van de resource-bytes.

Resource Load Duration meet vanaf het moment dat de browser start met het downloaden van de LCP-resource tot de download klaar is. Vier factoren bepalen deze duur:

• Bestandsgrootte: Grotere bestanden hebben een langere downloadtijd nodig.
• Netwerksnelheid: Een tragere verbinding verlengt de laadduur direct.
• Reactiesnelheid van de server: Vertraging in de serverrespons vertraagt het ophalen van de resource.
• Gelijktijdige downloads: Resources die tegelijk downloaden concurreren om bandbreedte, wat de laadtijd kan verlengen.

Zo meet je de Resource Load Duration

Er zijn twee effectieve manieren om de Resource Load Duration vast te stellen en te meten:

Netwerkinspectie in Chrome DevTools: Gebruik de sneltoets Ctrl + Shift + I om Chrome DevTools te openen, kies het tabblad "Network" en herlaad de pagina. Zoek het LCP-element op tussen de netwerk-requests (wil je weten wat het LCP-element is, probeer dan de Core Web Vitals Visualizer). In het netwerkoverzicht zie je precies hoelang het downloaden van de resource duurde.

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

Gebruik Real User Monitoring (RUM)-data:

RUM-tools slaan vaak LCP-attributiedata op. Deze attributiedata voor de Largest Contentful Paint bevat informatie over de resource load duration. Hiermee breng je trends in laadduur in kaart over de tijd of per pagina, en zie je direct welke pagina's of elementen voor vertraging zorgen.

Stappenplan: wil je een nauwkeurige labmeting, neem dan een trace op in het Performance-paneel. Het LCP-breakdown-inzicht toont de resource load duration naast de andere drie subonderdelen. Volledige walkthrough: Diagnosticeer LCP met het Chrome DevTools Performance-paneel.

Zo verbeter je de LCP Load Duration

Problemen met de resource load duration ontstaan als resources te groot zijn of via een suboptimaal netwerkpad worden verstuurd. Dit pak je op twee manieren aan: de bestandsgrootte verkleinen of de data-overdracht optimaliseren.

1. Optimaliseer de bestandsgrootte

Het optimaliseren van de bestandsgrootte verlaagt het aantal bytes dat over het netwerk moet. Minder data betekent minder downloadtijd. Voor een complete handleiding over afbeeldingsoptimalisatie, bekijk ons artikel over afbeeldingen optimaliseren.

Gebruik moderne afbeeldingsformaten

AVIF en WebP zijn de beste keuzes voor afbeeldingscompressie. Bij complexe foto's comprimeert AVIF tot 50% kleiner dan WebP, zonder zichtbaar kwaliteitsverlies. WebP heeft bredere browserondersteuning en werkt prima voor eenvoudigere afbeeldingen. Volgens de Web Almanac van 2025 wordt WebP inmiddels bij ruim 40% van alle image requests gebruikt, terwijl het aandeel van AVIF jaar op jaar ruwweg is verdubbeld, maar nog altijd onder de 10% ligt.

Kies de juiste kwaliteitsinstelling

Bij moderne afbeeldingsformaten zoals WebP en AVIF kun je de kwaliteit flink verlagen voordat kwaliteitsverlies zichtbaar wordt. Als vuistregel geldt: een kwaliteitsinstelling tussen 75 en 85 voor WebP en tussen 60 en 75 voor AVIF oogt op normale kijkafstand identiek aan het origineel, maar tegen een fractie van de bestandsgrootte. Test dit altijd met je eigen afbeeldingen; de optimale kwaliteit hangt af van het type content (foto's vs. illustraties vs. afbeeldingen met veel tekst).

Afbeeldingscompressie automatiseren met Sharp

Voor afbeeldingsoptimalisatie tijdens de build is de sharp-library een van de snelste en meest gebruikte tools in het Node.js-ecosysteem. In het volgende voorbeeld zie je hoe je een afbeelding converteert en comprimeert naar zowel WebP als AVIF met geoptimaliseerde kwaliteitsinstellingen:

const sharp = require('sharp');

// Converteer naar WebP met geoptimaliseerde kwaliteit
await sharp('input.jpg')
  .resize(1200)  // Schaal naar maximaal benodigde breedte
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Converteer naar AVIF met geoptimaliseerde kwaliteit
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Genereer meerdere formaten voor responsive afbeeldingen
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Deze aanpak genereert alle varianten die je nodig hebt voor een responsive <picture>-element met ondersteuning voor moderne formaten. Voor WordPress-sites regelen plugins zoals ShortPixel of Imagify deze conversie automatisch bij het uploaden.

Responsive afbeeldingen

Met het <picture>-element en het srcset-attribuut serveer je verschillende afbeeldingsformaten op basis van het scherm: kleinere versies voor mobiel, hogere resoluties voor grotere schermen. Dit is een voorbeeld van zo'n setup:

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

Juiste afmetingen van afbeeldingen

Responsive afbeeldingen zijn slechts het halve werk: responsive betekent namelijk niet dat ze het juiste formaat hebben. Het niet goed laten aansluiten van afbeeldingsafmetingen op het weergaveformaat is een van de meest gemaakte fouten die ik zie. Een afbeelding van 2000px breed inladen voor een weergavegebied van 500px verspilt bandbreedte en vertraagt de laadtijd flink.

Fontbestanden optimaliseren

Is het LCP-element een tekst die rendert met een custom web font, dan is het fontbestand de LCP-resource. Optimaliseer de laadduur van het font zo:

• Gebruik het WOFF2-formaat: WOFF2 biedt de beste compressie voor web fonts: doorgaans 30% kleiner dan WOFF en aanzienlijk kleiner dan TTF- of OTF-bestanden.
• Subset je fonts: Gebruikt je site alleen Latijnse tekens, subset het font dan om ongebruikte tekensets (Cyrillisch, Grieks, CJK) te verwijderen. Tools zoals glyphhanger of pyftsubset kunnen dit automatiseren, wat de bestandsgrootte van het font vaak met 50% of meer verkleint.
• Beperk het aantal fontvariaties: Elk gewicht en elke stijl (regular, bold, italic) is een afzonderlijke download. Laad alleen de gewichten in die je ontwerp echt gebruikt.

2. Verbeter netwerkprestaties

Zijn de bestandsgroottes eenmaal geoptimaliseerd, dan is de volgende stap het maximaliseren van de netwerksnelheid — of het netwerk zelfs helemaal overslaan.

Sla het netwerk over met browser caching

Er is geen snellere netwerkverbinding dan een netwerkverbinding die je overslaat. Browsers kunnen statische content (afbeeldingen, scripts, stylesheets) rechtstreeks uit de lokale cache serveren. Configureer de server om de juiste caching-instructies naar de browser te sturen.

De meest effectieve setup is het meesturen van een Cache-Control-header zoals deze:

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

• public: Zorgt dat zowel browsers als tussenliggende caches de resource mogen opslaan.
• max-age=31536000: Stelt de maximale tijd dat de resource als vers geldt in op één jaar (31.536.000 seconden).
• immutable: Geeft aan dat de resource in de loop van de tijd niet verandert, wat onnodige revalidatie-requests voorkomt.

Om deze strategie veilig toe te passen, gebruik je content-hashed bestandsnamen (zoals hero-abc123.webp). Verandert de afbeelding, dan verandert ook de bestandsnaam en bust je de cache automatisch.

Brotli vs. Gzip-compressie

Voor tekstuele resources (HTML, CSS, JavaScript, SVG) is server-side compressie essentieel. Brotli, ontwikkeld door Google, presteert qua compressieratio structureel beter dan Gzip, terwijl de decompressiesnelheid vergelijkbaar blijft. De volgende vergelijking toont het verschil:

De ideale setup is om statische assets tijdens je build-proces vooraf met Brotli te comprimeren op een hoog niveau (zoals level 11), met Gzip als fallback voor clients die geen Brotli ondersteunen. De meeste CDN's, waaronder Cloudflare, regelen dit automatisch. Meer weten over CDN-configuratie? Bekijk onze handleiding over Cloudflare configureren voor performance.

HTTP/2 en HTTP/3: voordelen van moderne protocollen

Het delivery-protocol maakt vooral verschil als de browser meerdere resources tegelijk downloadt.

• HTTP/2 introduceerde multiplexing, waarmee meerdere requests en responses tegelijk over één TCP-verbinding worden verstuurd. Dit elimineert het head-of-line blocking-probleem van HTTP/1.1, waarbij één trage resource alle andere kon ophouden. HTTP/2 ondersteunt daarnaast header-compressie (HPACK) en server push.
• HTTP/3 gaat nog een stap verder en vervangt TCP door QUIC, een protocol op basis van UDP. HTTP/3 rekent af met head-of-line blocking op TCP-niveau (waarbij één verloren pakket alle streams blokkeert), zet verbindingen sneller op via 0-RTT (Zero Round Trip Time-hervatting voor terugkerende bezoekers) en gaat beter om met pakketverlies. Deze verbeteringen versnellen vooral de Time to First Byte, maar verkorten ook de resource load duration.

Wil je controleren of HTTP/3 actief is? Inspecteer je netwerk met de sneltoets Ctrl+Shift+I. Kies het tabblad Network, klik met de rechtermuisknop op de kolomkoppen en zorg dat 'protocol' is aangevinkt. Herlaad de pagina en controleer het protocol. Bij HTTP/3 staat hier 'h3'.

Content Delivery Networks (CDN)

Een CDN is een netwerk van gedistribueerde servers die statische resources zoals afbeeldingen, CSS en JavaScript cachen en serveren vanaf locaties dichter bij de gebruiker. Dit verkort de reistijd van data (de round-trip time), wat direct invloed heeft op de Resource Load Duration.

Naast fysieke nabijheid bieden moderne CDN's verschillende prestatievoordelen die de laadduur verkorten:

• Automatische afbeeldingsoptimalisatie: Veel CDN's kunnen afbeeldingen on the fly comprimeren, schalen en converteren. Cloudflare Polish, Imgix en Cloudinary serveren bijvoorbeeld automatisch WebP of AVIF op basis van de Accept-header van de browser.
• Edge caching: Statische resources worden wereldwijd op edge nodes gecachet, waardoor het ophalen vanaf de origin server vaak helemaal niet meer nodig is.
• Protocol-optimalisatie: CDN's schakelen HTTP/2 en HTTP/3 meestal standaard in, net als Brotli-compressie, zonder dat je configuratiewijzigingen op de server hoeft door te voeren.
• Hergebruik van verbindingen: Omdat het CDN alle resources vanaf één domein serveert, hergebruikt de browser één enkele verbinding. Dat scheelt de overhead van meerdere DNS-lookups en TLS-handshakes.

Gespecialiseerde Image CDN's gaan nog een stap verder met automatische, realtime optimalisaties zoals formaatconversie, schalen en compressie.

Resources zelf hosten

Belangrijke resources die vroeg in het laadproces nodig zijn, horen standaard op de origin server te staan. Door zelf te hosten omzeil je verbindingen met third-party servers, die vaak flinke vertraging opleveren door extra DNS-lookups, SSL-onderhandelingen en connection setups. Zelf hosten zorgt voor hergebruik van één reeds geopende verbinding en voorkomt de overhead van aparte verbindingen opzetten. Bovendien heb je bij zelf gehoste resources volledige controle over compressie- en cache-policies.

3. Optimaliseer de prioriteit van resources

Naast het verkleinen van resources en het optimaliseren van het netwerk speelt ook concurrentie op het netwerk een rol. Vraagt de browser op een trage verbinding meerdere resources tegelijk op, dan strijden ze om bandbreedte. Die concurrentie beperk je door het downloaden van resources strak te plannen.

Geef kritieke resources prioriteit

Markeer essentiële resources, zoals hero images of above-the-fold CSS, met fetchpriority="high". Dit geeft de browser het signaal om deze assets als eerste te downloaden, zodat ze niet worden opgehouden door scripts, widgets of third-party elementen die niet direct nodig zijn. Door deze kritieke resources voorrang te geven, verkort je de laadtijd van de content die voor je gebruikers het belangrijkst is. De combinatie van preload (om late ontdekking op te lossen) en fetchpriority="high" (om netwerkconcurrentie te voorkomen) is de krachtigste techniek om te zorgen dat de LCP-resource zo vroeg en zo snel mogelijk binnen is.

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

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

Verminder netwerkconcurrentie

Stroomlijn initiële downloads door niet-essentiële assets uit te stellen of via lazy loading te laden. Stel het laden uit van afbeeldingen of video's die niet direct zichtbaar zijn, net als van achtergrond- of secundaire elementen. loading="lazy" gebruiken voor offscreen media is een goed startpunt. Door daarnaast niet-essentiële scripts en assets uit te stellen, maak je bandbreedte vrij en voorkom je concurrentie met je kritieke resources. Zo laadt en toont de belangrijkste content van je pagina snel. Zet nooit loading="lazy" op je LCP-afbeelding; dit is een kritiek anti-pattern dat funest is voor je score.

4. Stel Speculation Rules in

Speculation Rules stelt browsers in staat om webpagina's alvast te prefetchen of te prerenderen op basis van voorspeld navigatiegedrag van gebruikers. Prefetching elimineert in feite de Time to First Byte-fase van de LCP en heeft geen invloed op de resource load duration. Prerendering rendert de volgende pagina in een verborgen tabblad en downloadt alvast alle resources van de pagina. Hierdoor verdwijnt vrijwel de volledige laadduur van het LCP-element, zoals te zien is in dit voorbeeld van een LCP-breakdown bij een geprerenderde pagina.

Volgende stappen: ga door met het optimaliseren van LCP

Resource Load Duration is slechts een van de vier LCP-fasen. Heb je de downloadtijd geoptimaliseerd, ga dan door met de overige LCP-fasen:

• LCP-problemen identificeren en fixen: De complete diagnosemethodiek om alle LCP-problemen op te sporen en te fixen met behulp van field data en lab tools.
• De LCP-afbeelding optimaliseren: Keuze van afbeeldingsformaten, responsive afbeeldingen, preloading en veelgemaakte fouten bij afbeeldingsoptimalisatie.
• Resource Load Delay: Zorg dat de browser de LCP-resource zo vroeg mogelijk ontdekt. Dit is vaak een groter knelpunt dan de laadduur zelf.
• Element Render Delay: Zorg dat de browser het element na het downloaden direct kan painten door de main thread vrij te houden.