He estado teniendo este problema durante bastante tiempo, donde los sitios web vistos a través de navegadores basados en webkit cargan imágenes de manera inconsistente. Por inconsistente quiero decir que en una ejecución de prueba, una imagen o varias imágenes se cargarán correctamente, solo para tener otras que no lo harán. En otra prueba de ese mismo sitio web, las imágenes que no se cargaron anteriormente se cargarán repentinamente, solo para que las que sí se cargaron anteriormente, de repente no se carguen. Este comportamiento es tan no lineal que tengo dificultades extremas para descubrir el origen del problema. Noto que este problema se puede replicar con navegadores como jumanji, dwby vimperator. Creo que el factor común entre todos estos navegadores es que utilizan webkit. Recargar repetidamente la página web a veces producirá un resultado en el que todos los recursos se cargan correctamente.
Aquí hay una captura de pantalla del comportamiento descrito (del basado en webkit luakit):
Como puede ver, estas son dos imágenes fallidas que ilustran el comportamiento común aquí. No puedo replicar este problema con navegadores como Firefox o Chrome (que creo que usan geckoy blinkrespectivamente). Si hago clic derecho en la imagen/elemento y lo abro en una nueva ventana, puedo ver la imagen sin problemas. Estoy ejecutando el kernel 3.12.9-1-ck de Arch Linux. Cualquier ayuda o idea sobre lo que podría estar sucediendo sería muy apreciada. Gracias.
ACTUALIZAR:Cada imagen rota, cuando se inspecciona como un elemento mediante la consola de depuración en luakit, genera algo parecido a esta forma general:
GET [web address here] Cannot resolve hostname [domain here]
ACTUALIZACIÓN 2:Intenté instalar luakiten una instalación de virtualbox kali-linuxque tengo en mi sistema (basada en Debian) a través de apt-get install luakit, y obtuve un resultado interesante... No hay síntomas de nombres de host no resueltos/imágenes rotas/recursos fallidos. La navegación también es comparativamente más rápida en este entorno virtual.
Solución:
Seguir la sugerencia propuesta por @harrymc (usando el DNS público de Google) ha destruido por completo todos los síntomas de mala carga de la página. Según @harrymc, se debe a un DNS lento o defectuoso y/o estrategias de almacenamiento en caché de DNS deficientes. Más específicamente, lo que causó este problema fue un DNS deficiente y lo que parece ser un protocolo de tiempo de espera bastante apresurado integrado en el webkitmotor. Estos dos factores son una receta para el desastre.
Un arco de pensamiento más abierto:
Otra conclusión es la ineficiencia de los navegadores Webkit, ya que emiten múltiples consultas DNS para el mismo sitio web, en lugar de recordar la primera consulta. Otra conclusión es que el servidor DNS del ISP aparentemente a veces no puede manejar múltiples solicitudes paralelas (ya que el navegador probablemente maneja múltiples imágenes en paralelo a través de subprocesos), tal vez porque ahora tienen más clientes pero no suficientes servidores DNS. --harrymc
Respuesta1
DeEl tiempo de espera de Webkit elimina las tareas de ejecución prolongada:
Acabamos de vernos obligados a refactorizar/recodificar una parte importante de uno de nuestros RIA basados en AIR debido a una decisión arbitraria tomada por el equipo de Webkit de restringir todas las solicitudes HTTP XML a través de un tiempo de espera oculto y codificado de 60 segundos. Esta decisión no sólo afecta a AIR sino que también afecta a Safari y otros navegadores basados en Webkit.
Aunque esto no necesariamente se relaciona con su problema, sí indica la existencia de un tiempo de espera codificado en Webkit.
Si su problema está relacionado con que los tiempos de espera en Webkit son demasiado cortos, la pregunta es, ¿por qué experimenta largas esperas para recibir imágenes, dado que tiene una conexión rápida?
Como primera prueba te sugiero cambiar tu servidor DNS a DNS público de GoogleoOpenDNSy vea si esto hace la diferencia. Si es así, entonces el problema es que su ISP es demasiado lento en DNS o en el uso de su propio caché.
Otra referencia endeshabilitar HTTP keepalive por User-Agent:
Un error de larga data en Safari hace que la carga de archivos se cuelgue cuando las conexiones keepalive se reutilizan incorrectamente.
https://bugs.webkit.org/show_bug.cgi?id=5760
En Apache, deshabilitar la compatibilidad con Keepalive para Webkit resuelve este problema.
Si el servidor web Apache aún deshabilita keepalive para Webkit (Conexión persistente HTTP), esto significa que cada imagen requiere una conexión HTTP separada, mientras que Firefox y Chrome pueden usar la conexión ya existente de la página para descargar también las imágenes sin volver a conectarse.
Como establecer una conexión normalmente es bastante lento, esto, junto con un breve tiempo de espera incorporado, puede explicar el problema que tiene Webkit con las imágenes.
Me pregunto si sus navegadores Webkit tienen la capacidad de cambiar suAgente de usuario identidad ?
Por ejemplo, aunque no sabía absolutamente nada sobre vimperator, encontré a través de Google el complementoUserAgentSwitcherLite.