Hallo, vielleicht kennt ihr die Webseite, auf der die aktiven Server der exit notes des Tor-Projekts aufgelistet sind: https://torstatus.blutmagie.de Rufe ich diese Seite mit dem Firefox auf, so friert dieser für gut 30s teilweise ein. Sprich den Großteil der Zeit lässt sich Firefox nur sehr träge bedienen oder blockiert völlig. NoScript verbietet jeglichen Javascriptcode für diese Seite, sollte also reines HTML sein. Nach den 30s ist die Serverliste geladen und Firefox funktioniert wider normal. Speichert man die geladene Webseite ab, so hat die HTML-Datei etwa 12MByte ob der langen Liste. Kennt jemand von Euch ein ähnliches Problem? Kann es sein, dass Firefox tatsächlich so lange zum parsen des HTML-Codes braucht, weil der Download der 12MByte dauert keinesfalls so lange. CPU Auslastung liegt bei etwa 12% in der Hängephase bei einem 4(8)-Kern Prozessor. RAM ist ausreichend vorhanden. Besten Dank im Voraus, Roland.
Interessant, hängt dort auch der ganze Bowser? Also das der Tab hängt oder eben der Ladekreis sich dreht, das kennt man ja. Aber das gleich der ganze Browser wegen einer Seite hängt ist schon ungewöhnlich irgendwie, zumal jetzt auch kein Plugin àla Flash abschmiert.
Ja, alles hängt wie in deiner Beschreibung, wobei Opera 12.17 ja auch schon etwas älter ist. Dieses Phänomen sehe ich ab und zu, dh. ich habe es etwa 5 Mal bisher bei ein paar Seiten beobachten können.
Angehängte Dateien:
-
Firefox.jpg
18 KB
So sieht eine Seite mit Videos und Bildern nach 3x scrollen bei mir aus. In diesem Fall facebook, da gehts am schnellsten schief
Firefox hatte zumindest ewige Zeit nur einen Prozess für die gesamte Anzeige. Ob das noch so ist, weiß ich nicht, aber die Tatsache, dass die oben genannte Seite Firefox nicht mehr reagieren lässt und ein CPU-Kern auf 100% hängt, spricht dafür. Opera 33 (also Chrome (=> 1 Prozess pro Tab) mit anderem Logo und ein paar anderen Detailänderungen) lädt die Seite viel schneller und bleibt währenddessen bedienbar.
Also ich kenne dieses Hängenbleiben vorallen von Javascripts. Wenn ein Script lange rechnet oder gar hängt, dann hängt der komplette Firefox und nach einer Weile kommt das Popup mit der Meldung das ein Script nicht antwortet. Beim Internet Explorer hingegen hängt bei rechenintensiven Scripts nur der zuständige Tab, da hier wohl auch mehrere Prozesse erstellt werden. Was mich jedoch so wundert, dass Firefox bei reinem HTML auch hängt. Braucht das Darstellen einer 12MByte großen HTML Datei wirklich so lange?
Roland schrieb: > Was mich jedoch so wundert, dass Firefox bei reinem HTML auch hängt. > Braucht das Darstellen einer 12MByte großen HTML Datei wirklich so > lange? ...ähm, ja, wenn dem Browser nicht durch entsprechende Anweisungen in den Metadaten, beim Rendern der Ausgabe "geholfen" wird bzw. der HTML-Code insgesamt durch HTML-Regelverstösse (beliebt sind z.B. fehlende """) strotzt. Bei 12MByte dürften sich solche Probleme dann schon summieren, die bei "normalen" Seiten nur ein paar 10tel Sekunden ausmachen.
Ja ich kann das Problem auch nachvollziehen. Bei mir friert es zwar nicht dauerhaft ein, aber Firefox hängt so sehr, dass es kaum noch zu bedienen ist. CPU Auslastung ist bei 100%. FF 42.0 unter Linux Mint 17.2
Vielen Dank für die Antworten, scheint also wirklich so zu sein, dass der Bowser zum parsen der HTML-Anweisungen und zum Formatieren der CSS-Vorlage derart lange braucht. Unabhängig vom Betriessystem und CPU-Rechnenleistung. Dauert wohl noch ein paar Firefoxrevisionen bis jeder Tab einen eigenen CPU-Prozess bekommt um das Blockieren des gesamten Browsers in solch einem Fall zu verhindern ;-).
Ein Kern fast 100% Auslastung, flüssiges Scrollen auf der Seite während des ladens problemlos möglich und keine Auwirkungen auf andere Tabs. FF 3.0.19 FF sollte wohl mal wieder zu den Wurzeln zurück statt sich weiter sinn- und verstandlos aufzublasen. :-D
Die Seite ist recht lang, so das mein SeaMonkey 2.39/XP ein wenig braucht. Lädt aber komplett und ich kann währenddessen im anderen Tab weiter durchs MC.net scrollen. Der Apache 2.2 Server bei denen scheint aber auch nicht der schnellste zu sein.
:
Bearbeitet durch User
aha schrieb: > Ein Kern fast 100% Auslastung, flüssiges Scrollen auf der Seite > während > des ladens problemlos möglich und keine Auwirkungen auf andere Tabs. > > FF 3.0.19 > > FF sollte wohl mal wieder zu den Wurzeln zurück statt sich weiter sinn- > und verstandlos aufzublasen. :-D Lustig, in Version 3 blockiert nicht mal diese Seite wenn sie geladen wird und in Version 44 der ganze Browser. In der Tat, back to roots wäre angesagt, weil HTML parsen ist wohl das Grundlegendste. Matthias S. schrieb: > Die Seite ist recht lang, so das mein SeaMonkey 2.39/XP ein wenig > braucht. Lädt aber komplett und ich kann währenddessen im anderen Tab > weiter durchs MC.net scrollen. Interessant, obwohl SeaMonkey auf Firefox beruht funktioniert er besser.
Wenn ich die Seite mit Firefox 44.02 für Mac öffne, kommt nach einiger Zeit diese Meldung: Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen, im Debugger öffnen oder weiter ausführen. Skript: chrome://global/content/bindings/browser.xml:333 Und außerdem war mein Firefox noch 'ne ganze Weile mit sich selbst beschäftigt und hat gestottert und gezickt, nachem ich die Seite bzw. den Tab längst geschlossen hatte.
:
Bearbeitet durch User
Das ist die Krankheit von 64-Bit-FF, die mir schon lange ziemlich auf den Geist geht. Das Problem wird immer schlimmer, je mehr Fenster offen sind und je mehr Tabs und je länger er schon läuft. Ich habe ihn hier nach 5 Minuten Laden von https://torstatus.blutmagie.de/ abgeschossen. Er hatte es gerade mal geschafft, die Icons auf die Tabs zu malen, der Rest war weiß und FF hat auf nichts, außer kill -9 reagiert. JS war auch abgeschaltet. Das Problem ist wohl ein nicht mehr ganz neues Speicherverwaltungsproblem der 64-Bit-Version, den die Schnapsnasen einfach nicht beheben. Chromium zeigt den Anfang der Seite sofort an, lädt dann aber noch ein paar Sekunden weiter, bis er alles beisammen hat.
:
Bearbeitet durch User
Roland schrieb: > Interessant, obwohl SeaMonkey auf Firefox beruht funktioniert er besser. Die SeaMonkey Leute haben schon vor einiger Zeit angekündigt, nicht mehr jeden Mist mitzumachen, den FF vormacht.
Angehängte Dateien:
-
XHTML.png
18 KB
Mal den Seitenquelletext angeschaut? Da hat einer versucht XHTML zu schreiben, es aber nicht verstanden und zum Glück auch nicht hingekriegt. Sonst würde der Firefox nur eine reine Fehlermeldungs-Seite anzeigen, und garkeinen Content. Aber die Seite kommt dann wenigstens schnell :)
Die Seite will diverse Grafiken nachladen, was je Grafik zwischen 0,5s und 2s dauert. Bei 110 Anfragen in Summe steht der Browser... das ist eher Inkompetenz seitens des Seitenbetreibers wie ich finde. Nachprüfbar im FF über Extras -> Web-Entwickler -> Laufzeitanalyse und weitere...
Uhu U. schrieb: > Das ist die Krankheit von 64-Bit-FF, die mir schon lange ziemlich auf > den Geist geht. Das Problem wird immer schlimmer, je mehr Fenster offen > sind und je mehr Tabs und je länger er schon läuft. Das ist bei der 32-Bit-Version genauso. In den letzten Jahren war jede neuere Version schlechter als die ältere und diesen Schice kriegt man immer häufiger aufgedrängt. Aber das ist wohl der aktuelle Zeitgeist. Wahrscheinlich pfuscht da jetzt eine Programmierergeneration, die es einfach nicht mehr kapiert, was wirklich wichtig ist. Grüße Richard
hab das Problem mit Firefox andauernd...zwischendurch ist einfach Pause und nix geht mehr. Eigentlich wirds Zeit, Firefox in die Tonne zu kloppen. Das ist ein aufgeblähter Haufen Mist!
beim ersten Aufruf der Seite über den Link hat sich mein FF Version 38.6.1 gleich mal mit einem Absturz voll verabschiedet, es waren wohl parallel zu "viele" FF-Seiten schon offen , ca. 25 ! jetzt bei fast keinen offenen Seiten braucht der Aufbau der Seite über 10 sec. und hat dann über 300 MB im RAM dafür belegt, und was ist auf der Seite bitte so Systemlastig? die paar kleinen Grafiken links für die Länderfähnchen? da trifft sich wohl eine schlampig programmierte Seite mit einer ebenso stümperhaft gewordenen Anwendung - fast aktueller Firefox. Mit dem IE V8 ist es noch schlimmer, über 650 MB und fast volle CPU-Last, aber die Seite ist gleich im oberen Bereich wenigstens sichtbar, wenn auch lange nicht bedienbar.
Niemand schrieb: > beim ersten Aufruf der Seite über den Link hat sich mein FF Version > 38.6.1 gleich mal mit einem Absturz voll verabschiedet, es waren wohl > parallel zu "viele" FF-Seiten schon offen , ca. 25 ! Schau mal, was unter Einstellungen/Erweitert/Netzwerk unter Cache eingestellt ist. Wenn der überläuft, kann der FF oder gar W7 abstürzen. Ich habe den manuell auf 512MB und leere den regelmäßig. Falls ich das doch mal verpasse, dann kackt auch schon mal das W7 ab. Für WIN ist jetzt V.44 aktuell??
michael_ schrieb: > Ich habe den manuell auf 512MB und leere den regelmäßig. Lass das doch Firefox machen. Einstellungen → Datenschutz → "Chronik löschen, wenn Firefox geschlossen" anklicken → danach rechts auf Einstellungen und nur Cache auswählen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.