Warum ein Bild fehlschlägt, während der Rest der Seite lädt
Drei Bedingungen trennen einen Netzwerkfehler von einer blockierten Anfrage und einem Renderingfehler. Finden Sie die URL, die der Browser gewählt hat, bevor Sie den Pfad ändern.
Die Seite lädt, der Text wird gerendert, und ein Bild bleibt ein kaputtes Symbol. Der erste Reflex ist, den Tunnel zu beschuldigen, denn der Tunnel ist das, was sich geändert hat. Finden Sie vorher heraus, welche URL der Browser für dieses Bild tatsächlich angefordert hat, denn die Seiten-URL und die Bild-URL sind zwei verschiedene Beweise. Die meisten Meldungen über fehlende Bilder führen zu einem Host, der nie eine funktionierende Anfrage erhalten hat, und diese Antwort kostet einen Blick in den Netzwerk-Bereich.
Drei Bedingungen entscheiden, wo Sie suchen müssen
Die erste Bedingung ist, ob das Bild vom selben Host wie die Seite kommt. Ein separater Bildhost braucht eine eigene Namensauflösung, eine eigene Verbindung und eine eigene TLS-Identität, eine Seite, die lädt, sagt also nichts über ihn aus.
Die zweite ist, ob der Browser die Anfrage blockiert hat, bevor sie gesendet wurde. Gemischte Inhalte, Content-Security-Policy und Referrer-Regeln können ein Bild stoppen, ohne eine gewöhnliche Serverantwort zu erzeugen, deshalb erscheint keine fehlgeschlagene Anfrage in der Liste.
Die dritte ist, ob die Auslieferung gelungen und das Rendern fehlgeschlagen ist, ein Fall, in dem die Bytes ankommen und das Bild trotzdem nicht erscheint. Diese drei Bedingungen haben drei verschiedene Eigentümer, und nur die erste ist eine Netzwerkfrage.
| 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 |
Finden Sie die Ressource, die der Browser tatsächlich gewählt hat
Die URL, die Sie im Seitenquelltext sehen, ist oft nicht die URL, die angefordert wurde. Source-Sets, picture-Elemente und CSS-Hintergründe lassen den Browser je nach Viewport-Breite, Pixeldichte oder Formatunterstützung eine andere Ressource wählen. Ein lazy geladenes Bild wird möglicherweise gar nicht angefordert, bis die Seite einen bestimmten Zustand erreicht.
Untersuchen Sie Element und Anfrage zusammen, und behalten Sie den Initiator bei der Anfrage, wenn Sie das Problem melden. MDNs Referenz zum Bildelement behandelt Quellenauswahl, Ladeverhalten und Referrer-Steuerung an einer Stelle, was ausreicht, um zu erkennen, welches Attribut die fehlerhafte URL gewählt hat.
Notieren Sie Hostname, Status, eine etwaige Weiterleitungskette und den Inhaltstyp der Antwort. Eine 200, die eine Anmeldeseite zurückgibt, ist kein brauchbares Bild, und eine Weiterleitung auf eine HTML-Fehlerseite sieht bis zum Lesen des Typs wie eine beschädigte Datei aus.
Lesen Sie den Status vor dem Netzwerk
Zeitüberschreitung, abgelehnte Anfrage und Dekodierungsfehler erfordern unterschiedliche nächste Schritte, und der Statuscode ist das, was sie trennt. Eine Zeitüberschreitung deutet auf Namensauflösung, Route oder einen Host hin, der nicht antwortet. Eine abgelehnte Anfrage deutet auf eine Richtlinie oder eine Autorisierungsschicht hin. Ein Dekodierungsfehler deutet auf die Bytes oder das Format hin.
Erscheint die Anfrage gar nicht, hören Sie auf, das Netzwerk zu betrachten, und sehen Sie sich das Markup an. Die häufigste Ursache ist ein Eintrag in einem Source-Set, den der Browser bevorzugt hat und der auf dem Server nicht mehr existiert, gefolgt von einem Element, das ein Skript nie sichtbar gemacht hat.
Allein diese Unterscheidung verhindert den größten Teil der vergeudeten Arbeit bei dieser Art von Meldung.
Wenn der Browser blockiert, gibt es keine Antwort zu lesen
Gemischte Inhalte sind der klassische Fall: Eine HTTPS-Seite, die ein Bild über einfaches HTTP anfordert, bekommt die Anfrage blockiert statt fehlgeschlagen, und die Konsole zeichnet den Grund auf. Content-Security-Policy erzeugt dieselbe Form, wobei die blockierte Direktive in der Meldung genannt wird. Eine Referrer-Richtlinie, die den Header entfernt, kann auch dazu führen, dass ein hotlink-geschützter Host einen Platzhalter statt des Bildes zurückgibt.
Lesen Sie den aufgezeichneten Grund, bevor Sie den Netzwerkpfad anfassen, denn diese Blockaden bessern sich nicht, wenn sich die Route ändert. Auch das Hinzufügen von Cross-Origin-Berechtigungen ist nicht die Lösung: ein Bild von einem anderen Host anzuzeigen und seine Pixel in einem Canvas zu lesen sind verschiedene Vorgänge, und nur der zweite braucht die Header, die Leute einfügen.
Bei einer Seite, die Sie administrieren, korrigieren Sie die Ressourcen-URL, die Antwort oder die Richtlinie beim Eigentümer und lassen Sie die Autorisierungs- und Referrer-Anforderungen unangetastet. Bei einer Seite, die Sie nicht kontrollieren, senden Sie die Seite und die Anfragebelege an deren Supportkanal, statt private oder ablaufende Ressourcenlinks erneut zu veröffentlichen.
Vergleichen Sie Pfade, ohne die Beweise zu ändern
Wenn Sie den Zugangspfad testen wollen, halten Sie alles andere konstant: gleiche Seite, gleiches Konto, gleiches ausgewähltes Bild, ein erlaubter Pfad geändert. Vergleichen Sie die Anfrageeinträge nebeneinander statt das gerenderte Ergebnis, denn das gerenderte Ergebnis sagt, ob das Bild erschien, nicht warum.
Ein Bild, das auf einer neuen Route lädt, beweist nicht, dass diese Route autorisiert ist, und ein Bild, das kaputt bleibt, beweist nicht, dass der Tunnel schuld ist. Wenn das Bild entfernt wurde oder der Zugriff absichtlich beschränkt ist, verwenden Sie eine unterstützte Alternative, statt Zertifikatsprüfungen abzuschalten oder fremdes geschütztes Material zu spiegeln.
Reihenfolge der Arbeit: die gewählte URL ermitteln, ihren Status und Typ lesen, auf einen aufgezeichneten Blockiergrund prüfen und dann jeweils eine Pfadänderung vergleichen.