Waarom één afbeelding mislukt terwijl de rest van de pagina laadt
Drie voorwaarden onderscheiden een netwerkfout van een geblokkeerd verzoek en van een weergavefout. Zoek de URL die de browser koos voordat u het pad wijzigt.
De pagina laadt, de tekst wordt weergegeven en één afbeelding blijft een gebroken pictogram. De eerste reactie is de tunnel de schuld geven, want de tunnel is wat er veranderd is. Zoek eerst uit welke URL de browser voor die afbeelding werkelijk heeft opgevraagd, want de URL van de pagina en de URL van de afbeelding zijn twee verschillende bewijzen. De meeste meldingen over een ontbrekende afbeelding komen uit bij een host die nooit een werkend verzoek heeft gekregen, en dat antwoord kost één blik op het paneel Netwerk.
Drie voorwaarden bepalen waar u moet kijken
De eerste voorwaarde is of de afbeelding van dezelfde host komt als de pagina. Een aparte afbeeldingshost heeft eigen naamresolutie, een eigen verbinding en een eigen TLS-identiteit nodig, dus een pagina die laadt zegt niets over hem.
De tweede is of de browser het verzoek heeft geblokkeerd voordat het werd verzonden. Gemengde inhoud, content-security-policy en referrer-regels kunnen een afbeelding stoppen zonder een gewoon serverantwoord te produceren, daarom verschijnt er geen mislukt verzoek in de lijst.
De derde is of de levering slaagde en het weergeven mislukte, een geval waarin de bytes aankomen en de afbeelding toch niet verschijnt. Die drie voorwaarden hebben drie verschillende eigenaren, en alleen de eerste is een netwerkvraag.
| 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 |
Vind de bron die de browser werkelijk koos
De URL die u in de paginabron ziet is vaak niet de URL die is opgevraagd. Source sets, picture-elementen en CSS-achtergronden laten de browser een andere bron kiezen op basis van viewportbreedte, pixeldichtheid of formaatondersteuning. Een lazy geladen afbeelding wordt misschien helemaal niet opgevraagd tot de pagina een bepaalde toestand bereikt.
Inspecteer het element en het verzoek samen, en houd de initiator bij het verzoek wanneer u het probleem meldt. MDN's referentie voor het afbeeldingselement behandelt bronkeuze, laadgedrag en referrer-besturing op één plek, wat genoeg is om te bepalen welk attribuut de mislukkende URL koos.
Noteer de hostnaam, de status, een eventuele omleidingsketen en het inhoudstype van het antwoord. Een 200 die een inlogpagina teruggeeft is geen bruikbare afbeelding, en een omleiding naar een HTML-foutpagina ziet er hetzelfde uit als een beschadigd bestand tot u het type leest.
Lees de status vóór het netwerk
Een time-out, een geweigerd verzoek en een decoderingsfout vragen verschillende vervolgstappen, en de statuscode is wat ze scheidt. Een time-out wijst op naamresolutie, route of een host die niet antwoordt. Een geweigerd verzoek wijst op een beleid of een autorisatielaag. Een decoderingsfout wijst op de bytes of het formaat.
Als het verzoek helemaal niet verschijnt, stop dan met naar het netwerk te kijken en kijk naar de markup. De meest voorkomende oorzaak is een vermelding in een source set die de browser verkoos en die niet meer op de server staat, gevolgd door een element dat een script nooit zichtbaar heeft gemaakt.
Alleen dat onderscheid voorkomt het grootste deel van het verspilde werk in dit soort meldingen.
Als de browser blokkeert, is er geen antwoord om te lezen
Gemengde inhoud is het klassieke geval: een HTTPS-pagina die een afbeelding via gewone HTTP opvraagt, krijgt het verzoek geblokkeerd in plaats van mislukt, en de console legt de reden vast. Content-security-policy levert dezelfde vorm, met de geblokkeerde richtlijn in de melding genoemd. Een referrer-beleid dat de header verwijdert kan ook zorgen dat een tegen hotlinken beschermde host een plaatsaanduiding teruggeeft in plaats van de afbeelding.
Lees de vastgelegde reden voordat u het netwerkpad aanraakt, want deze blokkades worden niet beter als de route verandert. Cross-origin-machtigingen toevoegen is ook niet de oplossing: een afbeelding van een andere host tonen en de pixels ervan in een canvas lezen zijn verschillende bewerkingen, en alleen de tweede heeft de headers nodig die mensen plakken.
Voor een site die u beheert, corrigeer de bron-URL, het antwoord of het beleid bij de eigenaar en houd de autorisatie- en referrer-eisen intact. Voor een site die u niet beheert, stuur de pagina en de bewijzen van het verzoek naar het supportkanaal in plaats van privé- of verlopende bronlinks opnieuw te publiceren.
Vergelijk paden zonder de bewijzen te wijzigen
Als u het toegangspad echt wilt testen, houd dan al het andere constant: dezelfde pagina, hetzelfde account, dezelfde gekozen afbeelding, één toegestaan pad gewijzigd. Vergelijk de verzoekregels naast elkaar in plaats van het weergegeven resultaat, want het weergegeven resultaat zegt of de afbeelding verscheen, niet waarom.
Een afbeelding die op een nieuwe route laadt bewijst niet dat die route geautoriseerd is, en een afbeelding die kapot blijft bewijst niet dat de tunnel schuld heeft. Als de afbeelding is verwijderd of de toegang opzettelijk beperkt is, gebruik een ondersteund alternatief in plaats van certificaatcontroles uit te schakelen of andermans beschermd materiaal te spiegelen.
Werkvolgorde: identificeer de gekozen URL, lees de status en het type, controleer op een vastgelegde blokkeerreden en vergelijk dan één padwijziging per keer.