Optimaliseer de Largest Contentful Paint Afbeelding

Optimaliseer de Largest Contentful Paint Afbeelding

Volgens Google heeft slechts [url=https://developer.chrome.com/docs/crux/release-notes]65%[/url] van alle pageviews op het internet (en dat is inclusief desktop en mobiel) een 'good' Largest Contentful Paint Score. Dat betekent dat 35% van de pageviews faalt, en dat komt deels door fouten die gemaakt worden met afbeeldingen. Dit artikel analyseert veelvoorkomende best practices en fouten wanneer afbeeldingen het Largest Contentful Paint element worden.

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

Experimenten met de Largest Contentful Paint

Ik zeg altijd: luister en leer, maar geloof niemand op zijn woord. Er zijn te veel 'goeroes' die erop los prediken met verkeerde informatie. Daarom heb ik een volledig automatisch LCP-experiment gemaakt waar je zelf kunt controleren wat er gebeurt wanneer het LCP-element niet optimaal wordt geladen.  Bekijk mijn [url=https://github.com/corewebvitals/lcp-image]LCP Test[/url] op github of probeer de [url=https://corewebvitals.github.io/lcp-image/]live demo[/url]! 

Het zal automatisch meerdere LCP-scenario's voor je testen en je de resultaten tonen. Ik zal die scenario's hieronder bespreken en uitleggen hoe en waarom het het LCP-afbeeldingselement zal versnellen of vertragen.

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? Yep, je hoorde me goed. Laat me het uitleggen.

Waarom Tekst Sneller is Dan een Afbeelding. Het prestatieverschil komt neer op de verzoek-pijplijn. Een tekstknooppunt (zoals een <h1> of <p>) maakt deel uit van het hoofd-HTML-document. Het heeft geen apart resource-verzoek; de rendering wordt alleen geblokkeerd door CSS. Een afbeelding daarentegen is een externe resource die zijn eigen HTTP-verzoek vereist. Dit introduceert netwerklatentie (DNS, TCP, TLS en downloadtijd) bovenop het feit dat het wordt geblokkeerd door CSS. Dit onderscheid is de kernreden voor het prestatieverschil en waarom het beheren van de LCP-kandidaat een krachtige strategie op expert-niveau is.

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. Wanneer het LCP- element een op tekst gebaseerd element is, valt het meestal samen met de First Contentful Paint.

Dus moet je overschakelen naar een op tekst gebaseerd Largest Contentful Paint element? Dat hangt ervan af! Afbeeldingen doen ertoe en  ze maken je site visueel aantrekkelijk. Dat betekent dat je mij niet zult horen pleiten voor het overschakelen naar oude saaie tekst- elementen. Maar fouten gebeuren ook! Als ik een dollar had voor elke categoriepagina die slachtoffer werd van het **"Accidental LCP" anti-patroon**. Dit is waar een pagina "vergeet" om een beschrijvende categorietekst boven de vouw toe te voegen, waardoor een lazy-loaded productafbeelding de LCP wordt en laadtijden met seconden vertraagt. Dit gebeurt vaak wanneer ontwerpers een grote hero-banner helemaal bovenaan de DOM plaatsen, vóór enige significante koppen, waardoor de browser geen andere keuze heeft dan een tragere LCP- kandidaat te selecteren.

2. Gebruik het snelste beschikbare afbeeldingsformaat

Zonder in een verhit debat te raken 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. Als je een diepere duik wilt, [url=https://www.smashingmagazine.com/2021/09/modern-image-formats-avif-webp/]dit artikel[/url] legt het uit.

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 richten ons hier op LCP). Met [url=https://caniuse/webp]WebP-ondersteuning[/url] op ongeveer 95% en [url=https://caniuse.com/avif]AVIF-ondersteuning[/url] op 92%, is het nog steeds zinvol om ook oudere, fallback-afbeeldingen te serveren. Om dit te doen gebruik je gewoon 'progressive enhancements' 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 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 decoderingstijd zou dat voordeel teniet kunnen doen, vooral op mobiele apparaten. Je kunt dit diagnosticeren in het Chrome DevTools Performance-paneel door te zoeken naar langlopende "Decode Image" taken die geassocieerd zijn met je LCP- element. Als je dit ziet, is het een duidelijk signaal dat decodeersnelheid je knelpunt is, niet alleen downloadtijd.

Expert Inzicht: De Casus van JPEG-XL Een echte expertgids moet JPEG XL behandelen. Het is een technisch opmerkelijk formaat, vooral vanwege zijn vermogen om bestaande JPEG's lossless opnieuw te comprimeren (een enorme winst voor legacy-sites) en zijn ondersteuning voor progressieve decodering, wat AVIF mist. Het doorslaggevende nadeel is echter het gebrek aan brede browserondersteuning nadat het door Chrome werd geschrapt. Dit maakt het nog niet levensvatbaar 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 de eerste te selecteren die ze kunnen verwerken. Hier is hoe je het doet:

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

Gebruik van content negotiation: Content negotiation laat je server verschillende afbeeldingsformaten serveren op basis van browserondersteuning. Browsers kondigen ondersteunde formaten aan via de Accept-header. Bijvoorbeeld, in Chrome ziet de Accept- header voor afbeeldingen er zo uit:

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

Lees vervolgens aan de serverkant de accept-header en serveer op basis van de header het 'beste formaat' 

3. Gebruik responsieve afbeeldingen

Als het gaat om het optimaliseren van LCP-afbeeldingen, doet grootte er echt toe. Een van de gemakkelijkste overwinningen is het serveren van afbeeldingen met de kleinst mogelijke afmetingen die er nog steeds goed uitzien op de schermen van je gebruikers. Grote afbeeldingen hebben geen enkele functie: ze verspillen bandbreedte & vertragen laadtijden, vooral voor gebruikers op tragere verbindingen of mobiele apparaten.

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

Responsieve 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 de LCP te versnellen.

Waarom het `sizes` Attribuut Kritiek is

Het gebruik van srcset met w descriptors maar het weglaten van het sizes attribuut is een veelvoorkomende en kostbare fout. Zonder het sizes attribuut wordt de browser gedwongen om 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 zal downloaden, zelfs als de afbeelding slechts in een kleine 500px-kolom wordt weergegeven. Je hebt de juiste ingrediënten (srcset) geleverd maar het recept (sizes) weggelaten, wat leidt tot verspilde bandbreedte en een tragere LCP. Het sizes attribuut biedt de cruciale lay-outcontext, en vertelt de browser hoe breed de afbeelding daadwerkelijk zal zijn bij verschillende viewport-breekpunten, waardoor deze een intelligente downloadkeuze kan maken.

Begrip van `w` vs. `x` Descriptors

Het srcset attribuut ondersteunt twee soorten descriptors. Voor responsief ontwerp 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 lay-out. 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 lay-out, waardoor deze alleen geschikt is voor afbeeldingen met een vaste grootte zoals pictogrammen.

<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="Afbeelding" width="123" height="123">

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 dit te controleren doe je gewoon dit: inspecteer de afbeelding door met de rechtermuisknop op de afbeelding te klikken en 'inspect-element' te selecteren. Je zult nu de dev-tools zien en de afbeeldings-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 formaat wijzigen van de afbeelding had ten minste 50 van de bestandsgrootte kunnen besparen

5. Gebruik eager loaded LCP-afbeeldingen

Om de beste prestaties uit je LCP te halen, moet je het zichtbare LCP-element eager loaden (en afbeeldingen die niet direct zichtbaar zijn lazy loaden).

Eager Loading: Het LCP-element (meestal content above-the-fold) moet altijd eager geladen worden. Dit zorgt ervoor dat het zo snel mogelijk verschijnt, wat de tijd vermindert die het kost voor je Largest Contentful Paint om te renderen. Standaard laden afbeeldingen eager tenzij anders gespecificeerd, maar controleer dubbel of je loading="lazy" niet hebt ingesteld op de LCP-afbeelding. Dit doen 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 kritieke actie is om ervoor te zorgen dat loading="lazy" niet aanwezig is.

Geek alert: lazy images worden niet in de wachtrij geplaatst door de preload scanner. De preload scanner is een super snelle secundaire html-scanner die belangrijke resources onmiddellijk in de wachtrij plaatst. Wanneer de preload scanner wordt gepasseerd, zal de browser moeten wachten tot de rendering engine klaar is voordat hij 'visible images' in de wachtrij plaatst. Om de browser native loading="lazy" te laten evalueren, moet deze eerst alle render-blocking CSS downloaden en parsen om de render tree te construeren. Pas nadat de lay-out is berekend, kan de browser bepalen of de afbeelding in de viewport is. Dit betekent dat je gehele CSS een blokkerende afhankelijkheid wordt voor de LCP-afbeeldingsdownload, wat een prestatieramp is.

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

Voor afbeeldingen die below the fold verschijnen (die niet zichtbaar zijn wanneer de pagina voor het eerst laadt), is lazy loading de manier om te gaan. Door het laden van deze afbeeldingen uit te stellen totdat de gebruiker er bijna naartoe scrolt, 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, zal het je LCP-content versnellen, als het onjuist wordt gebruikt, zal het het vertragen!.

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

De balans? Laad de kritieke content (zoals je LCP-afbeelding) eager en lazy load minder kritieke resources en afbeeldingen below the fold!

6. Preload de LCP-afbeelding

Het preloaden van de Largest Contentful Paint (LCP) afbeelding is een van de gemakkelijkste manieren om de verschijning ervan op de pagina te versnellen. Het vertelt de browser om het laden van deze afbeelding te prioriteren, zodat deze zo snel mogelijk klaar is.

Waarom de LCP-afbeelding Preloaden?

Wanneer de browser een pagina laadt, verwerkt hij de HTML, stylesheets en scripts in een bepaalde volgorde. Soms wordt de LCP- afbeelding verderop in de keten gerefereerd, wat betekent dat de browser er later aan toekomt dan zou moeten. Het preloaden van de LCP- afbeelding laat de browser vooraf weten dat deze afbeelding kritiek is en onmiddellijk moet worden geladen, wat de vertraging in het renderen van je grootste element vermindert.

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 dat vaak optreedt als de afbeelding begraven is in CSS of scripts wordt vermeden.

<!-- 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, aangezien het preloaden van te veel resources de browser kan overweldigen en de prestaties kan schaden. Houd 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 als het gaat om je Largest Contentful Paint, zijn ze een verborgen knelpunt. Als het LCP-element (vaak een afbeelding) een fade-in effect gebruikt, telt de browser de LCP pas wanneer de animatie is voltooid. Dit vertraagt de LCP-timing en kan je prestatiemetrieken aanzienlijk schaden.

LCP Timing Gebeurt Nadat de Animatie Eindigt: De browser beschouwt de LCP pas als compleet wanneer het element volledig zichtbaar is. Als je een fade-in animatie hebt, blijft de timer lopen totdat de afbeelding of inhoud volledig is ingefaded, wat gemakkelijk extra seconden kan toevoegen aan je LCP-score.

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

Door fade-ins op de LCP-zbeelding over te slaan, voorkom je onnodige vertragingen en verbeter je je Core Web Vitals, wat zorgt voor een snellere, soepelere ervaring voor gebruikers.

8. Self-Host het LCP Element

Om de beste prestaties uit je Largest Contentful Paint te halen, moet je altijd overwegen om het LCP-element zelf te hosten, vooral als het een afbeelding of andere kritieke resource is. Vertrouwen op servers van derden kan vertragingen introduceren die volledig buiten je controle liggen, wat je LCP en algehele paginaprestaties kan schaden.

Bekijk het zo: Het niet self-hosten van je LCP-element is als constant suiker lenen van je buurman. Elke keer moet je erheen lopen, aan 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, wat laadtijden vertraagt. Self-hosting is als de suiker in je 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 overgeleverd aan de snelheid, beschikbaarheid en eventuele extra round-trip times (RTT) van die server. Self-hosting elimineert deze onzekerheid, waardoor je de afbeelding direct van je eigen server kunt serveren, wat zorgt voor snellere en betrouwbaardere levering.

Benut Caching en Optimalisaties: Door te self-hosten, kun je volledig profiteren van cachingstrategieën en de afbeelding serveren vanaf de server die het dichtst bij de gebruiker staat, vooral als je een CDN gebruikt. Dit vermindert de tijd die het kost om het LCP-element te laden, resulterend in snellere rendering.

Controle Over Afbeeldingsoptimalisatie: Self-hosting geeft je controle over hoe de afbeelding wordt geoptimaliseerd, of het nu gaat om compressie, formaatwijziging of formaatselectie —zonder afhankelijk te zijn van afhandeling door derden. Op deze manier kun je ervoor zorgen dat de afbeelding perfect is afgestemd op snel laden.

9. Vermijd Client-Side Rendering voor het LCP Element

Client-side rendering (CSR) kan een grote belemmering zijn als het gaat om het optimaliseren van je Largest Contentful Paint. Als je LCP-element (meestal een grote afbeelding, tekstblok of video) aan de clientzijde wordt gerenderd via JavaScript, leidt dit vaak tot tragere LCP- tijden omdat de browser moet wachten tot scripts zijn gedownload, geparsed en uitgevoerd voordat de kritieke content wordt weergegeven.

Vertragingen in 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 besteed aan het verwerken van scripts vertaalt zich in een langere wachttijd 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 of als onderdeel van een statische HTML-respons te renderen, sta je de browser toe om het onmiddellijk te laden en weer te geven, zonder te wachten tot JavaScript in werking treedt. Dit verbetert de LCP-timing drastisch, aangezien 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 voorkomen dat sommige client-side scripts worden gebruikt, zorg er dan voor dat ze het renderen van het LCP-element niet blokkeren. 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

Neem altijd expliciete width en height attributen op in je <img> tags. Dit is een kritieke instructie aan de browser, waardoor deze de beeldverhouding van de afbeelding kan berekenen en de juiste hoeveelheid ruimte in de lay-out kan reserveren *voordat* de afbeelding is gedownload.

Expert Inzicht: Modern width en height Gedrag

Een veelvoorkomende misvatting is dat deze attributen een afbeelding niet-responsief maken. Dit is niet langer waar in moderne browsers. De browser gebruikt deze HTML-attributen om een beeldverhouding te berekenen en de ruimte vast te houden, maar de afbeelding zal nog steeds perfect responsief zijn als de CSS is ingesteld op width: 100%; height: auto;. Het verstrekken van deze attributen is superieur aan het gebruik van alleen de CSS aspect-ratio eigenschap, aangezien de browser de ruimte kan reserveren *voordat* enige render-blocking CSS is gedownload en geparsed, wat het een cruciale voorsprong geeft.

Omgaan met CSS Achtergrondafbeeldingen

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

11. Audit voor Main-Thread Blocking

Zelfs als je LCP-afbeelding perfect geoptimaliseerd en geprioriteerd is, kan de uiteindelijke rendering worden vertraagd als de main thread van de browser bezig is met het uitvoeren van zware JavaScript. Vaak is de bron van deze blokkering scripts van derden voor analytics, advertenties of klantenservice-widgets. Deze scripts kunnen de CPU monopoliseren, wat de Element Render Delay verhoogt. Gebruik het Performance-paneel in Chrome DevTools om langlopende taken tijdens de initiële lading te identificeren, schrijf ze toe aan hun bron en stel ze uit of verwijder ze als ze niet kritiek zijn voor de initiële render.