Kort svar: De fleste billedproblemer løses før første plugin – i denne rækkefølge: (1) skaler 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.
Billeder er typisk halvdelen af en sides vægt – 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.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Diagrammet er en diagnoseillustration af arbejdsgangen.
Hvorfor rækkefølgen? Fordi hvert trin arbejder på forrige trins output: 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.
Et kamera leverer 6000×4000 pixels; en fuldbredde-visning bruger højst ~2560, og en indholdsbredde ~1600. Skaler derfor til maks. ca. 2560 px på længste side før upload (WordPress gør det selv over den grænse – men så gemmer den også den store original og bruger dobbelt plads). 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.
Målet er “ingen synlig forskel ved 100 % zoom” – ikke mindst mulige fil. For fotos rammer kvalitet 75-85 den balance; grafik med få farver hører hjemme i PNG eller endnu bedre SVG. Tommelfingertal for en færdig webside: hero-billeder under ~200 KB, indholdsbilleder under ~100 KB. Automatisér gerne trinnet – via QUIC.cloud på LiteSpeed eller et billedplugin – men kør kun én automatik ad gangen: dobbelt komprimering giver synligt kvalitetstab.
WebP sparer typisk 25-35 % i forhold til JPEG ved samme visuelle kvalitet; AVIF endnu mere på fotos. Du behøver ikke konvertere dit bibliotek manuelt: lad serveren eller optimeringslaget levere det moderne format til browsere, der understøtter det, og beholde JPEG/PNG som fallback. Tjek resultatet i Netværk-fanens content-type – filendelsen i URL’en kan snyde, når formatet byttes på serverniveau.
WordPress genererer automatisk flere størrelser og et srcset, så mobilen får en mindre fil end desktop – forudsat størrelserne findes (efter temaskift: regenerér thumbnails). Lazy load er ligeledes standard – din opgave er undtagelserne: LCP-billedet skal hentes straks, aldrig lazy; hele den øvelse står i lazy load-guiden og LCP-guiden. Sæt desuden altid width/height (eller aspect-ratio), så billeder reserverer deres plads – det er halvdelen af et godt CLS-tal.
Arbejdsgangen sidder, når en typisk side holder sig under ~1 MB samlet billedvægt (tjek i Netværk-fanen), mobilen beviseligt får mindre filer end desktop (sammenlign valgt srcset-kandidat), LCP-billedet hentes i første bundt requests – og alt ser skarpt ud på en højopløst skærm. Gør stikprøven til rutine, når nye redaktører kommer til: én uploadvane (trin 1) bærer hele systemet.
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.
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.
Med god uploadvane og et leveringslag, der klarer WebP/AVIF (som på LiteSpeed-hosting), er behovet lille. Plugins har værdi, når mange redaktører uploader råt – så automatiserer de trin 2-3 og redder vanerne.
