Optimaliseer de Largest Contentful Paint-afbeelding

Optimaliseer de Largest Contentful Paint-afbeelding

Deze handleiding is onderdeel van de Largest Contentful Paint (LCP) hub. Op de meeste websites is het LCP-element een afbeelding. Als je de afbeelding verkeerd aanpakt, lijdt je LCP-score. Dit artikel behandelt alle technieken om deze snel te maken.

Volgens Google heeft slechts 65% van alle paginaweergaven op internet (inclusief desktop en mobiel) een 'goede' Largest Contentful Paint-score. Dat betekent dat 35% van de paginaweergaven faalt, deels door fouten met afbeeldingen. Dit artikel bespreekt veelvoorkomende best practices en fouten wanneer afbeeldingen het Largest Contentful Paint-element worden.

Hoewel al deze factoren belangrijk zijn: is je LCP-element een afbeelding (en dat is vaak het geval), dan zijn er eenvoudige stappen om deze zo snel mogelijk te laten laden!

Experimenten met de Largest Contentful Paint

Ik zeg altijd: luister en leer, maar geloof niemand op zijn woord. Er zijn te veel 'goeroes' die verkeerde informatie verspreiden. Daarom heb ik een volledig automatisch LCP-experiment gemaakt waarin je zelf kunt zien wat er gebeurt als het LCP-element niet optimaal wordt geladen. Bekijk mijn LCP-test op GitHub of probeer de live demo!

De test voert automatisch verschillende LCP-scenario's uit en toont de resultaten. Hieronder bespreek ik deze scenario's en leg ik uit hoe en waarom ze de LCP-afbeelding versnellen of vertragen.

1. Beheers de LCP-kandidaat: de tekst-eerst-strategie

De snelste manier om een op afbeeldingen gebaseerde Largest Contentful Paint te verbeteren? Gebruik geen afbeelding! Wacht, wat? Ja, je hoort het goed. Ik leg het uit.

Waarom tekst sneller is dan een afbeelding. Het prestatieverschil komt door de request-pipeline. Een tekst-node (zoals een <h1> of <p>) is onderdeel van het HTML-hoofddocument. Deze heeft geen aparte resource-aanvraag; de rendering wordt alleen geblokkeerd door CSS. Een afbeelding is daarentegen een externe resource die een eigen HTTP-verzoek vereist. Dit introduceert netwerkvertraging (DNS, TCP, TLS en downloadtijd) bovenop de blokkade door CSS. Dit verschil is de kernreden voor het prestatieverschil en waarom het sturen van de LCP-kandidaat een krachtige expertstrategie is.

Dus wat spreekt er voor afbeeldingen versus tekst? Afbeeldingen zijn belangrijk; ze maken je site visueel aantrekkelijk. Maar Core Web Vitals maakt het niet uit welk element de LCP wordt. Wanneer het LCP-element een tekst-element is, valt dit meestal samen met de First Contentful Paint.

Moet je dus overstappen op een tekst-gebaseerd Largest Contentful Paint-element? Dat hangt ervan af! Afbeeldingen zijn belangrijk en maken je site visueel aantrekkelijk. Je zult mij dus niet horen pleiten voor het overstappen op saaie, oude tekst-elementen. Maar er worden ook fouten gemaakt! Ik wou dat ik een euro kreeg voor elke categoriepagina die slachtoffer werd van het "Accidental LCP" anti-pattern. Dit gebeurt wanneer een pagina "vergeet" om een beschrijvende categorietekst boven de vouw te plaatsen, waardoor een lazy-loaded productafbeelding de LCP wordt en de laadtijd met seconden vertraagt. Dit gebeurt vaak wanneer ontwerpers een grote hero-banner helemaal bovenaan de DOM plaatsen, nog vóór belangrijke koppen. De browser heeft dan geen andere keuze dan een tragere LCP-kandidaat te selecteren.

2. Gebruik het snelste beschikbare afbeeldingsformaat

Zonder in een verhitte discussie te belanden over het uitknijpen van de laatste byte of de perfecte instellingen voor WebP vs. AVIF, kunnen we het over één ding eens zijn: oudere formaten zoals JPEG en PNG zijn groter en trager vergeleken met moderne formaten zoals WebP of AVIF. Voor een volledig overzicht van technieken voor afbeeldingsoptimalisatie, zie onze gids over afbeeldingsoptimalisatie.

Als algemene regel geldt dat je een lossy WebP- of AVIF-versie van je LCP-afbeelding moet serveren (beter nog: gebruik deze formaten voor al je afbeeldingen, maar we richten ons hier op de LCP). Met WebP-ondersteuning rond de 95% en AVIF-ondersteuning op 92%, is het nog steeds verstandig om ook oudere fallback-afbeeldingen te serveren. Gebruik hiervoor 'progressive enhancement', waarbij we deze moderne formaten alleen serveren aan browsers die ze ondersteunen.

Afweging decodeersnelheid vs. compressie

Hoewel AVIF de beste compressie biedt (de kleinste bestandsgrootte), kunnen de complexe algoritmen meer CPU-kracht vereisen om te decoderen naar een renderbare afbeelding vergeleken met WebP. Dit is een CPU-gebonden taak die plaatsvindt op de rasterizer-threads van de browser en direct de Element Render Delay verhoogt. Een kleinere AVIF downloadt misschien sneller, maar de langere decodeertijd kan dat voordeel tenietdoen, vooral op mobiele apparaten. Je kunt dit diagnosticeren in het Performance-paneel van Chrome DevTools door te zoeken naar langlopende "Decode Image"-taken die gekoppeld zijn aan je LCP-element. Als je dit ziet, is dat een duidelijk signaal dat de decodeersnelheid je bottleneck is, en niet alleen de downloadtijd.

Expert-inzicht: de status van JPEG XL. Een echte expertgids moet ingaan op JPEG XL. Het is een technisch opmerkelijk formaat, vooral vanwege de mogelijkheid om bestaande JPEG's verliesvrij te hercomprimeren (een grote winst voor oudere sites) en de ondersteuning voor progressief decoderen, wat AVIF mist. Het doorslaggevende nadeel is echter het gebrek aan brede browserondersteuning nadat Chrome de ondersteuning stopzette. Dit maakt het nog niet bruikbaar voor algemeen webgebruik, maar het is een formaat om in de gaten te houden voor de toekomst.

Het <picture>-element gebruiken: Met het <picture>-element kunnen browsers niet-ondersteunde afbeeldingsformaten overslaan en het eerste formaat selecteren dat ze wel kunnen verwerken. Dit doe je zo:

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Formaatselectie combineren met responsieve maten

Voor maximale prestaties combineer je formaatselectie met responsieve afbeeldingsmaten in één enkel <picture>-element. Dit zorgt ervoor dat elke gebruiker het optimale formaat en de optimale grootte voor zijn apparaat krijgt. De browser evalueert <source>-elementen van boven naar beneden en selecteert het eerste formaat dat hij ondersteunt. Vervolgens kiest hij de juiste resolutie met de attributen srcset en sizes.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Dit patroon geeft de browser volledige vrijheid om de beste combinatie van formaat en resolutie te kiezen. Een mobiele gebruiker op een ondersteunde browser krijgt een klein AVIF-bestand, terwijl een oudere desktopbrowser terugvalt op een JPEG met de juiste afmetingen.

Content-negotiation gebruiken

Met content-negotiation kan je server verschillende afbeeldingsformaten serveren op basis van browserondersteuning. Browsers melden de ondersteunde formaten via de Accept-header. In Chrome ziet de Accept-header voor afbeeldingen er bijvoorbeeld zo uit:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Lees vervolgens aan de serverkant de Accept-header uit en serveer op basis daarvan het 'beste formaat'.

3. Gebruik responsieve afbeeldingen

Als het gaat om het optimaliseren van LCP-afbeeldingen, doet de grootte er echt toe. Een van de makkelijkste wins is het serveren van afbeeldingen met de kleinst mogelijke afmetingen die er nog goed uitzien op de schermen van je gebruikers. Te grote afbeeldingen hebben geen enkel nut: ze verspillen bandbreedte en vertragen de laadtijd, vooral voor gebruikers met trage verbindingen of mobiele apparaten.

Volg deze stappen om te zorgen dat je geen pixels verspilt:

Responsieve afbeeldingen:

Gebruik het attribuut srcset om verschillende afbeeldingsmaten te serveren op basis van het apparaat van de gebruiker. Op deze manier krijgen kleinere apparaten kleinere afbeeldingen, wat helpt om de LCP te versnellen.

Waarom het sizes-attribuut cruciaal is

Het gebruik van srcset met w-descriptors zonder het sizes-attribuut is een veelvoorkomende en kostbare fout. Zonder het attribuut sizes moet de browser uitgaan van een standaardwaarde van 100vw (100% van de viewport-breedte). Dit betekent dat de browser op een groot desktopscherm een enorme afbeelding uit je srcset-lijst downloadt, zelfs als de afbeelding in de layout slechts in een kolom van 500px breed wordt getoond. Je hebt de juiste ingrediënten geleverd (srcset) maar het recept weggelaten (sizes), wat leidt tot verspilde bandbreedte en een tragere LCP. Het attribuut sizes biedt de benodigde layout-context. Het vertelt de browser hoe breed de afbeelding daadwerkelijk zal zijn bij verschillende viewport-breakpoints, zodat deze een slimme downloadkeuze kan maken.

Het verschil tussen w- en x-descriptors

Het attribuut srcset ondersteunt twee soorten descriptors. Voor responsief ontwerp waarbij de afmeting van een afbeelding verandert met de viewport, is de w (breedte)-descriptor de beste en noodzakelijke keuze. Deze wordt gebruikt in combinatie met het sizes-attribuut zodat de browser de beste afbeelding kan kiezen op basis van de gerenderde grootte in de layout. De eenvoudigere x (device-pixel-ratio)-descriptor kijkt alleen naar de pixeldichtheid van het scherm en negeert hoe groot de afbeelding daadwerkelijk is in de layout. Dit maakt hem alleen geschikt voor afbeeldingen met een vaste grootte, zoals icons.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. Schaal je afbeeldingen naar de schermgrootte!

Voorkom dat je afbeeldingen serveert die groter zijn dan nodig. Als het LCP-element in de viewport slechts 600px breed is, zorg er dan voor dat de afbeelding niet groter is dan dat. Geloof me, dit zie ik dagelijks gebeuren! Om dit te controleren, doe je het volgende: klik met de rechtermuisknop op de afbeelding en selecteer 'Inspecteren'. Je ziet nu de DevTools waarin de HTML van de afbeelding blauw is gemarkeerd. Hier zie je dat de gerenderde grootte van de afbeelding (443 x 139px) veel kleiner is dan de intrinsieke afbeeldingsbreedte (1090 x 343px). Dat is bijna 3 keer zo groot. Door de afbeelding te verkleinen had je minstens 50% op de bestandsgrootte kunnen besparen.

5. Laad LCP-afbeeldingen eager

Voor de beste prestaties van je LCP moet je het zichtbare LCP-element eager laden (en afbeeldingen die niet direct zichtbaar zijn lazy laden). Dit is een van de meest gemaakte fouten bei LCP-optimalisatie. We behandelen dit in detail in ons artikel over het oplossen van lazy-loaded LCP-afbeeldingen.

Eager loading: Het LCP-element (meestal content boven de vouw) moet altijd eager worden geladen. Dit zorgt ervoor dat het zo snel mogelijk verschijnt, wat de tijd verkort die nodig is om je Largest Contentful Paint te renderen. Standaard laden afbeeldingen eager, tenzij anders aangegeven. Controleer dus goed of je geen loading="lazy" op de LCP-afbeelding hebt gezet. Dit kan de LCP aanzienlijk vertragen en je Core Web Vitals-score verslechteren. Het is belangrijk om te begrijpen dat loading="eager" het standaardgedrag van de browser is. Het weglaten van het attribuut heeft dus hetzelfde effect. De belangrijkste actie is om te zorgen dat loading="lazy" niet aanwezig is.

Geek-alert: Lazy-loaded afbeeldingen worden niet in de wachtrij geplaatst door de preload-scanner. De preload-scanner is een supersnelle secundaire HTML-scanner die belangrijke resources direct in de wachtrij zet. Wanneer de preload-scanner wordt omzeild, moet de browser wachten tot de rendering-engine klaar is voordat deze 'zichtbare afbeeldingen' in de wachtrij plaatst. Om native loading="lazy" te kunnen evalueren, moet de browser eerst alle render-blocking CSS downloaden en parsen om de render-tree op te bouwen. Pas nadat de layout is berekend, kan de browser bepalen of de afbeelding in de viewport staat. Dit betekent dat je volledige CSS een blokkerende afhankelijkheid wordt voor de download van de LCP-afbeelding. Dat is een ramp voor de prestaties.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Voor afbeeldingen die onder de vouw verschijnen (die niet direct zichtbaar zijn wanneer de pagina laadt), is lazy loading de juiste keuze. Door het laden van deze afbeeldingen uit te stellen tot de gebruiker er dichtbij scrollt, maak je bandbreedte vrij voor belangrijkere content, zoals je LCP-element. Hierdoor is lazy loading een tweesnijdend zwaard: correct gebruikt versnelt het je LCP-content, maar verkeerd gebruikt vertraagt het deze juist!

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

De balans? Laad kritieke content (zoals je LCP-afbeelding) eager, en laad minder kritieke resources en afbeeldingen onder de vouw lazy!

6. Preload de LCP-afbeelding

Het preloaden van de LCP-afbeelding vertelt de browser om deze direct op te halen, nog voordat deze op natuurlijke wijze in de HTML wordt ontdekt. Voor een complete handleiding over preloaden, zie ons speciale artikel over het preloaden van de LCP-afbeelding.

Waarom de LCP-afbeelding preloaden?

Wanneer de browser een pagina laadt, verwerkt deze de HTML, stylesheets en scripts in een bepaalde volgorde. Soms wordt er pas verderop in de keten naar de LCP-afbeelding verwezen, waardoor de browser er later bij komt dan zou moeten. Door de LCP-afbeelding te preloaden, weet de browser vooraf dat deze afbeelding kritiek is en direct geladen moet worden. Dit verkort de vertraging bij het renderen van je grootste element.

Hoe preload je de LCP-afbeelding?

Door de <link rel="preload">-tag te gebruiken, zorg je ervoor dat de browser de LCP-afbeelding zo vroeg mogelijk in het laadproces ophaalt.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Dit zorgt ervoor dat de LCP-afbeelding vanaf het begin in de wachtrij van de browser staat. Zo voorkom je dat de browser moet wachten omdat de afbeelding diep in de CSS of scripts zit.

<!-- In de <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In de <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Onthoud: Preload alleen de LCP-afbeelding. Te veel resources preloaden kan de browser overbelasten en de prestaties schaden. Beperk je tot wat het meest belangrijk is voor je Core Web Vitals.

7. Verwijder fade-in animaties van de LCP-afbeelding

Fade-in animaties kunnen er visueel aantrekkelijk uitzien, maar ze zijn een verborgen LCP-bottleneck. Als het LCP-element (vaak een afbeelding) een fade-in effect gebruikt, registreert de browser de LCP pas wanneer de animatie is afgelopen. Dit vertraagt de LCP-timing en kan je performance-metrics aanzienlijk verslechteren.

LCP-meting vindt plaats na afloop van de animatie: De browser beschouwt de LCP pas als voltooid wanneer het element volledig zichtbaar is. Bij een fade-in animatie blijft de timer lopen totdat de afbeelding of content volledig is ingefaded, wat eenvoudig extra seconden aan je LCP-score kan toevoegen.

Houd het simpel: Om te zorgen dat het LCP-element zo snel mogelijk verschijnt, moet je fade-in effecten vermijden. Laat de afbeelding direct laden en tonen, zonder overgang of animatie.

Sla fade-ins op de LCP-afbeelding over. Het visuele effect is de prestatieschade niet waard.

8. Host het LCP-element zelf

Host je LCP-afbeelding zelf. Het gebruik van externe servers introduceert vertragingen die je niet zelf in de hand hebt. Dit kan je LCP en de algehele prestaties van de pagina schaden.

Zie het zo: Het LCP-element niet zelf hosten is als constant suiker lenen van je buren. Je moet er elke keer naartoe lopen, voor de deur wachten en hopen dat ze thuis zijn. Wanneer je voor je LCP vertrouwt op een externe server, moet je website wachten op die externe resource, wat de laadtijd vertraagt. Zelf hosten is als suiker in je eigen keuken hebben staan: snel, direct en betrouwbaar.

Beperk externe afhankelijkheden: Wanneer je LCP-element (zoals een afbeelding) op een externe server staat, ben je overgeleverd aan de snelheid en beschikbaarheid van die server, plus extra round-trip times (RTT). Zelf hosten neemt deze onzekerheid weg. Je serveert de afbeelding direct vanaf je eigen server, wat zorgt voor een snellere en betrouwbaardere levering.

Gebruik caching en optimalisaties: Door zelf te hosten, kun je optimaal profiteren van caching-strategieën en de afbeelding serveren vanaf de server die zich het dichtst bij de gebruiker bevindt, vooral als je een CDN gebruikt. Dit verkort de laadtijd van het LCP-element, wat resulteert in een snellere rendering.

Controle over afbeeldingsoptimalisatie: Zelf hosten geeft je de controle over hoe de afbeelding wordt geoptimaliseerd (of het nu gaat om compressie, resizing of formaatselectie) zonder afhankelijk te zijn van verwerking door derden. Zo zorg je ervoor dat de afbeelding perfect is afgestemd op snel laden.

9. Vermijd client-side rendering voor het LCP-element

Client-side rendering (CSR) is een van de slechtste dingen die je kunt doen voor je LCP. Als je LCP-element (meestal een grote afbeelding, tekstblok of video) client-side wordt gerenderd via JavaScript, leidt dit vaak tot tragere LCP-tijden. De browser moet namelijk wachten tot scripts zijn gedownload, geparst en uitgevoerd voordat de kritieke content kan worden getoond.

Vertraging in de rendering: Bij CSR wordt het LCP-element pas weergegeven nadat de browser JavaScript heeft verwerkt. Dit kan de weergave ervan aanzienlijk vertragen. Hoe langer dit duurt, hoe slechter je LCP-score wordt. Elke extra seconde die aan scriptverwerking wordt besteed, betekent dat je gebruikers langer moeten wachten op de belangrijkste content.

Stap over op Server-Side Rendering (SSR) of Static Rendering: Door het LCP-element server-side of als onderdeel van een statische HTML-respons te renderen, kan de browser dit direct laden en weergeven zonder te wachten tot JavaScript start. Dit verbetert de LCP-timing drastisch, omdat de browser het LCP-element meteen kan renderen zodra deze begint met het laden van de HTML.

Minimaliseer JavaScript op het kritieke pad: Als je client-side scripts niet kunt vermijden, zorg dan dat ze het renderen van het LCP-element niet blokkeren. Gebruik defer of async op niet-kritieke scripts om te voorkomen dat ze de weergave van je LCP vertragen.

10. Reserveer ruimte om layout-shifts te voorkomen

Voeg altijd expliciete attributen voor width en height toe aan je <img>-tags. Dit is een cruciale instructie voor de browser. Hiermee kan deze de aspect-ratio van de afbeelding berekenen en de juiste hoeveelheid ruimte in de layout reserveren voordat de afbeelding is gedownload.

Expert-inzicht: modern gedrag van width en height

Een veelvoorkomend misverstand is dat deze attributen een afbeelding niet-responsief maken. In moderne browsers is dit niet langer het geval. De browser gebruikt deze HTML-attributen om een aspect-ratio te berekenen en de ruimte vrij te houden. De afbeelding blijft perfect responsief als de CSS is ingesteld op width: 100%; height: auto;. Het opgeven van deze attributen is beter dan alleen het gebruiken van de CSS-eigenschap aspect-ratio. De browser kan de ruimte namelijk al reserveren voordat eventuele render-blocking CSS is gedownload en geparst. Dat geeft een cruciale voorsprong.

CSS-achtergrondafbeeldingen afhandelen

Dit principe geldt ook voor elementen die dienen als container voor een CSS-background-image. Een veelvoorkomende bron van layout-shifts is een <div> die in eerste instantie inklapt tot nul hoogte en pas grootte aanneemt wanneer de achtergrondafbeelding wordt toegepast. Om dit te voorkomen, gebruik je de CSS-eigenschap aspect-ratio direct op het container-element om vanaf het begin de benodigde ruimte te reserveren.

11. Controleer op blokkering van de main thread

Zelfs als je LCP-afbeelding perfect is geoptimaliseerd en geprioriteerd, kan de uiteindelijke rendering worden vertraagd als de main thread van de browser druk is met het uitvoeren van zware JavaScript. Vaak is de bron van deze blokkering scripts van derden voor analytics, advertenties of widgets voor klantondersteuning. Deze scripts kunnen de CPU monopoliseren, wat de Element Render Delay verhoogt. Gebruik het Performance-paneel in Chrome DevTools om long tasks tijdens de initiële laadfase te identificeren, deze toe te wijzen aan hun bron, en alle scripts uit te stellen of te verwijderen die niet kritiek zijn voor de eerste render. Zie onze handleiding over Element Render Delay voor meer informatie over dit onderwerp.

Gerelateerde LCP-optimalisatiehandleidingen

Afbeeldingsoptimalisatie is slechts één puzzelstukje. Elke LCP-fase heeft haar eigen handleiding:

• LCP-problemen identificeren en oplossen: De volledige diagnostische methodologie voor het vinden en oplossen van LCP-problemen met behulp van field data en lab data.
• Resource Load Delay: Zorg ervoor dat de browser je LCP-resource zo vroeg mogelijk ontdekt met preload, fetchpriority en een optimale HTML-structuur.
• Resource Load Duration: Verkort de downloadtijd door compressie, CDN-configuratie en netwerkoptimalisatie.
• Element Render Delay: Maak de main thread vrij zodat de browser het LCP-element direct na het downloaden kan tekenen.