Fiks trege hero-bilder og Core Web Vitals

Slik fikser du trege hero-bilder - kort fortalt

Hero-bilder er store bilder øverst på en nettside. Disse hero-bildene vil forårsake en lang Largest Contentful Paint når hero-bildene ikke er optimalisert. 9 av 10 nettsteder jeg blir bedt om å optimalisere har problemer med hero-bildene. I denne artikkelen vil jeg vise deg forskjellige teknikker for å øke hastigheten på hero-bilder.

Hva er et hero-bilde?

Et hero-bilde, eller noen ganger kalt en 'hero header', er et stort bilde med tekst, ofte plassert øverst på en nettside. Et hero-bilde fungerer som brukerens første inntrykk av bedriften din og tilbudet ditt på grunn av den fremtredende plasseringen øverst på en nettside som vanligvis strekker seg over hele bredden.

En rask påminnelse: Hero-bilder, Core Web Vitals og Largest Contentful Paint

På grunn av størrelsen på hero-bildet (det dekker vanligvis hele bredden av siden og en god del av høyden på det synlige viewport) vil dette elementet bli Largest Contentful Pain-elementet i nesten alle tilfeller.

Largest Contentful Paint er en viktig Core Web Vitals-metrikk. Largest Contentful Paint-elementet er det største elementet som blir tegnet i det synlige viewport i nettleseren.

Fordi uoptimaliserte bilder har en tendens til å bruke mye båndbredde og derfor tar lang tid å laste, vil hero-bilder ofte forårsake dårlige Largest Contentful Paint-metrikker

Optimalisering av hero-bildet og Largest Contentful Paint

Det finnes mange teknikker for å optimalisere hero-bildene og Largest Contentful Paint. Jeg vil forklare dem her. De fleste teknikkene kan kombineres for enda bedre resultater!

1 Forhåndslast hero-bildet eller send 103-headere

Når du ønsker at et element skal være tilgjengelig så raskt som mulig i nettleseren, kan du forhåndslaste det elementet. Forhåndslasting innebærer bruk av resource hints. Resource hints forteller nettleseren noe om prioriteten til et element og vil utløse en veldig tidlig nedlasting av den ressursen.

<link 
  rel="preload" 
  as="image" 
  href="wolf.jpg" 
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w" 
  imagesizes="50vw">

I nær fremtid vil 103 early hints bli støttet av Chrome-nettlesere. Dette vil gjøre det mulig å sende resource hints FØR det endelige HTML-svaret har blitt sendt. 103 early hints forventes å bli en game changer når det gjelder å forbedre Largest Contentful Paint. Hvis du er interessert i å lære om tidlige resource hints sjekk ut artikkelen min.

2 Komprimer hero-bildet & bruk neste generasjons formater

Komprimering av bilder vil gjøre filstørrelsen mindre. Mindre filstørrelser vil bruke mindre båndbredde og er tilgjengelige for nettleseren så raskt som mulig. Komprimering av bilder kan gjøres i bilderedigeringsprogrammet ditt, i CMS-et ditt (tips: utvikleren din kan sette WordPress-kompresjonsnivået) eller med et online bildekomprimeringsverktøy

De fleste trege hero-bilder er tregere enn de trenger å være fordi de leveres i feil bildeformat som PNG eller JPEG. Det finnes mye raskere alternativer til JPEG og PNG som WebP og AVIF. 

For mange CMS-systemer finnes det konverteringsplugins som vil konvertere bildene dine til neste generasjons format. Når bildekonvertering er vanskelig å integrere i nettstedet ditt, kan et CDN med bildekonverteringsstøtte være løsningen du leter etter.

3. Ikke bruk bakgrunnsbilder, bruk vanlige responsive bilder

Hero-bildet ditt bør være et vanlig bilde og aldri et bakgrunnsbilde. Den vanlige måten å lage hero-bilder på er å legge til et bakgrunnsbilde i hero-beholderen og sette background-size for den beholderen til cover. Dette vil sikre at hero-bildet passer til skjermen i alle tilfeller.

Bakgrunnsbilder er dårlig for Core Web Vitals. Husk det! Det er ingen god grunn til å noen gang bruke bakgrunnsbilder.

• Bakgrunnsbilder lastes med lavere prioritet
• Bakgrunnsbilder er ikke responsive (med mindre du virkelig ønsker å komplisere ting)
• Bakgrunnsbilder kan forårsake Core Web Vitals-problemer med de fleste lazy loading-biblioteker.
  

Måten jeg gjør det på er å legge til et vanlig bilde i en absolutt posisjon og sette object-fit-egenskapen til bildet til cover. Når jeg har endret bakgrunnsbildet til et vanlig bilde, kan jeg begynne å bruke responsive bilder

Responsive bilder betyr at for forskjellige enheter (mobil, desktop, nettbrett) kan en annen versjon av det samme hero-bildet sendes. For en desktop-enhet kan jeg sende et stort 1920x1280 hero-bilde, mens for en mobilenhet trenger jeg bare å sende et mindre 400*266 piksler hero-bilde. Det er 25 ganger mindre data!

• Hero-bildene lastes nå med høyere prioritet
• Jeg kan nå bruke responsive bilder for hero-bildet

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source 
        type="image/webp" 
        media="(max-width:540px)" 
        srcset="herosm.webp">
    </source>
    <img loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

4. Server hero-bilder fra hoveddomenet & vurder et Content Delivery Network (CDN)

Altfor ofte ser jeg Largest Contentful Paint-bildet bli servert fra et annet domene, for eksempel 'static.mydomain.com'. Disse subdomenene peker ofte til et CDN. Selv om jeg oppfordrer til bruk av et CDN (se nedenfor), er et slikt oppsett ikke tilrådelig. Bildet på subdomenet krever en ny tilkobling til en ny server. Nye tilkoblinger er kostbare og vil ta opp verdifull tid. Når bildet serveres fra hoveddomenet (www.mydomain.com for eksempel) kan bildene hentes mye raskere gjennom den allerede etablerte servertilkoblingen.

Når det er satt opp på hoveddomenet, kan et CDN tilby en enorm hastighetsøkning. Spesielt når nettstedet ditt besøkes fra hele verden. Et CDN har servere strategisk plassert over hele verden der de statiske ressursene dine (som bilder er bufret) for raske lokale responstider. Dette betyr at data ikke trenger å reise over hele verden, men kan serveres fra en lokal edge-server.

5. Unngå lazy loading av Largest Contentful Paint-bildene & last hero-bildet eksplisitt med eager

Sørg for at det ikke brukes lazy loading på hero-bildet ditt. Hero-bilder bør alltid lastes med eager.

Mange nettsteder, spesielt WordPress-nettsteder, bruker en eller annen form for WordPress pagespeed-plugin som WP Rocket eller WP Core Web Vitals. Disse pluginene gjør vanligvis en god jobb med å øke hastigheten på trege nettsteder, men de kan ikke fikse dumhet :-)

Disse pluginene vil lazy loade bilder som virker som gode kandidater for lazy loading. Hvis hero-bildet ikke er et eager-bilde, vil disse pluginene sannsynligvis også lazy loade hero-bildet.

Dette vil i beste fall forårsake en liten forsinkelse i LCP-metrikken. I verste fall, spesielt når JavaScript-basert lazy loading er aktivert, vil det forårsake en større forsinkelse.

Å gjøre bilder eager-lastet er ganske enkelt. Bare legg til loading="eager" på bildet, og du er ferdig.

<img src="hero.webp" loading="eager" width="800" height="400">

6. Unngå layoutforskyvninger forårsaket av hero-bildet

Et annet vanlig problem jeg ser med hero-bannere og hero-bilder er at de forårsaker en stor layoutforskyvning. Disse layoutforskyvningene kan oppstå av forskjellige årsaker.

• Hero-elementet er opprettet med JavaScript. Noen hero-plugins og sidebyggere som Elementor er kjent for å være avhengige av JavaScript for å gjengi hero-innholdet. Selv om det ikke er noe galt med JavaScript, sørg for at hero-elementet gjengis likt uten JavaScript.
• Skriftene i hero-elementet forårsaker en layoutforskyvning. Hero-elementet inneholder vanligvis noe stor tekst med en oppfordring til handling og en tagline. Sørg for at disse store skriftene ikke forårsaker en layoutforskyvning.
• Manglende bildedimensjoner. Når hero-bildet ikke er et cover-bilde (verken som bakgrunnsbilde eller et absolutt posisjonert bilde), vil manglende bildedimensjoner (bredde og høyde) helt sikkert forårsake en stor layoutforskyvning.

Selv om det å fikse layoutforskyvningen ikke forbedrer Largest Contentful Paint, vil det forbedre Core Web Vitals for siden. For mer informasjon om hvordan du fikser layoutforskyvningen, vennligst les denne dybdeguiden om hvordan du fikser layoutforskyvningen!

7. Bruk 2-trinns lasting for å forbedre hero Core Web Vitals

2-trinns lasting er en rask teknikk som vi bruker på alle bildene våre. Vi serverer først et bilde med ekstremt lav kvalitet som forventes å lastes ned mye tidligere enn det større bildet med høy kvalitet. Når bildet med lav kvalitet har blitt tegnet på skjermen, utløses nettleseren til å hente bildet med høy kvalitet i bakgrunnen. Når bildet med høy kvalitet har blitt lastet ned, vil bildet med lav kvalitet bli erstattet av bildet med høy kvalitet.

Det finnes 3 metoder for 2-trinns lasting. De to første er metoder du bør vurdere. Den siste er en du ikke bør bruke.

1. Full 2-trinns lasting

Med full 2-trinns lasting har det første bildet med lav kvalitet nøyaktig samme dimensjoner (bredde og høyde) som det originale bildet med høy kvalitet.

Resultatet av denne 2-trinns lastingen er at Largest Contentful Paint-elementet vil være det mye raskere bildet med lav kvalitet (som deretter vil bli byttet ut lazy). Byttet av bildet vil skje så raskt at en vanlig besøkende sannsynligvis aldri vil legge merke til det. Resultatet av denne teknikken er at LCP tegnes mye tidligere, siden fremstår som 'klar' mye raskere, noe som bidrar til en langt bedre user experience og forbedrede Core Web Vitals.

2. Mindre innebygde plassholdere

Den mindre plassholderen er en ganske kul teknikk som har én ulempe: den forbedrer ikke Core Web Vitals. Det er likevel en flott teknikk fordi den forbedrer user experience.

Grunnideen er den samme som for 2-trinns lastingsteknikken, men i stedet for ett bilde med lav kvalitet med samme dimensjoner, plasseres et mye mindre bilde med mindre dimensjoner inline gjennom en data-URI. Det endelige hero-bildet, som vil være Largest Contentful Paint-bildet, lastes fortsatt ned i bakgrunnen. Dette trikset vil ikke forbedre Largest Contentful Paint, men vil få siden til å fremstå som klar enda raskere enn 2-trinns lastingsteknikken

3. Gjennomsiktige plassholdere

En vanlig 2-trinns lastingsteknikk og en metode for å lure nettleseren til å sende en tidlig Largest Contentful Paint-metrikk er å bruke gjennomsiktige SVG-elementer. Disse elementene er små og kan plasseres inline, akkurat som den mindre innebygde plassholderen.

Å bruke innebygde SVG-elementer og bytte dem ut er faktisk en lazy loading-teknikk. Fordelen med denne teknikken er at den fungerer på tvers av nettlesere. 

Lazy loading bør selvfølgelig bare brukes på elementer utenfor viewport. I dette tilfellet vil det gjennomsiktige SVG-elementet bare forsinke det virkelige hero-bildet og har ingen merverdi for den besøkende. Selv om paint-metrikken kan være bra, vil UX for siden faktisk bli dårligere.

Det er derfor hero-bildet alltid bør lastes eager uten triks som forårsaker dårlig UX.