Por qué falla una imagen mientras el resto de la página carga
Tres condiciones separan un fallo de red de una solicitud bloqueada y de un error de representación. Encuentre la URL que eligió el navegador antes de cambiar la ruta.
La página carga, el texto se representa y una imagen queda como un icono roto. La reacción inmediata es culpar al túnel, porque el túnel es lo que cambió. Antes de eso, averigüe qué URL pidió realmente el navegador para esa imagen, porque la URL de la página y la URL de la imagen son dos pruebas distintas. La mayoría de los avisos de imagen ausente se resuelven en un host que nunca recibió una solicitud funcional, y esa respuesta cuesta un vistazo al panel Red.
Tres condiciones deciden dónde mirar
La primera condición es si la imagen proviene del mismo host que la página. Un host de imágenes separado necesita su propia resolución de nombres, su propia conexión y su propia identidad TLS, así que una página que carga no dice nada sobre él.
La segunda es si el navegador bloqueó la solicitud antes de enviarla. El contenido mixto, la política de seguridad de contenido y las reglas de referente pueden detener una imagen sin producir una respuesta normal del servidor, por eso no aparece ninguna solicitud fallida en la lista.
La tercera es si la entrega se completó y la representación falló, un caso en el que los bytes llegan y la imagen sigue sin aparecer. Esas tres condiciones tienen tres dueños distintos, y solo la primera es una cuestión de red.
| 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 |
Encuentre el recurso que el navegador eligió realmente
La URL que ve en el código fuente de la página a menudo no es la URL que se solicitó. Los conjuntos de orígenes, los elementos picture y los fondos CSS permiten al navegador elegir un recurso distinto según el ancho de la ventana, la densidad de píxeles o la compatibilidad de formato. Puede que una imagen de carga diferida no se solicite en absoluto hasta que la página alcance un estado determinado.
Inspeccione el elemento y la solicitud juntos, y conserve el iniciador con la solicitud cuando informe del problema. La referencia del elemento de imagen de MDN cubre la selección de origen, el comportamiento de carga y los controles de referente en un solo lugar, lo que basta para saber qué atributo eligió la URL que falla.
Anote el nombre de host, el estado, cualquier cadena de redirección y el tipo de contenido de la respuesta. Una respuesta 200 que devuelve una página de inicio de sesión no es una imagen utilizable, y una redirección a una página de error HTML se ve idéntica a un archivo dañado hasta que lee el tipo.
Lea el estado antes que la red
Un tiempo de espera agotado, una solicitud denegada y un error de decodificación necesitan pasos siguientes distintos, y el código de estado es lo que los separa. Un tiempo de espera apunta a la resolución de nombres, la ruta o un host que no responde. Una solicitud denegada apunta a una política o a una capa de autorización. Un error de decodificación apunta a los bytes o al formato.
Si la solicitud no aparece nunca, deje de mirar la red y mire el marcado. La causa más común es una entrada de un conjunto de orígenes que el navegador prefirió y que ya no existe en el servidor, seguida de un elemento que ningún script hizo visible.
Solo esa distinción evita la mayor parte del esfuerzo desperdiciado en este tipo de avisos.
Cuando el navegador lo bloquea, no hay respuesta que leer
El contenido mixto es el caso clásico: una página HTTPS que pide una imagen por HTTP simple recibe la solicitud bloqueada en lugar de fallida, y la consola registra el motivo. La política de seguridad de contenido produce la misma forma, con la directiva bloqueada indicada en el mensaje. Una política de referente que elimina la cabecera también puede hacer que un host protegido contra hotlinking devuelva un marcador de posición en lugar de la imagen.
Lea el motivo registrado antes de tocar la ruta de red, porque estos bloqueos no mejoran cuando cambia la ruta. Añadir permisos de origen cruzado tampoco es la solución: mostrar una imagen de otro host y leer sus píxeles en un canvas son operaciones distintas, y solo la segunda necesita las cabeceras que la gente pega.
En un sitio que usted administra, corrija la URL del recurso, la respuesta o la política en su propietario y mantenga intactos los requisitos de autorización y de referente. En un sitio que no controla, envíe la página y las pruebas de la solicitud a su canal de soporte en lugar de republicar enlaces de recursos privados o caducados.
Compare rutas sin cambiar las pruebas
Si de verdad quiere probar la ruta de acceso, mantenga todo lo demás constante: misma página, misma cuenta, misma imagen seleccionada, una ruta permitida cambiada. Compare las entradas de solicitud en paralelo en lugar del resultado representado, porque el resultado representado dice si la imagen apareció, no por qué.
Una imagen que carga en una ruta nueva no demuestra que esa ruta esté autorizada, y una imagen que sigue rota no demuestra que el túnel tenga la culpa. Si la imagen se eliminó o el acceso está restringido a propósito, use una alternativa compatible en lugar de desactivar las comprobaciones de certificado o copiar material protegido de otra persona.
Orden de trabajo: identifique la URL seleccionada, lea su estado y tipo, compruebe si hay un motivo de bloqueo registrado y luego compare un cambio de ruta a la vez.