Optimaliseer de laadduur van de LCP-resource.

Deze gids maakt deel uit van de Largest Contentful Paint (LCP)-sectie van ons Core Web Vitals-kenniscentrum. Resource load duration is de derde van vier opeenvolgende LCP-fasen en meet de tijd die nodig is om de LCP-resource via het netwerk te downloaden. Hoewel Resource Load Delay vaak een groter deel van de LCP-tijd inneemt, blijft het optimaliseren van de downloadtijd essentieel voor een goede LCP-score.

Optimaliseer de LCP resource load duration

Largest Contentful Paint (LCP) is een van de drie Core Web Vitals prestatiestatistieken die je online UX meten. De LCP registreert de tijd die nodig is voordat het grootste content-element (een afbeelding, video of tekstblok) zichtbaar wordt in de viewport. De resource load duration is een subonderdeel van de LCP. Het geeft aan hoeveel tijd er wordt besteed aan het ophalen van de netwerk-resource voor het LCP-element.

Wat is resource load duration in LCP?

Resource load duration, vaak gewoon laadduur genoemd, is de tijd die de browser nodig heeft om de netwerk-resource (bijv. een afbeelding) te downloaden die uiteindelijk het LCP-element wordt. Voor afbeeldingen en video's loopt deze duur van de start tot het einde van de download door de browser. Voor op tekst gebaseerde LCP-elementen is de laadduur doorgaans nul. Google's LCP-optimalisatiegids deelt de LCP op in vier opeenvolgende subonderdelen. De resource load duration is de tijd die daadwerkelijk wordt besteed aan het downloaden van de resource-bytes.

Resource load duration wordt gemeten vanaf het moment dat de browser begint met het downloaden van de LCP-resource tot het moment dat de download is voltooid. Vier hoofdfactoren bepalen de resource load duration:

• Bestandsgrootte: Grotere bestanden vereisen langere downloadtijden.
• Netwerksnelheid: Tragere verbindingen verlengen de laadduur.
• Server-responsiviteit: Vertragingen in server-response vertragen het ophalen van resources.
• Gelijktijdige downloads: Resources die tegelijkertijd worden gedownload, strijden om bandbreedte. Dit kan laadtijden verhogen.

Hoe detecteer je resource load duration

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

Netwerkinspectie in Chrome DevTools: Gebruik de sneltoets Ctrl + Shift + I om Chrome's Developer Tools te openen. Selecteer vervolgens het "Network"-tabblad en herlaad de page. Zoek het LCP-element op in de netwerkverzoeken (als je het LCP-element wilt weten, probeer dan de Core Web Vitals Visualizer). De netwerkinspector toont je hoe lang het duurde om de resource te downloaden.

Pro-tip: Schakel large request rows in om extra details te zien, zoals LCP-latentie, transferred size en actual size.

Gebruik Real User Monitoring (RUM)-data:

RUM-tools loggen vaak LCP-attributiedata. Attributiedata voor de Largest Contentful Paint bevat informatie over de resource load duration. Met deze data kun je trends in laadduur over tijd of per page in kaart brengen en de pagina's of elementen spotten die de boel vertragen.

Stapsgewijze gids: neem voor een nauwkeurige lab-meting een trace op in het Performance-paneel. Het LCP-breakdown-inzicht toont de resource load duration naast de andere drie subonderdelen. Volledige walkthrough: Diagnoseer LCP met het Chrome DevTools Performance-paneel.

Hoe verbeter je de LCP load duration

Problemen met resource load duration treden op wanneer resources te groot zijn of via suboptimale netwerkpaden worden geleverd. Twee hoofdmethoden pakken dit aan: data-omvang verkleinen of data-levering optimaliseren.

1. Optimaliseer bestandsgrootte

Het optimaliseren van de bestandsgrootte vermindert het aantal bytes dat over het netwerk wordt verzonden. Minder data betekent minder downloadtijd. Voor een volledige gids over afbeeldingsoptimalisatie, zie ons artikel over hoe je afbeeldingen optimaliseert.

Gebruik moderne afbeeldingsformaten

AVIF en WebP zijn de beste opties voor afbeeldingscompressie. AVIF comprimeert tot 50% kleiner dan WebP voor complexe foto's, zonder zichtbaar kwaliteitsverlies. WebP heeft bredere browser-ondersteuning en werkt goed voor eenvoudigere afbeeldingen. Volgens de 2025 Web Almanac wordt WebP nu gebruikt bij ruim 40% van de afbeeldingsverzoeken. De adoptie van AVIF is ruwweg verdubbeld vergeleken met vorig jaar, maar ligt nog steeds onder de 10%.

Kies de juiste kwaliteitsinstelling

Moderne afbeeldingsformaten zoals WebP en AVIF laten aanzienlijke kwaliteitsverlaging toe voordat visuele degradatie merkbaar wordt. Als algemene regel geldt dat een kwaliteitsinstelling tussen 75 en 85 voor WebP, en tussen 60 en 75 voor AVIF, er op normale kijkafstanden identiek uitziet als het origineel, maar dan voor een fractie van de bestandsgrootte. Test altijd met je specifieke afbeeldingen. De optimale kwaliteit hangt af van het content-type (foto's vs. illustraties vs. tekstzware afbeeldingen).

Automatiseer afbeeldingscompressie met Sharp

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

const sharp = require('sharp');

// Converteer naar WebP met geoptimaliseerde kwaliteit
await sharp('input.jpg')
  .resize(1200)  // Schaal naar de 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 moderne formaat-ondersteuning. Voor WordPress-sites handelen plugins zoals ShortPixel of Imagify deze conversie automatisch af bij het uploaden.

Responsive afbeeldingen

Het <picture>-element en het srcset-attribuut serveren verschillende afbeeldingsformaten op basis van het scherm: kleinere versies voor mobiel, hogere resolutie voor grotere schermen. Hier is een voorbeeld-setup:

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

Correcte afbeeldingsafmetingen

Responsive afbeeldingen zijn slechts een deel van de oplossing. Responsive betekent niet dat ze het juiste formaat hebben. Het matchen van afbeeldingsafmetingen aan hun weergavegrootte is een van de meest gemaakte fouten die ik zie. Een afbeelding van 2000px breed serveren voor een weergavegebied van 500px verspilt bandbreedte en vertraagt laadtijden aanzienlijk.

Optimalisatie van font-bestanden

Wanneer het LCP-element tekst is die wordt gerenderd met een custom web font, wordt het font-bestand de LCP-resource. Optimaliseer de laadduur van je font door:

• Gebruik het WOFF2-formaat: WOFF2 biedt de beste compressie voor web fonts. Het is doorgaans 30% kleiner dan WOFF en aanzienlijk kleiner dan TTF- of OTF-bestanden.
• Subset je fonts: Als je site alleen Latijnse karakters gebruikt, subset het font dan om ongebruikte karaktersets (Cyrillisch, Grieks, CJK) te verwijderen. Tools zoals glyphhanger of pyftsubset automatiseren dit en verminderen de bestandsgrootte van het font vaak met 50% of meer.
• Beperk font-variaties: Elke dikte en stijl (regular, bold, italic) is een aparte bestand-download. Voeg alleen de diktes toe die je design daadwerkelijk gebruikt.

2. Verbeter netwerkprestaties

Zodra de groottes van resources zijn geoptimaliseerd, is de volgende stap het maximaliseren van de netwerksnelheid. Of zelfs het netwerk volledig omzeilen.

Omzeil het netwerk met browser caching

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

De meest effectieve setup is om een Cache-Control header als volgt mee te sturen:

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

• public: Staat toe dat de resource wordt gecachet door zowel browsers als intermediaire caches.
• max-age=31536000: Stelt de maximale tijd dat de resource als vers wordt beschouwd in op één jaar (31.536.000 seconden).
• immutable: Geeft aan dat de resource in de loop der tijd niet verandert. Dit voorkomt onnodige revalidatieverzoeken.

Om deze strategie veilig te laten werken, gebruik je content-hashed bestandsnamen (bijv. hero-abc123.webp). Wanneer de afbeelding verandert, verandert de bestandsnaam mee, wat de cache automatisch breekt.

Brotli vs. Gzip compressie

Voor op tekst gebaseerde resources (HTML, CSS, JavaScript, SVG) is server-side compressie essentieel. Brotli, ontwikkeld door Google, overtreft Gzip consistent in compressieratio terwijl de decompressiesnelheden vergelijkbaar blijven. De volgende vergelijking illustreert het verschil:

De ideale setup is om statische assets pre-compressed te maken met Brotli op een hoog compressieniveau (bijv. level 11) tijdens je build-proces, en Gzip te gebruiken als fallback voor clients die Brotli niet ondersteunen. De meeste CDN's, waaronder Cloudflare, handelen dit automatisch af. Voor meer details over CDN-configuratie, zie onze gids over Cloudflare configureren voor prestaties.

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

Het leveringsprotocol is het belangrijkst wanneer de browser meerdere resources tegelijkertijd downloadt.

• HTTP/2 introduceerde multiplexing. Dit stelt je in staat om meerdere requests en responses tegelijkertijd over een enkele TCP-verbinding te sturen. Dit elimineert het head-of-line blocking probleem van HTTP/1.1, waarbij één trage resource alle andere kon vertragen. HTTP/2 ondersteunt ook header-compressie (HPACK) en server push.
• HTTP/3 gaat hierin verder door TCP te vervangen door QUIC, een op UDP gebaseerd protocol. HTTP/3 elimineert TCP-level head-of-line blocking (waarbij een enkel verloren pakketje alle streams laat vastlopen). Het zorgt voor snellere verbindingen via 0-RTT (Zero Round Trip Time hervatting voor terugkerende bezoekers) en gaat beter om met packet loss. Deze verbeteringen versnellen voornamelijk de Time to First Byte, maar ze verlagen ook de resource load duration.

Om te controleren of HTTP/3 is ingeschakeld, inspecteer je je netwerk met de sneltoets Ctrl+Shift+I. Selecteer het network-tabblad, klik met de rechtermuisknop op de kolomkoppen van het netwerk en zorg dat 'protocol' is aangevinkt. Herlaad de page en controleer het protocol. Voor HTTP/3 moet het protocol 'h3' luiden.

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 user. Dit vermindert de data-reistijd (de round-trip time), wat directe invloed heeft op de resource load duration.

Naast 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 kunnen bijvoorbeeld automatisch WebP of AVIF serveren op basis van de Accept-header van de browser.
• Edge caching: Statische resources worden wereldwijd gecachet op edge nodes. Dit elimineert de noodzaak om ze volledig van de origin server op te halen.
• Protocol-optimalisatie: CDN's schakelen standaard vaak HTTP/2 en HTTP/3 in, samen met Brotli-compressie. Er zijn geen server-side configuratiewijzigingen nodig.
• Verbindingen hergebruiken: Omdat het CDN alle resources vanaf één enkel domein serveert, hergebruikt de browser één verbinding. Dit elimineert de overhead van meerdere DNS lookups en TLS handshakes.

Gespecialiseerde Image CDN's gaan nog een stap verder door automatische, real-time optimalisaties te bieden zoals formaat-conversie, schalen en compressie.

Resources self-hosten

Belangrijke en vroege netwerk-resources horen standaard altijd op de origin server te staan. Self-hosting vermijdt de noodzaak om verbinding te maken met third-party servers. Deze kunnen aanzienlijke vertragingen veroorzaken door extra DNS lookups, SSL-onderhandelingen en verbindingsopbouw. Self-hosting garandeert het hergebruik van één enkele, reeds geopende verbinding en verlaagt de overhead van het opzetten van aparte verbindingen. Self-hosted resources geven je bovendien volledige controle over compressie- en cache-beleid.

3. Optimaliseer resource-prioritering

Na het verkleinen van de resource-grootte en het optimaliseren van het netwerk, is er ook nog het probleem van netwerkcompetitie. Wanneer de browser meerdere resources tegelijkertijd opvraagt op een trage verbinding, strijden ze om bandbreedte. Minimaliseer die competitie door resource-downloads in te plannen.

Prioriteer kritieke resources

Markeer essentiële resources, zoals hero-afbeeldingen of above-the-fold CSS, met fetchpriority="high". Dit signaleert de browser om deze assets als eerste te downloaden. Zo voorkomen we dat ze vastlopen door scripts, widgets of third-party elementen die geen directe lading nodig hebben. Het prioriteren van deze kritieke resources verlaagt de laadtijd voor de content waar je users het meest om geven. De combinatie van preload (om late ontdekking op te lossen) en fetchpriority="high" (om netwerkcompetitie op te lossen) is de krachtigste techniek om ervoor te zorgen dat de LCP-resource zo vroeg en zo snel mogelijk wordt opgehaald.

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

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

Verminder netwerkcompetitie

Stroomlijn initiële downloads door niet-essentiële assets uit te stellen of via lazy loading in te laden. Stel het inladen uit voor afbeeldingen of video's die niet direct zichtbaar zijn, evenals achtergrond- of secundaire elementen. Het gebruik van loading="lazy" voor offscreen media is een goed startpunt. Het verder uitstellen van andere niet-essentiële scripts en assets maakt bandbreedte vrij en vermindert de competitie met je kritieke resources. Dit houdt de hoofdcontent van je page snel om te laden en weer te geven. Pas nooit loading="lazy" toe op je LCP-afbeelding; dit is een kritiek anti-pattern dat je score schaadt.

4. Stel Speculation Rules in

Speculation Rules stelt browsers in staat om webpagina's te prefetchen of prerenderen op basis van voorspelde user-navigatie. Prefetching elimineert effectief het Time to First Byte-subonderdeel van de LCP en heeft geen impact op de resource load duration. Prerendering rendert de volgende page in een verborgen tabblad en downloadt alle page-resources. Dit elimineert de meeste laadduur voor het LCP-element, zoals te zien is in deze voorbeeld-LCP-breakdown van een geprerenderde page.

Volgende stappen: blijf LCP optimaliseren

Resource load duration is slechts een van de vier LCP-fasen. Na het optimaliseren van de downloadtijd ga je door met de andere LCP-fasen:

• Fix &amp; identificeer LCP-problemen: De complete diagnostische methode voor het vinden en oplossen van alle LCP-problemen met behulp van field data en lab-tools.
• Optimaliseer de LCP-afbeelding: Selectie van afbeeldingsformaat, responsive afbeeldingen, preloading en veelgemaakte fouten bij afbeeldingsoptimalisatie.
• Resource Load Delay: Zorg ervoor dat de browser de LCP-resource zo vroeg mogelijk ontdekt. Dit is vaak een grotere bottleneck dan de laadduur zelf.
• Element Render Delay: Zorg er na het downloaden van de resource voor dat de browser deze onmiddellijk kan painten door de main thread vrij te maken.