Optimaliseer de LCP Resource Load Duration

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 uitmaakt, blijft het optimaliseren van de downloadduur essentieel voor het behalen van 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 user experience meten. De LCP meet de tijd die nodig is voordat het grootste contentful element (een afbeelding, video of tekstblok) zichtbaar wordt in de viewport. De Resource Load Duration is een subonderdeel van de LCP dat aangeeft hoeveel tijd wordt besteed aan het ophalen van de netwerkresource voor het LCP-element.

Wat is Resource Load Duration in LCP?

Resource Load Duration, vaak Load Duration genoemd, verwijst naar de tijd die de browser nodig heeft om de netwerkresource (bijv. een afbeelding) te downloaden die uiteindelijk het LCP-element wordt. Voor afbeeldingen en video's bestrijkt deze duur de periode vanaf het moment dat de afbeelding begint te downloaden tot het moment dat de browser de download voltooit. Voor tekst-gebaseerde LCP-elementen is de laadduur doorgaans nul. Google's LCP-optimalisatiegids verdeelt LCP in vier opeenvolgende subonderdelen, waarbij Resource Load Duration de tijd is 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 deze klaar is met downloaden. Vier hoofdfactoren bepalen de resource load duration:

• Bestandsgrootte: Grotere bestanden vereisen langere downloadtijden.
• Netwerksnelheid: Tragere verbindingen verlengen de laadduur vanzelfsprekend.
• Serverresponsiviteit: Vertragingen in de serverrespons vertragen het ophalen van resources.
• Gelijktijdige downloads: Resources die tegelijkertijd worden gedownload concurreren om bandbreedte, wat de laadtijden kan verhogen.

Hoe Resource Load Duration te detecteren

Er zijn twee effectieve manieren om resource load duration te identificeren en te 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 pagina. Zoek het LCP-element op in de netwerkverzoeken (als je het LCP-element wilt weten, probeer de Core Web Vitals Visualizer). De netwerkinspector toont je hoe lang het duurde om de resource te downloaden.

Pro Tip: Schakel grote verzoekrijen in om aanvullende details te zien zoals LCP-latentie, overgedragen grootte en werkelijke grootte.

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 laadduurtrends in de tijd of per pagina in kaart brengen en de pagina's of elementen identificeren die alles vertragen.

Hoe LCP Load Duration te verbeteren

Resource load duration-problemen ontstaan wanneer resources te groot zijn of via suboptimale netwerkpaden worden afgeleverd. Twee hoofdbenaderingen pakken dit aan: de datagrootte verkleinen of de datalevering optimaliseren.

1. Optimaliseer bestandsgrootte

Het optimaliseren van de bestandsgrootte vermindert het aantal bytes dat over het netwerk moet worden verzonden. Minder data betekent minder downloadtijd. Voor een volledige gids over beeldoptimalisatie, zie ons artikel over hoe afbeeldingen te optimaliseren.

Gebruik moderne afbeeldingsformaten

AVIF en WebP zijn de beste opties voor beeldcompressie. AVIF comprimeert tot 50% kleiner dan WebP voor complexe foto's, zonder zichtbaar kwaliteitsverlies. WebP heeft bredere browserondersteuning en werkt goed voor eenvoudigere afbeeldingen. Volgens de 2025 Web Almanac wordt WebP nu bij meer dan 40% van de afbeeldingsverzoeken gebruikt, terwijl AVIF-adoptie jaar na jaar ruwweg is verdubbeld maar nog steeds onder de 10% blijft.

De juiste kwaliteitsinstelling kiezen

Moderne afbeeldingsformaten zoals WebP en AVIF maken aanzienlijke kwaliteitsvermindering mogelijk voordat visuele degradatie merkbaar wordt. Als algemene regel ziet een kwaliteitsinstelling tussen 75 en 85 voor WebP, en tussen 60 en 75 voor AVIF, er op normale kijkafstand identiek uit aan het origineel, maar tegen een fractie van de bestandsgrootte. Test altijd met je specifieke afbeeldingen, aangezien de optimale kwaliteit afhangt van het contenttype (foto's vs. illustraties vs. tekst-zware afbeeldingen).

Beeldcompressie automatiseren met Sharp

Voor beeldoptimalisatie tijdens het buildproces is de sharp bibliotheek een van de snelste en meest gebruikte tools in het Node.js ecosysteem. Het volgende voorbeeld laat zien hoe je een afbeelding kunt converteren en comprimeren naar zowel WebP als AVIF formaat met geoptimaliseerde kwaliteitsinstellingen:

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
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 handelen plugins zoals ShortPixel of Imagify deze conversie automatisch af bij het uploaden.

Responsive afbeeldingen

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

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

Correcte afbeeldingsdimensies

Responsive afbeeldingen zijn slechts een deel van de oplossing, want responsive betekent niet dat ze de juiste grootte hebben. Het afstemmen van afbeeldingsdimensies op hun weergavegrootte is een van de meest voorkomende fouten die ik zie. Het serveren van een 2000px brede afbeelding voor een weergavegebied van 500px verspilt bandbreedte en kan de laadtijden merkbaar vertragen.

Lettertypebestand optimalisatie

Wanneer het LCP-element tekst is die wordt weergegeven met een aangepast weblettertype, wordt het lettertypebestand de LCP-resource. Optimaliseer de laadduur van lettertypen door:

• Gebruik WOFF2-formaat: WOFF2 biedt de beste compressie voor weblettertypen, doorgaans 30% kleiner dan WOFF en aanzienlijk kleiner dan TTF- of OTF-bestanden.
• Subset je lettertypen: Als je site alleen Latijnse tekens gebruikt, subset het lettertype om ongebruikte tekensets te verwijderen (Cyrillisch, Grieks, CJK). Tools zoals glyphhanger of pyftsubset kunnen dit automatiseren en verminderen de bestandsgrootte vaak met 50% of meer.
• Beperk lettertypevariaties: Elk gewicht en elke stijl (regulier, vet, cursief) is een apart bestandsdownload. Neem alleen de gewichten op die je ontwerp daadwerkelijk gebruikt.

2. Verbeter netwerkprestaties

Zodra de resourcegroottes zijn geoptimaliseerd, is de volgende stap het maximaliseren van de netwerksnelheid, of zelfs het volledig omzeilen van het netwerk.

Omzeil netwerkbehoeften met browsercaching

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

De meest effectieve opzet is om een Cache-Control header als volgt te verzenden:

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

• public: Staat toe dat de resource wordt gecached door zowel browsers als tussenliggende caches.
• max-age=31536000: Stelt de maximale tijd in dat de resource als vers wordt beschouwd op één jaar (31.536.000 seconden).
• immutable: Geeft aan dat de resource in de loop van de tijd niet zal veranderen, waardoor onnodige hervalidatieverzoeken worden voorkomen.

Om deze strategie veilig te laten werken, gebruik bestandsnamen met content-hashes (bijv. hero-abc123.webp) zodat wanneer de afbeelding verandert, de bestandsnaam ook verandert en de cache automatisch wordt doorbroken.

Brotli vs. Gzip compressie

Voor tekst-gebaseerde resources (HTML, CSS, JavaScript, SVG) is server-side compressie essentieel. Brotli, ontwikkeld door Google, presteert consistent beter dan Gzip in compressieverhouding terwijl het vergelijkbare decompressiesnelheden behoudt. De volgende vergelijking illustreert het verschil:

De ideale opzet is om statische assets vooraf te comprimeren met Brotli op een hoog compressieniveau (bijv. niveau 11) tijdens je buildproces, 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, waardoor meerdere verzoeken en antwoorden gelijktijdig over een enkele TCP-verbinding kunnen worden verzonden. Dit elimineert het head-of-line blocking probleem van HTTP/1.1, waarbij één trage resource alle andere kon vertragen. HTTP/2 ondersteunt ook headercompressie (HPACK) en server push.
• HTTP/3 gaat nog verder door TCP te vervangen door QUIC, een op UDP gebaseerd protocol. HTTP/3 elimineert TCP-niveau head-of-line blocking (waarbij een enkel verloren pakket alle streams stopt), biedt snellere verbindingsopbouw door 0-RTT (Zero Round Trip Time hervatting voor terugkerende bezoekers), en gaat beter om met pakketverlies. Deze verbeteringen versnellen voornamelijk de Time to First Byte, maar verminderen ook de resource load duration.

Om te controleren of HTTP/3 is ingeschakeld, inspecteer eenvoudig je netwerk met de sneltoets Ctrl+Shift+I. Selecteer het network-tabblad, klik met de rechtermuisknop op de netwerkkolom-headers en zorg dat 'protocol' is ingeschakeld. Herlaad de pagina en controleer het protocol. Voor HTTP/3 moet het protocol 'h3' weergeven.

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 vermindert de dataverplaatsingstijd (de round-trip time), wat direct invloed heeft op de Resource Load Duration.

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

• Automatische beeldoptimalisatie: Veel CDN's kunnen afbeeldingen on-the-fly comprimeren, verkleinen en converteren. Bijvoorbeeld, Cloudflare Polish, Imgix en Cloudinary kunnen automatisch WebP of AVIF serveren op basis van de Accept-header van de browser.
• Edge caching: Statische resources worden wereldwijd gecached op edge-nodes, waardoor het ophalen van de origin-server volledig wordt geëlimineerd.
• Protocoloptimalisatie: CDN's schakelen doorgaans standaard HTTP/2 en HTTP/3 in, samen met Brotli-compressie, zonder dat server-side configuratiewijzigingen nodig zijn.
• Verbindingshergebruik: Aangezien het CDN alle resources vanaf een enkel domein serveert, hergebruikt de browser een enkele verbinding, waardoor de overhead van meerdere DNS-lookups en TLS-handshakes wordt geëlimineerd.

Gespecialiseerde Image CDN's kunnen dit nog verder brengen door automatische, real-time optimalisaties te bieden zoals formaatconversie, formaat wijzigen en compressie.

Resources zelf hosten

Belangrijke en vroege netwerkresources moeten standaard altijd op de origin-server worden gehost. Zelf hosten vermijdt de noodzaak om verbinding te maken met servers van derden, wat aanzienlijke vertragingen kan veroorzaken door extra DNS-lookups, SSL-onderhandelingen en verbindingsopbouw. Zelf hosten garandeert het hergebruik van een enkele, reeds geopende verbinding en vermindert de overhead van het opzetten van afzonderlijke verbindingen. Zelf gehoste resources geven ook volledige controle over compressie- en cachebeleid.

3. Optimaliseer resourceprioritering

Na het verkleinen van de resourcegrootte en het optimaliseren van het netwerk, is er ook het probleem van netwerkconcurrentie. Wanneer de browser meerdere resources tegelijkertijd opvraagt via een trage verbinding, concurreren ze om bandbreedte. Minimaliseer die concurrentie door resourcedownloads 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, zodat ze niet worden vertraagd door scripts, widgets of third-party elementen die niet onmiddellijk geladen hoeven te worden. Het prioriteren van deze kritieke resources vermindert de laadtijd voor de content waar je gebruikers het meest om geven. De combinatie van preload (om late ontdekking op te lossen) en fetchpriority="high" (om netwerkconcurrentie op te lossen) is de krachtigste techniek om ervoor te zorgen dat de LCP-resource zo vroeg en zo snel mogelijk wordt opgehaald.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<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 lazy te laden. Stel het laden uit voor afbeeldingen of video's die niet onmiddellijk zichtbaar zijn, evenals achtergrond- of secundaire elementen. Het gebruik van loading="lazy" voor offscreen media is een goed startpunt, terwijl het verder uitstellen van andere niet-essentiële scripts en assets bandbreedte vrijmaakt en concurrentie met je kritieke resources vermindert, waardoor de hoofdcontent van je pagina snel geladen en weergegeven wordt. Pas nooit loading="lazy" toe op je LCP-afbeelding; dit is een kritiek antipatroon dat je score zal schaden.

4. Stel Speculation Rules in

Speculation Rules stelt browsers in staat om webpagina's te prefetchen of prerenderen op basis van voorspelde gebruikersnavigatie. 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 pagina in een verborgen tabblad en downloadt alle paginaresources. Dit elimineert het grootste deel van de laadduren voor het LCP-element zoals getoond in dit voorbeeld van een LCP-breakdown van een pregerenderde pagina.

Volgende stappen: Ga door met het optimaliseren van LCP

Resource Load Duration is slechts een van de vier LCP-fasen. Na het optimaliseren van de downloadtijd, ga verder met de andere LCP-fasen:

• LCP-problemen oplossen en identificeren: De complete diagnostische methodologie voor het vinden en oplossen van alle LCP-problemen met behulp van velddata en labtools.
• Optimaliseer de LCP-afbeelding: Selectie van afbeeldingsformaten, responsive afbeeldingen, preloading en veelgemaakte fouten bij beeldoptimalisatie.
• 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: Nadat de resource is gedownload, zorg ervoor dat de browser deze onmiddellijk kan weergeven door de main thread vrij te maken.