Pourquoi une image échoue alors que le reste de la page se charge
Trois conditions séparent une panne réseau d’une requête bloquée et d’une erreur de rendu. Trouvez l’URL que le navigateur a choisie avant de changer le chemin.
La page se charge, le texte s’affiche et une image reste une icône cassée. Le premier réflexe est d’accuser le tunnel, car le tunnel est ce qui a changé. Avant cela, déterminez l’URL que le navigateur a réellement demandée pour cette image, car l’URL de la page et celle de l’image sont deux preuves différentes. La plupart des signalements d’image manquante aboutissent à un hôte qui n’a jamais reçu de requête fonctionnelle, et cette réponse coûte un coup d’œil au panneau Réseau.
Trois conditions décident où chercher
La première condition est de savoir si l’image vient du même hôte que la page. Un hôte d’images séparé a besoin de sa propre résolution de noms, de sa propre connexion et de sa propre identité TLS, donc une page qui se charge ne dit rien de lui.
La deuxième est de savoir si le navigateur a bloqué la requête avant de l’envoyer. Le contenu mixte, la politique de sécurité du contenu et les règles de référent peuvent arrêter une image sans produire de réponse serveur ordinaire, c’est pourquoi aucune requête échouée n’apparaît dans la liste.
La troisième est de savoir si la livraison a réussi et le rendu échoué, un cas où les octets arrivent et où l’image ne s’affiche toujours pas. Ces trois conditions ont trois propriétaires différents, et seule la première est une question de réseau.
| 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 |
Trouvez la ressource que le navigateur a réellement choisie
L’URL que vous voyez dans le code source de la page n’est souvent pas celle qui a été demandée. Les jeux de sources, les éléments picture et les arrière-plans CSS permettent au navigateur de choisir une autre ressource selon la largeur de la fenêtre, la densité de pixels ou la prise en charge du format. Une image à chargement différé peut ne pas être demandée du tout tant que la page n’atteint pas un état donné.
Inspectez l’élément et la requête ensemble, et conservez l’initiateur avec la requête lorsque vous signalez le problème. La référence de l’élément image de MDN couvre la sélection de source, le comportement de chargement et les contrôles de référent en un seul endroit, ce qui suffit à savoir quel attribut a choisi l’URL défaillante.
Notez le nom d’hôte, le statut, toute chaîne de redirection et le type de contenu de la réponse. Une réponse 200 qui renvoie une page de connexion n’est pas une image utilisable, et une redirection vers une page d’erreur HTML ressemble à un fichier corrompu jusqu’à ce que vous lisiez le type.
Lisez le statut avant le réseau
Un délai expiré, une requête refusée et une erreur de décodage demandent des étapes suivantes différentes, et le code de statut est ce qui les sépare. Un délai expiré pointe vers la résolution de noms, la route ou un hôte qui ne répond pas. Une requête refusée pointe vers une politique ou une couche d’autorisation. Une erreur de décodage pointe vers les octets ou le format.
Si la requête n’apparaît pas du tout, cessez de regarder le réseau et regardez le balisage. La cause la plus fréquente est une entrée d’un jeu de sources que le navigateur a préférée et qui n’existe plus sur le serveur, suivie d’un élément qu’un script n’a jamais rendu visible.
Cette seule distinction évite la majeure partie du travail inutile dans ce type de signalement.
Quand le navigateur le bloque, il n’y a pas de réponse à lire
Le contenu mixte est le cas classique : une page HTTPS qui demande une image en HTTP simple voit la requête bloquée plutôt qu’échouée, et la console enregistre la raison. La politique de sécurité du contenu produit la même forme, avec la directive bloquée nommée dans le message. Une politique de référent qui supprime l’en-tête peut aussi amener un hôte protégé contre le hotlink à renvoyer un espace réservé au lieu de l’image.
Lisez la raison enregistrée avant de toucher au chemin réseau, car ces blocages ne s’améliorent pas quand la route change. Ajouter des autorisations cross-origin n’est pas non plus la solution : afficher une image d’un autre hôte et lire ses pixels dans un canvas sont des opérations différentes, et seule la seconde a besoin des en-têtes que les gens collent.
Pour un site que vous administrez, corrigez l’URL de la ressource, la réponse ou la politique chez son propriétaire et gardez intactes les exigences d’autorisation et de référent. Pour un site que vous ne contrôlez pas, envoyez la page et les preuves de la requête à son canal de support au lieu de republier des liens de ressources privés ou expirants.
Comparez des chemins sans changer les preuves
Si vous voulez vraiment tester le chemin d’accès, gardez tout le reste constant : même page, même compte, même image sélectionnée, un chemin autorisé modifié. Comparez les entrées de requête côte à côte plutôt que le résultat rendu, car le résultat rendu vous dit si l’image est apparue, pas pourquoi.
Une image qui se charge sur une nouvelle route ne prouve pas que cette route est autorisée, et une image qui reste cassée ne prouve pas que le tunnel est en cause. Si l’image a été supprimée ou si l’accès est volontairement restreint, utilisez une alternative prise en charge au lieu de désactiver les vérifications de certificat ou de copier le contenu protégé de quelqu’un d’autre.
Ordre du travail : identifiez l’URL sélectionnée, lisez son statut et son type, vérifiez la présence d’une raison de blocage enregistrée, puis comparez un changement de chemin à la fois.