TM
February 12, 2026
|
10 min läsning


När bilder inte laddas, ter sig en webbplats omedelbart "trasig" – och ofta är orsaken enklare än den känns.
Vi visar dig hur du känner igen de vanligaste felen, hur du kan felsöka i en fast ordning och vilka lösningar som verkligen fungerar i WordPress, med HTTPS och CDN.
I slutändan har du inte bara en reparation, utan en robust bildstrategi: snabbare, mer tillgänglig, mer hållbar.
404
403
500
Blandat innehåll
Cache
CDN
WebP
AVIF
LCP
CLS
Lata laddningar
CORS
Sökväg
Rättigheter
WordPress
Hotlinking
Vi upplever detta i projekt oftare än man tror: Sidan är klar, layouten passar – och plötsligt dyker det upp tomma ytor. I butiker är det produktbilder, i portföljer referenser, i bloggar hero-bilder. Det känns dramatiskt eftersom bilder ofta är den del som skapar förtroende.
För det första: Bilden är inte tillgänglig. Det klassiska problemet: 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. Servern ger ofta en 404 tillbaka. Lika ofta ser vi 403 om behörigheter eller en hotlink-skydd finns.
För det andra: Bilden blockeras. Sedan många webbplatser kör helt på HTTPS, stöter vi regelbundet på "Blandat innehåll": sidan är säker (https), men en bild är fortfarande länkad över http. Moderna webbläsare blockerar det då – inte av elakhet, utan av säkerhetsskäl. Informationen står vanligtvis tydligt i konsolen.
För det tredje: Bilden finns där – men den kommer inte fram. Det kan bero på för stora filer (på mobilen avbryts det oftare eller verkar "aldig slutat ladda"), ett format utan passande fallback, eller ett CDN/cache som levererar en gammal eller skadad version. Bilder är fortfarande det tunga på webben: På typiska hemsidor ligger det medianmässigt runt 900 KB (mobil) till 1054 KB (desktop) enbart i bilder. HTTP Archive Web Almanac 2024
På Pola tittar vi alltid extra noga vid bildproblem: Vad är trasigt – och varför kunde det gå sönder? För ofta saknas inte bara en enkel typo, utan en process. Därför kombinerar vi reparation med prevention: färre fel, färre data, mer effekt.
Om du just nu är akut drabbad, slå inte över till "allt-nytt"-läget. Börja med en ren diagnos – och du är mycket klokare på några minuter.


När bilder saknas är det snabbaste sättet nästan alltid detsamma: Vi tittar inte först i plugins eller serverloggar, utan där sanningen landar – i webbläsaren.
Vi använder en procedur som medvetet hålls kort, men täcker de vanligaste orsakerna. Du behöver bara Chrome eller Firefox.
1) Öppna bild-URL direkt. Högerklicka på platsen (eller i koden src) och öppna bild-URL i en ny flik. Om du redan ser en felsida där är det inget "renderingsproblem", utan ett leveransproblem.
2) Öppna DevTools och granska Network-tabben. Tryck F12, växla till "Network/Nätverk" och ladda sidan igen. Filtrera efter "Img". Nu ser du statuskoder: 404 (inte hittad), 403 (förbjuden), 500 (serverfel), eller även 200 – då ligger problemet snarare i representation, cache eller format.
3) Läs konsolen, gissa inte. I Console-tabben finns ofta ledtrådar som "Blandat innehåll" eller CORS-problem i klartext. Det här är ögonblicket när magkänslan blir en tydlig fix.
En 404 betyder nästan alltid: Sökväg, filnamn, stora/små bokstäver, fel mapp. En 403 ser vi typiskt vid felaktigt inställda filrättigheter, säkerhetsregler eller när hotlinking förhindras.
Om du ser 200 men inget visas ändå, blir det mer intressant: Då kollar vi nästa format och CSS. En bild kan vara "laddad", men landa på display:none genom CSS, överskrivas som bakgrundsbild eller blockeras av en cookie-banner/overlay. Det händer oftare i verkligheten än vad det låter i klassiska guider.
Om du har många sidor är det värt att göra en riktad crawl. För en snabb översikt använder vi beroende på setup Google PageSpeed Insights (för prestanda och bildledtrådar) eller WebPageTest (för vattenfall och verklig laddningsordning). För "Är någonstans bildsökvägar trasiga?" fungerar en Broken Link Checker pragmatiskt.
Det viktigaste: Håll ordningen. Den som ändrar på tio håll omedelbart fixar ibland av misstag – och lär sig inget av det. Den som först mäter, fixar rent och hållbart.
Vill du åtgärda orsaken snabbt, noggrant och permanent?
En bild som inte laddas är sällan „bara“ ett visuellt problem. Det är ett litet tillitsbrott: Du har fått någon till din webbplats – och då levererar inte sidan den viktigaste orienteringen.
När bilder saknas, saknas ofta svaren. I shoppen: "Hur ser produkten ut?" I rådgivningen: "Är teamet verkligt?" I NGO-kommunikation: "Vad står projektet för?" Användare hoppar av innan de ens läser din text.
Och även om bilder till slut dyker upp, räknas timing. I prestandakontext är det avgörande, vilket element som tar längst tid att bli synligt. I praktiken är det ofta en bild: Enligt Web Almanac bestämmer en bild i cirka 68% av fallen vilket element som Largest Contentful Paint. HTTP Archive Web Almanac 2024 När denna bild hänger, hänger den uppfattade 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 ett nummer som vi inte använder som hot, utan som påminnelse: Ditt innehåll är bara så effektivt som dess leverans.
På Pola kommer det ytterligare en nivå. Bilder är den största datadelen på många webbplatser – och varje byte måste lagras, överföras, 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 smått: En huvudbild som istället för 1.2 MB är bara 180 KB stor, laddar inte bara snabbare. Det är också helt enkelt mer ansvarsfullt. "Mindre data, mer effekt" är inte bara en slogan, utan ett designbeslut vid bilder.
Core Web Vitals har i åratal varit en del av Page-Experience-signaler. Sedan 2025 har kraven i många team ökat märkbart: Prestanda är inte längre "Nice", utan hygien. Den som åtgärdar bildproblem förbättrar oftast samtidigt LCP, minskar avhopp och gör innehåll pålitligt igen.
Det är det fina: Här ligger ofta de snabbaste, renaste förbättringarna – eftersom bilder har så mycket potential.


I praktiken är det ofta samma snubbelstenar – bara i olika kostymer. Vi går igenom dem här medvetet så som de möter oss i vardagen.
Den vanligaste orsaken är banal: Bilden finns inte där URL pekar. Efter en omstart, efter att mediemappar har flyttats eller efter en migration (till exempel från en staging- till en live-miljö) finns gamla sökvägar kvar.
Var även uppmärksam på filnamn: Specialtecken, diakritiska tecken, mellanslag eller ett "final-final-2.png" kan i kombination med kodning och CMS-logik sluta på tok. Och mycket viktigt: På många Linux-servrar är /bilder/foto.jpg något annat än /bilder/foto.jpg.
Om en 403 returneras, är det ofta ett rättighetsproblem eller en skyddsregel. Särskilt i WordPress ser vi detta efter värdbyten: Mappen uploads har fel behörigheter eller ett säkerhetsplugin blockerar vissa filtyper.
Om bara en bild inte laddas, kan den helt enkelt vara skadad (uppladdningen avbröts, filen är korrumperad). Då hjälper oftast: exportera om, ladda upp på nytt, diskutera inte länge.
En cache kan rädda en sida – och den kan driva dig till vansinne. När bilder byts men förblir under samma URL, levererar ibland webbläsare eller CDN fortfarande den gamla versionen. Vår rutin: en gång hård-inläsning, sedan cache-rensning i CDN/plugin, sedan fortsätter vi.
Många bildproblem i WordPress är indirekta. Ett optimeringsplugin konverterar bilder till WebP, men omskrivsregeln är fel. Eller ett lazy-loading-plugin sätter attribut så att webbläsaren laddar bilderna först när de är i vy – men ett overlay förhindrar att skrolla och därmed triggas laddningen.
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 verktyget i sig, utan att du sedan testar: i incognito-läge, på mobilen och en gång i Safari.
När vi åtgärdar bildproblem ändrar vi aldrig fem saker samtidigt. Vi tar en hypotes åt gången (t.ex. "Blandat innehåll"), genomför fixen, kontrollerar resultatet i Network-tabben – och sedan kommer nästa variabel.
Det låter långsamt, men är det motsatta: Du behåller kontrollen. Och du kan dokumentera fixen senare, istället för att börja från noll nästa gång.
Om grunderna stämmer (sökväg korrekt, status 200, trots allt ingen bild) är det oftast dessa "osynliga" fall som tar tid. Vi samlar dem här eftersom de ofta bara dyker upp vid sidan i klassiska how-tos.
Du har aktiverat SSL, sidan kör på https – men några bilder är fortfarande länkade hårt till http. Då blockerar webbläsaren det. Du känner igen det tillförlitligt i konsolen.
I WordPress hjälper ofta en sök-och-ersätt i databasen (med försiktighet och helst med backup). Många team använder för detta Better Search Replace. Viktigt är: sedan kontrollera om verkligen alla tillgångar levereras över https.
Om du laddar bilder över en annan domän kan det vid vissa applikationer (Canvas, vissa skriptåtkomst) finnas CORS-problem. För "vanlig visning" är CORS sällan orsaken, men i webb-appar ser vi det då och då. Lösningen är då: Rätta header eller flytta bilder till en passande tillgångsdomän.
Ibland är bilder "där" men tillåts endast att bäddas in från ens egen domän. En affärsägare kopierar sedan 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 källans avsikt. Den rätta lösningen är alltid: hosta bilden själv eller komma överens om frigörande.
CDN är fantastiska – tills en edge-node cachar fel variant. Då ser vissa användare bilder, andra inte. Om du har ett "bara hos vissa"-problem är det en stark indikation.
Här hjälper ofta en riktad purge (bara de berörda URL:erna) och sedan en test från olika regioner, till exempel med WebPageTest eller en multi-region-koll.
WebP stöds idag brett, AVIF är starkt på frammarsch. Enligt Web Almanac har AVIF fyrdubblats mellan 2022 och 2024, medan JPEG-andelar minskar. HTTP Archive Web Almanac 2024
I allafall: Om du spelar ut nästa generations format, behöver du rena fallbacks över – annars blir "optimerad" snabbt "osynlig" när en rand-webbläsare eller en speciell in-app-webbläsare kommer in i spelet.
Dessa specialfall är precis anledningen till varför vi alltid ser debugging som en liten berättelse: Vem kallar på vem, vad kommer tillbaka och vem blockerar det? Så snart du ser bilden som en förfrågningskedja, blir den åter lösbar.


Kritisk sida påverkad och ingen tid för försök och misstag?
Om vi vill förhindra bildproblem permanent räcker det inte att lappa enstaka trasiga länkar. Då behöver vi en bildpipeline som är lika självklar som en varumärkesguide: klara regler, enkla rutiner, få överraskningar.
Vi rekommenderar team en pragmatisk version som fungerar utan stor verktygslandskap:
1) Skala och komprimera innan uppladdning. Ett foto från kameran är nästan aldrig web-redo. 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 390px bred mobil ett 2400px bild, verkar det "skarpt" men är mest slöseri. Karakteristisk för webben enligt Almanac är att bilder i median på mobilsidor levereras cirka 25 % större än nödvändigt. HTTP Archive Web Almanac 2024 srcset och lämpliga storlekssteg löser detta.
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. (Beroende på setup kan även fetchpriority="high" hjälpa.)
4) Konfigurera caching så att uppdateringar inte fastnar. Långa cache-tider är bra så länge du använder versionering (filnamn eller hash). Då förblir sidan snabb och du förlorar inte kontrollen.
En punkt vi sällan läser i andra guider, men ser ständigt i designprojekt: Ju fler bilder som "bara är dekoration", desto bräckligare blir sidan. Minimalistisk design är inte bara ett estetiskt val, det är ofta också det robustare tekniska beslutet.
Vi frågar därför medvetet: "Vilken bild bär verkligen betydelse?" Om en bild bara fyller plats, ökar risken (fler förfrågningar, fler beroenden) utan tydlig effekt. Om en bild bär betydelse, behandlar vi den som en kärninnehåll: optimerad, prioriterad, med fallback.
Så blir prevention inte en extra uppgift, utan ett sätt att bygga webbplatser: lätt, tydlig, varaktig.


När bilder inte laddas är det för vissa användare "bara" irriterande. För andra är det ett riktigt hinder. Och det är där det blir spännande: Tillgänglighet är inte bara en juridisk fråga eller en checklista, utan ett stresstest för ditt innehåll.
En myt står fast: "Om bilden saknas, ser man ju alt-texten." I verkligheten händer det inkonsekvent – ofta visar webbläsaren bara en liten ikon, och alt-texten är framför allt värdefull för skärmläsare. Det betyder: Alt-texter ersätter inte bilder, men de räddar information.
Vi skriver alt-texter så att de bär bildens syfte, inte beskriver pixlarna. En produktbild behöver något annat än en stämningsbild. Och ett diagram behöver en textbaserad sammanfattning, annars är informationen borta.
Tillgänglighet är också layout: När bilder laddar sent eller faller bort, uppstår ofta hopp. Det är inte bara irriterande, utan kan belasta personer med kognitiva begränsningar eller koncentrationsproblem starkare. Ett enkelt, ofta underskattat steg: ange width och height (eller definiera fasta förhållanden med CSS), så att platsen är reserverad och sidan förblir stilla.
Vi bedömer gärna webbplatser efter hur de beter sig när saker går fel: långsamt nät, blockerade bilder, extern tjänst nere. Om då allt kollapsar var upplevelsen bräcklig.
Men om du däremot håller alt-texter rena, döljer inga viktiga detaljer endast 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 når fram.
Det passar vårt krav "Tillgång för alla": Inte för att vi lovar perfektion, utan för att vi tar ansvar på allvar.
Vid bildproblem ser vi två typiska reaktioner: Antingen "analyseras allt sönder och samman" – eller så antas snabba lösningar som skapar långsiktiga nya problem. Några missuppfattningar dyker ständigt upp.
Ett CDN kan minska fördröjningen, men gör inte plötsligt en 5 MB bild liten. Om du inte använder ett bild-CDN med automatisk transformation förblir filstorleken densamma. Effekten är då begränsad – och ibland uppstår till och med extra komplexitet genom cache-ogiltigförklaring.
Om du verkligen vill leverera automatiskt, ta en titt på tjänster som Cloudinary som spelar ut format och storlekar dynamiskt. Det är inte nödvändigt för varje sida, men vid stora bildmängder kan det spara mycket underhåll.
Vi älskar starka bilder. Men vi ser också att användare hellre ger upp än väntar på perfektion. Om laddningstiden ökar från 1 till 10 sekunder kan avhoppsfrekvensen växa drastiskt. Site Builder Report Vår erfarenhet är: En kvalitet som "visuellt ren" slår en kvalitet som "tekniskt maximal".
Prestanda är ett tillstånd som förändras dagligen eftersom innehållet förändras. Idag laddar en redaktör upp en 6 MB-bild, imorgon kommer ett nytt plugin, dagen efter aktiveras ett CDN. Därför är prevention viktigare än hjältedåd.
Alt-texter är viktiga – men de är ingen ursäkt för trasiga bilder. De är säkerhetsbältet, inte motorn.
Vi tycker inte om dessa myter eftersom de är "fel", utan för att de leder dig i fel riktning: bort från klar diagnos, bort från en ren bildstrategi. När du en gång har förstått sammanhangen blir ämnet mycket lugnare – och du gör beslut som kombinerar design, teknik och effekt.
Vill du spela ut bilder stabilt, snabbt och tillgängligt?
Skicka oss ett meddelande eller boka direkt ett obligationsfritt första möte – vi ser fram emot att träffa dig och ditt projekt.
Våra planer
Copyright © 2026 Pola
Läs mer
Direkt till
TM