Webkit browsers inconsistently load webpage images/resources

Question

I've been having this issue for quite some time, where websites viewed through webkit-based browsers inconsistently load images. By inconsistent, I mean that on one trial run, an image, or several images will load successfully, only to have others that will not. On another trial run of that very same website, the images that didn't load previously will suddenly load --only to have the ones that previously did load, suddenly not load. This behavior is so non-linear that I am having extreme difficulties finding out the source of the issue. I notice that this problem is replicable with browsers such as jumanji, dwb, and vimperator. I believe the common factor amongst all of these browsers is that they use webkit. Repeatedly reloading the webpage will sometimes produce a result where all resources are loaded correctly.

Here is a screenshot of described behavior (from the webkit-based luakit):

As you can see these are two failed images, that illustrate common behavior here. I cannot replicate this issue with browsers such as firefox or chrome (which I believe use gecko and blink respectively). If I right-click on the image/element and open it in a new window, I am able to view the image with no problems. I am running Arch Linux kernel 3.12.9-1-ck. Any help/insight as to what might be happening would be much appreciated. Thank you.

---

UPDATE: Every broken image, when inspected as an element by debugging console in luakit outputs something of this general form:

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

UPDATE 2: I tried installing luakit on a virtualbox installation of kali-linux that I have on my system (debian-based) via apt-get install luakit, and interesting result ... No symptoms of unresolved hostnames/broken images/failed resources. Browsing is also comparatively faster in this virtual environment.

Solution:

Following the suggestion proposed by @harrymc (using Google public DNS) has completely destroyed all symptoms of poor page loading. According to @harrymc, it is due to faulty/slow DNS, and/or poor DNS caching strategies. More specifically, what caused this problem was a poor DNS, and what appears to be a rather hasty time-out protocol built into the webkit engine. These two factors are a recipe for disaster.

A More Open-Ended Thought-Arc:

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

From Webkit timeout kills long running tasks :

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.

Although this doesn't necessarily pertain to your problem, it does point to the existence of a hardcoded timeout in Webkit.

If your problem is related to timeouts in Webkit being too short, the question is then why are you experiencing long waits for images, given that you have a fast connection.

As a first test I suggest changing your DNS server to Google Public DNS or OpenDNS, and see if this makes a difference. If it does, than the problem is with your ISP being too slow on DNS or on using its own cache.

---

Another reference at disabling HTTP keepalive by 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.

If the Apache web-server still disables keepalive for Webkit (HTTP persistent connection), this means that each image requires a separate HTTP connection, while Firefox and Chrome can use the already existing connection of the page to also download the images without re-connecting.

As establishing a connection normally is quite slow, then this coupled with a short built-in timeout, may explain the problem that Webkit has with images.

I wonder if your Webkit browsers have the ability to change their User agent identity ?

For example, while knowing absolutely nothing at all about vimperator, I found via google the plugin UserAgentSwitcherLite.