Bildeoptimalisering for WordPress med AVIF

Bilder er fortsatt den største byte-blokken på de fleste WordPress-nettsteder. I 2026 er problemet sjelden «mangel på et magisk plugin». Det er å servere riktig format, i riktig bredde, med korrekt prioritet på hero-bildet, og med en leveringskjede (origin eller CDN) som ikke tvinger nettleseren til å hente et JPEG på 2400 px til et kort på 360 px.

Denne guiden dekker den praktiske flyten: AVIF og WebP, srcset/sizes, native WordPress-størrelser, fetchpriority, lazy loading og rollen til et CDN. Uten generisk AI-komprimeringsteori og uten lister over «performance-partnere».

#Hva som endrer seg i 2026 kontra klassisk JPEG

I årevis var flyten: eksporter JPEG på 80 %, last opp i Media Library, la temaet kalle the_post_thumbnail( 'large' ). Det fungerer fortsatt, men lar tre hull stå åpne.

1. Én stor fil for alle skjermer.
2. Et format som er mindre effektivt enn AVIF eller WebP ved samme perseptuelle kvalitet.
3. Feil nettverksprioritet: heroen konkurrerer med CSS, fonter og tredjepartsskript.

Moderne nettlesere velger godt mellom kandidater i <picture> eller et ærlig srcset. WordPress emitter allerede srcset når du bruker wp_get_attachment_image() og størrelsene er registrert. Det redaksjonelle og tekniske arbeidet er å mate den API-en med gode filer og ærlige metadata.

På norske redaksjonsnettsteder ser vi ofte det samme mønsteret som i butikker: et hero-bilde fra pressefoto på 4000 px bredde, lagret som JPEG, og deretter et page builder-kort som viser det i 320 px. Codec hjelper lite hvis bredden er feil.

Samme historie dukker opp i kommunale og medlemsnettsteder: mange opplastinger fra fotografer som leverer TIFF eller RAW-eksport «for sikkerhets skyld», konvertert til PNG i Media Library. Da er du allerede bakpå før AVIF kommer inn i bildet. Begrens masterfilen ved opplasting, ikke etter at CDN-et har laget ti varianter av en for stor original.

#AVIF først, WebP som sikkerhetsnett

AVIF (basert på AV1) leverer ofte filer 20 til 50 % mindre enn tilsvarende JPEG, og mange ganger også mindre enn WebP, særlig i fotografier med himmel, hud og myke bakgrunner. Støtten i hovednettleserne er bred nok til å behandle det som primærformat på innholdssider og nettbutikker.

WebP er ikke «død». Det forblir den mest nyttige fallbacken når:

• hostingen ikke genererer AVIF (Imagick uten libavif, eller bare GD);
• et eldre CDN bare forhandler WebP;
• du trenger lett animasjon uten video.

Det stabile HTML-mønsteret er et <picture> med source type="image/avif", deretter image/webp, og et avsluttende <img> i JPEG eller PNG. I WordPress dukker dette opp via konverteringsplugins, filtre ved opplasting, eller transformasjon på CDN-edge. Kjernen alene garanterer ikke AVIF på alle installasjoner.

JPEG XL fortjener en omtale, men i 2026 er det fortsatt ikke standardveien for offentlige WordPress-nettsteder: nettleser- og hosting-verktøystøtte er ujevn. For produksjon: prioriter AVIF + WebP og behold JPEG som anker.

#Srcset og sizes: riktig bredde, ikke bare riktig format

Effektivt format med feil dimensjon ødelegger fortsatt LCP. Hvis heroen på mobil har 390 px CSS-bredde og src peker på en 2000 px-fil, laster nettleseren megabyte for mye selv i AVIF.

WordPress registrerer størrelser med add_image_size() og ved rendering bygger wp_get_attachment_image_srcset() kandidatlisten. Attributtet sizes forteller nettleseren hvilken CSS-bredde som forventes per breakpoint. Uten realistisk sizes (for eksempel (max-width: 768px) 100vw, 720px) kan nettleseren velge en for stor kandidat.

Kort sjekkliste:

• Registrer bare størrelsene temaet bruker (unngå titalls døde crops).
• Regenerer miniatyrer etter endring (wp media regenerate eller tilsvarende).
• På heroen: bekreft i DevTools Network filbredden som ble valgt, ikke bare Content-Type.
• I Gutenberg-blokker: hold bilder på linje med temaets content width; opplastinger på 5000 px «fordi vi beskjærer senere» øker lagring og genereringstid.

Nyttig dokumentasjon: referansen til wp_get_attachment_image_srcset i Developer Handbook og bildematerialet på web.dev forklarer samme idé fra to sider (CMS og nettleser).

#LCP: eager, fetchpriority og preload

Largest Contentful Paint på landinger og innlegg med fotografisk hero er nesten alltid bildet over folden. Tre kontroller betyr mer enn «mer komprimering».

loading=“eager” (eller utelat lazy) på heroen. Native lazy loading forsinker bilder brukeren allerede ser.

fetchpriority=“high” på LCP-bildet. Forteller nettleseren at det er en kritisk ressurs mot andre nedlastinger.

link rel=“preload” as=“image” i head, med URL-en til den mest sannsynlige varianten (og, ved <picture>, passende imagesrcset/imagesizes). Preload av alle bilder på siden er kontraproduktivt: bare LCP-kandidaten.

I WordPress 6.x bruker kjernen og flere temaer allerede fetchpriority på fremhevede bilder. Sjekk den faktiske markupen i ditt tema: eldre builders og shortcodes emitter fortsatt <img> uten disse attributtene.

Et konkret feilspor i DevTools: LCP-elementet er et bilde, men Network viser at CSS og tre skript startet før bildet. Da hjelper ikke mer komprimering før du har flyttet prioriteten. Preload uten fetchpriority på selve <img> kan også skape dobbel nedlasting hvis URL-ene ikke matcher.

Praktisk regel: de første to eller tre bildene over folden kan være eager; alt under folden får loading="lazy" og ikke høy fetchpriority.

#CDN: når det hjelper og når det bare skjuler problemet

Et bilde-CDN (Cloudflare Images, Imgix, selvhostet Thumbor, eller edge-resize hos leverandøren din) løser tre tilfeller godt:

1. Publikum i flere land og origin i én region.
2. Mange varianter (butikk med rutenett, gallerier, retina).
3. AVIF/WebP-konvertering på edge fra en master JPEG/PNG, uten å mette PHP ved opplasting.

For at det skal fungere må cache-nøkkelen inkludere akseptert format, bredde og eventuelt kvalitet. Ellers får halvparten av trafikken feil variant. Du trenger også stabile URL-er: tilfeldige query-strenger ved hver deploy invaliderer cache uten grunn.

Et CDN fikser ikke et tema som injiserer heroen via CSS background-image uten dimensjoner, eller en slider som laster ti full-bleed slides i første paint. Fiks markup og byte på origin; bruk CDN til distribusjon og resize.

#Anbefalt WordPress-pipeline

Flyt som skalerer uten operasjonelt kaos:

1. Opplasting: masterfoto i sRGB, maks bredde på linje med temaets største breakpoint (for eksempel 1920 eller 2560 px, ikke 8000 px fra kameraet).
2. Generering: kjernen lager JPEG/WebP i registrerte størrelser; plugin eller CDN legger til AVIF.
3. Rendering: wp_get_attachment_image() (eller Image-blokken) med korrekte srcset/sizes.
4. Hero: eager + fetchpriority high; eventuelt preload.
5. Resten: lazy; ingen preload.
6. Overvåking: PageSpeed/CrUX på den virkelige URL-en, filtrer på «LCP element» og bildevekt.

På delt hosting uten Imagick AVIF er konvertering på CDN-edge ofte billigere enn å bytte server bare for én codec.

#Vanlige feil på WordPress-nettsteder

• PNG i fotografier. PNG er for UI og transparens. Foto i PNG blåser opp HTML og disk.
• Kvalitet 100 i JPEG/AVIF. Nesten aldri synlig forskjell mot 70–80 perseptuelt; forskjellen synes i vekt.
• Crops 1:1 og 16:9 «for sikkerhets skyld» som aldri brukes. Hver opplasting multipliserer I/O og backups.
• Lazy på logo og hero. Forsinker LCP og CLS hvis dimensjoner mangler i markup.
• To optimaliseringsplugins samtidig. Den ene omskriver URL-er, den andre serverer WebP; resultatet er 404 eller dobbel prosessering.
• Ignorere width og height. Uten intrinsiske dimensjoner hopper layouten når bildet kommer.

#Rask sjekkliste før publisering

• Veier heroen under ca. 150–200 KB i typisk mobilvariant?
• Viser Network AVIF eller WebP i selve dokumentet, ikke bare på pluginets testside?
• Matcher sizes den faktiske CSS-bredden til content/hero?
• Har bare ett bilde fetchpriority="high"?
• Svarer CDN-et (hvis det finnes) 200 med cache-hit etter andre forespørsel?
• Er CLS for heroen stabil (dimensjoner eller aspect-ratio i CSS)?

Hvis et punkt feiler, fiks det punktet før du kjøper mer verktøy.

#Når det lønner seg med teknisk hjelp

Hvis temaet kommer fra en eldre builder, hvis WooCommerce-butikken serverer inkonsistente miniatyrer per produktvariasjon, eller hvis LCP svinger mellom bilde og tekstblokk avhengig av enhet, er problemet ikke lenger «mer komprimering» men markup og arkitektur. Da gir det mening å ta kontakt via kontakt slik at tema, Media Library og CDN justeres i samme flyt, i stedet for å stable enda et bildeplugin.

#Konklusjon

Å optimalisere bilder i WordPress i 2026 er en kort sekvens: AVIF med WebP i reserve, ærlig srcset, riktig LCP-prioritet, lazy bare under folden, og CDN når distribusjonen rettferdiggjør det. Brukeren skal ikke legge merke til codec-et; de skal legge merke til at siden åpner raskt og at bildene fortsatt er skarpe på skjermen de bruker.