Já faz algum tempo que tenho esse problema, em que sites visualizados por meio de navegadores baseados em webkit carregam imagens de maneira inconsistente. Por inconsistente, quero dizer que em uma execução de teste, uma imagem ou várias imagens serão carregadas com êxito, mas outras não serão carregadas. Em outro teste do mesmo site, as imagens que não foram carregadas anteriormente serão carregadas repentinamente - apenas para que as que foram carregadas anteriormente não sejam carregadas repentinamente. Esse comportamento é tão não linear que estou tendo extrema dificuldade em descobrir a origem do problema. Percebo que esse problema pode ser replicado com navegadores como jumanji, dwbe vimperator. Acredito que o fator comum entre todos esses navegadores é que eles usam arquivos webkit. Recarregar repetidamente a página da Web às vezes produzirá um resultado em que todos os recursos serão carregados corretamente.
Aqui está uma captura de tela do comportamento descrito (do webkit luakit):
Como você pode ver, essas são duas imagens com falha, que ilustram um comportamento comum aqui. Não consigo replicar esse problema com navegadores como Firefox ou Chrome (que acredito usar geckoe blinkrespectivamente). Se eu clicar com o botão direito na imagem/elemento e abri-la em uma nova janela, poderei visualizar a imagem sem problemas. Estou executando o kernel 3.12.9-1-ck do Arch Linux. Qualquer ajuda/insight sobre o que pode estar acontecendo seria muito apreciada. Obrigado.
ATUALIZAR:Cada imagem quebrada, quando inspecionada como um elemento pelo console de depuração no luakit, gera algo desta forma geral:
GET [web address here] Cannot resolve hostname [domain here]
ATUALIZAÇÃO 2:Tentei instalar luakitem uma instalação virtualbox kali-linuxque tenho em meu sistema (baseado em Debian) via apt-get install luakit, e resultado interessante ... Nenhum sintoma de nomes de host não resolvidos/imagens quebradas/recursos com falha. A navegação também é comparativamente mais rápida neste ambiente virtual.
Solução:
Seguir a sugestão proposta por @harrymc (usando o DNS público do Google) destruiu completamente todos os sintomas de mau carregamento da página. De acordo com @harrymc, isso se deve a DNS defeituoso/lento e/ou estratégias de cache de DNS ruins. Mais especificamente, o que causou esse problema foi um DNS ruim e o que parece ser um protocolo de tempo limite bastante apressado incorporado ao webkitmecanismo. Esses dois fatores são uma receita para o desastre.
Um arco de pensamento mais aberto:
Uma outra conclusão é a ineficiência dos navegadores Webkit, pois eles emitem múltiplas consultas DNS para o mesmo site, em vez de lembrar a primeira consulta. Outra conclusão é que o servidor DNS do ISP aparentemente às vezes não consegue lidar com múltiplas solicitações paralelas (já que o navegador provavelmente lida com múltiplas imagens em paralelo por meio de threads), talvez porque agora eles tenham mais clientes, mas não tenham servidores DNS suficientes. --harrymc
Responder1
DeO tempo limite do Webkit elimina tarefas de longa execução:
Acabamos de ser forçados a refatorar/recodificar uma parte significativa de um de nossos RIAs baseados em AIR devido a uma decisão arbitrária tomada pela equipe do Webkit de restringir todas as solicitações XML HTTP por meio de um tempo limite oculto e codificado de 60 segundos. Esta decisão não afeta apenas o AIR, mas também o Safari e outros navegadores baseados no Webkit.
Embora isso não se refira necessariamente ao seu problema, indica a existência de um tempo limite codificado no Webkit.
Se o seu problema estiver relacionado ao tempo limite do Webkit ser muito curto, a questão é por que você está enfrentando longas esperas por imagens, visto que possui uma conexão rápida.
Como primeiro teste sugiro alterar seu servidor DNS para DNS público do GoogleouOpenDNSe veja se isso faz diferença. Se isso acontecer, o problema é que o seu ISP está muito lento no DNS ou no uso de seu próprio cache.
Outra referência emdesabilitando o keepalive HTTP pelo User-Agent:
Um bug de longa data no Safari faz com que os uploads de arquivos sejam interrompidos quando as conexões de manutenção de atividade são reutilizadas indevidamente.
https://bugs.webkit.org/show_bug.cgi?id=5760
No Apache, desabilitar o suporte keepalive para Webkit resolve esse problema.
Se o servidor web Apache ainda desabilitar o keepalive para Webkit (Conexão persistente HTTP), isso significa que cada imagem requer uma conexão HTTP separada, enquanto o Firefox e o Chrome podem usar a conexão já existente da página para também baixar as imagens sem se reconectar.
Como o estabelecimento de uma conexão normalmente é bastante lento, isso, juntamente com um curto tempo limite integrado, pode explicar o problema que o Webkit tem com as imagens.
Eu me pergunto se os navegadores do seu Webkit têm a capacidade de alterar seusAgente de usuário identidade?
Por exemplo, apesar de não saber absolutamente nada sobre o vimperator, encontrei no google o pluginUserAgentSwitcher Lite.