Perché un’immagine fallisce mentre il resto della pagina si carica
Tre condizioni separano un guasto di rete da una richiesta bloccata e da un errore di rendering. Trovate l’URL scelto dal browser prima di cambiare il percorso.
La pagina si carica, il testo viene renderizzato e un’immagine resta un’icona rotta. Il primo riflesso è dare la colpa al tunnel, perché il tunnel è ciò che è cambiato. Prima di farlo, scoprite quale URL il browser ha realmente richiesto per quell’immagine, perché l’URL della pagina e quello dell’immagine sono due prove diverse. La maggior parte delle segnalazioni di immagine mancante si risolve in un host che non ha mai ricevuto una richiesta funzionante, e quella risposta costa uno sguardo al pannello Rete.
Tre condizioni decidono dove guardare
La prima condizione è se l’immagine proviene dallo stesso host della pagina. Un host di immagini separato ha bisogno della propria risoluzione dei nomi, della propria connessione e della propria identità TLS, quindi una pagina che si carica non dice nulla su di lui.
La seconda è se il browser ha bloccato la richiesta prima di inviarla. Contenuti misti, politica di sicurezza dei contenuti e regole del referrer possono fermare un’immagine senza produrre una normale risposta del server, per questo nell’elenco non compare alcuna richiesta fallita.
La terza è se la consegna è riuscita e il rendering è fallito, un caso in cui i byte arrivano e l’immagine continua a non comparire. Queste tre condizioni hanno tre proprietari diversi, e solo la prima è una questione di rete.
| 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 |
Trovate la risorsa che il browser ha realmente scelto
L’URL che vedete nel codice sorgente della pagina spesso non è quello richiesto. I set di sorgenti, gli elementi picture e gli sfondi CSS permettono al browser di scegliere una risorsa diversa in base alla larghezza della finestra, alla densità di pixel o al supporto del formato. Un’immagine a caricamento differito può non essere richiesta affatto finché la pagina non raggiunge un certo stato.
Ispezionate insieme l’elemento e la richiesta, e conservate l’iniziatore con la richiesta quando segnalate il problema. La referenza dell’elemento immagine di MDN copre selezione della sorgente, comportamento di caricamento e controlli del referrer in un solo posto, il che basta a capire quale attributo ha scelto l’URL che fallisce.
Annotate il nome host, lo stato, qualsiasi catena di reindirizzamenti e il tipo di contenuto della risposta. Una risposta 200 che restituisce una pagina di accesso non è un’immagine utilizzabile, e un reindirizzamento a una pagina di errore HTML sembra identico a un file danneggiato finché non leggete il tipo.
Leggete lo stato prima della rete
Un timeout, una richiesta negata e un errore di decodifica richiedono passi successivi diversi, e il codice di stato è ciò che li separa. Un timeout punta alla risoluzione dei nomi, alla rotta o a un host che non risponde. Una richiesta negata punta a una politica o a uno strato di autorizzazione. Un errore di decodifica punta ai byte o al formato.
Se la richiesta non compare affatto, smettete di guardare la rete e guardate il markup. La causa più comune è una voce in un set di sorgenti che il browser ha preferito e che non esiste più sul server, seguita da un elemento che nessuno script ha reso visibile.
Solo questa distinzione evita la maggior parte dello sforzo sprecato in questo tipo di segnalazioni.
Quando il browser la blocca, non c’è risposta da leggere
I contenuti misti sono il caso classico: una pagina HTTPS che chiede un’immagine su HTTP semplice vede la richiesta bloccata invece che fallita, e la console registra il motivo. La politica di sicurezza dei contenuti produce la stessa forma, con la direttiva bloccata indicata nel messaggio. Una politica del referrer che rimuove l’intestazione può anche far restituire a un host protetto contro l’hotlink un segnaposto al posto dell’immagine.
Leggete il motivo registrato prima di toccare il percorso di rete, perché questi blocchi non migliorano quando cambia la rotta. Aggiungere autorizzazioni cross-origin non è la soluzione: mostrare un’immagine di un altro host e leggerne i pixel in un canvas sono operazioni diverse, e solo la seconda richiede le intestazioni che le persone incollano.
Per un sito che amministrate, correggete l’URL della risorsa, la risposta o la politica presso il suo proprietario e mantenete intatti i requisiti di autorizzazione e del referrer. Per un sito che non controllate, inviate la pagina e le prove della richiesta al suo canale di supporto invece di ripubblicare collegamenti a risorse private o in scadenza.
Confrontate percorsi senza cambiare le prove
Se volete davvero provare il percorso di accesso, tenete tutto il resto costante: stessa pagina, stesso account, stessa immagine selezionata, un percorso consentito modificato. Confrontate le voci di richiesta affiancate invece del risultato renderizzato, perché il risultato renderizzato dice se l’immagine è comparsa, non perché.
Un’immagine che si carica su una nuova rotta non dimostra che quella rotta sia autorizzata, e un’immagine che resta rotta non dimostra che il tunnel sia la causa. Se l’immagine è stata rimossa o l’accesso è limitato di proposito, usate un’alternativa supportata invece di disattivare i controlli sui certificati o copiare materiale protetto altrui.
Ordine di lavoro: identificate l’URL selezionato, leggete stato e tipo, verificate se esiste un motivo di blocco registrato, poi confrontate un cambiamento di percorso alla volta.