Billedoptimering i WordPress: rækkefølgen før du installerer noget

Kort svar: De fleste billedproblemer løses før første plugin – i denne rækkefølge: (1) skalér til maks. ca. 2560 px på længste side før upload, (2) komprimér fornuftigt, (3) lad et moderne format (WebP/AVIF) klare leveringen, og (4) lad WordPress’ srcset og lazy load gøre resten – med topbilledet undtaget. Plugins automatiserer trin 2–3; de reparerer ikke en 6000-pixel original med dårlig beskæring.

Fagligt gennemgået: 2. oktober 2026

Billeder er ofte den tungeste del af en side – og det sted, hvor flest hastighedsproblemer starter og løses. Men løsningen begynder ikke i et plugin: den begynder i arbejdsgangen, før billedet overhovedet uploades. Får du rækkefølgen rigtig, bliver plugin-laget en let automatisering i stedet for en redningsaktion.

Guiden gennemgår de fire trin, hvad WordPress allerede gør for dig af sig selv, hvordan du rydder op i billedstørrelser, og hvordan du måler, at arbejdet virker.

Før du ændrer noget: Tag en backup af mediebiblioteket (wp-content/uploads) og databasen, før du bulk-komprimerer, konverterer formater eller regenererer thumbnails. Komprimering med tab kan ikke fortrydes på selve filen.

Rækkefølgen og hvorfor den betyder noget

Hvert trin arbejder på det forrige trins resultat: komprimering af et alt for stort billede giver stadig en stor fil, og et moderne format kan ikke redde forkerte dimensioner. Trin 1 er dit håndværk – trin 2–4 kan automatiseres.

1. Størrelse før alt andet

Et kamera leverer typisk 6000×4000 pixels; en fuldbredde-visning bruger sjældent mere end ca. 2560, og en indholdsbredde omkring 1200–1600. Skalér derfor til maks. ca. 2560 px på længste side før upload.

WordPress har selv en grænse: billeder over 2560 px skaleres automatisk ned til en „-scaled“-udgave, som bruges på siden – men den store original gemmes også. Du får altså den rigtige visning, men bruger dobbelt plads og længere uploadtid. Det er bedre at skalere selv.

Beskær samtidig til det motiv og format, visningen skal bruge – beskæring er også kompression, bare den kloge slags. Og navngiv fil og alt-tekst beskrivende på dansk: det koster nul bytes og gavner både tilgængelighed og søgning.

2. Komprimering med omtanke

Målet er „ingen synlig forskel ved 100 % zoom“ – ikke den mindst mulige fil. For fotos rammer en JPEG-kvalitet omkring 75–85 typisk den balance; grafik med få farver hører hjemme i PNG eller endnu bedre SVG.

Billedtype	Format ved upload	Tommelfingerregel for færdig fil
Hero- eller topbillede	JPEG i god kvalitet	Under ca. 200 KB
Indholdsbillede	JPEG	Under ca. 100 KB
Logo og ikoner	SVG (eller PNG)	Så lille som muligt
Skærmbillede med tekst	PNG	Komprimér uden at teksten bliver grumset

Tallene er tommelfingerregler, ikke krav – et stort fuldbredde-foto kan godt være tungere og stadig være rigtigt. Automatisér gerne trinnet, fx via QUIC.cloud på LiteSpeed eller et billedplugin, men kør kun én automatik ad gangen: dobbelt komprimering giver synligt kvalitetstab.

3. Moderne formater

WebP giver typisk 25–35 % mindre filer end JPEG ved samme visuelle kvalitet; AVIF ofte endnu mindre på fotos. WordPress kan modtage WebP-uploads, og nyere versioner også AVIF, hvis serverens billedbibliotek understøtter formatet.

Du behøver dog ikke konvertere dit bibliotek manuelt. Den robuste løsning er at uploade JPEG/PNG som original og lade serveren eller optimeringslaget levere det moderne format til browsere, der understøtter det. Så har du altid en universel original, og formatvalget kan ændres centralt senere.

Tjek resultatet i browserens Netværk-fane under kolonnen for indholdstype (content-type). Filendelsen i URL’en kan snyde, når formatet byttes på serverniveau – en fil, der hedder .jpg, kan sagtens blive leveret som image/webp.

4. srcset og lazy load

WordPress genererer automatisk flere størrelser af hvert billede (bl.a. 150, 300, 768, 1024, 1536 og 2048 px) og et srcset, så mobilen får en mindre fil end desktop – forudsat størrelserne findes. Efter et temaskift kan det være nødvendigt at regenerere thumbnails.

Lazy load er standard i WordPress: billeder længere nede på siden får loading="lazy" og hentes først, når de nærmer sig skærmen. Nyere WordPress-versioner forsøger selv at undtage det første store billede og give det fetchpriority="high". Men temaer, sidebyggere og optimeringsplugins kan overstyre det, så din opgave er at kontrollere undtagelserne: LCP-billedet skal hentes straks, aldrig lazy. Hele øvelsen står i lazy load-guiden og LCP-guiden.

Sæt desuden altid width og height (eller aspect-ratio), så billeder reserverer deres plads. Det er halvdelen af et godt CLS-tal.

Baggrundsbilleder og sidebyggere

Alt det automatiske i trin 4 gælder billeder, der indsættes som <img>. Billeder, der sættes som CSS-baggrund – typisk i hero-sektioner i sidebyggere – får hverken srcset, width/height eller WordPress’ indbyggede lazy load. Her afhænger resultatet af byggerens egne indstillinger.

• Brug byggerens responsive indstillinger til at vælge et mindre baggrundsbillede på mobil, hvis muligheden findes.
• Overvej at bruge et almindeligt billedelement i stedet for en baggrund til det vigtigste topbillede – så kan browseren prioritere det som LCP-billede.
• Kontrollér i Netværk-fanen, at baggrundsbilleder længere nede på siden ikke hentes, før de er i nærheden af skærmen.

Baggrundsbilleder er en af de hyppigste forklaringer på, at en side har god billedoptimering „på papiret“, men stadig får dårlig LCP på mobil.

5. Ryd op i billedstørrelser

Hvert uploadet billede bliver til mange filer: WordPress’ egne størrelser plus dem, temaet og plugins registrerer. Med flere temaskift bag sig kan et site have størrelser, som intet længere bruger – det koster diskplads, backupplads og uploadtid.

• Se, hvilke størrelser der er registreret (fx med WP-CLI: wp media image-size).
• Fjern ubrugte størrelser i temaet eller via pluginindstillinger – ikke ved at slette filer manuelt.
• Regenerér først thumbnails, når størrelserne er på plads, og helst uden for travle tidspunkter.

Store mediebiblioteker kan tage lang tid at regenerere. Kør det via WP-CLI frem for i browseren, så du undgår timeouts – se evt. guiden om WP-CLI.

6. Verifikation

Arbejdsgangen sidder, når en typisk side holder en fornuftig samlet billedvægt (tjek i Netværk-fanen med filteret „Img“), mobilen beviseligt får mindre filer end desktop, og LCP-billedet hentes i første bundt requests – og alt ser skarpt ud på en højopløst skærm.

• Sammenlign den valgte srcset-kandidat på mobil og desktop i udviklerværktøjerne.
• Kontrollér, at topbilledet ikke har loading="lazy".
• Kontrollér, at billederne leveres som WebP eller AVIF, hvor det er sat op.
• Kør PageSpeed Insights på en tung side før og efter, og se om billedadvarslerne er væk.

Gør stikprøven til rutine, når nye redaktører kommer til: én god uploadvane (trin 1) bærer hele systemet.

Læs også

• Hub: WordPress performance og cache
• Dårlig LCP i WordPress
• CLS i WordPress
• Billedoptimering i QUIC.cloud
• HTTP-fejl ved upload af billeder
• WordPress hosting hos Hostious – LiteSpeed og NVMe som udgangspunkt

Ofte stillede spørgsmål om billedoptimering

Hvilket format skal jeg uploade i?

Upload gerne JPEG (fotos) og PNG/SVG (grafik) i god kvalitet – og lad leveringslaget om WebP/AVIF. Så har du altid en universel original, og formatvalget kan ændres centralt senere.

Er PageSpeeds „korrekt størrelse på billeder“-advarsel kritisk?

Den betyder, at der leveres flere pixels end visningen bruger – typisk manglende srcset-størrelser eller et for stort valg. Ret den på de tunge sider først; nogle KB på et lille ikon flytter intet.

Behøver jeg et billedoptimeringsplugin?

Med god uploadvane og et leveringslag, der klarer WebP/AVIF (som på LiteSpeed-hosting med QUIC.cloud), er behovet lille. Plugins har værdi, når mange redaktører uploader råt – så automatiserer de komprimering og formater og redder vanerne.

Hvorfor er der en „-scaled“-fil i mediebiblioteket?

WordPress skalerer automatisk billeder over 2560 px ned og bruger den skalerede udgave på siden, men gemmer også originalen. Skalér selv før upload, så slipper du for den ekstra store fil.