Os navegadores Webkit carregam inconsistentemente imagens / recursos da página da Web

Question

Eu tenho tido esse problema há algum tempo, em que sites visualizados por meio de navegadores baseados em webkit carregam imagens de maneira inconsistente. Por inconsistente, quero dizer que, em um teste, uma imagem ou várias imagens serão carregadas com êxito, apenas para outras que não serão. Em outro teste do mesmo site, as imagens que não foram carregadas anteriormente serão carregadas de repente - somente para que as que anteriormente foram carregadas não sejam carregadas de repente. Esse comportamento é tão não linear que estou tendo dificuldades extremas para descobrir a origem do problema. Percebo que esse problema é replicável com navegadores como jumanji , dwb e vimperator . Eu acredito que o fator comum entre todos esses navegadores é que eles usam webkit . O recarregamento repetitivo da 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 luakit baseado em webkit):

Como você pode ver, há duas imagens com falha, que ilustram o comportamento comum aqui. Não consigo replicar esse problema com navegadores como firefox ou chrome (que, acredito, usam gecko e blink respectivamente). Se eu clicar com o botão direito do mouse na imagem / elemento e abri-la em uma nova janela, consigo visualizar a imagem sem problemas. Estou executando o kernel do Arch Linux 3.12.9-1-ck. Qualquer ajuda / insight sobre o que poderia estar acontecendo seria muito apreciado. Obrigado.

UPDATE: Toda imagem quebrada, quando inspecionada como um elemento pelo console de depuração no luakit, produz algo dessa forma geral:

GET [web address here] Cannot resolve hostname [domain here]

UPDATE 2: Eu tentei instalar luakit em uma instalação de kali-linux no VirtualBox que eu tenho no meu sistema (baseado no Debian) via apt-get install luakit , e resultado interessante ... Não sintomas 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:

Após a sugestão proposta por @harrymc (usando o DNS público do Google) destruiu completamente todos os sintomas de carregamento de página ruim. De acordo com @harrymc, isso ocorre devido a DNS defeituoso / lento e / ou a estratégias ruins de armazenamento em cache do DNS. Mais especificamente, o que causou esse problema foi um DNS deficiente, e o que parece ser um protocolo de tempo limite bastante apressado embutido no mecanismo webkit . Esses dois fatores são uma receita para o desastre.

Um Arco de Pensamento Mais Aberto:

One other conclusion is the inefficiency of Webkit browsers in that they issue multiple DNS queries for the same website, rather than remembering the first query. Another conclusion is that the ISP's DNS server apparently sometimes cannot handle multiple parallel requests (since the browser probably handles multiple images in parallel via threads), perhaps because they now have more clients but not enough DNS servers. --harrymc

    

Answer 1

De Tempo limite do Webkit mata tarefas demoradas :

We have just been forced to refactor/recode a significant portion of one of our AIR based RIA's due to an arbitrary decision made by the Webkit team to restrict all XML HTTP requests via a hard coded, hidden timeout of 60 seconds. This decision not only affects AIR but also affects Safari and other browsers based upon Webkit.

Embora isso não esteja necessariamente relacionado ao seu problema, ele aponta para a existência de um tempo limite embutido no Webkit.

Se o seu problema estiver relacionado a tempos de espera no Webkit serem muito curtos, a questão é, então, por que você está passando por longas esperas por imagens, dado que você tem uma conexão rápida.

Como primeiro teste, sugiro mudar seu servidor DNS para DNS público do Google ou OpenDNS e veja se isso faz diferença. Em caso afirmativo, que o problema é com o seu ISP sendo muito lento no DNS ou usando seu próprio cache.

Outra referência em desabilitando o keepalive HTTP pelo User-Agent :

A long-standing bug in Safari causes file uploads to hang when keepalive connections are improperly reused.

https://bugs.webkit.org/show_bug.cgi?id=5760

In Apache, disabling keepalive support for Webkit solves this problem.

Se o servidor web Apache ainda desabilitar o keepalive para o Webkit ( conexão persistente HTTP ), isso significa que cada imagem requer uma conexão HTTP separada, enquanto o Firefox e o Chrome podem usar o já existente conexão da página para também baixar as imagens sem re-conectar.

Como estabelecer uma conexão normalmente é bem lenta, então isso combinado com um curto tempo limite embutido, pode explicar o problema que o Webkit tem com imagens.

Gostaria de saber se os seus navegadores Webkit têm a capacidade de alterar seu agente do usuário identidade?

Por exemplo, apesar de não saber absolutamente nada sobre o vimperator, Eu encontrei via google o plugin UserAgentSwitcherLite .