我已经遇到这个问题很长时间了，通过基于 webkit 的浏览器访问网站时，图像加载不一致。所谓不一致，是指在一次试运行中，一张或几张图片可以成功加载，而其他图片则加载不上。在对同一个网站的另一次试运行中，之前未加载的图片会突然加载——而之前加载的图片突然无法加载。这种行为是如此非线性，以至于我很难找出问题的根源。我注意到，、和等浏览器中都可以复制这个问题。jumanji我dwb相信vimperator所有这些浏览器的共同点是它们都使用webkit。反复重新加载网页有时会导致所有资源都正确加载。
以下是所描述行为的屏幕截图（来自基于 webkit luakit）：
如您所见，这是两个失败的图像，说明了此处的常见行为。我无法使用 Firefox 或 Chrome 等浏览器复制此问题（我相信它们分别使用gecko和blink）。如果我右键单击图像/元素并在新窗口中打开它，我就可以毫无问题地查看图像。我正在运行 Arch Linux 内核 3.12.9-1-ck。任何有关可能发生的情况的帮助/见解都将不胜感激。谢谢。
更新：每个损坏的图像，当通过 luakit 中的调试控制台作为元素检查时，会输出以下一般形式的内容：
GET [web address here] Cannot resolve hostname [domain here]
更新2：我尝试通过 在我的系统（基于 debian）上的luakitvirtualbox 安装中进行安装，结果很有趣... 没有出现无法解析的主机名/损坏的图像/失败的资源的症状。在这个虚拟环境中浏览速度也相对较快。kali-linuxapt-get install luakit
解决方案：
按照 @harrymc 的建议（使用 Google 公共 DNS）完全消除了页面加载缓慢的所有症状。据 @harrymc 说，这是由于 DNS 错误/缓慢和/或 DNS 缓存策略不佳造成的。更具体地说，导致此问题的是 DNS 不佳，以及引擎内置的似乎相当仓促的超时协议webkit。这两个因素是灾难的根源。
更加开放的思路：
另一个结论是 Webkit 浏览器效率低下，因为它们会针对同一个网站发出多个 DNS 查询，而不是记住第一个查询。另一个结论是，ISP 的 DNS 服务器有时似乎无法处理多个并行请求（因为浏览器可能通过线程并行处理多个图像），也许是因为他们现在拥有更多客户端，但 DNS 服务器不够用。 --harrymc
答案1
由于 Webkit 团队武断地决定通过硬编码的隐藏超时 60 秒来限制所有 XML HTTP 请求，我们刚刚被迫重构/重新编码了我们基于 AIR 的 RIA 的很大一部分。此决定不仅影响 AIR，还影响 Safari 和其他基于 Webkit 的浏览器。
虽然这并不一定与您的问题有关，但它确实指出了 Webkit 中存在硬编码超时。
如果您的问题与 Webkit 中的超时时间太短有关，那么问题是，既然您的连接速度很快，为什么您还要等待很长时间才能看到图像。
作为第一次测试，我建议将您的 DNS 服务器更改为 Google 公共 DNS或者开放DNS，看看这是否有区别。如果不同，则问题在于您的 ISP 的 DNS 速度太慢或使用自己的缓存。
另一个参考通过 User-Agent 禁用 HTTP keepalive：
Safari 中长期存在的错误会导致在不正确地重用保持连接时文件上传挂起。
https://bugs.webkit.org/show_bug.cgi?id=5760
在 Apache 中，禁用对 Webkit 的 keepalive 支持可解决这个问题。
如果 Apache Web 服务器仍然禁用 Webkit 的 keepalive（HTTP 长连接)，这意味着每张图片都需要单独的 HTTP 连接，而 Firefox 和 Chrome 可以使用页面已经存在的连接来下载图片，而无需重新连接。
由于建立连接通常非常慢，再加上较短的内置超时时间，这或许可以解释 Webkit 在图像方面存在的问题。
我想知道你的 Webkit 浏览器是否有能力改变它们的用户代理 身份 ？
例如，尽管我对 vimperator 一无所知，但我通过谷歌找到了这个插件用户代理切换器精简版。