Mozilla Flux

Mozilla関係の情報に特化したブログです。

タブのダブルクリックで現在表示させているタブを閉じる小技(Firefox 61以降)

Firefox 61以降、以下の手順で本体の設定を変更すると、タブのダブルクリックによって現在表示させている(=アクティブな)タブを閉じることができる(Bug 1435142)。

  1. アドレスバーに"about:config"と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。
  2. 検索欄にbrowser.tabs.closeTabByDblclickを入力し、ヒットした設定名をクリックして真偽値をtrueに変更する。

通常、タブを閉じる際はタブの右端にある「×」マークをクリックする。上記の設定をすれば、アクティブなタブに限りダブルクリックで閉じることができるので、手間が省けるわけだ。対象をアクティブなタブに限定しているのは、タブ切り替え時に誤ってタブを閉じてしまう事故を防ぐためである。

タブを閉じる作業を効率よく行うという意味では、マウスジェスチャ系の拡張機能を入れるほうがよいかもしれない。だが、WebExtensionsの制約によって、読み込み途中のページや一部のページではマウスジェスチャが効かない。そんな場合でも、本機能はFirefox本体に搭載されたものなので動作する。併用も選択肢のうちだろう。

Firefox 61でRetained Display Listsが段階的に有効化

Firefox 61のリリース後、当初は無効となっているRetained Display Lists(以下RDL)という機能が有効化されていく(Bug 1467514)。現在の計画では、リリースの2日後にまず25%のユーザーが対象となる。1週間様子を見てから対象を50%に拡大し、さらに1週間様子を見て100%に引き上げるという。

RDLについては、今年の1月にFirefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Fluxで紹介した。再描画の処理を軽減する仕組みであり、余力をJavaScriptの処理やレイアウトの実行、入力イベントへの応答などに回せるので、Webページの応答性が向上する。

Retained Display Lists for improved page performance – Mozilla Hacksによれば、MozillaがFirefox 60 Betaのユーザーを対象に行ったテストの結果、RDLを有効化すると描画処理に要する時間の中央値が、4.5ミリ秒から3ミリ秒へと減少したとのこと。

f:id:Rockridge:20180626234920p:plain
〔グラフ〕前半:RDL有効 後半:RDL無効

このように、全体的に見て描画処理に要する時間が3分の2になっただけでなく、16ミリ秒を超える「遅い」描画処理に関しては、ほぼ40%の割合で削減することに成功したという。Firefox 58 Betaの時点ではこの削減割合が「30%近く」にとどまっていたから、その後の改良で効果を増したことがわかる。

今後もRDLは改良が加えられる見込みだ。RDLが効果を発揮できない、ページ全体の再描画を要する場面を早期に検知できるようにするほか、RDLの準備作業にかかる時間も短縮させる。

2019年のFirefoxのリリース予定日

通常版のFirefoxは年に7回、ESR(延長サポート版)は年に1回、メジャーアップデートが実施される。アップデートのリリース間隔は6週間に固定されない変則的なものなので、Mozillaは早い段階でスケジュールを明らかにして、ユーザーがアップデートに備えた計画を立てられるようにしている。ただし、スケジュール公開後もときどき変更が加えられる。

Firefox Release Calendar - MozillaWikiに2019年のスケジュールが掲載されているので、リリース版とESRの日程(米国時間が基準)を紹介しておく。便宜上、リリース未了のバージョンについては2018年のスケジュールも記載するので、対象バージョンはリリース版のFirefox 61から71までとなる。

なお、Firefox ESR 60系列の次がESR 68系列となっている。かつては毎年3月に新しいESR系列に移行していたが、7月まで持ち越されることになった。

リリース予定日 正式版 ESR
2018-06-26 Firefox 61 Firefox 52.9; 60.1
2018-09-05 Firefox 62 Firefox 60.2
2018-10-23 Firefox 63 Firefox 60.3
2018-12-11 Firefox 64 Firefox 60.4
2019-01-29 Firefox 65 Firefox 60.5
2019-03-19 Firefox 66 Firefox 60.6
2019-05-21 Firefox 67 Firefox 60.7
2019-07-09 Firefox 68 Firefox 60.8; 68.0
2019-09-03 Firefox 69 Firefox 60.9; 68.1
2019-10-22 Firefox 70 Firefox 68.2
2019-12-10 Firefox 71 Firefox 68.3

(19/05/26追記)
元サイトにおけるスケジュール変更を反映させた。

Mozillaがメリトクラシーを捨てるとき

Mozillaはガバナンスのあり方を自ら定義しているのだが、最近、その定義を見直す動きがある。mozilla.governanceフォーラムの"Proposal: Addressing the term “meritocracy” in the governance statement"スレッドで議論が行われている。

まずはMozillaのガバナンスのあり方について、現在の定義を見てみよう。

Mozilla is an open source project governed as a meritocracy. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they show their abilities through contributions to the project.

Mozillaはメリトクラシーを採用するオープンソース・プロジェクトである。我々のコミュニティは仮想的な組織として構築され、そこでの権威は、プロジェクトへの貢献を通じて自らの能力を示すことにより、ボランティアにも雇用されたコミュニティ構成員にも配分される。

難しい言い回しだが、かみ砕いて言えば、努力・能力・成果の総体を「メリット」と呼ぶとすると、Mozillaコミュニティはメリットを基準にして運営されていくということだ。コミュニティの構成員はMozilla Corp.の従業員と外部貢献者の双方を含むから、世界中に散らばっているし、外部貢献者に対する業務上の指揮命令関係があるわけでもないので、仮想的な組織とならざるをえない。そして、Mozilla Corp.の従業員の特権は否定されており、メリットを示せば外部貢献者の成果物であっても採用される。

この説明でもまだ抽象度が高いわけだが、Mozillaの活動が多様であるため、抽象的な概念を使うことなく簡潔にガバナンスのあり方を定義することは難しい。話をわかりやすくするため、Firefoxの開発に焦点を絞ろう。要するに、メリトクラシーを採用すると、Firefoxの機能を改善する優れたコードが提供されるのであれば、Mozilla Corp.の内外を問わず受け入れることになる。

だが、その一方で、Mozillaはダイバーシティと社会的包摂に関する活動にも力を入れている。"Women and Web Literacy"と名付けられたプログラムはその一例だ。この観点からは、Firefoxのコードに対する内外の貢献者において、仮に白人男性が7割を占めているとすると、是正を検討する必要が出てくることになる。

Mozillaが2018年の国際女性デーに合わせて、コードレビュー時のジェンダーバイアスや人種バイアスを減らす実験に取り組んでいることを発表したのも、そうした文脈の中で理解できよう。この実験は、Bugzilla@Mozillaのレビュー申請やGitHubのプルリクエストを匿名化することで、コードレビュー担当者が予断を持ってレビューに臨むことを防ぐというもの。メリットによって評価する際に余計なバイアスがかからないようにするわけだから、これもメリトクラシーの範疇だ。

そこから先、たとえばMozilla Corp.がプログラマを採用する際に、女性の比率を定めるだとか、特定のエスニック・グループ(黒人やヒスパニックなど)に属する場合は面接で加点するといったアファーマティブ・アクションをとろうとすれば、メリトクラシーとの抵触が問題となる。

ここまでの予備知識を踏まえてもらったうえで、提案中の新しい定義を紹介しよう。Mozillaはガバナンスのあり方についての定義を、次のように変えようとしている。

Mozilla is an open source project. Our community is structured as a virtual organization. Authority is primarily distributed to both volunteer and employed community members as they show their ability through contributions to the project. The project also seeks to debias this system of distributing authority through active interventions that engage and encourage participation from diverse communities.

Mozillaはオープンソース・プロジェクトである。我々のコミュニティは仮想的な組織として構築される。権威は、主に、プロジェクトへの貢献を通じて自らの能力を示すことにより、ボランティアにも雇用されたコミュニティ構成員にも配分される。プロジェクトは、多様なコミュニティからの参加を呼び込み、促進することによる積極的な介入を通じて、この権威配分のシステムに存在するバイアスを是正することも追求する。

この定義に則れば、上記のアファーマティブ・アクションも「権威配分のシステムに存在するバイアスを是正する」ための積極的な介入措置として正当化されるだろう。新定義の提案者は、Mozillaのガバナンスのあり方自体を変えようとは思っておらず、説明の仕方を変えるだけだと述べているが、額面通り受け取ることは難しい。

Mozillaが営利を追求しないため、Firefoxにユーザーのプライバシーを尊重する機能を積極的に組み込めるというのであれば、ユーザーにとって利益のある話だ。しかし、Firefoxが「政治的に正しい」プロセスによって開発されたからといって、ユーザーがどんな利益を受けるというのだろう。Firefoxがパフォーマンス面でChromeに追いつくためには、メリトクラシーの徹底こそがむしろ求められているのではないか。

さらに別の疑念が頭をもたげる。「バイアスを是正するための積極的な介入措置」が、プログラマの思想を問題にするようになっていく危険はないだろうか。極端な例を挙げれば、差別主義者がとても優れたコードを書く場合、Mozillaはその貢献を受け入れるのか、ということになるわけだが、実はここで「受け入れない」を選んだ先にこそ真の問題がある。現実には、誰が見ても差別主義者だと判断できるケースは少ないだろう。あるプログラマの過去の発言を捉えて、「彼は女性差別的な発言をしたからMozillaにふさわしくない」との批判が出た際、メリトクラシーに従えば、「彼は優れたコードを書いて貢献してきたからMozillaにふさわしい」と反論できるが、バイアスの是正も追求するとなれば、どうなるかわからない。

ここで思い出されるのがBrendan Eich氏の顛末だ。Eich氏はMozillaプロジェクトの創設者であり、Mozilla Corp.のCTOを努め、2014年3月24日には同社のCEOに就任したが、強い批判を受けて2週間と経たないうちに辞職を余儀なくされた。Eich氏が2008年に同性婚を禁じるカリフォルニア州憲法改正案に賛成し、1000ドルを寄付した点が、Mozilla Corp.のCEOとして不適格だと批判されたのだ。Eich氏はCEO就任後、"Inclusiveness at Mozilla"というブログ記事を発表し、ダイバーシティと社会的包摂を尊重した経営を行っていく旨を宣言したのだが、いったん巻き起こった批判が止むことはなかった。

Mozillaのガバナンスのあり方に関する新定義が発効されれば、同じようなことがもっと広範に起こる可能性も否定できない。この定義は、単なる建て前ではなく、Mozillaの活動の中で常に参照され、活動の方向性の指針となるものだからだ。考えすぎかもしれないが、ニーメラーの警句の例もあることなので、あえて記事を起こして記録に残しておく。

Firefox 60の性能は1年前とは別物 Chromeを視界に捉える

当ブログでは、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(日本語版)になる。

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の値はその後も変わっていない。