我遇到這個問題已經有一段時間了，透過基於 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）上luakit安裝的 virtualbox 進行安裝，結果很有趣......沒有未解析的主機名稱/損壞的圖像/失敗的資源的症狀。在這個虛擬環境中瀏覽也相對更快。kali-linuxapt-get install luakit
解決方案：
遵循 @harrymc 提出的建議（使用 Google 公共 DNS）已經完全消除了頁面加載不良的所有症狀。根據 @harrymc 的說法，這是由於 DNS 故障/緩慢和/或 DNS 快取策略不佳造成的。更具體地說，導致此問題的原因是 DNS 效能不佳，以及引擎中內建的似乎相當倉促的逾時協定webkit。這兩個因素會導致災難。
更開放的思想弧：
另一個結論是 Webkit 瀏覽器效率低下，因為它們對相同網站發出多個 DNS 查詢，而不是記住第一個查詢。另一個結論是，ISP 的 DNS 伺服器有時顯然無法處理多個並行請求（因為瀏覽器可能會透過執行緒並行處理多個映像），也許是因為他們現在有更多的客戶端，但沒有足夠的 DNS 伺服器。 ——哈利·麥克
答案1
由於 Webkit 團隊任意決定透過硬編碼、隱藏的 60 秒逾時限制所有 XML HTTP 請求，我們剛剛被迫重構/重新編碼基於 AIR 的 RIA 的很大一部分。這項決定不僅影響AIR，也影響Safari和其他基於Webkit的瀏覽器。
雖然這不一定與您的問題有關，但它確實表明 Webkit 中存在硬編碼逾時。
如果您的問題與 Webkit 中的超時太短有關，那麼問題是，既然您的連接速度很快，為什麼您會經歷長時間的圖像等待。
作為第一個測試，我建議將您的 DNS 伺服器更改為 谷歌公共 DNS或者開放DNS，看看這是否有所不同。如果確實如此，則問題出在您的 ISP 在 DNS 上或使用自己的快取時速度太慢。
另一個參考透過用戶代理禁用 HTTP keepalive:
Safari 中長期存在的錯誤會導致在不正確地重複使用 keepalive 連線時檔案上傳掛起。
https://bugs.webkit.org/show_bug.cgi?id=5760
在 Apache 中，停用 Webkit 的 keepalive 支援可以解決此問題。
如果 Apache Web 伺服器仍然停用 Webkit 的 keepalive (HTTP 持久連接），這意味著每個圖像都需要單獨的 HTTP 連接，而 Firefox 和 Chrome 可以使用頁面已有的連接來下載圖像，而無需重新連接。
由於建立連線通常相當緩慢，再加上較短的內建逾時，可以解釋 Webkit 的影像問題。
我想知道您的 Webkit 瀏覽器是否能夠更改其使用者代理 身份 ？
例如，雖然我對 vimperator 一無所知，但我透過谷歌找到了這個插件使用者代理切換器Lite。