Per què falla una imatge mentre la resta de la pàgina es carrega
Tres condicions separen una fallada de xarxa d’una sol·licitud bloquejada i d’una errada de representació. Trobeu l’URL que el navegador va triar abans de canviar el camí.
La pàgina es carrega, el text es representa i una imatge queda com una icona trencada. La reacció immediata és culpar el túnel, perquè el túnel és el que ha canviat. Abans d’això, esbrineu quina URL va demanar realment el navegador per a aquesta imatge, perquè l’URL de la pàgina i l’URL de la imatge són dues proves diferents. La majoria d’avisos d’imatge absent es resolen en un amfitrió que mai no va rebre una sol·licitud funcional, i aquesta resposta només costa una mirada al panell Xarxa.
Tres condicions decideixen on cal mirar
La primera condició és si la imatge prové del mateix amfitrió que la pàgina. Un amfitrió d’imatges separat necessita la seva pròpia resolució de noms, la seva pròpia connexió i la seva pròpia identitat TLS, així que una pàgina que es carrega no diu res sobre ell.
La segona és si el navegador va bloquejar la sol·licitud abans d’enviar-la. El contingut mixt, la política de seguretat de contingut i les regles de referent poden aturar una imatge sense produir una resposta normal del servidor, i per això no apareix cap sol·licitud fallida a la llista.
La tercera és si el lliurament va tenir èxit i la representació va fallar, un cas en què els bytes arriben i la imatge encara no apareix. Aquestes tres condicions tenen tres propietaris diferents, i només la primera és una qüestió de xarxa.
| 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 |
Trobeu el recurs que el navegador va triar realment
L’URL que veieu al codi font de la pàgina sovint no és l’URL que es va sol·licitar. Els conjunts d’orígens, els elements picture i els fons CSS permeten al navegador triar un recurs diferent segons l’amplada de la finestra, la densitat de píxels o el suport de format. Una imatge carregada de manera mandrosa pot no sol·licitar-se gens fins que la pàgina arriba a un estat determinat.
Inspeccioneu l’element i la sol·licitud junts, i conserveu l’iniciador amb la sol·licitud quan informeu del problema. La referència de l’element d’imatge de MDN cobreix la selecció d’origen, el comportament de càrrega i els controls de referent en un sol lloc, cosa suficient per saber quin atribut va triar l’URL que falla.
Anoteu el nom d’amfitrió, l’estat, qualsevol cadena de redirecció i el tipus de contingut de la resposta. Una resposta 200 que retorna una pàgina d’inici de sessió no és una imatge utilitzable, i una redirecció a una pàgina d’error HTML sembla idèntica a un fitxer trencat fins que llegiu el tipus.
Llegiu l’estat abans que la xarxa
Un temps d’espera esgotat, una sol·licitud denegada i una errada de descodificació necessiten passos diferents, i el codi d’estat és el que els separa. Un temps d’espera assenyala la resolució de noms, la ruta o un amfitrió que no respon. Una sol·licitud denegada assenyala una política o una capa d’autorització. Una errada de descodificació assenyala els bytes o el format.
Si la sol·licitud no apareix mai, deixeu de mirar la xarxa i mireu el marcatge. La causa més habitual és una entrada d’un conjunt d’orígens que el navegador va preferir i que ja no existeix al servidor, seguida d’un element que cap script no va fer visible.
Aquesta distinció per si sola evita la major part de l’esforç malgastat en aquest tipus d’avisos.
Quan el navegador ho bloqueja, no hi ha resposta per llegir
El contingut mixt és el cas clàssic: una pàgina HTTPS que demana una imatge per HTTP simple rep la sol·licitud bloquejada en lloc de fallida, i la consola registra el motiu. La política de seguretat de contingut produeix la mateixa forma, amb la directiva bloquejada indicada al missatge. Una política de referent que elimina la capçalera també pot fer que un amfitrió protegit contra hotlinking retorni un marcador de posició en lloc de la imatge.
Llegiu el motiu registrat abans de tocar el camí de xarxa, perquè aquests bloquejos no milloren quan canvia la ruta. Afegir permisos d’origen creuat tampoc no és la solució: mostrar una imatge d’un altre amfitrió i llegir-ne els píxels en un canvas són operacions diferents, i només la segona necessita les capçaleres que la gent enganxa.
Per a un lloc que administreu, corregiu l’URL del recurs, la resposta o la política al seu propietari i manteniu intactes els requisits d’autorització i de referent. Per a un lloc que no controleu, envieu la pàgina i les proves de la sol·licitud al seu canal de suport en lloc de republicar enllaços de recursos privats o que caduquen.
Compareu camins sense canviar les proves
Si voleu provar el camí d’accés, manteniu la resta constant: mateixa pàgina, mateix compte, mateixa imatge seleccionada, un camí permès canviat. Compareu les entrades de sol·licitud costat per costat en lloc del resultat representat, perquè el resultat representat diu si la imatge va aparèixer, no per què.
Una imatge que es carrega en una ruta nova no demostra que aquesta ruta estigui autoritzada, i una imatge que continua trencada no demostra que el túnel sigui el culpable. Si la imatge s’ha eliminat o l’accés està restringit intencionadament, feu servir una alternativa compatible en lloc de desactivar les comprovacions de certificat o copiar material protegit d’algú altre.
Ordre de treball: identifiqueu l’URL seleccionat, llegiu-ne l’estat i el tipus, comproveu si hi ha un motiu de bloqueig registrat i, després, compareu un canvi de camí alhora.