Firefox wurde 2023 in realen Nutzerumgebungen tatsächlich schneller

 (hacks.mozilla.org)
1 Punkte von GN⁺ 2023-11-01 | 1 Kommentare | Auf WhatsApp teilen
  • Firefox zeigte nach den Optimierungsarbeiten 2023 nicht nur in Benchmarks, sondern auch in der Telemetrie realer Nutzer Verbesserungen bei Seitenaufbau, Eingabereaktionsfähigkeit und JavaScript-Ausführungszeit
  • Mozilla treibt gemeinsam mit anderen Browsern Speedometer 3 voran und entwickelt einen Test, der die von Nutzern wahrgenommene Leistung auf realen Webseiten besser abbildet
  • Die Zeit vom Empfang des ersten Bytes bis zum First Contentful Paint sank von etwa 250 ms zu Jahresbeginn auf 215 ms im Oktober, wodurch das Lade-Feedback fast 15 % schneller wurde
  • Das 95. Perzentil der JavaScript-Ausführungszeit während des Seitenladens sank von etwa 1560 ms auf etwa 1260 ms, also um 300 ms, was mit Optimierungen an SpiderMonkey zusammenhängt
  • Nach den Releases Firefox 116 und 117 sank auch die Verzögerung bei langsamen Tastatureingaben von etwa 65 ms auf unter 59 ms, was eine Verbesserung um 10 % mit weniger Ruckeln beim Tippen brachte

Warum es schwierig ist, die Leistung bei realen Nutzern zu messen

  • Firefox ist komplexe Client-Software, die Code von Drittanbietern ausführt, daher ist es schwierig, Veränderungen der realen Nutzererfahrung allein anhand kontrollierter Labor-Metriken zu beurteilen
  • Um die Browser-Performance zu bewerten, werden anonymisierte Timing-Metriken für Seitenaufbau, Reaktionsfähigkeit und Startzeit benötigt
  • Da die Daten unter Einhaltung von Datenschutzstandards verarbeitet werden müssen, ist die Analyse eingeschränkt
    • Weil man auf aggregierte Metriken angewiesen ist, gibt es keine Möglichkeit, Daten einer bestimmten Website präzise herauszugreifen
    • Auch aus den gesammelten Daten belastbare, umsetzbare Schlussfolgerungen zu ziehen, ist nicht einfach
  • Speedometer 3 ist die Arbeit an einem Performance-Test, der reale Nutzererfahrungen simuliert und Browsern hilft, Verbesserungen auf Grundlage realer Nutzer und realer Webseiten voranzutreiben

Verbesserungen bei Seitenaufbau und JavaScript-Ausführungszeit

  • Für die wahrgenommene Leistung beim Seitenladen ist First Contentful Paint ein geeigneterer Messwert als das onload-Ereignis
  • Gemessen wird die Zeit vom Empfang des ersten Bytes aus dem Netzwerk bis zum FCP
    • Dieser Wert zeigt, wie schnell Nutzer Rückmeldung erhalten, dass die Seite erfolgreich geladen wird
    • Die Webseite selbst hat großen Einfluss darauf, aber wenn sich die Gesamtleistung des Browsers verbessert, kann auch dieser Wert sinken
  • Die FCP-bezogene Zeit sank von etwa 250 ms zu Jahresbeginn auf 215 ms im Oktober
    • Nutzer erhalten Rückmeldung zum Seitenladen damit fast 15 % schneller als zu Jahresbeginn
    • Diese Verbesserung entstand aus Optimierungsarbeiten, die nicht direkt auf den Seitenaufbau abzielten
  • Die Ausführungszeit von JavaScript-Code während des Seitenladens wird anhand des 95. Perzentils verglichen
    • Diese Metrik zeigt, wie viel Spielraum es gibt, Reibung für Nutzer auf JavaScript-lastigen Seiten zu verringern
    • Sie sank von etwa 1560 ms zu Jahresbeginn auf etwa 1260 ms im Oktober
    • Der Rückgang um 300 ms, also fast 20 % Verbesserung, dürfte mit einem erheblichen Teil der verkürzten FCP-Zeit zusammenhängen
  • Die JavaScript-Engine SpiderMonkey erhielt im Zuge der Arbeit an Speedometer 3 erhebliche Optimierungen, was zu Verbesserungen bei der JavaScript-Ausführungszeit führte

Veränderungen bei der Eingabereaktionsfähigkeit

  • Die Reaktionsfähigkeit nach dem Seitenladen wird über die „keypress present latency“ gemessen
    • Das ist die Zeit vom Drücken einer Taste auf der Tastatur bis zu dem Moment, in dem das Ergebnis auf dem Bildschirm erscheint
    • Die Webseite kann zur Verarbeitung des keypress-Ereignisses JavaScript auf dem Main Thread ausführen, sodass mehr Arbeit anfällt als bei einfacher Textdarstellung
  • Die meisten Tippvorgänge sind schnell und hauptsächlich durch Hardware wie die Bildwiederholrate des Monitors begrenzt, doch langsame Eingabefälle beeinträchtigen die Nutzung deutlich
  • Weil es wichtig ist, die schlimmsten Fälle abzumildern, wird auch diese Metrik anhand des 95. Perzentils betrachtet
  • Die keypress present latency im 95. Perzentil lag den Großteil des Jahres bei etwa 65 ms und fiel nach den Firefox-Releases 116 und 117 im August auf unter 59 ms
    • In den langsamsten Fällen von Tastatureingaben wurde eine Verbesserung von etwa 10 % erreicht
    • Nutzer erleben beim Tippen unmittelbareres Feedback und weniger Unterbrechungen
  • Die Verbesserungen in der Telemetrie zeigen, dass die Performance-Arbeiten von 2023 für Firefox-Nutzer tatsächlich positive Effekte hatten und weiterhin Spielraum für zusätzliche Optimierungen besteht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-01
Meinungen auf Hacker News

  • Dass sich Firefox in letzter Zeit flotter anfühlt, lässt sich subjektiv bestätigen, und die Verbesserungen sind wirklich willkommen und zufriedenstellend.
    Allerdings habe ich bei der Messmethodik mit starker Anonymisierung ein etwas mulmiges Gefühl. Könnte es nicht auch daran liegen, dass das Web selbst schneller geworden ist oder dass die Leute bessere Hardware verwenden?
    Wenn stark frequentierte Websites besser optimiert werden und schlankere Versionen ausliefern, kann es in der Telemetrie so aussehen, als würde im Durchschnitt alles ein wenig schneller. Hardwarewechsel sowie Updates von Betriebssystemen und Treibern könnten denselben Effekt haben.

    • Ich habe lange eine alte Firefox-Version von 2020 genutzt und erst nach dem WebP-Sicherheitsproblem aktualisiert; die neue Version fühlte sich sofort schneller an.
    • Da auch ältere Firefox-Versionen noch im Einsatz sind, ließe sich vergleichen, ob die Verbesserung auf Updates von Firefox selbst zurückgeht oder darauf, dass das Web insgesamt schneller geworden ist.
    • Der einfachste Weg zu mehr Geschwindigkeit scheint zu sein, die Software unverändert zu lassen und Rechenleistung und Netzwerk immer weiter besser werden zu lassen.
      Historisch hat sich Software wie ein Gas verhalten: Sie füllt den verfügbaren Raum aus und verbraucht Ressourcen, die normalerweise nicht den Softwareautoren gehören.
      Software frisst nicht die Welt, sondern die Computerressourcen und Bandbreite, für die man monatlich bezahlt.
    • In den letzten sechs Monaten fühlte sich Firefox zunehmend wie ein schwergewichtiges Programm an, und wegen zufälliger Abstürze und Ruckler habe ich darüber nachgedacht, zu Chrome zu wechseln.
      Bis ich diesen Artikel gelesen habe, war mir das nicht bewusst, aber in letzter Zeit scheint dieses Gefühl verschwunden zu sein, und den Gedanken an einen Wechsel hatte ich bereits aufgegeben.
    • Das Web wird tatsächlich schneller. In weltweit aggregierten Kennzahlen zeigt sich ein langsamer, aber stetiger Abwärtstrend, und ich denke, das liegt zu einem großen Teil daran, dass Google Performance-Metriken und Suchranking miteinander verknüpft und damit Druck gemacht hat.
      Die Daten in diesem Artikel zeigen jedoch eine deutliche stufenweise Performance-Veränderung im Zusammenhang mit der Auslieferung neuer Browser-Versionen. Es wäre nicht ehrlich, die Performance-Arbeit des Firefox-Teams nicht anzuerkennen.

  • Es ist schön zu sehen, dass Mozilla tatsächlich Firefox verbessert, statt nur UI-Komponenten hin und her zu schieben.
    Als langjähriger Nutzer möchte ich den Underdog unterstützen, um das Kräfteverhältnis im Web wenigstens ein wenig zu erhalten. Es ist gut, dass Mozilla sich stärker auf Technik als auf Politik konzentriert, und ohnehin ist Firefox gute Software, über die ich mich kaum beschweren kann.

    • Ich finde es auch in Ordnung, dass Mozilla die UI immer wieder ändert. Wenn das mehr Nutzer bringt, ist es eine gute Sache, und Mozilla muss die Freiheit haben, Risiken einzugehen, wenn es nicht ständig nur einen Schritt hinterher sein will.
      FirefoxOS war zum Beispiel wohl ein Fehlschlag, aber die meisten großen Wagnisse scheitern nun einmal. Wenn man sich solche langfristigen Wetten spart, merkt man wie Microsoft irgendwann zu spät, dass viele junge Leute heute nicht einmal mehr einen Laptop haben und auf ihren Smartphones natürlich kein Windows läuft. Ich fände es in Ordnung, wenn es mehr Projekte wie FirefoxOS gäbe.
    • Wichtig ist nicht nur, sich auf Technik zu konzentrieren, sondern auch auf das Produkt, also Firefox.
      Man könnte behaupten, sich nur auf Technik zu konzentrieren, und trotzdem alle Ressourcen in Firefox OS stecken.
    • Ich stimme zu, den Underdog zugunsten des Kräftegleichgewichts im Web zu unterstützen, und nachdem ich vor ein paar Jahren gewechselt bin, bin ich mit dem Umstieg tatsächlich zufrieden.

  • Seit dem Upgrade auf 118 friert Firefox alle paar Tage zufällig ein. Es liegt weder an CPU noch Swap, aber alle Fenster hängen, killall firefox ist nötig, und trotzdem beendet sich Firefox sauber.
    Wegen Suchmaschinen-Spam ist es schwer, relevante Informationen zu finden, und bis 118 lief es jahrelang problemlos. Es passiert zu selten, um sinnvoll mit deaktivierten Erweiterungen oder einem neuen Profil zu reproduzieren; vermutlich muss ich es einfach hinnehmen.

    • Ich bin Firefox-Entwickler. Je nach Umgebung gibt es einige Diagnosemöglichkeiten. Wenn unter Linux alles einfriert, liegt das Problem wahrscheinlich im Parent-Prozess, dem obersten Prozess, der die Tabs verwaltet.
      Wenn der Crash-Reporter aktiviert ist, kann man dem Parent-Prozess SIGABRT senden; nach dem Neustart erscheint dann unter about:crashes ein Eintrag, den man einreichen kann.
      Wenn man die Firefox-Version der Distribution nutzt und gdb sowie debuginfod verfügbar sind, kann man gdb an den Firefox-Parent-Prozess anhängen, die Symbole laden und anschließend thread all apply bt ausführen, um die Stacks aller Threads des Parent-Prozesses zu dumpen.
      Wenn man einen Mozilla-Build verwendet, kann man https://firefox-source-docs.mozilla.org/toolkit/crashreporte... nutzen, um den eigenen Symbolserver einzubinden. Je nach Distribution kann das auch mit dem Firefox der Distribution funktionieren oder eben nicht.
      Wenn Crash-Informationen vorliegen, kann man sie im Bugtracker der Distribution oder unter https://bugzilla.mozilla.org/enter_bug.cgi?product=Core einreichen und relevante Informationen wie Stack, Firefox-Version, Crash-Report und about:support anhängen.
      Solche Hänger unter Linux sind oft Bugs zwischen Firefox und der Desktop-Umgebung oder Probleme mit dem Grafiktreiber; mit einem Stack lässt sich die Ursache stark eingrenzen. Manchmal reicht auch ein Paket-Update oder eine einzelne Einstellung, um es zu beheben.
    • Bei Brave hatte ich auf zwei Computern ähnliche Symptome, und das Deaktivieren der Hardwarebeschleunigung hat es gelöst. Beide hatten Intel-Grafik.
    • Ich frage mich, ob du eine Linux-Distribution nutzt, die nicht Stable oder eine Long-Term-Support-Version ist.
      Die Beschwerden über Firefox-Instabilität, die man auf HN sieht, scheinen meist von Windows-Nutzern zu kommen oder von Linux-Nutzern, die außerhalb des Distributions-Packagings die neueste Version installieren. Dagegen habe ich bei jahrelanger Nutzung von Firefox aus Debian Stable nie die Bugs erlebt, die in solchen Threads beschrieben werden.
    • Falls es beim Tippen passiert, könnte es https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 sein. Ich bin ebenfalls von diesem Bug betroffen, bin aber bisher nicht auf die Idee gekommen, nach dem Ticket zu suchen.
      Zum Reproduzieren müsste man wohl das unveränderte Mozilla-Binary ausprobieren.

  • Gute Nachrichten, und ich bekomme wieder Lust, es noch einmal auszuprobieren
    Ich habe Firefox fast 20 Jahre lang genutzt, seit den Phoenix-/Firebird-Zeiten mit der Installationsmethode „irgendwo entpacken“, bin aber wegen des spürbaren Geschwindigkeitsunterschieds zu einem Chromium-basierten Browser gewechselt
    Ich habe keine Benchmarks laufen lassen, um meinen Verdacht zu überprüfen, und auch nicht gemessen, welche Aktion in Firefox wie viele Millisekunden langsamer ist. Aber bei einem Werkzeug, das man inklusive Arbeit jeden Tag den ganzen Tag nutzt, merkt man so etwas leicht
    Angesichts mehrerer aktueller Berichte zu Performance-Verbesserungen und realer Nutzungsmetriken überlege ich, es ein paar Tage lang wieder auszuprobieren. Wenn ich keinen Unterschied merke oder es sich tatsächlich schneller anfühlt, werde ich zurückwechseln
    Der Grund, warum ich zurückmöchte: Es braucht unbedingt eine alternative Browser-Engine. Ich möchte nicht, dass Standardisierungsgremien zu Veranstaltungen werden nach dem Motto: „Dieses Jahr hat Google entschieden, dass man es so macht“

    • Gute Performance plus hervorragende Add-ons wie Multi Account Containers und Tree Style Tabs ergeben einen ausgezeichneten Browser

  • Die Killer-Funktion von Firefox ist weiterhin, dass er Flexibilität beim Tab-Management zulässt. Dank Sidebery und TreeStyleTab bleibe ich weiterhin im Firefox-Ökosystem
    Wenn man viele Tabs ansammelt oder Tabs wie eine Aufgabenliste verwendet, ist die Erfahrung so überwältigend besser, dass ich mir kaum vorstellen kann, etwas anderes zu nutzen
    Auch unter Android nutze ich Firefox, weil es dort Add-ons wie uBlock Origin und Dark Reader gibt. Das macht mobiles Web-Browsing deutlich besser. Ich bin Firefox selbst nicht besonders loyal; ich habe nur keinen Chromium-basierten Browser gefunden, der so gut zu mir passt

    • Die integrierten vertikalen Tabs in Edge sind ebenfalls ziemlich gut. Sie sind nicht besonders funktionsreich – im Wesentlichen vertikale Tabs mit automatischem Entladen und Tab-Gruppen –, dafür aber sehr stabil und fast fehlerfrei
    • Als jemand, der viele Tabs ansammelt, brauche ich Auto Tab Discard. Es legt ungenutzte Hintergrund-Tabs schlafen, damit sie keine Ressourcen fressen
      Außerdem gefällt mir, dass man die Tab-Leiste per CSS zum Beispiel in drei scrollbare Zeilen verwandeln kann
    • Ich frage mich, ob ihr bei TreeStyleTab die oberen Tabs entfernt habt oder ob ihr beides gleichzeitig auf dem Bildschirm habt
      Auf kleinen Bildschirmen hatte ich das Gefühl, dass man mit beidem ziemlich viel Bildschirmfläche verliert
    • Ich habe beides ausprobiert, aber am Ende gefielen mir die Safari-Tabgruppen, die nahtloser in das Browser-Erlebnis integriert sind, besser

  • Ich nutze Firefox seit Jahren als Hauptbrowser, und er war sehr gut. Vielleicht liegt es daran, dass ich ihn meist auf leistungsstarker Hardware laufen lasse, aber unter Linux, Windows und Mac hatte ich kaum Beschwerden

    • Bei mir genauso, obwohl ich keine leistungsstarke Hardware nutze. Alle Geräte, die ich täglich verwende, sind über fünf Jahre alt, aber mit der Kombination Firefox + uBlock Origin bin ich vollkommen zufrieden
    • Ich nutze ihn seit Jahren und stimme dem fast vollständig zu; Probleme hatte ich nur mit den Developer Tools
      Beim Öffnen großer JS-Dateien wird der Debugger ziemlich langsam, und Source Maps verstärken diese Langsamkeit noch. Mit Source Maps kann ich Variablenwerte auch nicht immer zuverlässig inspizieren; das könnte allerdings auch an der Konfiguration des Build-Tools liegen

  • In Speedometer 2 ist Firefox deutlich langsamer als Chrome, und Chrome ist etwas langsamer als Edge. Trotzdem sehe ich im Alltag keinen großen Unterschied
    Ich respektiere und vertraue Mozillas Datenschutz. Container sowie die Möglichkeit, Ublock und Tampermonkey auf Mobilgeräten auszuführen, sind kaum mit Geld aufzuwiegen

    • Für Menschen mit leistungsschwachen Computern ist das weiterhin wichtig. Auf Reisen ging der Bildschirm meines MacBooks kaputt, und ich kaufte notgedrungen ein Notebook mit Celeron 6305 und 4 GB RAM. Wie üblich installierte ich Firefox, aber er war so langsam und ruckelig, dass er unbenutzbar war
      Nach dem Wechsel zu Edge war es deutlich schneller und nutzte auch weniger von den 4 GB RAM. Ich hätte nicht gedacht, dass der Unterschied so groß sein würde, aber er war nicht zu leugnen; auf Low-End-PCs läuft Edge deutlich besser als andere Browser
    • Die großen Browser scheinen inzwischen alle schnell genug zu sein. Ich fände es gut, wenn nun stärker auf geringeren Stromverbrauch fokussiert würde
    • Dazu gibt es auch https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
    • Bei einer 75-Mbps-Verbindung lädt Firefox alles, was ich brauche, sofort
      Da frage ich mich, welche Bedeutung Benchmarks überhaupt haben

  • Ich glaube, dass das Firefox-Team weiß, was es in Sachen Performance tut, und die richtigen Schlüsse gezogen hat
    Ein kleiner Wermutstropfen ist nur, dass ich zur Kontrolle von Saisoneffekten auch gern die Performance-Veränderung gegenüber demselben Zeitraum im Vorjahr gesehen hätte. Bild 1 zeigt Veränderungen im Hundertstelsekundenbereich; bei Signalen dieser Größenordnung scheint mir Rauschkontrolle umso wichtiger
    Nebenbei: Ich bin ein zufriedener Firefox-Nutzer

    • Ist das nicht arewefastyet?
      https://arewefastyet.com/
      Außerdem gibt es https://wiki.mozilla.org/Areweyet
    • Ich frage mich, welche Saisoneffekte hier angenommen werden. Ich kenne mich im Bereich Browser-Performance nicht gut aus und weiß daher nicht, ob sich die Zusammensetzung der Webtechnologien, die Menschen konsumieren, je nach Jahreszeit wirklich verändert
      Naiv betrachtet wirkt der Trend hier konsistent, und das Signal scheint größer zu sein als die Streuung. Es sieht nach dem Ergebnis kluger Ingenieure aus, die diese Metrik über den Messzeitraum hinweg optimiert haben
      Gleichzeitig stimme ich zu, dass eine längere Zeitachse wünschenswert wäre. Die große Verbesserung im August könnte ja nicht daran liegen, dass Firefox 116 am 1. August erschienen ist, sondern daran, dass Menschen auf der Nordhalbkugel in der Urlaubszeit leichtere Lektüre lesen

  • Wer wegen des gefühlten Tempos bei Chromium-basierten Browsern geblieben ist, sollte zumindest Firefox einmal ausprobieren.
    Ich nutze ihn derzeit so gut, dass ich nicht daran denke, zurückzuwechseln, und für die Zukunft des Webs ist es wirklich wichtig, dass Browser-Vielfalt stark erhalten bleibt.

    • Ich nutze Brave, nachdem ich Rewards, VPN und Wallet abgeschaltet und etwa 20 Flags geändert habe. Für mich ist er schneller, unterstützt Erweiterungen besser, hat weniger Bugs und verbraucht bei wenigen Tabs auch weniger Speicher. Ich habe mich für Brave entschieden, weil Synchronisierung möglich ist.
      Firefox war ebenfalls beeindruckend, und ich habe auch einen Fork namens Floorp ausprobiert. Er hat einige nützliche Zusatzfunktionen, unterstützt Synchronisierung und fühlte sich für mich besser an als der normale Firefox. Früher habe ich ungoogled-chromium genutzt.
      https://github.com/Floorp-Projects/Floorp/releases
      Leider funktionieren manche Websites meiner Erfahrung nach weiterhin besser in Chromium-Browsern. Anekdotisch habe ich bei Google-eigenen Websites auch so etwas wie negatives Fingerprinting gegenüber Firefox gespürt, und es scheint auch mehr Memory Leaks zu geben. Wegen Manifest V3 werde ich am Ende wohl zu Firefox wechseln, aber vorerst bleibe ich bei Brave.

  • Ob es besser geworden ist, weiß ich wirklich nicht, aber es gibt zwei Probleme, die einfach nicht endgültig gelöst werden.
    Erstens verhält sich Hardware-beschleunigtes Videodecoding bei VP9-Videos seltsam. Selbst wenn ich es abschalte oder AV1 erzwinge, ruckelt es gelegentlich.
    Zweitens friert kWin ein, wenn ich in einer Hybrid-Grafikumgebung beim Spielen im Hintergrund ein Video laufen lasse; das im Browser abgespielte Video wird grün, und alles, was die iGPU oder dGPU nutzt, stottert massiv. Am Ende muss ich mich ausloggen und wieder einloggen, um die Sitzung manuell neu zu starten.
    Das zweite Problem könnte an Nvidia Prime Offload unter Wayland liegen. Es ist zwar meine Schuld, eine Nvidia-Karte zu haben, aber ich habe in Bugzilla kein bereits ungelöstes passendes Thema gefunden, und ehrlich gesagt habe ich etwas Angst, es zu melden und dann mit bohrenden Rückfragen konfrontiert zu werden. Ich würde gern weiter debuggen, habe aber keine Geduld dafür.
    Es reicht nicht, um Firefox zu verlassen, aber es sind zwei langwierige Ärgernisse. Trotzdem Glückwunsch an das Team. Heute habe ich 5 Leute erfolgreich zu Firefox gebracht.

    • Hardware-Decoding unter Linux ist leider ein ziemliches Durcheinander. Bei den meisten dieser Probleme dürfte Firefox korrekt mit den verschiedenen Video-Coding-APIs zusammenarbeiten, während eher irgendwo auf der Treiberseite ein Bug steckt.
      Auf einem Desktop kann es sich lohnen, Hardware-Videodecoding komplett zu deaktivieren.
    • Tipp: Es gibt eine Firefox-Erweiterung, die YouTube dazu zwingt, H.264 zu verwenden.
      Mein Gerät unterstützt VP9-Hardwarebeschleunigung, aber sie war unzuverlässig; nach dem Wechsel auf H.264 liefen YouTube-Videos flüssig. Andere Videoseiten verwenden standardmäßig H.264, daher braucht man das praktisch nur für YouTube.
    • Das zweite Problem macht einen wirklich wahnsinnig. Jahrelang hatte ich auf dem zweiten Monitor YouTube- oder Twitch-Streams offen, aber jetzt habe ich ständig Frame-Drops, Videoruckler und Hänger.
      Das ist eine wirklich seltsame Performance-Regression.