Ich habe dieses Problem schon seit einiger Zeit: Websites, die über WebKit-basierte Browser aufgerufen werden, laden Bilder inkonsistent. Mit inkonsistent meine ich, dass bei einem Probelauf ein Bild oder mehrere Bilder erfolgreich geladen werden, andere aber nicht. Bei einem weiteren Probelauf derselben Website werden die Bilder, die vorher nicht geladen wurden, plötzlich geladen – und die, die vorher geladen wurden, werden plötzlich nicht mehr geladen. Dieses Verhalten ist so nicht linear, dass es mir große Schwierigkeiten bereitet, die Ursache des Problems herauszufinden. Mir ist aufgefallen, dass dieses Problem bei Browsern wie jumanji, dwb, und reproduzierbar ist vimperator. Ich glaube, der gemeinsame Faktor all dieser Browser ist, dass sie verwenden webkit. Das wiederholte Neuladen der Webseite führt manchmal dazu, dass alle Ressourcen korrekt geladen werden.
Hier ist ein Screenshot des beschriebenen Verhaltens (aus dem WebKit-basierten luakit):
Wie Sie sehen, handelt es sich hier um zwei fehlerhafte Bilder, die ein typisches Verhalten veranschaulichen. Ich kann dieses Problem mit Browsern wie Firefox oder Chrome (die ich glaube, bzw. verwenden) nicht reproduzieren gecko. blinkWenn ich mit der rechten Maustaste auf das Bild/Element klicke und es in einem neuen Fenster öffne, kann ich das Bild problemlos anzeigen. Ich verwende Arch Linux Kernel 3.12.9-1-ck. Für jede Hilfe/Einsicht, was hier passieren könnte, wäre ich sehr dankbar. Vielen Dank.
AKTUALISIEREN:Wenn jedes defekte Bild als Element von der Debug-Konsole in Luakit untersucht wird, wird ungefähr diese allgemeine Form ausgegeben:
GET [web address here] Cannot resolve hostname [domain here]
UPDATE 2:Ich habe versucht, es über luakitauf einer Virtualbox-Installation zu installieren kali-linux, die ich auf meinem System (debian-basiert) habe apt-get install luakit, und das Ergebnis war interessant ... Keine Symptome von nicht aufgelösten Hostnamen/defekten Bildern/fehlgeschlagenen Ressourcen. Das Surfen ist in dieser virtuellen Umgebung auch vergleichsweise schneller.
Lösung:
Durch Befolgen des von @harrymc vorgeschlagenen Vorschlags (Verwendung des öffentlichen DNS von Google) wurden alle Symptome einer schlechten Seitenladezeit vollständig beseitigt. Laut @harrymc liegt dies an fehlerhaftem/langsamem DNS und/oder schlechten DNS-Caching-Strategien. Genauer gesagt war die Ursache dieses Problems ein schlechtes DNS und ein anscheinend ziemlich hastiges Timeout-Protokoll, das in die webkitEngine eingebaut wurde. Diese beiden Faktoren sind ein Rezept für eine Katastrophe.
Ein offenerer Gedankenbogen:
Eine weitere Schlussfolgerung ist die Ineffizienz der Webkit-Browser, da sie mehrere DNS-Abfragen für dieselbe Website stellen, anstatt sich die erste Abfrage zu merken. Eine weitere Schlussfolgerung ist, dass der DNS-Server des ISPs anscheinend manchmal mehrere parallele Anfragen nicht verarbeiten kann (da der Browser wahrscheinlich mehrere Bilder parallel über Threads verarbeitet), möglicherweise weil er jetzt mehr Clients, aber nicht genügend DNS-Server hat. --harrymc
Antwort1
AusEin Webkit-Timeout beendet lang laufende Aufgaben:
Wir waren gerade gezwungen, einen wesentlichen Teil eines unserer AIR-basierten RIAs umzugestalten/neu zu codieren, da das Webkit-Team willkürlich entschieden hatte, alle XML-HTTP-Anfragen über ein fest codiertes, verstecktes Timeout von 60 Sekunden einzuschränken. Diese Entscheidung betrifft nicht nur AIR, sondern auch Safari und andere auf Webkit basierende Browser.
Obwohl dies nicht unbedingt mit Ihrem Problem zusammenhängt, deutet es auf die Existenz eines fest codierten Timeouts in Webkit hin.
Wenn Ihr Problem damit zusammenhängt, dass die Timeouts in Webkit zu kurz sind, stellt sich die Frage, warum Sie trotz einer schnellen Verbindung so lange auf Bilder warten müssen.
Als ersten Test empfehle ich, Ihren DNS-Server zu ändern auf Öffentliches DNS von GoogleoderOpenDNS, und prüfen Sie, ob dies einen Unterschied macht. Wenn ja, liegt das Problem daran, dass Ihr ISP beim DNS zu langsam ist oder seinen eigenen Cache verwendet.
Eine weitere Referenz beiDeaktivieren von HTTP-Keepalive durch User-Agent:
Ein seit langem bestehender Fehler in Safari führt dazu, dass Datei-Uploads hängen bleiben, wenn Keepalive-Verbindungen fälschlicherweise wiederverwendet werden.
https://bugs.webkit.org/show_bug.cgi?id=5760
In Apache löst das Deaktivieren der Keepalive-Unterstützung für Webkit dieses Problem.
Wenn der Apache-Webserver immer noch Keepalive für Webkit deaktiviert (Permanente HTTP-Verbindung), bedeutet dies, dass jedes Bild eine separate HTTP-Verbindung erfordert, während Firefox und Chrome die bereits bestehende Verbindung der Seite verwenden können, um auch die Bilder herunterzuladen, ohne die Verbindung erneut herzustellen.
Da der Verbindungsaufbau normalerweise recht langsam ist, könnte dies in Verbindung mit einem kurzen integrierten Timeout das Problem erklären, das Webkit mit Bildern hat.
Ich frage mich, ob Ihre Webkit-Browser die Möglichkeit haben, ihreUser-Agent Identität?
Obwohl ich zum Beispiel überhaupt nichts über Vimperator wusste, fand ich über Google das PluginUserAgentSwitcherLite.