Bildeoptimalisering for WordPress med AVIF

AVIF aksepteres av 96,35 % av nettleserbruken som caniuse måler (per 12. oktober 2026). Mediekapittelet i Web Almanac 2024 fant formatet på 1,0 % av bildene på mobil. Et gap på over 95 prosentpoeng skyldes ikke nettleserne. Det skyldes opplastingsveien, markupen som velger kandidat, og øyeblikket nettleseren oppdager at bildet finnes.

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: diagnose av LCP-elementet, AVIF i WordPress-kjernen, srcset/sizes, fetchpriority, lazy loading, rollen til et CDN, den reelle statusen for JPEG XL og kravene til tilgjengelighet. Uten generisk AI-komprimeringsteori og uten lister over «performance-partnere».

#Problemer med JPEG-bilder i WordPress

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.

#Hvordan finne LCP-elementet i WordPress

Før du konverterer noe, bekreft med feltdata, ikke med en antakelse, hvilket element som er Largest Contentful Paint i hver mal. Web Almanac 2024 målte at dette elementet er et bilde på 68 % av mobilsidene, med en median på 135 KB for det største bildet. Lest motsatt: på de øvrige 32 % er LCP tekst, og der flytter en AVIF-konvertering ikke metrikken ett millisekund.

Det finnes to tilfeller der WordPress-kjernen ikke kan hjelpe, selv om LCP faktisk er et bilde:

1. LCP-elementet er ikke en img-tagg som kjernen har rendret. En CSS-bakgrunn, plakaten til en video, eller en page builder som skriver markup utenfor wp_filter_content_tags(). Kjernen prioriterer ikke det den ikke ser, så heroen kommer etter stilarket som refererer til den.
2. LCP-elementet varierer med breakpoint. Toppbildet på desktop og kortet på mobil er forskjellige elementer. En statisk antakelse treffer ett av dem.

For disse to tilfellene finnes Image Prioritizer, som krever Optimization Detective. Optimization Detective samler URL Metrics fra ekte besøkende per breakpoint og vet derfor hvilket element som faktisk var LCP, i stedet for å gjette ut fra rekkefølgen i dokumentet. Med disse dataene legger Image Prioritizer til en preload med høy prioritet for LCP-bildet, både som LINK-element i HTML og som HTTP-headeren Link, og preloaden dekker også CSS-bakgrunner (inline eller fra stilark) og videoplakater. Den setter fetchpriority=high på en img bare når elementet er LCP på alle breakpoints, setter fetchpriority=low på bilder i det første viewporten som er skjult (lysbilde to og tre i en karusell, det klassiske tilfellet), og lazy-loader bakgrunner deklarert i inline style-attributter. Pluginet har ingen innstillingsside og virker først når det er samlet inn besøksmetrikker.

Begge pluginene kommer fra ytelsesteamet i kjernen, det samme teamet som publiserer på make.wordpress.org/performance. De er ikke tredjepartsverktøy, men laboratoriet for funksjoner som senere havner i WordPress, så det du installerer som plugin i dag, viser prosjektets offisielle retning.

#Hvordan aktivere AVIF i WordPress

WordPress 6.5 la til AVIF-støtte i februar 2024, i en endring kunngjort av Adam Silverstein. Siden da kan du laste opp og servere .avif på samme måte som JPEG, uten plugin, så lenge serverens Imagick- eller LibGD-bygg kan kode formatet. Den betingelsen har en egen visning i adminpanelet: Verktøy > Nettstedshelse > Info > Mediehåndtering.

Her lønner det seg å gå fra teori til faktisk hosting. På delt hosting (Domeneshop, one.com og lignende pakker) velger du ikke ImageMagick-bygget, du arver det. PHP-versjonen i kontrollpanelet sier ingenting om Imagick-delegatene, og en flytting mellom pakker hos samme leverandør kan endre dem. Åpne Nettstedshelse etter hver flytting og etter hver større serveroppdatering, og behandle resultatet som prosjektdata, ikke som en engangssjekk. Et tema som forutsetter AVIF på en server uten støtte, produserer ingenting og varsler heller ikke.

Det andre å ta inn over seg er at kjernen ikke konverterer noe av seg selv. Et opplastet JPEG forblir JPEG, og mellomstørrelsene forblir JPEG. Hooken som endrer dette er image_editor_output_format, tilgjengelig siden WordPress 5.8, som kobler en kilde-MIME-type til en utdata-MIME-type:

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Tre konsekvenser før du ruller ut filteret:

• Originalfilen beholdes urørt. Bare de genererte mellomstørrelsene får det nye formatet, og det er det som holder mediebiblioteket redigerbart.
• Det gjelder bare fremtidige opplastinger. Eksisterende medier trenger en regenerering.
• Standardverdien er ikke lenger tom. Fra WordPress 6.7 legger kjernen inn koblinger fra HEIC og HEIF til JPEG i dette filteret, så returner arrayen du fikk i stedet for å bygge en ny. Den som i 2023 skrev return array( 'image/jpeg' => 'image/avif' );, slår i dag stille av konverteringen av bilder fra iPhone.

Den andre kjerneinnstillingen som former hver opplasting er big_image_size_threshold, 2560 piksler siden WordPress 5.3. Alt som er bredere eller høyere skaleres ned, og den nedskalerte kopien blir den største tilgjengelige størrelsen. PNG-opplastinger er unntatt fra denne skaleringen. Er hero-plassen din virkelig bredere enn 2560 piksler, serverer du allerede et oppskalert bilde, og ingen formatjobb fikser den uskarpheten.

#Hvor lang tid tar AVIF-koding

Cloudflares dokumentasjon for transformasjoner sier at AVIF-koding kan være en størrelsesorden tregere enn koding til andre formater, og at Cloudflare faller tilbake til WebP eller JPEG når et bilde er for stort til å kodes raskt. Samme regnestykke gjelder på din origin, og enda mer på en delt pakke med prosessgrense. Å konvertere et mediebibliotek på 40 000 elementer i én omgang er en batchjobb med kø og tidsvindu, ikke et klikk på en innstillingsside.

#Hvordan regenerere miniatyrer med WP-CLI

Filteret når bare nye opplastinger, så et eksisterende bibliotek trenger en egen kjøring. wp media regenerate går gjennom vedleggene og lager mellomstørrelsene på nytt med gjeldende konfigurasjon, inkludert utdataformatet du nettopp satte. To flagg sparer deg for det meste av bryet: --only-missing, så en avbrutt kjøring ikke gjentar ferdig arbeid, og --image_size, for å begrense kjøringen til én størrelse når bare den er endret.

wp media regenerate --only-missing --yes

Begrens selve kjøringen, ikke bare kommandoen. På delt hosting konkurrerer en regenerering over titusenvis av vedlegg om den samme CPU-en som betjener ekte trafikk, og AVIF er formatet som krever mest. Del biblioteket i ID-intervaller, kjør utenfor rushtid og ta vare på loggen: listen over vedlegg som feiler er oversikten over ødelagte originaler som ingen har sett på på årevis.

Er du misfornøyd med resultatet, er løsningen å kjøre på nytt med en annen kvalitetsinnstilling, ikke å gjenopprette en sikkerhetskopi. Originalen ble aldri rørt.

#AVIF eller WebP i WordPress

Ifølge utviklernotatet for WordPress 6.5 kan AVIF-bilder være opptil 50 % mindre enn JPEG ved samme bildekvalitet, og forskjellen er størst i fotografier med himmel, hud og myke bakgrunner. Med 96,35 % støtte i caniuse er formatet bredt nok støttet til å behandles 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. Kjernen skriver ett src og ett srcset, ikke <picture>, så den kan ikke alene servere AVIF til nettlesere som aksepterer det og JPEG til resten fra samme markup. Du får ett format per generert størrelse. Det finnes to brukbare svar, og i praksis utelukker de hverandre.

Innholdsforhandling på edge eller server. CDN-et leser Accept-headeren og serverer AVIF, WebP eller JPEG fra én URL. HTML forblir enkel. Prisen er at cachingen avhenger av request-headere, så cache-nøklene må ta hensyn til det, og en slurvete konfigurasjon serverer AVIF til en klient som ikke aksepterer det.

Fallback i markup. Pluginet Modern Image Formats, del av Performance Lab-programmet, genererer mellomstørrelser i moderne formater ved opplasting og kan fra versjon 2.0.0 skrive ut <picture>-elementer med fallback. Standardvalget er AVIF når serveren støtter det og ellers WebP, som er riktig standard for et plugin som ikke kjenner infrastrukturen din. Innstillingene ligger under Innstillinger > Media. I likhet med kjernefilteret gjelder det nye opplastinger.

Og behold JPEG. Utenfor nettleseren er det fortsatt det trygge formatet for e-postklienter, Open Graph-bilder, sosiale kort, RSS-lesere og alle feeder en partner henter. Modern Image Formats beholder den opprinnelige opplastingen, men lager som standard mellomstørrelser av JPEG og PNG bare i det moderne formatet. Trenger en feed eller et sosialt kort JPEG-mellomstørrelser, kryss av for Output fallback images under Innstillinger > Media: da lager pluginet originalformatet ved siden av det moderne i hver størrelse, på bekostning av diskplass og tid per opplasting.

#Hvordan bruke srcset og sizes i WordPress

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. Hvilke størrelser WordPress lager som standard og hvordan du registrerer egne, går vi gjennom i guiden om TimThumb og innebygd bildehåndtering.

Kort sjekkliste:

• Registrer bare størrelsene temaet bruker (unngå titalls døde crops).
• Regenerer miniatyrer etter endring (wp media regenerate, se over).
• 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).

#Fetchpriority og sizes auto i WordPress 6.3 og 6.7

Largest Contentful Paint på landinger og innlegg med fotografisk hero er som regel bildet over folden. Tre kontroller betyr mer enn «mer komprimering»: at heroen ikke lazy-loades, at den har fetchpriority="high", og at nettleseren oppdager den tidlig.

Rådet om å legge til loading="eager" og fetchpriority="high" for hånd er tre år gammelt for innholdsbilder. WordPress 6.3 la til wp_get_loading_optimization_attributes(), som beregner begge attributtene for bilder som går gjennom kjernens renderingsvei:

• Det første bildet som oppfyller terskelen får fetchpriority="high". Å oppfylle betyr et minsteareal på 50 000 piksler, bredde ganger høyde, justerbart med filteret wp_min_priority_img_pixels.
• loading="lazy" utelates på bilder nær toppen av dokumentet. Terskelfilteret er wp_omit_loading_attr_threshold, med standardverdi som økte fra 1 til 3 i 6.3.
• Funksjonen skriver aldri fetchpriority="high" og loading="lazy" sammen, fordi instruksjonene motsier hverandre.

WordPress 6.7 la deretter til sizes="auto" for lazy-loadede bilder, via wp_img_tag_add_auto_sizes(). Det retter den eldste srcset-feilen i WordPress: det genererte sizes-attributtet antok at bildet fylte hele viewporten, så et sidefelt-miniatyrbilde på 300 piksler kunne trekke en kandidat på 1024 på mobil. Siden et lazy-bilde ikke lastes før layouten er klar, kan nettleseren nå bruke den faktiske bredden. Kjernen setter auto foran bare når bildet allerede har loading="lazy", og legger til en liten CSS-regel (wp_enqueue_img_auto_sizes_contain_css_fix()) for å unngå en bivirkning i layouten.

Lærdommen fra begge versjonene: prioritet og bredde er ikke lenger temaets avgjørelse. Tvinger malen din fortsatt disse attributtene for hånd, kjemper den sannsynligvis mot kjernen i stedet for med nettleseren. Sjekk den faktiske markupen i temaet ditt: eldre builders og shortcodes som skriver <img> utenfor kjernens renderingsvei, får ikke disse attributtene.

link rel=“preload” as=“image” i head, med URL-en til den mest sannsynlige varianten (og, ved <picture>, passende imagesrcset/imagesizes), er fortsatt riktig verktøy når LCP-bildet er en CSS-bakgrunn eller kommer fra en builder. Preload av alle bilder på siden er kontraproduktivt: bare LCP-kandidaten.

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.

#Når lønner bilde-CDN seg for WordPress

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.

Hos Cloudflare betyr edge-resize en URL på formen https://<SONE>/cdn-cgi/image/<VALG>/<KILDEBILDE>, der kilden er en absolutt sti på serveren eller en absolutt URL, og valgene skilles med komma. Det som teller her er format=auto, som serverer det mest effektive formatet klienten aksepterer. Tre ting fra dokumentasjonen endrer planleggingen:

• Funksjonen må slås på per sone i dashbordet før noen transformasjons-URL fungerer på det vertsnavnet. Det er den vanligste grunnen til at en korrekt skrevet URL returnerer originalen uskalert.
• Kildebilder er som standard begrenset til samme sone. Tillatte kilder følger en liste som Cloudflare dokumenterer separat fra URL-formatet: et eget medie-subdomene eller en S3-bøtte må legges til listen, eller sonen må åpnes for alle kilder.
• format=auto kan avslå AVIF. På grunn av kodekostnaden nevnt over faller Cloudflare tilbake til WebP eller JPEG når bildet er for stort til å kodes raskt. Heroen din kan være AVIF i test og WebP i produksjon, avhengig av kildedimensjonene, og den forskjellen dukker ikke opp i noen plugin-rapport.

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. Det erstatter heller ikke korrekte srcset og sizes: nettleseren velger kandidat før den sender forespørselen, så feil markup ber om feil bredde, og edge genererer lydig akkurat den feile bredden. Fiks markup og byte på origin; bruk CDN til distribusjon og resize.

#Hvilken komprimeringskvalitet du bør bruke i WordPress

WP_Image_Editor::$default_quality er 82, utfaset siden WordPress 5.8.1 til fordel for get_default_quality(), som returnerer 86 for WebP og de samme 82 for JPEG og alt annet. JPEG går deretter gjennom filteret jpeg_quality, som kjører etter wp_editor_set_quality og derfor har siste ord.

De to filtrene får ulike argumenter, og å blande dem er den vanlige måten en regel ment for ett format ender opp med å gjelde alle. wp_editor_set_quality får standardkvaliteten, MIME-typen og, fra WordPress 6.8, dimensjonene, så den kan variere kvalitet etter format og størrelse. jpeg_quality får bare kvaliteten og en kontekststreng som image_resize. Et fotoportefølje og et bibliotek med skjermbilder av grensesnitt vil ikke ha samme tall. Merk også at kvalitet 100 setter AVIF i tapsfri modus, ifølge utviklernotatet for 6.5, så «maks kvalitet» på AVIF betyr store filer.

Det er også verdt å vite hvordan hvert format svikter når tallet er for lavt. JPEG svikter synlig, med blokker og ringer som vises selv i et miniatyrbilde. AVIF på lav kvalitet glatter i stedet ut fin tekstur: korn, stoff, løvverk og hår mister detaljer mens kantene forblir rene. Den feilen er mye vanskeligere å se i liten størrelse, så kontrollen må gjøres i full oppløsning og på den faktiske malen, ikke i rutenettet i mediebiblioteket.

Og en advarsel om tallene. Påstanden om at en koder oppdager et ansikt, komprimerer himmelen aggressivt og gir en konkret besparelse på 70 %, sirkulerer uten kilde. Behandle ethvert slikt tall som uverifisert til du har målt det på ditt eget bibliotek. Et plugin-dashbord som rapporterer prosent spart, rapporterer om filer på disk, ikke om det nettleseren lastet ned etter at edge forhandlet format. Bare to målinger teller: leverte byte for LCP-ressursen og det visuelle resultatet på malen bildet publiseres i.

Den praktiske sjekken tar tjue minutter. Velg et lite, fast sett representative bilder fra det ekte biblioteket (et ansikt, et produkt på hvit bakgrunn, et skjermbilde med liten tekst og et bredt landskap), kod det med hver kandidatinnstilling og se på resultatet i full størrelse. Det hindrer en global verdi som ødelegger produktfotografiet.

#Hvilke nettlesere støtter JPEG XL i 2026

Her tar de fleste 2026-guider feil, inkludert den tidligere versjonen av denne. JPEG XL har så vidt begynt å komme til levering.

Den eneste reelle endringen kom 6. oktober 2026. Googles kunngjøring lyder: “Chrome leverer støtte for dekoding av bildeformatet JPEG XL (.jxl) fra og med Chrome 155” (Chrome for Developers, egen oversettelse). Brukere av Chrome på desktop får den etter hvert som nettleseren oppdateres de påfølgende ukene. Edge, som kjører på samme motor, har ikke fulgt etter ennå.

Caniuse viser 16,95 % global støtte for JPEG XL per 12. oktober 2026, opp fra 15,02 % da denne delen først ble skrevet, og nesten hele tallet er delvis støtte. Den faktiske statusen, nettleser for nettleser:

Web Almanac målte ikke engang bruken av JPEG XL i 2024, og oppga grunnen: Chromium-baserte nettlesere støttet ikke formatet. Det er et ærligere signal enn noen adopsjonskurve, fordi datasettet som måler hele nettet ikke regnet det som et leveringsformat. Chrome 155 endrer grunnlaget for neste utgave, ikke konklusjonen for et nettsted som publiseres denne måneden. Den siste raden i tabellen avgjør saken overalt der mobiltrafikken hovedsakelig kommer fra Android.

Hva det betyr i praksis:

• Som arkiv- eller masterformat er JPEG XL virkelig bra. Tapsfri transkoding til og fra JPEG er en reell funksjon og en reell grunn til å lagre mastere i JXL. Det er en lagringsbeslutning, ikke en leveringsbeslutning, og den berører ikke srcset.
• Hvis du likevel serverer det, må det stå som første <source type="image/jxl"> i et <picture>, med en AVIF-kilde og en JPEG-fallback bak. De aller fleste besøkende tar en av fallbackene, så JXL-grenen sparer deg ikke for å bygge resten.
• Ikke bruk det som argument for å utsette AVIF. AVIF er formatet med 96,35 % støtte i dag.

Og kan hostingen din ikke kode AVIF, er svaret ikke å vente på JPEG XL, men WebP, via image_editor_output_format eller innstillingen i Modern Image Formats. WebP-støtte er langt mer utbredt i eldre Imagick- og LibGD-bygg, og avstanden mellom JPEG og WebP er mye større enn mellom WebP og AVIF.

#Slik optimaliserer du bilder i WordPress steg for steg

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; kjernen skalerer uansett ned alt over 2560 px).
2. Generering: kjernen lager mellomstørrelser i opplastingens format; image_editor_output_format, Modern Image Formats eller CDN-et gir AVIF eller WebP.
3. Rendering: wp_get_attachment_image() (eller Image-blokken) med korrekte srcset/sizes.
4. Hero: la kjernen sette fetchpriority="high" og droppe lazy; preload bare når heroen er en bakgrunn eller ligger utenfor kjernens markup.
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 med bildeoptimalisering i WordPress

• PNG i fotografier. PNG er for UI og transparens. Foto i PNG blåser opp disk og overføring.
• Kvalitet 100 i JPEG/AVIF. Forskjellen mot et moderat nivå er sjelden synlig, men den synes i vekt, og på AVIF betyr 100 tapsfri modus.
• 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.

#Krav til tilgjengelige bilder i WordPress

Denne delen faller ofte ut av ytelsesguider, og i Norge er den lovpålagt. Ifølge Uutilsynet skal IKT-løsninger i Norge være universelt utformet, og både private og offentlige virksomheter, lag og organisasjoner må følge regelverket. Kravene er hentet fra WCAG-standarden: offentlig sektor skal følge 48 krav, privat sektor 35. Les også vår gjennomgang av den europeiske tilgjengelighetsloven og WCAG 2.1. For bildearbeid er to av kravene på listen viktigst.

Det første er tekstalternativ (1.1.1). En tom alt er korrekt og ønsket for et dekorativt bilde, og en mangel for et bilde som bærer informasjon. WordPress lagrer feltet i mediebiblioteket, så en revisjon er en spørring mot postmeta etter _wp_attachment_image_alt, ikke en gjennomgang mal for mal.

Det andre treffer dette temaet direkte: bilder av tekst (1.4.5). Et kampanjebanner med overskriften brent inn i pikslene bryter kravet, kan ikke oversettes eller markeres, og er i tillegg den verst tenkelige kandidaten for AVIF, fordi utglattingen av fin tekstur som formatet gjør, rammer liten skrift hardest. HTML-tekst over bildet løser det juridiske problemet og komprimeringsproblemet på en gang. Det samme gjelder skjermbilder av grensesnitt med bitteliten skrift: er de illustrasjoner, beskjær og forstørr dem før koding i stedet for å laste opp hele skjermen og stole på koderen.

En beslektet merknad, i tilfelle den dukker opp i samme gjennomgang: SVG er fortsatt riktig svar for ikoner, fordi det er oppløsningsuavhengig og én fil dekker alle skjermtettheter uten srcset. Kjernen tillater ikke opplasting som standard fordi en SVG kan bære skript. Slår du det på, rens filen ved opplasting i stedet for å stole på den som laster opp.

#Sjekkliste for bildeoptimalisering før publisering

• Hvor mye veier heroen i den typiske mobilvarianten, sammenlignet med medianen på 135 KB for det største bildet i Web Almanac 2024?
• 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)?
• Har informative bilder alt-tekst, og er tekst i bannere HTML og ikke piksler?

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

#Når trenger du hjelp med WordPress-bilder

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. Det første nyttige artefaktet er da en kort oversikt: berørte maler, hvor hvert bilde kommer fra, og nåværende LCP-element og tid per mal. Den listen går vi gjennom i WordPress-hastighetsoptimalisering, eller ta kontakt via kontakt slik at tema, Media Library og CDN justeres i samme flyt, i stedet for å stable enda et bildeplugin.

#Konklusjon

Formatene er avgjort. AVIF har 96,35 % nettleserstøtte og innebygd støtte i WordPress siden 6.5. JPEG XL har ingen av delene: Chrome 155 begynte å dekode det 6. oktober 2026, men Edge, Chrome for Android og WordPress-kjernen gjør det ikke, så det holdes utenfor srcset inntil videre. WebP er fallbacken som fungerer overalt.

Å optimalisere bilder i WordPress i 2026 er en kort sekvens: bekreft LCP-elementet med feltdata, sjekk hva serveren kan kode, slå på konvertering av mellomstørrelser og regenerer i batcher, ærlig srcset og sizes, la kjernen styre prioritet, lazy bare under folden, CDN når distribusjonen rettferdiggjør det, og til slutt alt-tekst og bilder av tekst. 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.