2023年、実ユーザー環境でさらに高速になった Firefox
(hacks.mozilla.org)- Firefox は2023年の最適化作業以降、ベンチマークだけでなく実ユーザーのテレメトリでも ページ読み込み、入力応答性、JavaScript 実行時間が改善
- Mozilla は他のブラウザとともに Speedometer 3 を推進しており、実際の Web ページでユーザーが感じる性能をよりよく反映するテストを作っている
- 最初のバイト受信から First Contentful Paint までの時間は、年初の約250msから10月には215msへ短縮され、読み込みフィードバックがほぼ15%速くなった
- ページ読み込み中の JavaScript 実行時間の95パーセンタイルは約1560msから約1260msへ300ms短縮され、SpiderMonkey の最適化がこの改善と関連している
- Firefox 116・117リリース以降、遅いキー入力の遅延も約65msから59ms未満へ下がり、タイピング中の引っかかりを減らす 10%の改善 が見られた
実ユーザー性能の測定が難しい理由
- Firefox はサードパーティコードを実行する複雑なクライアントソフトウェアであるため、管理された実験室の指標だけで実ユーザー体験の変化を判断するのは難しい
- ブラウザ性能を見るには、ページ読み込み、応答性、起動時間のような 匿名化されたタイミング指標 が必要
- プライバシー保護基準を維持しながらデータを扱う必要があるため、分析には制約が伴う
- 集計指標に依存するため、特定の Web サイトのデータを正確に特定する機能はない
- 収集データから実行可能な結論を引き出すことも容易ではない
- Speedometer 3 は実ユーザー体験をシミュレートする性能テストを作り、ブラウザが実ユーザーと実際の Web ページを基準に改善を進められるよう支援する取り組み
ページ読み込みと JavaScript 実行時間の改善
- ページ読み込みの体感性能には、
onloadイベントよりも First Contentful Paint がより適した指標として使われる - 測定基準は、ネットワークから 最初のバイト を受け取った時点から FCP までにかかった時間
- この値は、ページが正常に読み込まれているというフィードバックをユーザーがどれだけ早く受け取れるかを示す
- Web ページ自体の影響も大きいが、ブラウザ全体の性能が向上すればこの数値は下がり得る
- FCP 関連の時間は、年初の約250msから10月には215msへ減少
- ユーザーがページ読み込みのフィードバックを受け取る速度が、年初よりほぼ 15%速くなった
- この改善は、ページ読み込みを直接狙ったものではない最適化作業から生まれた
- ページ読み込み中の JavaScript コード実行時間は、95パーセンタイル基準で比較された
- この指標は、JavaScript の多いページでユーザーの摩擦を減らす余地を示す
- 年初の約1560msから10月には約1260msへ短縮
- 300ms、ほぼ 20%の改善 であり、FCP 時間短縮のかなりの部分と関連している可能性がある
- SpiderMonkey JavaScript エンジンは Speedometer 3 の取り組みを通じて大幅な最適化を受け、JavaScript 実行時間の改善につながった
入力応答性に見られた変化
- ページ読み込み後の応答性は「keypress present latency」で測定される
- キーボードでキーを押した時点から、その結果が画面に表示される時点までの時間
- Web ページが keypress イベントに対応するためにメインスレッドの JavaScript を実行する場合があり、単純なテキスト描画よりも多くの処理が関与する
- ほとんどのタイピングは高速で、主にモニターのリフレッシュレートのようなハードウェアに制限されるが、遅い入力ケースはユーザー体験を大きく妨げる
- 最悪のケースを緩和することが重要なため、この指標も 95パーセンタイル を基準に見る
- 95パーセンタイルの keypress present latency は年内の大半で約65msだったが、8月の Firefox 116・117 リリース以降、59ms未満へ低下
- 最も遅いキー入力ケースで約 10%改善
- ユーザーはタイピング中、より即時的なフィードバックと少ない妨げを体験できる
- テレメトリの改善は、2023年の性能向上作業が Firefox ユーザーに実際にポジティブな効果をもたらし、さらに最適化の余地も残っていることを示している
1件のコメント
Hacker News のコメント
最近 Firefox がよりキビキビした感じになったことは主観的にも確認でき、改善点は本当にありがたく満足している
ただ、強い匿名化が入った測定方法論には少しもやもやするところがある。ウェブ自体が速くなったり、人々がより良いハードウェアを使うようになった影響かもしれないのでは、と思う
訪問者の多いサイトがより最適化され、軽量版を配布するようになれば、テレメトリ上は平均してすべてが少し速くなったように見える可能性がある。ハードウェアの買い替え、OS・ドライバーのアップデートも同じかもしれない
歴史的にソフトウェアは気体のように振る舞い、空間を満たしてリソースを食いつぶしてきた。そしてそのリソースはたいてい、ソフトウェアを書く人のものではない
ソフトウェアが世界を食べているのではなく、毎月お金を払っているコンピューター資源と帯域幅を食べている
この記事を読むまでは意識していなかったが、最近はその感じが消えたようで、すでに乗り換える考えも止まっていた
しかしこの記事のデータは、ブラウザーのバージョン配布と連動した明確な段階的な性能変化を示している。Firefox チームのパフォーマンス改善の努力を認めないのは誠実ではない
Mozilla が UI コンポーネントをあちこち動かすだけでなく、実際に Firefox を改善しているのを見るのは良い
長年のユーザーとして、ウェブの力の均衡を少しでも保つために弱い側を応援したい。Mozilla が政治より技術により集中するのは良いことで、いずれにせよ Firefox は良いソフトウェアなので大きな不満はない
例えば FirefoxOS は失敗だったように思うが、そもそも大きな挑戦の大半は失敗する。そういう長期的な挑戦を惜しんでいると、Microsoft のように、最近の子どもたちの中にはノート PC すら持たず、スマホで Windows が動くのは当然ではないという状況に後から気づくことになる。FirefoxOS のようなプロジェクトがもっとあってもいいと思う
技術にだけ集中すると言いながら、全リソースを Firefox OS に注ぎ込むこともあり得る
118 にアップグレードしてから、数日に一度 Firefox がランダムに固まる。CPU やスワップの問題ではないのに全ウィンドウがフリーズし、
killall firefoxが必要になる。それでも Firefox はきれいに終了する検索エンジンのスパムのせいで関連情報を探すのも難しく、118 以前は何年も問題なかった。あまりにまれなので、拡張機能の無効化や新規プロファイルといった再現実験も難しく、ただ受け入れるしかなさそうだ
クラッシュレポーターが有効なら、親プロセスに
SIGABRTを送ればよく、再起動後にabout:crashesに項目が作成され、送信できますディストリビューション版 Firefox を使っていて
gdbとdebuginfodがあるなら、Firefox の親プロセスにgdbをアタッチし、シンボルを取得したうえでthread all apply btを実行すると、親プロセスの全スレッドのスタックをダンプできますMozilla ビルドを使っているなら、https://firefox-source-docs.mozilla.org/toolkit/crashreporte... を使って独自のシンボルサーバーと連携できます。ディストリビューションによっては、ディストリビューション版 Firefox でもできる場合とできない場合があります
クラッシュ情報ができたら、ディストリビューションのバグトラッカーか https://bugzilla.mozilla.org/enter_bug.cgi?product=Core に、スタック、Firefox バージョン、クラッシュレポート、
about:supportなど関連情報を添えて投稿すればよいですLinux でのこうしたフリーズは、Firefox とデスクトップ環境の間のバグやグラフィックドライバーの問題であることが多く、スタックがあれば原因をかなり絞り込めます。時にはパッケージ更新や設定一つで解決することもあります
HN で見かける Firefox の不安定性への不満は、たいてい Windows ユーザーか、ディストリビューションのパッケージング外で最新版を入れている Linux ユーザーから出ているように思う。一方で Debian 安定版の Firefox を何年も使っているが、こうしたスレッドで描写されるバグを経験したことはない
再現するには素の Mozilla バイナリを使ってみる必要がありそうだ
良いニュースで、また使ってみたくなる
Phoenix/Firebird 時代の「どこかに展開する」インストール方式の頃からほぼ20年使ってきたが、体感速度の差で Chromium ベースのブラウザに移った
疑いを確認するためにベンチマークを回したり、Firefox でどの動作が何ミリ秒遅いのかを測ったりはしなかったが、仕事を含めて毎日一日中使う道具なら、体感は生まれやすい
最近の複数の性能改善レポートと実利用指標を見ると、数日また使ってみる気になった。違いを感じないか、実際により速く感じるなら戻るつもり
戻りたい理由は、代替ブラウザエンジンがどうしても必要だから。標準化委員会が「今年は Google がこうしろと決めた」という類のイベントになるのは望まない
Firefox のキラー機能は、今でもタブ管理の柔軟性を許している点だ。Sidebery と TreeStyleTab のおかげで、Firefox エコシステムに居続けている
タブを大量に積んでおいたり、タブを ToDo リストのように使うスタイルでは、体験が圧倒的に良く、他のものを使っている自分を想像しにくい
Android でも uBlock Origin と Dark Reader のアドオンがあるので Firefox を使っている。モバイルでのウェブ閲覧がずっと良くなる。Firefox 自体への忠誠心が強いわけではなく、自分にここまで合う Chromium ベースのブラウザを見つけられていないだけ
それに CSS でタブバーを、たとえばスクロール可能な3行に変えられる点も良い
小さい画面で両方あると、画面スペースをかなり失う感じがした
Firefox を何年もメインブラウザとして使ってきて、とても良かった。主に高スペック機で動かしているからかもしれないが、Linux、Windows、Mac のいずれでも特に不満はなかった
大きな JS ファイルを開くとデバッガがかなり遅くなり、ソースマップはその遅さをさらに大きくする。ソースマップを使うときに変数値を常に検査できない場合もあるが、ビルドツールの設定の問題かもしれない
Speedometer 2 では Firefox は Chrome よりずっと遅く、Chrome は Edge より少し遅い。それでも実生活では大きな差はないと思う
Mozilla のプライバシー保護を尊重し、信頼している。コンテナ、モバイルで Ublock と Tampermonkey を動かせる機能は、値段を付けがたい
Edge に替えるとずっと速く、4GB RAM の使用量も少なかった。差がここまで大きいとは思わなかったが否定できず、低スペックPCでは Edge が他のブラウザよりはるかによく動く
ベンチマークに何の意味があるのかと思う
Firefox チームが性能について何をしているかは分かっているし、正しい結論に達したと信じている
ただ些細に惜しい点として、季節効果をコントロールするために、前年同時期比の性能変化も見たかった。画像1は 1/100 秒単位の変化なので、この程度のシグナルを見るときはノイズの制御がより重要に見える
付け加えると、Firefox には満足しているユーザーだ
https://arewefastyet.com/
さらに https://wiki.mozilla.org/Areweyet もある
素朴に見ると、この傾向は一貫していて、シグナルは分散より大きく見える。測定期間中に優秀なエンジニアたちがその指標を最適化した結果のように見える
同時に、長い時間軸があればよいという点には同意する。8月の大きな改善が、Firefox 116 が8月1日に出たおかげではなく、北半球の人々が休暇シーズンにより軽い読み物を見ていた影響だった可能性もあるから
速度の体感差が理由でChromiumベースのブラウザに張り付いている人なら、少なくとも一度Firefoxを試してみるとよいと思う
最近はもう戻る気が起きないほど快適に使えているし、Webの未来のためにもブラウザの多様性が強く保たれることは本当に重要
Firefoxも印象的だったし、Floorpというフォークも試した。いくつか便利な追加機能があり、同期をサポートしながら通常のFirefoxよりよいと感じた。以前はungoogled-chromiumを使っていた
https://github.com/Floorp-Projects/Floorp/releases
残念ながら自分の経験では、一部のWebサイトはいまだにChromiumブラウザのほうがうまく動く。逸話的ではあるが、Google所有のサイトでFirefoxに対するネガティブなフィンガープリンティングのようなものも感じるし、メモリリークもより多い気がする。Manifest V3のせいで最終的にはFirefoxに乗り換えることになりそうだが、今のところはBraveに留まるつもり
よくなったのかは本当にわからないが、どうしても解決されない問題が2つある
1つ目は、VP9動画でハードウェアアクセラレーションによる動画デコードが妙な動きをすること。オフにしたりAV1を強制したりしても、時々カクつく
2つ目は、ハイブリッドグラフィックス環境でバックグラウンドに動画を流しながらゲームをすると、kWinが固まり、ブラウザで再生中だった動画が緑色になり、iGPUやdGPUを使うものすべてがひどくカクつくこと。結局ログアウトして再ログインし、セッションを手動で再起動しなければならない
2つ目はWayland上のNvidia prime offloadが原因かもしれない。Nvidiaカードを持っている自分が悪いのだが、Bugzillaで未解決の関連トピックはまだ見つけられていないし、正直、報告して詰問されるのが少し怖い。もっとデバッグしたいが、忍耐力がない
Firefoxを離れるほどではないが、長く続いている悩みの種が2つある。とはいえチームには祝福を送りたい。今日、5人をFirefoxへ移行させることに成功した
デスクトップなら、ハードウェア動画デコードを完全にオフにしてみるのも試す価値がある
自分のデバイスはVP9のハードウェアアクセラレーションに対応しているが信頼性が低く、H.264に変えるとYouTube動画が滑らかに再生された。他の動画サイトは基本的にH.264を使うので、実質的にはYouTubeにだけ必要
本当に妙な性能リグレッションだ