Varför en bild misslyckas medan resten av sidan laddas
Tre villkor skiljer ett nätverksfel från en blockerad begäran och ett renderingsfel. Hitta den URL som webbläsaren valde innan du ändrar sökvägen.
Sidan laddas, texten renderas och en bild blir en trasig ikon. Den första reaktionen är att skylla på tunneln, eftersom tunneln är det som ändrades. Innan det, ta reda på vilken URL webbläsaren faktiskt begärde för den bilden, eftersom sidans URL och bildens URL är två olika bevis. De flesta rapporter om en saknad bild hamnar hos en värd som aldrig fick en fungerande begäran, och det svaret kostar en blick på panelen Nätverk.
Tre villkor avgör var du ska leta
Det första villkoret är om bilden kommer från samma värd som sidan. En separat bildvärd behöver sin egen namnmatchning, sin egen anslutning och sin egen TLS-identitet, så en sida som laddas säger ingenting om den.
Det andra är om webbläsaren blockerade begäran innan den skickades. Blandat innehåll, innehållssäkerhetspolicy och referrer-regler kan stoppa en bild utan att producera ett vanligt serversvar, därför visas ingen misslyckad begäran i listan.
Det tredje är om leveransen lyckades och renderingen misslyckades, ett fall där byten anländer och bilden ändå inte visas. Dessa tre villkor har tre olika ägare, och bara det första är en nätverksfråga.
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
Hitta den resurs som webbläsaren faktiskt valde
URL:en du ser i sidans källkod är ofta inte den URL som begärdes. Källuppsättningar, picture-element och CSS-bakgrunder låter webbläsaren välja en annan resurs baserat på visningsbredd, pixeltäthet eller formatstöd. En lat inläst bild kanske inte begärs alls förrän sidan når ett visst tillstånd.
Undersök elementet och begäran tillsammans, och behåll initiativtagaren med begäran när du rapporterar problemet. MDN:s referens för bildelementet täcker källval, laddningsbeteende och referrer-kontroller på ett ställe, vilket räcker för att avgöra vilket attribut som valde den felande URL:en.
Anteckna värdnamnet, statusen, en eventuell omdirigeringskedja och svarets innehållstyp. Ett 200 som returnerar en inloggningssida är inte en användbar bild, och en omdirigering till en HTML-felsida ser identisk ut med en trasig fil tills du läser typen.
Läs statusen före nätverket
Tidsgräns, en nekad begäran och ett avkodningsfel kräver olika nästa steg, och statuskoden är det som skiljer dem. En tidsgräns pekar på namnmatchning, rutt eller en värd som inte svarar. En nekad begäran pekar på en policy eller ett auktoriseringslager. Ett avkodningsfel pekar på byten eller formatet.
Om begäran inte visas alls, sluta titta på nätverket och titta på markeringen. Den vanligaste orsaken är en post i en källuppsättning som webbläsaren föredrog och som inte längre finns på servern, följt av ett element som ett skript aldrig gjorde synligt.
Bara den åtskillnaden förhindrar större delen av det bortkastade arbetet i den här typen av rapporter.
När webbläsaren blockerar den finns inget svar att läsa
Blandat innehåll är det klassiska fallet: en HTTPS-sida som begär en bild över vanlig HTTP får begäran blockerad i stället för misslyckad, och konsolen registrerar orsaken. Innehållssäkerhetspolicy ger samma form, med det blockerade direktivet namngivet i meddelandet. En referrer-policy som tar bort headern kan också få en hotlink-skyddad värd att returnera en platshållare i stället för bilden.
Läs den registrerade orsaken innan du rör nätverksvägen, eftersom dessa blockeringar inte blir bättre när rutten ändras. Att lägga till cross-origin-behörigheter är inte heller lösningen: att visa en bild från en annan värd och att läsa dess pixlar i en canvas är olika operationer, och bara den andra behöver de headers som folk klistrar in.
För en webbplats du administrerar, rätta resurs-URL:en, svaret eller policyn hos ägaren och håll auktoriserings- och referrer-kraven intakta. För en webbplats du inte kontrollerar, skicka sidan och bevisen för begäran till dess supportkanal i stället för att publicera privata eller utgående resurslänkar igen.
Jämför sökvägar utan att ändra bevisen
Om du verkligen vill testa åtkomstvägen, håll allt annat konstant: samma sida, samma konto, samma valda bild, en tillåten sökväg ändrad. Jämför begärandeposterna sida vid sida i stället för det renderade resultatet, eftersom det renderade resultatet säger om bilden dök upp, inte varför.
En bild som laddas på en ny rutt bevisar inte att rutten är auktoriserad, och en bild som förblir trasig bevisar inte att tunneln är skyldig. Om bilden har tagits bort eller åtkomsten är avsiktligt begränsad, använd ett stött alternativ i stället för att stänga av certifikatkontroller eller spegla någon annans skyddade material.
Arbetsordning: identifiera den valda URL:en, läs dess status och typ, kontrollera om det finns en registrerad blockeringsorsak och jämför sedan en sökvägsändring i taget.