Varför laddas inte bilder på en webbsida?

Tomma ytor har oftast få tekniska orsaker

Vi ser det här i projekt oftare än man tror: sidan finns där, layouten stämmer – och sedan dyker plötsligt tomma ytor upp. I butiker är det produktbilder, i portföljer referenserna, i bloggar hero-bilderna. Det känns dramatiskt, eftersom bilder ofta är den del som skapar förtroende.

Orsakskartan: tre kluster

För det första: Bilden går inte att nå. Det här är klassikern: en felaktig sökväg, en omdöpt fil, en stor bokstav för mycket (ja, det räcker på många servrar), eller en mapp har flyttats. Då returnerar servern ofta en 404. Lika ofta ser vi 403 när behörigheter eller ett hotlink-skydd träder i kraft.

För det andra: Bilden blockeras. Sedan många webbplatser helt har gått över till HTTPS stöter vi regelbundet på „Mixed Content“: Sidan är säker (https), men en bild bäddas fortfarande in via http. Moderna webbläsare blockerar då detta – inte av elakhet, utan av säkerhetsskäl. I konsolen står hänvisningen oftast ganska tydligt.

För det tredje: Bilden finns – men den kommer inte fram på ett meningsfullt sätt. Hit hör för stora filer (på mobilen avbryts laddningen lättare eller det känns som att den „aldrig laddar“), ett format utan lämplig fallback, eller ett CDN/cache som levererar en gammal eller skadad variant. Bilder är fortfarande tungviktarna på webben: På typiska startsidor ligger medianen på omkring 900 KB (mobil) till 1054 KB (Desktop) enbart för bilder. HTTP Archive Web Almanac 2024↗

Vårt perspektiv: Felet är sällan „bara teknik“

På Pola tittar vi alltid två gånger på bildproblem: Vad är trasigt – och varför var det möjligt att det gick sönder? För ofta ligger det inte ett enskilt skrivfel bakom, utan en process som saknas. Därför kombinerar vi reparation med förebyggande åtgärder: färre avbrott, mindre data, större effekt.

Om du är akut drabbad just nu, gå inte direkt in i läget ”allt nytt”. Börja med en ordentlig diagnos – och på några minuter är du betydligt klokare.

Webbläsaren visar först var det går fel

Om bilder saknas är den snabbaste vägen nästan alltid densamma: Vi tittar inte först i plugins eller serverloggar, utan där sanningen hamnar – i webbläsaren.

Pola-metod 1: Tre-kontrollers-flödet

Vi använder ett flöde som medvetet hålls kort, men täcker de vanligaste orsakerna. Du behöver bara Chrome eller Firefox.

1) Öppna bild-URL:en direkt. Högerklicka på platsen (eller i koden på src) och öppna bild-URL:en i en ny flik. Om du redan där ser en felsida är det inget ”renderingsproblem”, utan ett leveransproblem.

2) Öppna DevTools och kontrollera Network-fliken. Tryck på F12, byt till ”Network/Nätverk” och ladda om sidan. Filtrera efter ”Img”. Nu ser du statuskoder: 404 (hittades inte), 403 (förbjudet), 500 (serverfel), eller även 200 – då ligger problemet snarare i visning, cache eller format.

3) Läs konsolen, gissa inte. I Console-fliken står hänvisningar som ”Mixed Content” eller CORS-problem ofta ordagrant. Det är ögonblicket då magkänsla blir en tydlig fix.

Vad statuskoderna verkligen säger dig

En 404 betyder nästan alltid: sökväg, filnamn, stora/små bokstäver, fel mapp. En 403 ser vi typiskt vid felaktigt satta filrättigheter, vid säkerhetsregler eller när hotlinking ska förhindras.

Om du ser 200, men ändå inget visas, blir det mer intressant: Då kontrollerar vi härnäst format och CSS. En bild kan vara ”laddad”, men genom CSS hamna på display:none , skrivas över som bakgrundsbild eller täckas av en cookie-banner/overlay. Det händer i praktiken oftare än vad det låter som i klassiska guider.

Verktyg när det blir större

Om du har många sidor lönar det sig med en riktad crawl. För en snabb överblick använder vi ofta, beroende på setup, Google PageSpeed Insights (för prestanda och bildhänvisningar) eller WebPageTest (för vattenfallet och den faktiska laddningsordningen). För ”Är några bildsökvägar trasiga någonstans?” fungerar en Broken Link Checker pragmatiskt.

Det viktigaste: Håll dig till ordningen. Den som först vrider på tio reglage reparerar ibland av misstag – och lär sig inget av det. Den som först mäter fixar rent och hållbart.

Saknade bilder skadar orientering och förtroende

En bild som inte laddas är sällan „bara“ ett visuellt problem. Det är ett litet förtroendebrott: Du har fått någon till din webbplats – och sedan levererar sidan inte den viktigaste orienteringen.

UX, SEO och konvertering hänger ihop med det

När bilder saknas saknas ofta svaren. I webbutiken: „Hur ser produkten ut?“ I rådgivningen: „Är teamet äkta?“ I NGO-kommunikationen: „Vad står projektet för?“ Användare lämnar sidan innan de ens läser din text.

Och även om bilderna till slut ändå visas, spelar tajmingen roll. I prestandasammanhang är det avgörande, vilket element som tar längst tid att bli synligt. I praktiken är det ofta en bild: Enligt Web Almanac är en bild i omkring 68 % av fallen det element som bestämmer Largest Contentful Paint. HTTP Archive Web Almanac 2024↗ Om den här bilden hänger, hänger den upplevda sidan.

Då blir det snabbt ekonomiskt: Mer än hälften av mobila användare lämnar en sida om den laddar längre än tre sekunder. Site Builder Report↗ Det är en siffra som vi inte använder som ett hot, utan som en påminnelse: Ditt innehåll är bara så verkningsfullt som dess leverans.

Vårt nya perspektiv: Bilder är också hållbarhet

Hos Pola tillkommer ytterligare en nivå. Bilder är den största datadelen på många webbplatser – och varje byte måste lagras, överföras och bearbetas. Det kostar energi i datacenter, nätverk och på slutenheter. Internet har ett mätbart CO₂-avtryck, och onödig dataöverföring är en del av det. SHIFT↗

Det låter stort, men börjar i det lilla: En hero-bild som istället för 1,2 MB bara är 180 KB laddas inte bara snabbare. Den är också helt enkelt mer ansvarsfull. „Mindre data, större effekt“ är när det gäller bilder inte en slogan, utan ett designbeslut.

Och ja: Google tittar också

Core Web Vitals har i flera år varit en del av Page-Experience-signalerna. Sedan 2025 har kraven blivit tydligare i många team: Prestanda är inte längre „Nice“, utan hygien. Den som får ordning på bildproblem förbättrar oftast samtidigt LCP, minskar avhopp och gör innehållet tillförlitligt igen.

Det fina: Det är precis här de snabbaste, renaste förbättringarna ofta finns – eftersom bilder har så stor potential.

Sökvägar, format och rättigheter förklarar de flesta bortfallen

I praktiken är det ofta samma snubbeltrådar – bara i olika kostymer. Vi går igenom dem här medvetet så som de möter oss i vardagen.

Sökväg, filnamn, stora och små bokstäver

Den vanligaste orsaken är banal: Bildet ligger inte där URL:en pekar. Efter en relansering, efter att mediemappar har flyttats eller efter en migrering (till exempel från staging- till live-miljön) blir gamla sökvägar kvar.

Tänk också på filnamn: specialtecken, omljud, mellanslag eller en „final-final-2.png“ kan i kombination med encoding och CMS-logik sluta märkligt. Och mycket viktigt: På många Linux-servrar är /Bilder/Foto.jpg något annat än /bilder/foto.jpg.

Behörigheter, server och uppladdningsfel

Om en 403 kommer tillbaka är det ofta en behörighetsfråga eller en skyddsregel. Särskilt i WordPress ser vi detta efter byten av webbhotell: uploads-mappen har felaktiga behörigheter eller ett säkerhetsplugin blockerar vissa filtyper.

Om bara en bild inte laddas kan den också helt enkelt vara skadad (uppladdningen avbröts, filen är korrupt). Då hjälper oftast: exportera på nytt, ladda upp på nytt, diskutera inte saken länge.

Cache är både förbannelse och välsignelse

En cache kan rädda en sida – och den kan driva dig till vansinne. När bilder byts ut men ligger kvar under samma URL levererar webbläsare eller CDN:er ibland fortfarande den gamla varianten. Vår rutin: gör först en Hard-Reload, sedan Cache-Purge i CDN/plugin, och gå först därefter vidare.

WordPress-specifikt: Plugins och bildoptimerare

Många bildproblem i WordPress är indirekta. Ett optimeringsplugin konverterar bilder till WebP, men Rewrite-regeln är fel. Eller så sätter ett Lazy-Loading-plugin attribut på ett sådant sätt att webbläsaren laddar bilderna först när de är i viewporten – men ett overlay förhindrar scrollningen och därmed triggern.

Om du vill optimera men måste förbli stabil, börjar många team med etablerade verktyg som ShortPixel eller Imagify. Det viktiga är inte själva verktyget, utan att du testar efteråt: i inkognitoläge, på mobilen, och en gång i Safari.

Pola-metod 2: Fixa med „en variabel per steg“

När vi åtgärdar bildproblem ändrar vi aldrig fem saker samtidigt. Vi tar exakt en hypotes (t.ex. „Mixed Content“), genomför fixen, kontrollerar resultatet i Network-fliken – och först därefter kommer nästa variabel.

Det låter långsamt, men är raka motsatsen: Du behåller kontrollen. Och du kan dokumentera fixen senare, i stället för att börja om från noll nästa gång.

Osynliga säkerhetsregler orsakar synliga luckor

Om grunderna stämmer (sökvägen är korrekt, status 200, ändå ingen bild), är det oftast dessa „osynliga“ fall som kostar tid. Vi samlar dem här, eftersom de i klassiska how-tos ofta bara nämns i förbifarten.

Mixed Content efter HTTPS-omläggning

Du har aktiverat SSL, sidan körs på https – men några bilder är fortfarande hårdkodade till http. Då blockerar webbläsaren dem. Du kan se det mycket tillförlitligt i konsolen.

I WordPress hjälper ofta en sök-och-ersätt-operation i databasen (var försiktig och helst med en säkerhetskopia). Många team använder Better Search Replace. Viktigt är: Kontrollera därefter att verkligen alla tillgångar levereras via https.

CORS och externa bildkällor

Om du laddar bilder från en annan domän kan det uppstå CORS-problem i vissa tillämpningar (Canvas, vissa skriptåtkomster). För ”normal visning” är CORS mer sällan orsaken, men i webbappar ser vi det definitivt. Då är lösningen: sätt rätt headers eller flytta bilderna till en lämplig asset-domän.

Hotlinking och Referrer-skydd

Ibland är bilder ”där”, men får bara bäddas in från den egna domänen. En butiksägare kopierar då en bild från ett gammalt system eller från en tillverkare – och plötsligt är den borta, eftersom källan blockerar hotlinking. Det är ingen bugg, utan avsiktligt från källans sida. Den rena lösningen är alltid: hosta bilden själv eller klargör tillståndet.

CDN och Edge-cache: det trasiga ekot

CDN:er är fantastiska – tills en edge-nod cachar en felaktig variant. Då ser vissa användare bilder, andra inte. Om du har ett sådant ”bara hos vissa”-problem är det en stark indikation.

Här hjälper ofta en riktad purge (bara de berörda URL:erna) och därefter ett test från olika regioner, till exempel med WebPageTest eller en kontroll från flera platser.

Formatstöd och fallbacks (WebP, AVIF)

WebP stöds idag brett, AVIF är starkt på frammarsch. Enligt Web Almanac har AVIF fyrdubblats mellan 2022 och 2024, medan andelen JPEG minskar. HTTP Archive Web Almanac 2024↗

Trots det gäller: Om du levererar Next-Gen-format behöver du rena fallbacks via <picture> – annars blir ”optimerat” snabbt ”osynligt”, så snart en webbläsare i utkanten eller en särskild in-app-webbläsare kommer in i bilden.

Dessa specialfall är precis anledningen till att vi alltid läser debugging som en liten historia: Vem anropar vem, vad kommer tillbaka, och vem blockerar det? Så snart du ser bilden som en request-kedja blir det lösbart igen.

Robusta processer förhindrar trasiga länkar

Om vi vill förhindra bildbortfall permanent räcker det inte att laga enskilda trasiga länkar. Då behöver vi en bildpipeline som är lika självklar som en varumärkesguide: tydliga regler, enkla rutiner, få överraskningar.

Vår ”lilla pipeline” som sparar mycket besvär

Vi rekommenderar team en pragmatisk version som fungerar utan någon stor verktygslåda:

1) Skala och komprimera före uppladdning. Ett foto från kameran är nästan aldrig redo för webben. För snabb kvalitetskontroll använder vi gärna Squoosh eller små verktyg som TinyJPG.

2) Ta responsiva bilder på allvar. Om du skickar en 2400px-bild till en 390px bred mobil ser den ”skarp” ut, men är framför allt slöseri. Web Almanac visar att bilder i median levereras cirka 25 % större än nödvändigt på mobilsidor. HTTP Archive Web Almanac 2024↗ srcset och meningsfulla storleksnivåer löser det.

3) Lazy loading, men med känsla. För bilder under det synliga området är loading="lazy" oftast rätt. För den centrala hero-bilden är det ofta fel, eftersom det kan försämra LCP. (Här hjälper beroende på setup även fetchpriority="high".)

4) Konfigurera caching så att uppdateringar inte fastnar. Långa cachetider är bra, så länge du använder versionshantering (filnamn eller hash). Då förblir sidan snabb och du tappar inte kontrollen.

Vårt färska perspektiv: Minimalism som teknisk stabilitet

En punkt som vi sällan läser i andra guider, men som vi ständigt ser i designprojekt: Ju fler bilder som är ”bara dekoration”, desto skörare blir sidan. Minimalistisk design är inte bara en estetisk hållning, det är ofta också det robustare tekniska beslutet.

Därför frågar vi medvetet: ”Vilken bild förmedlar verkligen betydelse?” Om en bild bara fyller ut utrymme ökar risken (fler förfrågningar, fler beroenden) utan tydlig effekt. Om en bild förmedlar betydelse behandlar vi den som kärninnehåll: optimerad, prioriterad, med fallback.

På så sätt blir förebyggande arbete inte en extra uppgift, utan ett sätt att bygga webbplatser: lätta, tydliga, hållbara.

Bra innehåll fungerar även utan bilden

När bilder inte laddas är det för vissa användare ”bara” irriterande. För andra är det ett verkligt hinder. Och just där blir det intressant: tillgänglighet är inte bara en lagfråga eller en kryssruta, utan ett stresstest för ditt innehåll.

Alt-texter är ingen dekoration

En myt lever envist kvar: ”Om bilden saknas ser man ju alt-texten.” I verkligheten sker det på olika sätt – ofta visar webbläsaren bara en liten symbol, och alt-texten är framför allt värdefull för skärmläsare. Det betyder: Alt-texter ersätter inga bilder, men de räddar information.

Vi skriver alt-texter på ett sådant sätt att de förmedlar syftet med bilden, inte beskriver pixlarna. Ett produktfoto behöver något annat än en stämningsbild. Och ett diagram behöver en textuell sammanfattning, annars går informationen förlorad.

Platshållare och layoutstabilitet

Tillgänglighet handlar också om layout: När bilder laddas sent eller inte alls uppstår ofta hopp. Det är inte bara irriterande, utan kan belasta personer med kognitiva begränsningar eller koncentrationssvårigheter mer. Ett enkelt, ofta underskattat steg: width och height ange (eller definiera fasta proportioner via CSS), så att utrymmet reserveras och sidan förblir stabil.

Vårt nya perspektiv: ”Tillgång trots bortfall” som kvalitetskriterium

Vi bedömer gärna webbplatser utifrån hur de beter sig när saker går fel: långsamt nätverk, blockerade bilder, extern tjänst nere. Om allt då kollapsar var upplevelsen skör.

Om du däremot sköter alt-texter ordentligt, inte gömmer viktig information enbart i bilden, och bäddar in visuellt innehåll med stabila platshållare, förblir din webbplats användbar – även när en bild inte kommer fram.

Det passar vårt anspråk ”Tillgång för alla”: Inte för att vi lovar perfektion, utan för att vi tar ansvar på allvar.

Snabba lösningar kan skapa nya fel

Vid bildproblem ser vi två typiska reaktioner: Antingen blir allt ”sönderanalyserat” – eller så används snabba lösningar som på lång sikt skapar nya problem. Några missförstånd dyker ständigt upp.

Myt: Ett CDN gör allt automatiskt snabbt

Ett CDN kan minska latensen, men det gör inte plötsligt en bild på 5 MB liten. Om du inte använder ett bild-CDN med automatisk transformering förblir filstorleken identisk. Effekten är då begränsad – och ibland uppstår till och med ytterligare komplexitet genom cache-invalidering.

Om du verkligen vill leverera automatiserat, titta på tjänster som Cloudinary som levererar format och storlekar dynamiskt. Det behövs inte för varje webbplats, men vid stora mängder bilder kan det spara mycket underhåll.

Myt: Högsta kvalitet är alltid det bästa valet

Vi älskar starka bilder. Men vi ser också att användare hellre ger upp än väntar på perfektion. När laddningstiden ökar från 1 till 10 sekunder kan avvisningsfrekvensen öka drastiskt. Site Builder Report↗ Vår erfarenhet: En kvalitet som är ”visuellt ren” slår en kvalitet som är ”tekniskt maximal”.

Myt: Optimerad en gång, klar för alltid

Prestanda är ett tillstånd som förändras dagligen, eftersom innehållet förändras. Idag laddar en redaktör upp en bild på 6 MB, imorgon kommer ett nytt plugin, i övermorgon aktiveras ett CDN. Därför är förebyggande åtgärder viktigare än hjältedåd.

Myt: Alt-text löser problemet

Alt-texter är viktiga – men de är ingen ursäkt för trasiga bilder. De är säkerhetsbältet, inte motorn.

Vi gillar inte dessa myter för att de är „fel“, utan för att de leder dig i fel riktning: bort från tydlig diagnos, bort från en genomtänkt bildstrategi. När du väl har förstått sambanden blir ämnet betydligt mer avslappnat – och du fattar beslut som förenar design, teknik och effekt.