Optimaliseer de Largest Contentful Paint-afbeelding

Optimaliseer de Largest Contentful Paint afbeelding

Deze gids is onderdeel van de Largest Contentful Paint (LCP) hub. Op de meeste websites is het LCP-element een afbeelding. Doe je de afbeelding fout, dan lijdt je LCP-score eronder. Dit artikel behandelt elke techniek om hem snel te maken.

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

Al deze factoren zijn belangrijk. Is je LCP-element een afbeelding (en dat is vaak zo!), dan zijn er simpele stappen om hem zo snel mogelijk te 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 gebouwd. Hier kun je zelf bekijken wat er gebeurt als het LCP-element niet optimaal laadt. Bekijk mijn LCP Test op GitHub of probeer de live demo!

Het test automatisch meerdere LCP-scenario's en toont je de resultaten. Ik bespreek die scenario's hieronder. Ik leg uit hoe en waarom dit het LCP-afbeeldingselement versnelt of vertraagt.

1. Beheer de LCP-kandidaat: De tekst-eerst strategie

De snelste manier om je Largest Contentful Paint met een afbeelding te verbeteren? Gebruik geen afbeelding! Wacht, wat? Ja, je hoort het goed. Laat me dit uitleggen.

Waarom tekst sneller is dan een afbeelding. Het prestatieverschil zit in de request pipeline. Een tekstknooppunt (zoals een <h1> of <p>) is onderdeel van het hoofd-HTML-document. Het heeft geen apart resource-request. De rendering wordt alleen geblokkeerd door CSS. Een afbeelding is een externe resource die een eigen HTTP-request vereist. Dit introduceert netwerklatentie (DNS, TCP, TLS en downloadtijd) bovenop de CSS-blokkering. Dit onderscheid is de kernreden voor het prestatieverschil. Dit maakt het beheren van de LCP-kandidaat een krachtige strategie op expertniveau.

Dus wat is het argument voor afbeeldingen versus tekst? Afbeeldingen zijn belangrijk; ze maken je site visueel aantrekkelijk. Maar Core Web Vitals geeft er niet om welk element de LCP wordt. Is het LCP-element gebaseerd op tekst, dan valt dit meestal samen met de First Contentful Paint.

Moet je overstappen op een tekstgebaseerd Largest Contentful Paint element? Dat hangt ervan af. Afbeeldingen zijn belangrijk en maken je site visueel aantrekkelijk. Je hoort me niet pleiten voor oude, saaie tekstelementen. Maar er gebeuren ook fouten. Ik wou dat ik een euro kreeg voor elke categoriepagina die slachtoffer werd van het "Accidental LCP" anti-patroon. De pagina "vergeet" hierbij een beschrijvende categorietekst above the fold toe te voegen. Een lazy-loaded productafbeelding wordt zo de LCP. Dit vertraagt de laadtijden met seconden. Dit gebeurt vaak wanneer ontwerpers een grote hero-banner bovenaan de DOM plaatsen, voor enige belangrijke koppen. De browser heeft dan geen andere keuze dan een tragere LCP-kandidaat te selecteren.

2. Gebruik het snelste afbeeldingsformaat beschikbaar

Zonder een verhit debat te starten over de laatste byte of de perfecte instellingen voor WebP versus AVIF, laten 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. Zie onze gids over afbeeldingsoptimalisatie voor een compleet overzicht.

Als algemene regel serveer je een lossy WebP of AVIF-versie van je LCP-afbeelding (beter nog, gebruik deze formaten voor al je afbeeldingen, maar we focussen hier op de LCP). Met een WebP-ondersteuning van ongeveer 95% en AVIF-ondersteuning op 92%, is het verstandig om ook oudere, fallback-afbeeldingen te serveren. Gebruik hiervoor 'progressive enhancement'. Je serveert deze moderne formaten dan alleen aan browsers die ze ondersteunen.

Decodeersnelheid versus compressie-afweging

AVIF biedt de beste compressie (kleinste bestandsgrootte). De complexe algoritmes vereisen echter meer CPU-kracht om te decoderen naar een renderbare afbeelding dan WebP. Dit is een CPU-gebonden taak op de Rasterizer-threads van de browser. Het verhoogt direct de Element Render Delay. Een kleinere AVIF downloadt misschien sneller, maar de langere decodeertijd kan dit voordeel tenietdoen, vooral op mobiele apparaten. Je diagnosticeert dit in het Chrome DevTools Performance-paneel. Zoek naar langlopende "Decode Image"-taken gekoppeld aan je LCP-element. Zie je dit, dan is je decodeersnelheid het knelpunt, niet alleen de downloadtijd.

Expertinzicht: De casus JPEG-XL. Een echte expertgids moet JPEG XL behandelen. Het is een technisch opmerkelijk formaat, vooral vanwege de capaciteit om bestaande JPEG's verliesvrij te hercomprimeren (een enorme winst voor oude sites). Het ondersteunt progressive decoding, wat AVIF mist. Het grote nadeel is het gebrek aan brede browserondersteuning nadat Chrome het liet vallen. Dit maakt het nu niet bruikbaar voor algemeen webgebruik. Houd het wel in de gaten voor de toekomst.

Het <picture>-element gebruiken: Het <picture>-element laat browsers niet-ondersteunde afbeeldingsformaten overslaan. Ze selecteren de eerste die 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 responsieve afmetingen

Voor maximale prestaties combineer je formaatselectie met responsieve afbeeldingsgroottes in één <picture>-element. Dit garandeert dat elke gebruiker het optimale formaat én de optimale grootte voor zijn apparaat krijgt. De browser evalueert <source>-elementen van boven naar beneden. Hij selecteert het eerste formaat dat hij ondersteunt. Daarna gebruikt hij 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="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. Een oudere desktopbrowser valt terug op een JPEG van de juiste grootte.

Contentonderhandeling gebruiken

Contentonderhandeling laat je server verschillende afbeeldingsformaten serveren op basis van browserondersteuning. Browsers kondigen ondersteunde formaten aan 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. Serveer op basis van de header het 'beste formaat'.

3. Gebruik responsieve afbeeldingen

Grootte is echt belangrijk bij het optimaliseren van LCP-afbeeldingen. Een van de makkelijkste overwinningen is het serveren van afbeeldingen met de kleinst mogelijke afmetingen die er nog steeds goed uitzien op het scherm van je gebruikers. Grote afbeeldingen hebben geen enkele functie. Ze verspillen bandbreedte en vertragen de laadtijden. Dit geldt vooral voor gebruikers op tragere verbindingen of mobiele apparaten.

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

Responsieve afbeeldingen:

Gebruik het srcset attribuut om verschillende afbeeldingsgroottes te serveren op basis van het apparaat van de gebruiker. Zo krijgen kleinere apparaten kleinere afbeeldingen. Dit versnelt de LCP.

Waarom het sizes attribuut cruciaal is

Het gebruik van srcset met w-descriptors en het weglaten van het sizes attribuut is een veelvoorkomende en kostbare fout. Zonder het sizes attribuut moet de browser een standaardwaarde van 100vw (100% van de viewport-breedte) aannemen. Op een groot desktopscherm downloadt de browser dan een enorme afbeelding uit je srcset-lijst. Dit gebeurt zelfs als de afbeelding slechts in een kleine kolom van 500px staat. Je hebt de juiste ingrediënten (srcset) geleverd, maar het recept (sizes) weggelaten. Dit leidt tot verspilde bandbreedte en een tragere LCP. Het sizes attribuut levert de noodzakelijke lay-outcontext. Het vertelt de browser hoe breed de afbeelding daadwerkelijk zal zijn op verschillende viewport-breekpunten. Hierdoor kan hij een intelligente downloadkeuze maken.

De w versus x descriptors begrijpen

Het srcset attribuut ondersteunt twee soorten descriptors. Voor responsief ontwerp waarbij de afbeeldingsgrootte verandert met de viewport, is de w (width) descriptor de superieure en noodzakelijke keuze. Het wordt gebruikt met het sizes attribuut. Dit laat de browser de beste afbeelding kiezen op basis van zijn gerenderde grootte in de lay-out. De simpelere x (device-pixel-ratio) descriptor kijkt alleen naar de pixeldichtheid van het scherm. Het negeert hoe groot de afbeelding daadwerkelijk in de lay-out is. Dit maakt het alleen geschikt 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. Is het LCP-element slechts 600px breed in de viewport? Zorg dan dat de afbeelding niet groter is dan dat. Geloof me, dit zie ik elke dag gebeuren! Om dit te controleren doe je het volgende. Klik met de rechtermuisknop op de afbeelding en selecteer 'inspect-element'. Je ziet nu de dev-tools en de HTML van de afbeelding 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. De afbeelding verkleinen had minstens 50% van de bestandsgrootte kunnen besparen.

5. Gebruik eager geladen LCP-afbeeldingen

Voor de beste prestaties van je LCP laad je het zichtbare LCP-element eager in. Je past lazy loading toe op afbeeldingen die niet direct zichtbaar zijn. Dit is een van de meest gemaakte fouten bij LCP-optimalisatie. We behandelen dit gedetailleerd in ons artikel over het oplossen van lazily loaded LCP-afbeeldingen.

Eager loading: Het LCP-element (meestal above-the-fold content) moet altijd eager laden. Dit garandeert dat het zo snel mogelijk verschijnt. Het verlaagt de tijd die je Largest Contentful Paint nodig heeft om te renderen. Standaard laden afbeeldingen eager, tenzij anders aangegeven. Controleer wel dubbel of je geen loading="lazy" op de LCP-afbeelding hebt ingesteld. Dit doen kan de LCP flink vertragen en je Core Web Vitals score schaden. Begrijp goed dat loading="eager" het standaardgedrag van de browser is. Het attribuut helemaal weglaten heeft hetzelfde effect. De cruciale actie is garanderen dat loading="lazy" niet aanwezig is.

Geek alert: Lazy afbeeldingen worden niet door de preload scanner in de wachtrij gezet. De preload scanner is een super snelle secundaire HTML-scanner. Deze zet belangrijke resources direct in de wachtrij. Wordt de preload scanner gepasseerd, dan moet de browser op de rendering engine wachten. Pas daarna zet hij 'zichtbare afbeeldingen' in de wachtrij. Om native loading="lazy" te evalueren, moet de browser eerst alle render-blocking CSS downloaden en parsen om de render tree op te bouwen. Pas na het berekenen van de lay-out 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. Dit is een ramp voor prestaties.

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

Voor afbeeldingen below the fold (niet zichtbaar bij de eerste paginalading) is lazy loading de juiste keuze. Door het laden hiervan uit te stellen totdat de gebruiker in de buurt scrolt, maak je bandbreedte vrij voor belangrijkere content. Dit is bijvoorbeeld je LCP-element. Lazy loading snijdt aan twee kanten. Correct gebruikt versnelt het je LCP-content. Verkeerd gebruikt vertraagt het deze.

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

De balans? Laad kritieke content (zoals je LCP-afbeelding) eager in. Pas lazy loading toe op minder kritieke resources en afbeeldingen below the fold!

6. Preload de LCP-afbeelding

De LCP-afbeelding preloaden vertelt de browser om deze direct op te halen. Dit gebeurt voordat hij hem op natuurlijke wijze in de HTML ontdekt. Zie ons toegewijde artikel over het preloaden van de LCP-afbeelding voor een complete gids.

Waarom de LCP-afbeelding preloaden?

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

Hoe de LCP-afbeelding te preloaden

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 garandeert dat de LCP-afbeelding direct vanaf de start in de wachtrij van de browser staat. Het voorkomt het wachten 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. Te veel resources preloaden kan de browser overbelasten en de prestaties schaden. Blijf 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 het zijn verborgen LCP-knelpunten. Gebruikt het LCP-element (vaak een afbeelding) een fade-in effect, dan rekent de browser de LCP pas mee als de animatie klaar is. Dit vertraagt de LCP-timing. Het kan je prestatiemetrics flink schaden.

LCP-timing gebeurt na het einde van de animatie: De browser beschouwt de LCP pas als compleet wanneer het element volledig zichtbaar is. Heb je een fade-in animatie, dan blijft de timer lopen totdat de afbeelding of content volledig is verschenen. Dit kan makkelijk extra seconden aan je LCP-score toevoegen.

Houd het simpel: Vermijd fade-in effecten om te garanderen dat het LCP-element zo snel mogelijk verschijnt. Laat de afbeelding direct laden en weergeven, zonder overgangen of animaties.

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

8. Zelf-host het LCP-element

Host je LCP-afbeelding zelf. Afhankelijk zijn van third-party servers introduceert vertragingen buiten jouw controle. Dit kan je LCP en de algehele prestaties van je pagina schaden.

Zie het zo: Je LCP-element niet zelf hosten is als constant suiker lenen bij de buren. Elke keer moet je ernaartoe lopen, bij de deur wachten en hopen dat ze thuis zijn. Afhankelijk zijn van een externe server voor je LCP laat je website wachten op die externe resource. Dit vertraagt de laadtijden. Zelf hosten is als suiker in je eigen keuken bewaren: snel, direct en betrouwbaar.

Verminder externe afhankelijkheden: Wanneer je LCP-element (zoals een afbeelding) op een externe server staat, ben je overgeleverd aan de snelheid, beschikbaarheid en extra round-trip times (RTT) van die server. Zelf hosten elimineert deze onzekerheid. Het laat je de afbeelding direct vanaf je eigen server serveren. Dit garandeert een snellere en betrouwbaardere levering.

Gebruik caching en optimalisaties: Door zelf te hosten, benut je caching-strategieën volledig. Je serveert de afbeelding vanaf de server dichtst bij de gebruiker, vooral als je een CDN gebruikt. Dit verlaagt de laadtijd van het LCP-element. Dit resulteert in snellere rendering.

Controle over afbeeldingsoptimalisatie: Zelf hosten geeft je de controle over hoe de afbeelding wordt geoptimaliseerd. Dit geldt voor compressie, afmetingen of formaatselectie. Je bent niet afhankelijk van third-party afhandeling. Zo garandeer je 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 met je LCP kunt doen. Wordt je LCP-element (meestal een grote afbeelding, tekstblok of video) aan de client-side gerenderd via JavaScript, dan leidt dit vaak tot tragere LCP-tijden. De browser moet wachten totdat scripts zijn gedownload, geparseerd en uitgevoerd voordat hij de kritieke content toont.

Vertragingen in rendering: Bij CSR wordt het LCP-element pas weergegeven nadat de browser de JavaScript verwerkt. Dit vertraagt de weergave flink. Hoe langer dit duurt, hoe slechter je LCP-score wordt. Elke extra seconde die aan scriptverwerking opgaat, is een langere wachttijd voor je gebruikers om de belangrijkste content te zien.

Schakel over op server-side rendering (SSR) of statische rendering: Door het LCP-element aan de serverkant of als deel van een statische HTML-respons te renderen, laat je de browser deze direct laden en tonen. Je wacht niet op JavaScript. Dit verbetert de LCP-timing drastisch. De browser kan het LCP-element direct renderen bij het laden van de HTML.

Minimaliseer JavaScript op het kritieke pad: Kun je sommige client-side scripts niet vermijden? Zorg dan dat ze de rendering van het LCP-element niet blokkeren. Maak niet-kritieke scripts async of gebruik defer. Dit voorkomt dat ze de weergave van je LCP vertragen.

10. Reserveer ruimte om layout shifts te voorkomen

Neem altijd expliciete width en height attributen op in je <img> tags. Dit is een cruciale instructie voor de browser. Het stelt hem in staat de aspectverhouding van de afbeelding te berekenen. Zo reserveert hij de juiste hoeveelheid ruimte in de lay-out voordat de afbeelding is gedownload.

Expertinzicht: Modern gedrag van width en height

Een veelvoorkomende misvatting is dat deze attributen een afbeelding onresponsief maken. In moderne browsers is dit niet meer waar. De browser gebruikt deze HTML-attributen om een aspectverhouding te berekenen en de ruimte vast te houden. De afbeelding blijft perfect responsief als de CSS op width: 100%; height: auto; staat. Deze attributen toevoegen is superieur aan alleen de CSS aspect-ratio property gebruiken. De browser kan hiermee de ruimte reserveren voordat render-blocking CSS is gedownload en geparseerd. Dit geeft een cruciale voorsprong.

Omgaan met CSS-achtergrondafbeeldingen

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 eerst instort tot een hoogte van nul. Deze springt daarna in omvang als de achtergrondafbeelding wordt toegepast. Voorkom dit door de CSS aspect-ratio property direct op het containerelement te gebruiken. Zo reserveer je vanaf het begin de benodigde ruimte.

11. Controleer op main-thread blokkades

Zelfs als je LCP-afbeelding perfect geoptimaliseerd en geprioriteerd is, kan de uiteindelijke rendering vertraging oplopen. Dit gebeurt als de main thread van de browser druk bezig is met zware JavaScript uitvoeren. Vaak zijn third-party scripts voor analytics, advertenties of klantensupportwidgets de bron van deze blokkade. Deze scripts kunnen de CPU monopoliseren, wat de Element Render Delay verhoogt. Gebruik het Performance-paneel in Chrome DevTools om long-running tasks tijdens de initiële laadtijd te identificeren. Wijs ze toe aan hun bron en verwijder of stel ze uit (defer) als ze niet kritiek zijn voor de eerste render. Voor meer hierover, zie onze gids over Element Render Delay.

Stap-voor-stap gids: Diagnose LCP met het Chrome DevTools Performance-paneel toont hoe je een gethrottelde trace opneemt. Het leert je deze lange taken in de Main-track te spotten.

Gerelateerde LCP-optimalisatiegidsen

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

• LCP-problemen identificeren en oplossen: De complete diagnostische methodiek voor het vinden en oplossen van LCP-problemen met field data en lab tools.
• Resource Load Delay: Zorg dat de browser je LCP-resource zo vroeg mogelijk ontdekt met preload, fetchpriority en een optimale HTML-structuur.
• Resource Load Duration: Verlaag de downloadtijd via compressie, CDN-configuratie en netwerkoptimalisatie.
• Element Render Delay: Maak de main thread vrij zodat de browser het LCP-element direct na download kan painten.