当ブログでは、Firefoxの延長サポート版（ESR）のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 60のパフォーマンスをFirefox 52およびChrome 66と比較する。
検証を行った具体的なバージョンを挙げると、32bit版Firefox 52.7.4（ビルドID：20180427222832）、64bit版Firefox 60.0 RC2（ビルドID：20180503143129）、それに64bit版Chrome 66（バージョン：66.0.3359.139）である。Firefox Quantumのリリースに伴ってマルチプロセス機能（e10s-multi）が全面的に有効化され、その前に64bit版への移行も開始された。今回のテストではそれらの点が反映されている。
動作環境についてだが、OSは64bit版Windows 10 Professional（Fall Creators Update）で、使用したハードウエアは、CPUがIntel Core i7-7500U CPU 2.70GHz、GPUがIntel HD Graphics 620（ドライバのバージョン：21.20.16.4542）、メモリ容量が16.0GB、ストレージがWestern Digital製SATA-IIIのHDDである。GPU描画支援はDirect3D 11、Direct2D 1.1とDirectWriteをバックエンドに使用している。
測定にあたってブラウザごとに新規プロファイルを用意し、拡張機能のインストールは行わず、テストの中断を防ぐためFirefoxではdom.max_script_run_timeの値を0に設定した。プラグインは、初期設定でインストール・有効化されるものはそのままにして、Shockwave Flash 29.0 r0を有効化している（Firefox 60では「実行時に確認する」の設定）。なお、Firefox 52ではフォントの設定をメイリオに変更した。
測定の際にはTurbo Boost機能を無効化し、定格の動作周波数でPCを動作させた。画面サイズは3840×2160で、表示を250％に拡大しており、測定時のウィンドウは最大化された状態である。なお、各ベンチマークの実行後はブラウザを終了させて、メモリ上に前のベンチマークが残らないようにした。
最後に、対象となるベンチマークは、前回の記事で用いたものから一部を入れ替えた。
ページの読み込み速度およびメモリ使用量
10のWebサイトを同時に開いて、読み込み中であることを示すアイコン（throbber）が消えるまでの時間を手動で計測した。秒数の小数点以下は切上げている。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。
具体的な手順は次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル（FirefoxはJSON形式、ChromeはHTML形式）をインポートし、「タブですべて開く」で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefoxのホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia（日本語版）になる。
- 日本マイクロソフト / 食べログ / 郵便局
- Amazon.co.jp / YouTube / NHKオンライン / 日経電子版
- はてなブログ / Yahoo! JAPAN / Wikipedia（日本語版）
1分間そのまま放置した後、Firefoxでは新しいタブを開いてabout:performanceを呼び出し、"Memory usage of Subprocesses"欄に表示される、Parentつまり親プロセスのResident Set Sizeの値と、その他子プロセスの各Unique Set Sizeの値を合算する*1。Chromeではメニューの「その他のツール」から「タスク マネージャ」を選択して、各タスクのメモリ使用量を合算する*2。
そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。5分間*3そのまま放置した後、再び新しいタブを開き、上記の手順でメモリ使用量を数値を合算する。ブラウザをいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果を以下に示す。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| 読込時間（1回目） | 57 秒 | 15 秒 | 16 秒 |
| 読込時間（2回目） | 23 秒 | 15 秒 | 8 秒 |
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| 使用メモリ(10タブ) | 641.0 MB | 1011.5 MB | 970.5 MB |
| 使用メモリ(単タブ) | 459.0 MB | 600.5 MB | 222.7 MB |
対象としたサイトとの相性が悪いのか、Firefox 52は1回目の読み込みにやたらと時間がかかった。日経電子版のリダイレクト処理が影響したとみられる。Firefox 60とChrome 66は、1回目の読み込みに関しては互角だが、2回目で差がつきChromeが最速となった。
メモリ使用量に関し、FirefoxとChromeでは測定方法が違うため、比較は難しい。だが、少なくとも拡張機能をインストールしない状態では、Firefoxのほうが省メモリだと言えるだけの根拠は見いだせなかった。Chromeはタブを閉じた後のメモリの解放がスムーズに行われている印象である。
ストレージ
HTML5 Offline Storage Benchmarkは、オフラインストレージの性能を計測するベンチマークだ。localStorage、WebSQLおよびIndexedDBを対象にできるが、ここではIndexedDBの結果（主に1ミリ秒あたりに処理されたオペレーション数）を掲載する。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Clear | 22.00 ms | 14.00 ms | 59.40 ms |
| Inject-L | 2.08 op/ms | 2.50 op/ms | 0.12 op/ms |
| Inject-S | 2.27 op/ms | 2.94 op/ms | 0.14 op/ms |
| InjectBulk-L | 1.12 op/ms | 4.82 op/ms | 3.06 op/ms |
| InjectBulk-S | 6.54 op/ms | 5.03 op/ms | 2.97 op/ms |
| Lookup | 1.67 op/ms | 6.25 op/ms | 1.15 op/ms |
| Lookup2 | 6.37 op/ms | 7.78 op/ms | 3.55 op/ms |
ほとんどの項目でFirefox 60はFirefox 52を上回る成績を残し、Chrome 66を圧倒している。
レイアウトおよび描画処理
HTML5 Canvas
CanvasMark 2013 version 1.1は、HTML5ゲームでよく使用される処理（ビットマップ、Canvas描画、αブレンディングなど）に対するレンダリング・パフォーマンスをテストする。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| CanvasMark Score | 8583 | 9449 | 9107 |
Firefox 60のスコアはFirefox 52から1割アップし、Chrome 66を超えた。
WebGL
Microsoft Edge TestDrive demosからFishGLをピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定する。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| 秒間フレーム数 | 10 fps | 8 - 9 fps | 11 fps |
ほとんど差がつかなかったが、Firefox 60のフレームレートが若干落ち込んでいるのは気になるところだ。
次に、Unity WebGL Benchmarks 2015年版での結果を見てみよう。このベンチマークは、Unityの開発したグラフィックスエンジンが一定時間内にどの程度のタスクを処理できるかをテストするものだ。Unity Blogの記事によれば、Unity 5.3がベースになっているという。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Overall Score | 44228 | 55864 | 50612 |
CanvasMark 2013と似たような傾向にあるが、こちらはFirefox 60のスコアがFirefox 52比で26％アップと伸びが大きい。
総合
MotionMark 1.0は、WebKitチームが提供するベンチマーク・スイートであり、複雑なシーンを目標フレームレートでアニメーションさせる能力を測定する。描画処理を中心とするものの、その他の能力も問われる重いテストである。画面サイズがMedium（900 x 600）の場合の結果は、以下のようになった。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Score | 97.20 ± 6.73% | 109.28 ± 4.04% | 85.75 ± 19.13% |
| Multiply | 118.75 ± 2.18% | 85.78 ± 3.54% | 222.35 ± 6.36% |
| Canvas Arcs | 697.07 ± 2.56% | 802.59 ± 2.72% | 284.88 ± 1.78% |
| Leaves | 141.80 ± 2.04% | 183.82 ± 2.24% | 283.17 ± 24.88% |
| Paths | 2281.46 ± 2.46% | 2467.31 ± 3.62% | 820.63 ± 1.85% |
| Canvas Lines | 1708.67 ± 2.36% | 2037.31 ± 1.77% | 4288.82 ± 1.74% |
| Focus | 6.21 ± 4.04% | 8.93 ± 3.41% | 39.00 ± 5.13% |
| Images | 13.56 ± 2.90% | 16.61 ± 2.71% | 25.46 ± 6.52% |
| Design | 6.00 ± 33.33% | 7.48 ± 14.33% | 2.00 ± 100.00% |
| Suits | 33.47 ± 3.31% | 31.50 ± 6.11% | 2.00 ± 50.00% |
Firefox 60は、おおむねFirefox 52を上回る成績を収めている。グラフィックス関連の性能が、負荷のかかる状態で1割から2割程度アップしているのは間違いなさそうだ。これに対し、Chrome 66は今ひとつである。
JavaScript/DOM処理
Speedometer 2.0は、WebKitチームが提供するベンチマーク・スイートで、さまざまな手法によりDOM APIを酷使し、Webアプリの応答性をテストする。バージョン2.0では最新のJavaScriptフレームワークや言語仕様をサポートしたほか、スコアの算出方法も変更した。
GoogleのV8チームはOctaneベンチマークを引退させて、Speedometer 2.0の開発に参加しており、実環境のパフォーマンスを反映したスコアが出ると太鼓判を押している。MozillaもFirefox Quantumのリリースにあたり、Quantum Flowプロジェクトにおいてこのスコアを重視した。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Runs / Minute | 24.4 ± 0.41 | 46.7 ± 0.87 | 57.6 ± 0.64 |
Firefox 60はFirefox 52の倍近いスコアを叩き出しており、Quantum Flowの成果が十分に認められる。それでもChrome 66には及ばないが、差を縮めていくことは可能だろう。
JetStream 1.1は、WebKitチームが提供するベンチマーク・スイートで、SunSpider 1.0.2やOctane 2.0からも一部のベンチマークを取り入れ、スループットとレイテンシを計測する。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Score | 123.48 ± 31.101 | 134.95 ± 11.652 | 127.95 ± 3.0543 |
Firefox 60がChrome 66を上回る最高のスコアを示した。
新たに加わったARES-6 1.0.1は、WebKitチームが提供するベンチマーク・スイートで、JavaScriptの最新機能に焦点を当てて、その処理時間を計測する。起動が高速かつ処理が滑らかであれば、良い結果が出るように設計されており、結果のばらつきの大きさもスコアに反映される。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Overall | 163.88 ± 2.35ms | 93.66 ± 2.83ms | 33.55 ± 0.50ms |
Speedometer 2.0の場合と同様に、Firefox 60は大きな進歩を見せているのだが、いかんせんChrome 66が強い。
新たに加わったWeb Tooling Benchmark v0.4.0は、GoogleのV8チームが提供するベンチマーク・スイートで、Web開発用のツールを動作させた場合のパフォーマンスを計測する。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Runs/Sec | 2.33 | 3.57 | 6.75 |
ここでも、Firefox 60が5割以上の改善を示す一方、Chrome 66が強さを見せつけた。
asm.js
Emscriptenプロジェクトの一環として公開されているベンチマーク・スイートMASSIVE v1.2を走らせて、asm.jsの処理性能を見る。このベンチマークは大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とする。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Score | 3911 | N/A | 1667 |
Firefox 60はハング状態となったためスコアを計測できなかった。Chromeはasm.jsの処理に関しては力を入れていないようだ。
総合的なベンチマーク・スイート
Basemark Web
Basemark Web 3.0は、フィンランドのBasemark社が提供する総合ベンチマークで、最新のWeb標準と機能を用いて実環境のパフォーマンスを計測できるというのがセールスポイント。以下はConformanceがオン、Batteryがオフという初期設定で実行させた結果だ。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Score | 270.09 | 185.86 | 293.43 |
Firefox 52がChrome 66に迫るスコアだったのに、Firefox 60になって大幅に落ち込むという謎の結果に。MASSIVEと同じく、バグのためどこか一部の処理が足を引っ張っているのかもしれない。
RoboHornet
RoboHornet RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い（FAQ）。ここでは、標準的なCore Suiteを選んで計測した。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| RoboHornet index | 92.45 | 106.22 | 143.88 |
| Add Rows to Table | 5.48 | 8.00 | 9.49 |
| Add Columns to Table | 2.63 | 4.85 | 4.35 |
| Descendant Selector | 22.67 | 23.91 | 10.03 |
| 2D Canvas toDataURL | 4.42 | 4.76 | 19.57 |
| 2D Canvas clearRect | 5.70 | 5.81 | 11.76 |
| innerHTML Table | 2.87 | 5.11 | 2.96 |
| Table scrolling | 4.56 | 6.56 | 3.18 |
| Resize columns | 5.31 | 8.05 | 21.74 |
| Object Scope Access | 3.13 | 3.06 | 2.33 |
| ES5 Property Accessors | 11.85 | 6.54 | 6.77 |
| Argument instantiation | 1.81 | 10.11 | 10.31 |
| Animated GIFS | 0.80 | 1.04 | 0.31 |
| offsetHeight triggers reflow | 2.41 | 3.80 | 7.30 |
| DOM Range API | 4.88 | 4.19 | 5.18 |
| Write to localStorage | 8.51 | 5.08 | 13.71 |
| Read from localStorage | 5.41 | 5.35 | 14.91 |
ほとんどのテストでFirefox 60はスコアを伸ばし、総合的に15％程度の改善を見せている。ただ、Chrome 66との差はなお大きい。
WebXPRT
WebXPRT 3 v2.93は、米Principled Technologies社が提供するWebベンチマークである。オフィスワーカー向けWebアプリを念頭に置いたらしき6つのタスクを、繰り返し7回実行することで、精度の高い判定を行う。タスクはWebXPRT 2015から一部変更されているようだ。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間（ミリ秒）を示しており、数値が小さい方がよい。
| Firefox 52 | Firefox 60 | Chrome 66 | |
|---|---|---|---|
| Score | 134 | 167 | 137 |
| Photo Enhancement | 481 ms | 373 ms | 347 ms |
| Organize Album using AI | 2523 ms | 2370 ms | 2698 ms |
| Stock Option Pricing | 341 ms | 262 ms | 290 ms |
| Encrypt Notes and OCR Scan | 2059 ms | 1700 ms | 3279 ms |
| Sales Graphs | 681 ms | 611 ms | 652 ms |
| Online Homework | 3754 ms | 2480 ms | 3318 ms |
Firefox 60がFirefox 52比で約25％のスコアアップを達成し、Chrome 66を抑えてトップに立った。
総合評価
一部のテストで不自然な結果が確認されたものの、Firefox 60はFirefox 52を圧倒しており、パフォーマンスが大幅に向上したことは疑う余地がない。これには、64bit化、e10s-multi（Quantum Compositor〔GPUプロセス〕を含む）の全面的導入、Quantum Flowにおける地道な改良の積み重ね、Quantum CSS（Stylo）の実装など、複合的な要因が作用しているとみられる。今回は適切なテストがなく見送ったが、WebAssemblyの処理性能まで含めていれば、さらに差がついたはずだ。
MozillaはSpeedometer 2.0のスコアを根拠として、1年間で2倍の速さになったとアピールしているが、実環境における複雑なタスクを基準にすると、15％から25％の改善といったところが適切ではないか。一見すると小さな数字に見えるかもしれないが、PC性能の伸びが鈍化する一方、Webアプリが重量化している近年の状況からすると、下手をすればPCを買い換えたくらいの違いがある。
Firefox 60とChrome 66を比較した場合も、相対的に古いベンチマークでは差がつきにくく、グラフィックス関連ではFirefoxのほうが良いパフォーマンスを示すケースもある。また、WebXPRT 3のように実環境に近いテストでも、FirefoxはChromeに勝る実力を示した。もっとも、DOM関連の処理の速さや安定性ではChromeに軍配が上がる。追いつくまでにはまだまだ時間がかかるだろう。
消費メモリに関しても、Firefoxは多プロセス化が進んでメモリを喰うようになったのに対し、ChromeはJavaScriptエンジンの改良によって効率的なメモリ利用を実現するに至っており、MozillaがアピールするほどFirefoxが省メモリというわけではなさそうだ。ただ、昔と違ってメモリを消費してもFirefoxの動作は重くなりにくい。デスクトップ環境において消費メモリを競う意義は小さくなっているのかもしれない。
次のESRは、Firefox 66がベースになると予想される。MozillaがFirefox 59ではなく60をもってESRとしたのは、Policy Engineという企業向け機能を開発するためだったが、毎年11月ころに大きな開発成果を投入するという最近の開発パターンと照らし合わせると、3月ころに新ESRを出さないと開発に支障が出かねない。ESRが出るまでは互換性に配慮して大きな変更を加えづらいが、大きな変更ほど長いテスト期間を要するためだ。おそらくFirefox 66では、開発が遅れているQuantum Renderが初期設定で有効化されているだろう。Quantum Flowのようなプロジェクトが再度行われて、その成果も投入されているはずだ。今回、FirefoxはChromeを視界に捉えるところまで来たが、次回は背中が見えていることを期待したい。
*1:Are they slim yet, round 2参照
*2:Firefoxとの単純比較は困難だが、この方法であればChromeのメモリ使用量が過大に出ることはないはず。
*3:Bug 1188834参照。javascript.options.compact_on_user_inactive_delayの値はその後も変わっていない。
