Schnelligkeit beim Seitenaufbau zwischen Firefox und Chrome?

  • Nabend / Moin ,

    ich hab mich gefragt, ob es einen Vergleich gibt zwischen den beiden Browsern, wer eine Seite schneller aufbaut?
    Das wird man jetzt vielleicht eh nicht spüren,aber ich wollts trotzdem einfach mal wissen :)
    IE nutz ich ja schon seit ein paar Jahren nicht mehr und Chrome auch noch nie benutzt.
    Immer nur Firefox,wobei ich selber nicht ganz weiss wieso :shock:
    Ich überlege auch,ob es nicht sinnvoll wäre die beiden paralel zu nutzen :O
    Werbelink entfernt

    Einmal editiert, zuletzt von Hinvi (31. März 2012 um 14:29)

  • Zitat von Hinvi

    ...ich hab mich gefragt, ob es einen Vergleich gibt zwischen den beiden Browsern, wer eine Seite schneller aufbaut?


    Solche Vergleiche machen keinen Sinn, da das Ergebnis von vielen Faktoren abhängig ist. Rechnerleistung, Umgebung dessen, Firefox-Add-ons und nicht zuletzt die gesamte Softwareumgebung.

    Zitat

    Immer nur Firefox,wobei ich selber nicht ganz weiss wieso :shock:


    Das wirst du auch auf der theoretischen Ebene nicht klären können. Das musst du schon praktisch testen und sicherlich nicht nur einen Tag lang. Aber die Frage kannst nur du dir selbst beantworten.

    Mir persönlich ist es ziemlich egal, wie lange es dauert, bis sich eine Seite aufgebaut hat. Wenn es keine zu behebenden Behinderungen gibt, akzeptiere ich auch Bremsen, die z.B. unter den Firefox-Erweiterungen zu finden sind. Dass mir Firefox besser als andere Browser gefällt, ist ein komplexes Ergebnis. Und zu diesem Ergebnis sollte sich jeder per Selbsterfahrung hinhangeln.

  • Nimms nicht persönlich, aber: Bitte nicht schon wieder ;)

    Ist hier ein Klassiker wie anderorts "der beste Virenscanner"

    Es gibt keine Auszeichnung für möglichst viel freien Arbeitsspeicher!

  • Das läuft bei der Frage nach dem "schnellsten" Rechner auch nicht anders. Den Lahmsten hat letztlich immer derjenige, der die wirksamsten Tuningprogrämmchen drauf gekleistert hat.

  • Hey,
    mein erster Beitrag hier! Tach erstmal! :)
    Klar haengt die Geschwindigkeit des Browsers von zu vielen DIngen ab, als dass man einfach sagen koennte, "der browser ist schneller als jener" :!: Letztendlich sind die GEschwindigkeitsunterschiede sowieso minimal, kaum merklich, es sei denn man hat in einem seiner BRowser unzaehlige Toolbars installiert oder irgendwas an den Einstellungen vermurkst.
    Auf techfacts gab es dazu letztens noch nen interessanten Artikel. :)

    Liebe Gruesse!

  • Zitat von bugcatcher

    Inzwischen wird nicht mal mehr an der Geschwindigkeit gearbeitet. Inzwischen wird auch an der "gefühlten" Geschwindigkeit gewerkelt. Ist schon drollig.


    War der Beitrag komplett sarkastisch? Ich frag lieber. Denn es wird schließlich selbstverständlich noch an der Geschwindigkeit gearbeitet. Worauf ich eigentlich hinauswill: Was ist daran drollig? "Gefühlte Geschwindigkeit" ist ein ernsthaftes Thema, welches sogar wichtiger als gemessene Geschwindigkeit ist. Man kann gute Geschwindigkeiten erzielen und das Produkt fühlt sich trotzdem langsam an und umgekehrt muss man nicht die besten Werte erzielen und kann sich trotzdem schneller anfühlen. Beispielsweise flackert bis Firefox 12 beim Neuladen einer Seite im Tabtitel ein “Verbinden…” kurz auf, ab Firefox 13 nicht mehr und das wirkt sich sehr positiv auf die Wahrnehmung aus. Das ist eine Verbesserung der gefühlten Geschwindigkeit. Noch deutlicheres Beispiel: Animationen der Benutzeroberfläche, insbesondere Tabs. Ändert an der realen Geschwindigkeit absolut gar nichts. Gefühlt macht es den Browser schneller. Psychologischer Fakt. Und das ist tatsächlich relevant. Daher verstehe ich den Kommentar nicht. Diese ganze Begrifflichkeit ist auch nicht von Mozilla ausgedacht, sondern ein reales und ernsthaftes, sehr großes Thema, für alle Browser-Hersteller, generell für Entwickler von Software, bei der eine gute Bedienbarkeit und Reaktionsfreudigkeit im Vordergrund steht.

  • Ist auch nicht auf Mozilla gemünzt, sondern auf Entwicklung generell. Und ja, dass hat einen sarkastischen Unterton, weil ich mich ständig um sowas kümmern muss, weil die Leute immer nur gefühlte Probleme haben. Sprich, statt das ich echte Probleme angehe, geht meine Zeit dafür drauf den Leuten ihre psychologische Probleme mit Placebos zu behandeln. Das das sehr relevant ist, ist mir klar. Ändert nichts daran, dass ich das drollig finde, dass wir inzwischen mehr bei Einbildung statt bei Realität angekommen sind. Das hat für mich ähnliche Anwandlungen wie Religion. Der Glaube versetzt Berge. Ich persönlich würde aber lieber auf Religion verzichten, da das für mich die reinste Zeitverschwendung ist. Und meine Zeit ist mir zu kostbar für ein paar Hirngespinste. Da würde ich lieber anders machen...

  • Ich verstehe dich schon ein ganz bisschen, letzten Endes sind es aber keine Placebos. So funktionieren alle Menschen und die Wahrnehmung ganz einfach, das ist Biologie, Gehirnforschung, Psychologie, wasauchimmer und sich nicht darauf ein wenig zu fokussieren, wäre verschwendete Zeit. Mir ist es ehrlich auch lieber, es wird Zeit in flüssig wahrzunehmende Interaktionen gesteckt als wieder 0.1ms aus der JavaScript-Engine rauszuholen oder 1MB niedrigeren Speicherverbrauch zu feiern. Denn davon kannst du dir nichts und kann ich mir nichts kaufen. Ich find diese Benchmark-Geilheit, die es allgemein gibt, so extrem schlimm. So nach dem Motto *Ich hab den längsten*. Der Nutzer merkt davon herzlich wenig. Aber diese Baustellen, die unter die gefühlte Geschwindigkeit fallen, die sind wirklich für uns als Menschen wahrnehmbar und werten das Browsing-Erlebnis auf, es sieht gut aus. Wenn ich da zum Beispiel mal an das Animieren vom Verschieben der Tabs denke. Es fühlt sich flüssiger an. Obwohl real nichts flüssiger ist. Das ist so ein großer Unterschied und es macht wirklich mehr Spaß, den Browser zu bedienen. Das Versteifen auf reale Geschwindigkeit hingegen und damit im Endeffekt auf nichts anderes als auf Zahlen ist am Benutzer komplett vorbeientwickelt. Das ist höchstens für die Marketingabteilung sinnvoll, da die *3x bessere Performance* besser verkaufen können. Damit meine ich nicht, dass reale Geschwindigkeit kein wichtiges Thema sei, im Gegenteil, die ist nach wie vor immens wichtig. Aber das eine ist schwach ohne das andere und umgekehrt. Konkret im Falle von Mozilla jetzt: Firefox ist ein extrem schneller Browser. Und trotzdem nehmen Anwender ihn immer wieder teilweise deutlich langsamer als Chrome wahr. Was die Wichtigkeit der gefühlten Geschwindigkeit nur unterstreicht.

  • Missverstehe meine "lieber an richtigen Sachen arbeiten" nicht als irgendwelche Vorlieben für Benchmarks. Und ich weiß, welche Vorteile das für die Nutzer hat. Ich bin derjenige in unserem Unternehmen, der das Thema überhaupt auf den Tisch gebracht hat. User centered process.

    Und ja, ich bin es auch leid immer wieder diese unsinnige "aber Chrome ist schneller" Argument zu hören, wenn ich weiß das es nur gefühlt ist. Insofern muss man halt am Gefühl arbeiten. Und ja, ich weiß auch dass das menschlich ist und wir den Menschen nicht ändern werden.

    Ich bleib trotzdem der verbitterte Kauz. ; )

  • Nur eine kleine Ergänzung.

    Mozilla hat ja das Projekt Performance/Snappy aufgelegt, bei dem die allgemeine Griffigkeit / Schmissigkeit gesteigert werden soll / wird. An vielen kleinen Stellen wird parallel gearbeitet.

    Der Fx 15 fühlt sich inzwischen auch irgendwie runder an, obgleich nicht gesagt werden kann, ob das nicht zum Teil der Kenntnis über das Projekt geschuldet werden muss.

  • Problematisch bei sowas ist, wenn man selbst in der Entwicklung involviert ist, dass man es als "logisch" wahr nimmt. Auch schon weil man sich aktiv damit beschäftigt. Sobald man sich mit Abläufen beschäftigt und man sich an diese gewöhnt, wird man einerseits selbst schneller, weil man weiß was zu tun ist und andererseits hinterfragt man es weniger, weil es schon wieder zur Gewohnheit wird. Man muss sich im Grunde immer wieder selbst hinterfragen, um flexibel zu bleiben. Das kann aber auch dazu führen, das nie mal was fertig wird und sein ganzes Potential freisetzt. ; )

    Unterm Strich kann es das die Effizienz für bestimmte Leute (oft auch bei denen im eigenen Team) wirklich gesteigert wird, aber externe die den Prozess nicht mitgemacht haben, den Anschluss und dadurch die Vorteile verlieren. Daher sind Tests mit Unbeteiligten immer so wichtig. In der Regel entscheidet die Zugänglichkeit darüber, ob ein Feature überhaupt angenommen wird. Das ist immer dann eine Gradwanderung, wenn man allgemeine Konzepte über den Haufen wirft, um neue Herangehensweisen zu ermöglichen. Das meiste ist hier reine Psychologie. Auf beiden Seiten. Sowohl bei den Nutzern als auch bei den Entwicklern. ; )

    Ich persönlich würde mich aber eher dafür entscheiden z.B. das Einfrieren der UI zu verhindern (z.B. falls eine Webseite mal zu viel Leistung frisst), weil man mich hier wirklich einschränkt und ich wirklich warten muss, bis ich wieder was machen kann, als dass ich irgendwelche Informationen verberge, die mir zeigen das noch was geladen wird. Nur mal so zum Beispiel. ^^

  • Zitat von bugcatcher

    Das kann aber auch dazu führen, das nie mal was fertig wird und sein ganzes Potential freisetzt.


    Das ist ein Widerspruch in sich. Ein optimaler Zustand gilt immer nur für einen bestimmten Moment, ist also immer temporär.

    Sobald ich als Entwickler aufhöre mein Produkt fortzuentwickeln, wird damit nicht ein Zustand von Stagnation im Optimum gehalten. Vielmehr tritt ab diesem Moment ein rasanter Rückschritt ein, weil man von der Entwicklung um sich herum zwangsläufig überholt wird.

  • Vor den Widersprüchen sollte bitte erstmals geklärt werden, worüber man eigentlich spricht.

    Wenn ein Programm die gewünschte Funktionalität erfüllt, dann ist es fertig und kann von der Entwicklung zu den Akten gelegt werden, Hier laufen einige uralte Schinken und erfüllen immer noch ihre Aufgabe. Das ist kein Rückschritt, denn ein Mehr oder Neuerungen werden nicht benötigt. Genau genommen verlässt man sich auf die etablierte Stabilität.

  • Zitat von .Hermes

    Wenn ein Programm die gewünschte Funktionalität erfüllt, dann ist es fertig


    Im Prinzip hast du damit recht. Aber auf Browser wie Firefox und Chrome (um die geht es in diesem Thread) lässt sich diese These nicht so einfach übertragen.

  • Zitat von .Hermes

    obgleich nicht gesagt werden kann, ob das nicht zum Teil der Kenntnis über das Projekt geschuldet werden muss.


    Mit der Kenntnis über das Projekt hat das defintiv nichts zu tun, denn das ist ja kein Hokus Pokus. Das sind ganz konkrete Projekte mit ganz konkretem Benefit. Ich habe ja schon mehrere Beispiele genannt. Die kann jeder wahrnehmen und wird sie größtenteils auch wahrnehmen, obgleich er von "Snappy" oder allgemein Verbesserungen auf diesem Gebiet je etwas gehört hat oder nicht. Snappy ist aber ein gutes Stichwort, dazu hatte ich im November auch ein paar Worte hier auf der Seite verloren, um das Ganze mal auf Deutsch zusammenzufassen:
    https://www.camp-firefox.de/node/440

    Zitat von bugcatcher

    Ich persönlich würde mich aber eher dafür entscheiden z.B. das Einfrieren der UI zu verhindern (z.B. falls eine Webseite mal zu viel Leistung frisst), weil man mich hier wirklich einschränkt und ich wirklich warten muss, bis ich wieder was machen kann, als dass ich irgendwelche Informationen verberge, die mir zeigen das noch was geladen wird. Nur mal so zum Beispiel. ^^


    Auch diese Dinge werden vom Projekt Snappy im Übrigen erfasst. Das ist nämlich gar kein so anderes Thema, das gehört unmittelbar zum ganzen Komplex wahrgenommener Geschwindigkeit dazu, denn die Reaktionsfreudigkeit des Browsers bestimmt die Wahrnehmung sehr klar. Man kann das alles gar nicht so genau trennen, weil die Grenzen hier fließend sind. Auf jeden Fall werden in diesem Bereich momentan größere Fortschritte erzielt, nur ein Stichwort sei hier mal die inkrementelle Garbage Collection, welche seit Firefox 13 testweise aktiviert werden kann und es dann hoffentlich ab Firefox 15 standardmäßig ist. Einfaches Prinzip: Nicht mehr benötigte JavaScript-Objekte in kleineren Schritten löschen -> häufiger notwendig, dafür jeweils kürzer -> weniger Ruckler.

  • O.K., nun in anderen Worten, mit dem Fx 4 wurde der Parser für HTML5 eingeführt. Da gibt es keine eigenständige Entwicklung und auch keine Stagnation. Das Regelwerk wurde eingetippt und von etablierten Programmen in maschinell nutzbare Ergebnisse gewandelt.

    Wenn sich der in Entwicklung befindliche Standard ändert, dann wird der Parser angepasst.

  • Zitat von Sören Hentzschel

    Das sind ganz konkrete Projekte mit ganz konkretem Benefit.

    An dieser Stelle konnte ich mir jedoch ein leichtes Lächeln nicht verkneifen, denn die Assoziation mit dem guten alten Pflichtenheft waren zu naheliegend.

    Ich habe genug Projekte erlebt, bei denen die Diskrepanz zwischen Erwartungshaltung und dem realen Bedarf 'etwas' hinderlich war.