Optimaliseer de Largest Contentful Paint Afbeelding

Optimaliseer de Largest Contentful Paint Afbeelding

Deze gids maakt deel uit van de Largest Contentful Paint (LCP) hub. Op de meeste websites is het LCP element een afbeelding. Als de afbeelding niet goed is, lijdt je LCP score eronder. Dit artikel behandelt elke techniek om het snel te maken.

Volgens Google heeft slechts 65% van alle pageviews op het internet (en dat geldt voor zowel desktop als mobiel) een 'goede' Largest Contentful Paint Score. Dat betekent dat 35% van de pageviews faalt en dat komt deels door fouten met afbeeldingen. Dit artikel beschrijft veelvoorkomende goede praktijken en fouten wanneer afbeeldingen het Largest Contentful Paint element worden.

Hoewel al deze factoren belangrijk zijn, als je LCP element een afbeelding is (en dat is het vaak!), zijn er eenvoudige stappen die je kunt nemen om ervoor te zorgen dat het zo snel mogelijk laadt!

Experimenten met de Largest Contentful Paint

Ik zeg altijd: luister en leer, maar neem niemand op zijn woord. Er zijn te veel 'goeroes' die verkeerde informatie verkondigen. Daarom heb ik een volledig automatisch LCP experiment gemaakt waar je zelf kunt uitproberen wat er gebeurt wanneer het LCP element niet optimaal wordt geladen. Bekijk mijn LCP Test op github of probeer de live demo!

Het zal automatisch meerdere LCP scenario's voor je testen en de resultaten tonen. Ik bespreek die scenario's hieronder en leg uit hoe en waarom het het LCP afbeeldingselement versnelt of vertraagt.

1. Beheer de LCP Kandidaat: De Tekst-Eerst Strategie

De snelste manier om je op afbeeldingen gebaseerde Largest Contentful Paint te verbeteren? Gebruik geen afbeelding! Wacht, wat? Ja, je leest het goed. Laat me uitleggen.

Waarom tekst sneller is dan een afbeelding. Het prestatieverschil komt neer op de request pipeline. Een tekstnode (zoals een <h1> of <p>) maakt deel uit van het hoofd-HTML document. Het heeft geen apart resource request; de rendering wordt alleen geblokkeerd door CSS. Een afbeelding daarentegen is een externe resource die een eigen HTTP request vereist. Dit introduceert netwerklatentie (DNS, TCP, TLS en downloadtijd) bovenop het geblokkeerd worden door CSS. Dit onderscheid is de kernreden voor het prestatieverschil en waarom het beheersen van de LCP kandidaat een krachtige strategie op expertniveau is.

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

Dus moet je overschakelen naar een tekstgebaseerd Largest Contentful Paint element? Dat hangt ervan af! Afbeeldingen zijn belangrijk en ze maken je site visueel aantrekkelijk. Dat betekent dat je mij niet zult horen pleiten voor het overschakelen naar saaie oude tekst- elementen. Maar fouten gebeuren ook! Ik wou dat ik een euro kreeg voor elke categoriepagina die slachtoffer werd van het "Onbedoelde LCP" anti-pattern. Dit is wanneer een pagina "vergeet" een beschrijvende categorietekst boven de vouw toe te voegen, waardoor een lazy-loaded productafbeelding de LCP wordt en de laadtijden met seconden vertraagt. Dit gebeurt vaak wanneer ontwerpers een grote hero-banner helemaal bovenaan de DOM plaatsen, vóór alle belangrijke koppen, waardoor de browser geen andere keuze heeft dan een langzamere LCP kandidaat te selecteren.

2. Gebruik het snelste beschikbare afbeeldingsformaat

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

Als algemene regel moet je een lossy WebP of AVIF versie van je LCP afbeelding serveren (beter nog, gebruik deze formaten voor al je afbeeldingen, maar we focussen hier op LCP). Met WebP ondersteuning op ongeveer 95% en AVIF ondersteuning op 92%, is het nog steeds zinvol om oudere, fallback afbeeldingen te serveren. Om dit te doen, gebruik je 'progressive enhancement' waarbij we deze moderne formaten alleen serveren aan browsers die ze ondersteunen.

Decodeersnelheid vs. compressie afweging

Hoewel AVIF de beste compressie biedt (kleinste bestandsgrootte), kunnen de complexe algoritmes 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 de Element Render Delay direct 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 Chrome DevTools Performance paneel door te zoeken naar langlopende "Decode Image" taken die gekoppeld zijn aan je LCP element. Als je dit ziet, is het een duidelijk signaal dat decodeersnelheid je bottleneck is, niet alleen downloadtijd.

Expert Insight: Het geval van JPEG-XL. Een echte expertgids moet JPEG XL behandelen. Het is een technisch opmerkelijk formaat, vooral vanwege de mogelijkheid om bestaande JPEG's lossless te hercomprimeren (een enorme winst voor legacy sites) en de ondersteuning voor progressive decoding, die AVIF mist. Het doorslaggevende nadeel is echter het gebrek aan brede browserondersteuning nadat het door Chrome is gedropt. Dit maakt het nog niet bruikbaar voor algemeen webgebruik, maar positioneert het als een formaat om in de gaten te houden voor de toekomst.

Gebruik van het <picture> element: Het <picture> element stelt browsers in staat om niet-ondersteunde afbeeldingsformaten over te slaan, en het eerste formaat te selecteren dat ze aankunnen. Zo doe je dat:

<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>

Formaatonderhandeling combineren met responsive afmetingen

Voor maximale prestaties moet je formaatselectie combineren met responsive afbeeldingsafmetingen in één <picture> element. Dit zorgt ervoor dat elke gebruiker het optimale formaat en de optimale grootte voor hun apparaat krijgt. De browser evalueert <source> elementen van boven naar beneden en selecteert het eerste formaat dat wordt ondersteund, en gebruikt vervolgens de srcset en sizes attributen om de juiste resolutie te kiezen.

<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="Beschrijvende alt-tekst voor hero afbeelding"
    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 desktop browser terugvalt op een JPEG van de juiste grootte.

Content negotiation gebruiken

Content negotiation laat je server verschillende afbeeldingsformaten serveren op basis van browserondersteuning. Browsers maken ondersteunde formaten bekend 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

Vervolgens lees je aan de serverzijde de accept header en serveer je op basis van de header het 'beste formaat'.

3. Gebruik responsive afbeeldingen

Als het gaat om het optimaliseren van LCP afbeeldingen, maakt grootte echt uit. Een van de makkelijkste verbeteringen is het serveren van afbeeldingen met de kleinst mogelijke afmetingen die er nog goed uitzien op de schermen van je gebruikers. Grote afbeeldingen hebben helemaal geen functie: ze verspillen bandbreedte en vertragen laadtijden, vooral voor gebruikers op tragere verbindingen of mobiele apparaten.

Om ervoor te zorgen dat je geen pixels verspilt, volg je deze stappen:

Responsive afbeeldingen:

Gebruik het srcset attribuut om verschillende afbeeldingsgroottes 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

srcset gebruiken met w descriptors maar het sizes attribuut weglaten is een veelvoorkomende en kostbare fout. Zonder het sizes attribuut wordt de browser gedwongen een standaardwaarde van 100vw (100% van de viewport breedte) aan te nemen. Dit betekent dat op een groot desktopscherm de browser een enorme afbeelding uit je srcset lijst downloadt, zelfs als de afbeelding maar in een kleine kolom van 500px wordt weergegeven. Je hebt de juiste ingrediënten (srcset) aangeleverd maar het recept (sizes) weggelaten, wat leidt tot verspilde bandbreedte en een tragere LCP. Het sizes attribuut biedt de nodige layout context en vertelt de browser hoe breed de afbeelding daadwerkelijk zal zijn bij verschillende viewport breakpoints, zodat deze een intelligente downloadkeuze kan maken.

w vs. x descriptors begrijpen

Het srcset attribuut ondersteunt twee soorten descriptors. Voor responsive design waarbij de grootte van een afbeelding verandert met de viewport, is de w (width) descriptor de superieure en noodzakelijke keuze. Deze wordt gebruikt met het sizes attribuut om de browser de beste afbeelding te laten kiezen op basis van de gerenderde grootte in de layout. De eenvoudigere x (device-pixel-ratio) descriptor houdt alleen rekening met de pixeldichtheid van het scherm en negeert hoe groot de afbeelding daadwerkelijk is in de layout, waardoor deze alleen geschikt is voor afbeeldingen met een vaste grootte zoals iconen.

<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!

Vermijd het serveren van afbeeldingen die groter zijn dan nodig. Als het LCP element slechts 600px breed is in de viewport, zorg er dan voor dat de afbeelding niet groter is dan dat. Geloof me, ik zie dit elke dag gebeuren! Om te controleren, doe je gewoon dit: inspecteer de afbeelding door met rechts te klikken op de afbeelding en selecteer 'element inspecteren'. Je ziet nu de dev-tools en de afbeelding HTML is gemarkeerd met een blauwe achtergrond. Je kunt nu zien dat de gerenderde grootte van de afbeelding (443 x 139px) veel kleiner is dan de intrinsieke afbeeldingsbreedte (1090x343px). Dat is bijna 3 keer zo groot en het verkleinen van de afbeelding had minstens 50% van de bestandsgrootte kunnen besparen.

5. Gebruik eager geladen LCP afbeeldingen

Voor de beste prestaties van je LCP moet je het zichtbare LCP element eager laden (en afbeeldingen die niet direct zichtbaar zijn lazy loaden). Dit is een van de meest voorkomende fouten bij LCP optimalisatie, en we behandelen het in detail in ons artikel over het oplossen van lazy geladen LCP afbeeldingen.

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

Geek alert: Lazy afbeeldingen worden niet in de wachtrij geplaatst door de preload scanner. De preload scanner is een supersnelle secundaire HTML scanner die belangrijke resources onmiddellijk in de wachtrij plaatst. Wanneer de preload scanner wordt omzeild, moet de browser wachten tot de rendering engine klaar is voordat het 'zichtbare afbeeldingen' in de wachtrij plaatst. Om de browser native loading="lazy" te laten evalueren, moet het eerst alle render-blokkerende 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 LCP afbeelding download, wat een prestatieramp is.

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

Voor afbeeldingen die onder de vouw verschijnen (die niet zichtbaar zijn wanneer de pagina voor het eerst laadt), is lazy loading de juiste aanpak. Door het laden van deze afbeeldingen uit te stellen totdat de gebruiker er naartoe scrollt, maak je bandbreedte vrij voor belangrijkere content, zoals je LCP element. Op deze manier is lazy loading een tweesnijdend zwaard: als het correct wordt gebruikt versnelt het je LCP content; als het verkeerd wordt gebruikt vertraagt het!

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

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

6. Preload de LCP afbeelding

Het preloaden van de LCP afbeelding vertelt de browser om deze onmiddellijk op te halen, voordat het deze op natuurlijke wijze ontdekt in de HTML. Voor een complete gids over preloading, zie ons speciale artikel over het preloaden van de LCP afbeelding.

Waarom de LCP afbeelding preloaden?

Wanneer de browser een pagina laadt, verwerkt het de HTML, stylesheets en scripts in een bepaalde volgorde. Soms staat de LCP afbeelding verder in de keten, wat betekent dat de browser er later bij komt dan zou moeten. Het preloaden van de LCP afbeelding laat de browser vooraf weten dat deze afbeelding kritiek is en onmiddellijk geladen moet worden, waardoor de vertraging bij het renderen van je grootste element wordt verminderd.

Hoe de LCP afbeelding te preloaden

Door de <link rel="preload"> tag te gebruiken, kun je ervoor zorgen dat de browser zo vroeg mogelijk in het laadproces begint met het ophalen van de LCP afbeelding.

<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, waardoor het wachten wordt vermeden dat vaak optreedt als de afbeelding verborgen zit in CSS of scripts.

<!-- In the <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 the <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, want het preloaden van te veel resources kan de browser overweldigen en de prestaties schaden. Hou het bij wat het belangrijkst is voor je Core Web Vitals.

7. Verwijder fade-in animaties van de LCP afbeelding

Fade-in animaties kunnen visueel aantrekkelijk zijn, maar ze zijn een verborgen LCP bottleneck. Als het LCP element (vaak een afbeelding) een fade-in effect gebruikt, telt de browser de LCP pas als de animatie klaar is. Dit vertraagt de LCP timing en kan je prestatiemetrieken aanzienlijk schaden.

LCP timing vindt plaats na het einde van de animatie: De browser beschouwt de LCP als compleet pas wanneer het element volledig zichtbaar is. Als je een fade-in animatie hebt, blijft de timer lopen totdat de afbeelding of content volledig is ingefade, wat gemakkelijk extra seconden aan je LCP score kan toevoegen.

Houd het simpel: Om ervoor te zorgen dat het LCP element zo snel mogelijk verschijnt, vermijd het gebruik van fade-in effecten. Laat de afbeelding laden en direct weergeven, zonder enige overgang of animatie.

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

8. Self-host het LCP element

Self-host je LCP afbeelding. Vertrouwen op servers van derden introduceert vertragingen die volledig buiten je controle liggen, wat je LCP en algehele paginaprestaties kan schaden.

Zie het zo: Je LCP element niet self-hosten is als constant suiker lenen bij je buurman. Elke keer moet je erheen lopen, bij de deur wachten en hopen dat ze thuis zijn. Vertrouwen op een server van derden voor je LCP laat je website wachten op die externe resource, waardoor laadtijden vertragen. Self-hosting is als de suiker in je eigen keuken bewaren: snel, direct en betrouwbaar.

Verminder externe afhankelijkheden: Wanneer je LCP element (zoals een afbeelding) gehost wordt op een server van derden, ben je afhankelijk van de snelheid, beschikbaarheid en eventuele extra round-trip times (RTT) van die server. Self-hosting elimineert deze onzekerheid, zodat je de afbeelding direct kunt serveren vanaf je eigen server, wat zorgt voor snellere en betrouwbaardere levering.

Gebruik caching en optimalisaties: Door self-hosting kun je optimaal profiteren van cachingstrategieën en de afbeelding serveren vanaf de dichtstbijzijnde server bij de gebruiker, vooral als je een CDN gebruikt. Dit verkort de tijd die nodig is om het LCP element te laden, wat resulteert in snellere rendering.

Controle over afbeeldingsoptimalisatie: Self-hosting geeft je controle over hoe de afbeelding wordt geoptimaliseerd, of het nu gaat om compressie, verkleining of formaat- selectie, zonder afhankelijk te zijn van de afhandeling door derden. Op deze manier kun je ervoor zorgen dat de afbeelding perfect is afgestemd voor 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, tekst- blok of video) aan de client-side wordt gerenderd via JavaScript, leidt dit vaak tot langzamere LCP tijden omdat de browser moet wachten tot scripts zijn gedownload, geparsed en uitgevoerd voordat de kritieke content wordt weergegeven.

Vertragingen bij rendering: Met CSR wordt het LCP element pas weergegeven nadat de browser JavaScript heeft verwerkt, wat de verschijning aanzienlijk kan vertragen. Hoe langer dit duurt, hoe slechter je LCP score wordt. Elke extra seconde die wordt besteed aan het verwerken van scripts vertaalt zich in een langer wachten voor je gebruikers om de belangrijkste content te zien.

Schakel over naar Server-Side Rendering (SSR) of statische rendering: Door het LCP element server-side te renderen of als onderdeel van een statische HTML response, kun je de browser het onmiddellijk laten laden en weergeven, zonder te wachten tot JavaScript in actie komt. Dit verbetert de LCP timing drastisch, omdat de browser het LCP element direct kan renderen wanneer het begint met het laden van de HTML.

Minimaliseer JavaScript op het kritieke pad: Als je niet kunt vermijden dat er client-side scripts zijn, zorg er dan voor dat ze het LCP element niet blokkeren bij het renderen. Defer of async niet-kritieke scripts om te voorkomen dat ze de verschijning van je LCP vertragen.

10. Reserveer ruimte om layout shifts te voorkomen

Voeg altijd expliciete width en height attributen toe aan je <img> tags. Dit is een cruciale instructie aan de browser, waardoor het de beeldverhouding van de afbeelding kan berekenen en de juiste hoeveelheid ruimte in de layout kan reserveren voordat de afbeelding is gedownload.

Expert Insight: Modern width en height gedrag

Een veelvoorkomend misverstand is dat deze attributen een afbeelding niet-responsive maken. Dit is niet langer waar in moderne browsers. De browser gebruikt deze HTML attributen om een beeldverhouding te berekenen en de ruimte te reserveren, maar de afbeelding zal nog steeds perfect responsive zijn als de CSS is ingesteld op width: 100%; height: auto;. Het opgeven van deze attributen is superieur aan het alleen gebruiken van de CSS aspect-ratio eigenschap, omdat de browser de ruimte kan reserveren voordat render-blokkerende CSS is gedownload en geparsed, wat een cruciale voorsprong geeft.

Omgaan met CSS background images

Dit principe geldt ook voor elementen die dienen als container voor een CSS background-image. Een veelvoorkomende bron van layout shift is een <div> die aanvankelijk naar nul hoogte klapt en vervolgens in grootte springt wanneer de background image wordt toegepast. Om dit te voorkomen, gebruik je de CSS aspect-ratio eigenschap direct op het container element om de benodigde ruimte vanaf het begin te reserveren.

11. Controleer op main-thread blokkering

Zelfs als je LCP afbeelding perfect is geoptimaliseerd en geprioriteerd, kan de uiteindelijke rendering worden vertraagd als de main thread van de browser bezig is met het uitvoeren van zwaar JavaScript. Vaak is de bron van deze blokkering scripts van derden voor analytics, advertenties of klantenservice widgets. Deze scripts kunnen de CPU monopoliseren, waardoor de Element Render Delay toeneemt. Gebruik het Performance paneel in Chrome DevTools om langlopende taken tijdens het initiële laden te identificeren, ze toe te schrijven aan hun bron, en defer of verwijder alles wat niet kritiek is voor de initiële render. Voor meer informatie over dit onderwerp, zie onze gids over Element Render Delay.

Gerelateerde LCP optimalisatie gidsen

Afbeeldingsoptimalisatie is één stukje van de puzzel. Elke LCP fase heeft zijn eigen gids:

• LCP problemen identificeren en oplossen: De complete diagnostische methodologie voor het vinden en oplossen van LCP problemen met velddata en lab tools.
• Resource Load Delay: Zorg ervoor dat de browser je LCP resource zo vroeg mogelijk ontdekt met preload, fetchpriority en 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 onmiddellijk na het downloaden kan painten.