Por que uma imagem falha enquanto o resto da página carrega
Três condições separam uma falha de rede de um pedido bloqueado e de um erro de composição. Encontre o URL que o navegador escolheu antes de mudar o caminho.
A página carrega, o texto é renderizado e uma imagem fica como um ícone quebrado. A primeira reação é culpar o túnel, porque o túnel é o que mudou. Antes disso, descubra qual URL o navegador realmente pediu para essa imagem, porque o URL da página e o URL da imagem são duas provas diferentes. A maioria dos relatos de imagem ausente termina num host que nunca recebeu um pedido funcional, e essa resposta custa uma olhada no painel Rede.
Três condições decidem onde procurar
A primeira condição é se a imagem vem do mesmo host que a página. Um host de imagens separado precisa da sua própria resolução de nomes, da sua própria ligação e da sua própria identidade TLS, por isso uma página que carrega nada diz sobre ele.
A segunda é se o navegador bloqueou o pedido antes de o enviar. Conteúdo misto, política de segurança de conteúdo e regras de referenciador podem parar uma imagem sem produzir uma resposta normal do servidor, e é por isso que não aparece nenhum pedido falhado na lista.
A terceira é se a entrega teve êxito e a composição falhou, um caso em que os bytes chegam e a imagem continua a não aparecer. Essas três condições têm três donos diferentes, e só a primeira é uma questão de rede.
| 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 |
Encontre o recurso que o navegador realmente escolheu
O URL que vê no código-fonte da página muitas vezes não é o URL que foi pedido. Os conjuntos de origens, os elementos picture e os fundos CSS permitem ao navegador escolher outro recurso com base na largura da janela, na densidade de píxeis ou no suporte ao formato. Uma imagem de carregamento diferido pode não ser pedida de todo até a página atingir um determinado estado.
Inspecione o elemento e o pedido em conjunto, e guarde o iniciador com o pedido quando reportar o problema. A referência do elemento de imagem da MDN cobre a seleção da origem, o comportamento de carregamento e os controlos de referenciador num só lugar, o que basta para saber que atributo escolheu o URL que falha.
Registe o nome do host, o estado, qualquer cadeia de redirecionamento e o tipo de conteúdo da resposta. Uma resposta 200 que devolve uma página de início de sessão não é uma imagem utilizável, e um redirecionamento para uma página de erro HTML parece idêntico a um ficheiro danificado até ler o tipo.
Leia o estado antes da rede
Um tempo limite, um pedido recusado e um erro de descodificação exigem passos seguintes diferentes, e o código de estado é o que os separa. Um tempo limite aponta para a resolução de nomes, a rota ou um host que não responde. Um pedido recusado aponta para uma política ou uma camada de autorização. Um erro de descodificação aponta para os bytes ou o formato.
Se o pedido não aparecer de todo, pare de olhar para a rede e olhe para a marcação. A causa mais comum é uma entrada de um conjunto de origens que o navegador preferiu e que já não existe no servidor, seguida de um elemento que nenhum script tornou visível.
Só essa distinção evita a maior parte do esforço desperdiçado neste tipo de relato.
Quando o navegador bloqueia, não há resposta para ler
O conteúdo misto é o caso clássico: uma página HTTPS que pede uma imagem por HTTP simples recebe o pedido bloqueado em vez de falhado, e a consola registra o motivo. A política de segurança de conteúdo produz a mesma forma, com a diretiva bloqueada indicada na mensagem. Uma política de referenciador que remove o cabeçalho também pode fazer com que um host protegido contra hotlink devolva um marcador de posição em vez da imagem.
Leia o motivo registado antes de tocar no caminho de rede, porque estes bloqueios não melhoram quando a rota muda. Acrescentar permissões de origem cruzada também não é a solução: mostrar uma imagem de outro host e ler os seus píxeis num canvas são operações diferentes, e só a segunda precisa dos cabeçalhos que as pessoas colam.
Num site que administra, corrija o URL do recurso, a resposta ou a política no seu proprietário e mantenha intactos os requisitos de autorização e de referenciador. Num site que não controla, envie a página e as provas do pedido para o canal de suporte em vez de republicar ligações a recursos privados ou expirados.
Compare caminhos sem mudar as provas
Se quer mesmo testar o caminho de acesso, mantenha tudo o resto constante: a mesma página, a mesma conta, a mesma imagem escolhida, um caminho permitido alterado. Compare as entradas de pedido lado a lado em vez do resultado renderizado, porque o resultado renderizado diz se a imagem apareceu, não porquê.
Uma imagem que carrega numa rota nova não prova que essa rota está autorizada, e uma imagem que continua quebrada não prova que o túnel tem culpa. Se a imagem foi removida ou o acesso está restringido de propósito, use uma alternativa suportada em vez de desativar as verificações de certificado ou copiar material protegido de outra pessoa.
Ordem de trabalho: identifique o URL selecionado, leia o estado e o tipo, verifique se existe um motivo de bloqueio registado e depois compare uma alteração de caminho de cada vez.