Billeder er stadig den største synder

Efter 25 år er der stadig ét svar der oftere end noget andet forklarer hvorfor en hjemmeside er langsom: billederne er for store.

Det er også den bedste nyhed i hele hastighedsoptimering, for det er den letteste ting at rette. Du behøver ikke skifte tema, du behøver ikke skifte host, og du behøver ikke røre en linje kode. Du skal bare holde op med at sende 1,5 MB, hvor 80 kB gør det samme.

De fem fejl

1. Filen er for stor

Et hero-billede taget med et telefonkamera og lagt direkte ind i WordPress fylder let 3–5 MB. Det koster sekunder alene på hentetiden, og det er som regel netop det billede der afgør din LCP — grænsen for en god LCP er 2,5 sekunder.

Løsningen: komprimér. Et fotografi der fylder 80–200 kB er stort nok til et hero på en almindelig hjemmeside.

2. Formatet er forældet

JPEG er fra 1992 og PNG fra 1996. WebP og AVIF fylder markant mindre ved samme kvalitet, og de er ikke længere et eksperiment: AVIF understøttes af over 94 procent af browserne i brug — Chrome fra version 85, Firefox fra 93, Safari fra 16.4 og Edge fra 121. WebP er understøttet endnu bredere.

Løsningen: konvertér. De fleste billedplugins kan gøre det automatisk ved upload, og de behøver ikke koste noget — Imagify, ShortPixel og Smush vejer alle omkring −0,10 i min vægtning, altså de gør siden hurtigere.

3. Billedet er større end det bliver vist

Det her er den der overrasker folk. Et billede på 3000 px bredde, som vises i en spalte på 600 px, bliver hentet i fuld størrelse og først derefter skaleret ned inde i browseren. Du har betalt for 3000 px og fået 600.

Løsningen: skalér ned til den bredde billedet faktisk vises i, gerne ganget med to for skarpe skærme. Ingen visning på en almindelig hjemmeside er bredere end 1600 px — alt derover er spildt vægt. Brug srcset, så mobilen får en mindre fil end computeren.

4. Der er ingen width og height

Uden dem aner browseren ikke hvor meget plads billedet skal fylde. Den lader teksten løbe sammen, og skubber den ned igen når billedet lander. Det er CLS, og det er et af de tre Core Web Vitals.

Løsningen: sæt width og height på hvert eneste <img>. Browseren regner selv forholdet ud og reserverer pladsen — også når billedet er responsivt og skalerer med spalten. Det er to attributter, og det er forskellen på CLS 0 og CLS 0,25.

5. Hero-billedet er sat til at vente

Den mest ærgerlige af de fem, fordi det er selvskade. Lazy loading er en god idé på de billeder der ligger langt nede på siden. Sat på billedet i toppen fortæller det browseren, at netop det billede der afgør LCP kan vente.

Det sker oftere end man tror, fordi WordPress selv sætter loading="lazy" på billeder i indholdet, og fordi mange temaer henter hero-billedet gennem de samme funktioner.

Løsningen: fjern loading="lazy" fra billederne der er synlige uden at rulle, og giv LCP-billedet fetchpriority="high" i stedet.

Den sjette, som er en fælde for sig

Bygger du siden i Elementor eller Divi, ender hero-billedet ofte som en CSS-baggrund frem for et rigtigt <img>. Forskellen betyder noget: browseren opdager først et baggrundsbillede når sidens CSS er hentet og læst, mens et <img> i HTML’en bliver fundet med det samme og sat i kø.

Det er en af grundene til at LCP er sværere at få ned på en side bygget i en sidebygger. Se Elementor og hastighed.

Sådan finder du dine egne

Kør din forside gennem PageSpeed Insights på mobil, og kig efter fire punkter:

• “Properly size images” — billeder større end de vises. Fejl nummer 3.
• “Serve images in next-gen formats” — JPEG og PNG der burde være WebP eller AVIF. Fejl nummer 2.
• “Efficiently encode images” — filer der er større end de behøver ved samme kvalitet. Fejl nummer 1.
• “Image elements do not have explicit width and height” — fejl nummer 4.

Ved siden af hvert punkt står den estimerede besparelse. Det er dét tal du skal rangordne efter, ikke rækkefølgen på listen.

Rækkefølgen jeg selv arbejder i

1. Find LCP-billedet først. Det er som regel det store i toppen. Det ene billede betyder mere end alle de andre tilsammen.
2. Skalér det til den bredde det vises i, konvertér til WebP eller AVIF, og komprimér.
3. Fjern lazy loading fra det, og sæt fetchpriority="high".
4. Sæt width og height på alt. Det tager fem minutter og redder CLS.
5. Kør resten af billederne igennem med et plugin der konverterer automatisk ved upload.
6. Sæt lazy loading på alt under folden — inklusive YouTube-indlejringer, som ellers trækker flere hundrede kilobytes ned før nogen har trykket play.
7. Mål igen.

Er der stadig langt til målet efter det, ligger problemet et andet sted. Se Hvorfor er min WordPress-hjemmeside langsom?

Ofte stillede spørgsmål

Skal jeg bruge WebP eller AVIF?

AVIF fylder mindst, og understøttelsen er over 94 procent. WebP fylder lidt mere, men er understøttet af stort set alt. Kan dit plugin levere begge med automatisk fallback, så gør det. Skal du vælge ét, er WebP det sikre og AVIF det hurtigste.

Ødelægger komprimering kvaliteten?

Ikke synligt, når det gøres rigtigt. Et fotografi tåler at blive skåret ned til en brøkdel af sin oprindelige størrelse, før nogen kan se forskel på en skærm. Grafik med skarpe kanter og tekst tåler mindre — der er det værd at kigge efter.

Hvor mange billeder skal hentes med det samme?

Dem der er synlige når siden åbnes — typisk to til fem på en mobilskærm. Resten kan vente. Er du i tvivl, så åbn siden på en telefon og tæl.

Hjælper et CDN på billederne?

Ja, men først bagefter. Et CDN leverer filerne hurtigere, men det gør dem ikke mindre. Skær filerne ned først — så er der mindre at levere.