読者です 読者をやめる 読者になる 読者になる

Mozilla Flux

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

Firefox Developer Editionは早期Beta版として存続 未署名のアドオンも引き続き利用可能

速報:Firefox 55でDeveloper Editionの廃止が決定 - Mozilla Fluxを公開してから3週間が過ぎた。この間、Mozillaのリリースマネージメントチームが"Dawn project or the end of Aurora"(以下「公式アナウンス」)でAuroraチャンネルの廃止を正式に発表した。ところが、実は公式アナウンスの後も計画が変更されている。本記事執筆時点の最新情報をお伝えしよう。

Auroraチャンネル廃止の影響範囲とスケジュール

Auroraチャンネルの廃止は、Firefoxデスクトップ版のみならずAndroid版も対象となっている。だが、Google Playはアプリの作成者がユーザーを別のアプリに引き継がせることを認めていない。そこで、MozillaはFirefox Aurora for DevelopersアプリをNightlyビルドのアプリに置き換える予定だ。

また、ThunderbirdSeaMonkeyでもFirefoxのAuroraチャンネル廃止と同様の措置が執られる。これによりEarlybirdも終了となる。

Firefoxの新しいスケジュール(米国時間。以下同じ)は以下の公式画像が見やすい。ただ、RapidRelease/Calendar - MozillaWikiによるとFirefox 56のリリース時期は2017年9月26日となっている。公式画像は古いスケジュールのまま作ってしまったようだ。

f:id:Rockridge:20170422203145p:plain

Firefox Developer EditionはBeta版の派生ビルドへ移行

Mozillaは、Auroraチャンネルの廃止後もFirefox Developer Editionの提供を続ける。これまでと違うのは、Firefox Beta版をベースにする点だ。従来通り独立したブランドとしてMozillaのWebサイトで公開されるほか、従来のユーザーにはBeta版をベースにした新Developer Editionが自動アップデートで提供される(Bug 1353825)。この際、Developer Edition用のプロファイルは維持され、設定やテーマだけでなくショートカットも変更されることはない。

新Developer Editionは、通常Beta版と同様に概ね週2回のアップデート間隔になる。もっとも、アップデートの設定上は「早期Beta」と呼ばれて区別され、NightlyからBetaへの移行時、まずは新Developer Editionのユーザーが対象になるという差がある。ここで問題が見つかった機能は無効化されて、通常Beta版ユーザーに提供される。おそらく、他にも新機能を実験的に有効化するなど、新Developer Editionだけに適用される措置があるだろう。

公式アナウンスが出たのは2017年4月17日だが、この時点で新Developer Editionは通常Beta版のrepackつまりカスタマイズ版になるはずだった。Mozillaは提携企業がFirefoxのカスタマイズ版を作成できるようにしているが、この機能を利用していわば公式カスタマイズ版となる新Developer Editionを作成し、作業に要する時間やコストを抑えようとしたのだ。

しかし、この方法ではmacOS版において問題が発生することがわかった。Developer Editionのアイコンやアプリケーション名が変更されてしまうのだ。検討の結果、Auroraチャンネルの廃止によって浮いたリソースを流用し、Betaチャンネルのコードを基にDeveloper Editionビルドが作成されることになった(4月21日決定)。この方法だと自動化テストも必要になるため、カスタマイズ版よりも作業時間やコストは大幅に増える。

ユーザーにとって大きいのは、Beta版のカスタマイズではなく独自ビルドとなったことで、従来のDeveloper Editionと同様に、Mozilla Add-ons(AMO)のデジタル署名が付いていないアドオンを引き続き利用できるという部分だろう。副作用としてリリース候補版相当のアップデートが受け取れなくなるが、早期Beta版の位置付けからすればほとんど問題にならない。

ローカライズはNightlyチャンネルでの作業がメインに

Auroraチャンネルが廃止されると、Firefoxのローカライズ作業は必然的にNightlyチャンネルがその中心となる。では、Nightlyからリリースまでの期間が6~8週間も短縮されることに、どう対処していくのか。

1つの回答が、cross-channelの導入である。すなわち、Nightly用・Beta版用・リリース版用に分かれているローカライズ向けリポジトリを一本化する。そうすることで作業の重複を省き、新規投入・修正される文字列の翻訳に集中することができるわけだ。Mozilla Corp.でローカライズ担当エンジニアを務めるFrancesco Lodolo氏によれば、Auroraチャンネルの廃止時期が予期せず前倒しになったため、cross-channelを直ちに導入することはできないものの、Nightly 56への切り替えには何とか間に合わせるという。

もう1つの回答が、2017年後半に予定されるL20nの導入である。L20nはローカライズ・国際化に関する新しいフレームワークであり、これがFirefoxに実装されると、FTL構文を用いることで翻訳担当者の作業が容易になるだけでなく、Firefox本体のリリースから独立したローカライズ部分のアップデート(「翻訳のライブアップデート」と呼ばれる)も可能になる。要するに、リリース直前に文字列の修正などがあって翻訳作業が間に合わない場合でも、後から翻訳されたものに差し替えられるようになるのだ。

トップダウンの決定?

Auroraチャンネルの廃止が判明してから3週間の動きを見ていると、Mozillaの準備不足が目につく。過去に類似の計画が実現できずに終わっているにもかかわらず、リリースマネージメントの担当者らは実施方法の細部を詰めていなかったし、実施時期についてローカライズ担当者らとの調整も行っていなかった。しかも、Auroraチャンネル廃止の狙いであったはずのビルド作業・テストの省力化は、Developer Editionビルドの作成を決めた時点で実現できなくなったわけだが、そのことで揉めた様子もない。これらのことから、筆者は今回の廃止がトップダウンによるものではないかと疑っている。

Nightlyからリリースまでの期間が短くなれば、ユーザーは最新の機能を従来よりも早く手元で使うことができる。同じことを開発者サイドから眺めてみると、QuantumプロジェクトのようにFirefox 57で一定の成果を示すといった形で締切りが決まっている場合、より締切りに近い時期まで開発作業を続けることが可能になる。ユーザーの得になるうえ6~8週間の開発期間が捻出できるとなれば、Firefox開発の責任者としては多少の無理を押してでも実行に移そうとするのではないか。外部からは知るよしもないが、Senior Vice President, FirefoxのMark Mayo氏か、Vice President, Product, FirefoxのNick Nguyen氏のコメントを聞いてみたいものだ。

Windows版Firefox 53でQuantumプロジェクトの成果が初披露

Firefox 53では一部の環境においてQuantum Compositorが初期設定で有効化される(Bug 1307578)。ここでいうcompositorは、Webページ内のいろいろな要素が複数のレイヤーにレンダリングされているのを1つにまとめ、スクリーンに送り出すシステムのことである。Firefoxのマルチプロセス化(e10s)に伴い、compositorはchromeプロセス内の独立したスレッドとなっているが、そのスレッドをプロセスとして独立させたものがQuantum Compositorだ。旧名をGPUプロセスといい、現在でもその名称がよく使われる。

当然ながらQuantum Compositorは、e10sが有効化されていなければ動作しない。また、Windows 8以降か、Windows 7であればプラットフォーム更新プログラムを適用済みである必要がある(Bug 1297822)。DXGI 1.2以降のAPIを使用するためだ。加えて、PCのグラフィックスドライバがMozillaにより不適格と判断された場合もアウトだ。Mozillaの推計では、Firefoxのリリース版ユーザーのおよそ25%がこれらの条件を満たす環境に該当するという。無事有効化された場合、タスクマネージャーのバックグラウンドプロセスの欄にfirefox.exeの項目が1つ増える(Bug 1309890)。

Firefox Beta版におけるQuantum Compositorのテスト結果をまとめた記事が、"GPU Process in Beta 53"である。それによると、Quantum Compositorを有効化した場合、ドライバ関連のクラッシュが17%低下、Direct3D関連のクラッシュが22%低下、動画再生のハードウェアアクセラレーション関連のクラッシュが11%低下とめざましい効果が上がったという。しかも、代償となるような本体動作の不安定化は特に生じておらず、ほぼストレートにグラフィックス関連の処理が安定することになる。

Quantumプロジェクトの成果第1弾としては、なかなかのものだろう。また、将来的にQuantum Renderが有効化されるのも、少なくとも当初はQuantum Compositorが有効化された環境に限られることが決まっており、地味ながらその果たす役割は決して小さくない。

Firefox 53でパーミッション通知のデザインが変更

Firefox 41以降、認証や通信の暗号化に関する情報は、トラッキング防止やパーミッションに関する情報とともに、コントロールセンターと呼ばれるパネルに集約されている。Firefox 53ではこのパネルのパーミッション通知に関する部分が改善され、ダイアログも新しくなる(Bug 1282768)。

改善のコンセプトやデザインを説明した記事が、"Feeling safer online with Firefox"である。記事によると従来のデザインは、プロンプトをうっかり消してしまいやすい、個別のサイトにおけるパーミッションの管理がたいへん、スクリーン共有の際のアクセス権限付与が面倒といった問題があったという。Mozillaの開発者たちは、コントロールセンターの仕組みを継承しつつ、こうした問題に対処することにした。

まず、パネルのパーミッションに関する表示をシンプルにした。過去または一時的に機器等の利用が許可された場合はアイコンを赤く表示し、ドロップダウンメニューを廃止して許可・不許可の切り替えを1クリックで行えるようにした。

f:id:Rockridge:20170417232136p:plain
f:id:Rockridge:20170417232432p:plain

Webサイト側が機器等の利用許可を求めてきた場合も、ダイアログに2つのボタンが色違いで示されるので、どこを押せば許可・不許可になるのか迷わなくて済む。しかも、このダイアログはいったん別のタブに切り替えて戻ってきた場合も消えずに残る。

f:id:Rockridge:20170417233446p:plain

ちなみに、新しいダイアログはログイン情報の保存の場面にも用いられる。このとき、ドロップダウンメニューから別のボタンを呼び出すことが可能だ。

f:id:Rockridge:20170417234033p:plain

また、スクリーン共有の際のアクセス権限付与についても、サイトをホワイトリストに登録する作業が不要になり、共有する内容をダイアログ上の選択肢から指定できるようになった。

f:id:Rockridge:20170417234536p:plain

それほど目立つ変更ではないが、入念な検討を重ねた末に導入されているだけに、使い勝手は良好だ。また、ダイアログの新デザインは、アドオンをインストールする場面などで繰り返し目にすることになるだろう。今後は、Firefox 55で本体のアップデートに関しこのダイアログが用いられる(Bug 893505)など、別の箇所にも応用されていくようである。

ServoのWindows版Nightlyが公開 ギーク向けのプレα版

待望のWindows版

窓の杜で既報だが、ServoのWindows版Nightlyが公開されている。ダウンロードページからMSI形式のインストーラを取得することができ、Windows 7以降で動作する。

Servoはモダンかつ高パフォーマンスを謳うブラウザエンジンであり、MozillaはServoの開発過程で得られた成果をFirefoxの基盤となるGeckoに採り入れていく予定だ。その意味で重要なソフトウェアなのだが、Windows版Nightlyの提供は遅れに遅れた。

macOS版とLinux(64bit)版が公開されたのは、2016年6月30日(米国時間。以下同じ)のこと。このときWindows版は近日公開とされ、7月20日が当初の目標であり、現に7月28日にはダウンロード用のリンクもGitHubで公開された。だが、そこからが長かった。Blockerバグが潰されては新しく登録されることが繰り返された。2017年に入っても状況は変わらず、3月14日にはMozilla Corp.でSenior Research Engineerを務めるJack Moffitt氏が次のようにコメントしていた。

We'll be shipping core components of Servo in Firefox releases later this year, focusing on the Windows platform. However, Servo by itself is not web compatible enough yet that you can use it as a replacement for Chrome or Firefox, and so at this stage we have focused on core functionality that is platform agnostic rather than platform specific functionality. What platform specific functionality we do have now is a direct result of the individuals working on Servo making it usable for themselves during development, not the result of targeting deployment for specific OSes.

我々はServoのコアコンポーネントを今年後半にFirefoxのリリース版に投入する予定で、Windowsプラットフォームがその対象となる。しかし、Servoそれ自体は今のところWeb互換性が十分でなく、ChromeやFirefoxの代わりとしては使えない。そのため、現段階で我々はプラットフォーム特有の機能ではなく、プラットフォームに依存しないコア機能に注力している。今あるプラットフォーム特有の機能は、Servoに取り組んでいる個々人が開発の過程で使えるようにしただけで、特定のOSへの展開を狙った結果ではない。

ユーザー規模の大きいWindows版を早く公開すべきとの声もあったが、開発者たちはあくまでも慎重で、4月13日にようやく正式発表(Windows nightly builds now available | Servo Blog)に至った。なお、4月6日にはMozilla Hacksの記事において自分でWindows版Servoをビルドする方法が紹介されている。

日常的な利用には適さず

Nightlyをインストール後、Servo Tech Demoを起動すると、フロントエンドであるBrowser.htmlが表示される。Firefoxの新規タブページのように、所定のページへのリンクとなるタイルが並べられ、上部には検索バーもある。検索バーのさらに上に見える「<」の記号は、戻るボタンだ。

f:id:Rockridge:20170416230613p:plain

画面右上にはタブを追加する「+」ボタンがあり、その脇のメニューボタンをクリックすると、タブの切り替え画面に遷移する。この切り替え画面では、既存のタブを閉じることができるほか、ピン留めのボタンをクリックして画面右端にタブバーを固定することも可能だ。

f:id:Rockridge:20170416230638p:plain

ミニマリスト的なUIはロケーションバーも排除している。Firefoxとは勝手が違うものの、Microsoft Edgeと同じなのでさほど違和感はないはずだ。デフォルトの検索エンジンはDuckDuckGoに設定されている。一応入力補完機能は備わっているが、処理は遅くあまり使いものにならない。日本語の直接入力にも対応していない。

英語を用いた静的なWebページは大体崩れずに表示できるようだ。表示速度はまちまちで、中には高速に表示されるコンテンツもあるが、概ねもっさりとした印象を受ける。

f:id:Rockridge:20170416230700p:plain

他方、マルチバイト対応は限定されており、日本語が上手く表示できるケースはまれだ。

f:id:Rockridge:20170416230719p:plain

終了ボタンがないので、ウィンドウを閉じて終わらせる。ただ、正常に終了しないことも多く、タスクマネージャからバックグラウンドプロセスが残っていないか、毎回確認する必要があるだろう。また、ハングもしょっちゅう起きる。エラーメッセージが出てきた際、UIがハングしていたためGitHub上のServoのページへリンクするボタンが押せないことがあった。

ブックマーク機能や履歴の表示機能も実装されておらず、初期設定にないWebページは毎回手入力で呼び出すことになる。本体のみでアップデートを完結させることもできず、更新にはインストーラが必須だ。

以上のとおり、プレα版なので仕方ないが、機能の面でも安定性の面でも完全にギーク向けとなっている。せめてWeb上の各種ベンチマークを完走させられるようになれば、もう少しユーザーを呼び込めると思うのだが、当分先になりそうである。

速報:Firefox 55でDeveloper Editionの廃止が決定(追記あり)

Auroraチャンネルの廃止

4月1日だがエイプリルフールのウソ記事ではない。Mozilla Corp.でFirefox release management leadを務めるSylvestre Ledru氏は、米国時間の2017年3月31日、Firefox 54を最後にAuroraチャンネル(Developer Edition)を廃止する旨を明らかにした(Project Dawn or the end of Aurora)。Mozillaは2月のFOSDEM 2017で、Nightlyの品質が十分ならAuroraは不要になるとアピールしていたが、筆者の予想を超えた早さで実現する運びとなった。

Auroraチャンネルの廃止に伴い、そのままだと製品版のリリースが前倒しになるため、Firefox Nightly 55の開発サイクルを通常の2サイクル分とすることで調整を図る。具体的には、2017年6月12日までNightly 55が続いて、翌13日にFirefox 55のBeta 1がリリースされることになる。その後は通常の6~8週間の開発サイクルで、NightlyからBetaへと移行する。

もっとも、MozillaはBeta版が不安定になってよいと考えているわけではなく、Beta版に載せる品質に達していない機能は移行時に無効化される。また、Beta 1の時点で新機能をユーザーに対し段階的にロールアウトし、その結果を見ながらBetaチャンネル内で有効化するかどうかを最終的に決める場合もあるという。

これまでFirefox Developer Editionを使用していた開発者やヘビーユーザーは、新機能を取るならNightlyを、安定性を取るならBeta版をそれぞれ選択することになるだろう。Firefox 53以降、Developer Edition専用テーマに近いCompact Darkテーマが他のチャンネルでも使える(Bug 1314091)ようになっているため、移行後の外観が変わることもない。

なお、Auroraチャンネルの廃止はデスクトップ版とAndroid版に共通の措置だが、Android版AuroraユーザーをスムーズにNightlyに移行させる方法については検討中とされている。

廃止の背景事情

Auroraチャンネルの導入は2011年に遡る。Firefoxはバージョン5から高速リリースサイクルに移行し、当初"dev"、次いで"experimental"と呼ばれた開発チャンネルは、2011年4月までに現在の名称で呼ばれるようになった。その後、Firefoxのリリース10周年を迎えた2014年11月、Firefox Developer Editionとして開発者向けにアピールされることになった。

だが、Auroraチャンネルに対しては比較的早い段階からその存在に疑問符が付けられていた。たとえば、2013年10月に提案された「連結列車モデル」では、NightlyとBetaの期間を長く取る代わりに、Auroraの期間を短縮する開発サイクルになっていた。その背景事情として、Auroraのユーザー数が伸びなかったことが大きい。もともとNightlyユーザーの10倍程度になることが期待されていたのだが、Developer Editionとして宣伝を初めて優に2年以上が過ぎた現在でさえ、デスクトップ版Auroraの常用ユーザー数はNightlyの3~4倍にとどまっている。

Developer Editionの登場と同時期、2014年11月には、Mozilla Corp.でPrincipal Engineerを務めるL. David Baron氏が、事実上AuroraチャンネルとBetaチャンネルを統合し、Nightlyからリリースまでの間隔を短縮する旨の私案を公表している。ChromeがCanary、Beta、Releaseの3チャンネルになっていることを意識したとみられるが、この私案と今回の決定の類似性は明らかだろう。

Auroraチャンネルが廃止されれば、従来よりも新機能が迅速に一般ユーザーの手元に届く。チャンネル1つ分のビルド作業やテストが不要になるだけでなく、400~600ものパッチを追加投入(uplift)するコストも省ける。これらに釣り合うだけの品質向上というメリットがあればよいのだが、MozillaがFirefox 46から50までの後退バグを調査したところ、Nightlyサイクル中に見過ごされてそのままリリースまで行ってしまったケースが多いという。結局、Auroraチャンネルはこれを維持するだけの価値を示すことができず、今回の廃止決定に至った。

ユーザー数が相対的に多いデスクトップ版でもAuroraチャンネルがNightlyチャンネルに切り替わるのか、ローカライズにかける時間が足りなくなるという上記私案に対し示された懸念は解決したのかなど、現時点では不明確な点も残る。判明し次第、本記事に追記したい。

(17/04/22追記)
追記の範囲ではカバーできないほど新情報が多かったので、新しい記事を書いた。続報はFirefox Developer Editionは早期Beta版として存続 未署名のアドオンも引き続き利用可能 - Mozilla Fluxをご覧ください。

Firefoxのテーマ機能が刷新予定 JavaScript APIを通じて動的な制御も可能に

MozillaはFirefox 57のリリース(2017年11月14日:米国時間)までにテーマ機能を刷新する予定だ。その概略はImproving Themes in Firefox | Mozilla Add-ons Blogで発表されており、窓の杜でも既報ではあるが、今ひとつ具体像が見えず、当ブログでは記事にするのを躊躇していた。だが、最近になってQA/Theming/Testplan - MozillaWikiなどを通じて細部がはっきりしてきたので、ここに紹介しておきたい。

軽量・完全テーマから静的・動的テーマへ

現在、Firefoxは2種類のテーマをサポートしている。軽量テーマ完全テーマがそれだ。軽量テーマは、手軽に作成することができてFirefoxのバージョンアップに伴う互換性の問題も生じないが、Firefoxのユーザーインターフェイス(UI)のうちごく一部しか変更することができない。他方、完全テーマはUIを大きく変更できるが、作者はFirefoxのUIについて内部的な動作を把握することが求められるし、互換性の問題も頻繁に生じる。

こうした違いを反映して、本記事執筆現在、Mozilla Add-ons(AMO)に軽量テーマが42万以上登録されてるのに対し、完全テーマは500しか登録されておらず、しかもFirefoxの最新版と互換性があるのは60程度にすぎないという。同じカテゴリーの中にありながら、軽量テーマと完全テーマは差がありすぎる。そのうえ、これまではFirefoxの外観を制御するJavaScript APIも提供されてこなかった。

そこで、Mozillaは新しいテーマの仕組みを構築し、上記の問題の解決を図ろうとしている。新しいテーマの1つは静的テーマ(static theme)と呼ばれる。静的テーマの中核はJSONマニフェスト*1であり、UI要素に対応したプロパティに色や画像などを指定する。もう1つはWebExtensions APIを用いたもので、テーマ型拡張(themextension)の仮称もあるが、ここでは静的テーマと対比して動的テーマと呼ぶことにする。動的テーマがコントロールできるプロパティは静的テーマと同一だが、JavaScriptを用いて色や画像などをダイナミックに変更できる。動的テーマは実質的にWebExtensionsベースの拡張機能だが、Firefoxのアドオンマネージャでは「テーマ」として扱われる(Bug 1330349)。

MozillaはFirefox 55の時点で、Nightly/Auroraチャンネルにおいてこの新テーマ機能を有効化するとみられる(Bug 1341722)。

軽量テーマは静的テーマに変換 Chrome向けテーマの適用も

従来の完全テーマは、Firefox 57でサポートが廃止される。これは開発版も例外ではなく、Nightlyチャンネルから順に完全テーマは使えなくなっていく。

これに対し軽量テーマは、互換性の問題を気にせず使い続けることができる。ただ、インストール済みのパッケージは自動的に静的テーマへと変換される(Bug 1330338)。Mozillaは静的テーマへの一本化を目指しているのだ。おそらく、ある時期からAMOに軽量テーマを新規登録できないようにして、静的テーマへの移行を促すことだろう。

以上で見てきたように、Firefoxのテーマの仕組みはガラッと変わってしまう。だが、結局のところUI要素に対応したプロパティがどの程度細かなものになるかの問題であるともいえる。きめ細かなプロパティが用意されれば完全テーマに近いことも可能になるが、互換性の維持に責任を持つMozillaとしては、プロパティをあまり増やしたくない。とはいえ、使い勝手が悪ければ誰も新テーマに手を出さなくなってしまう。バランスを取るため、MozillaはFirefoxの開発版ではJSONマニフェスト内でUIのCSSを直接操作できるようにするという。テーマ作者が実例とともに新プロパティの実装を要請すれば、認められるかもしれない。

テーマ機能の刷新により、ユーザーは軽量テーマよりも複雑な内容のテーマを、互換性を気にせず使えるようになる。時間帯や訪問したWebサイトに合わせて変化するテーマも従来より増えそうだ。また、Chrome向けのテーマをそのままFirefoxに適用することも可能とされる。この場合、静的テーマはAMOのデジタル署名が不要なので、作者が自分のWebサイトでChrome向けのテーマを公開し、ユーザーがそれをインストールすればよい。

(17/03/14追記)
Add-ons/Firefox57 - MozillaWikiが改訂され、Nightly/AuroraチャンネルではFirefox 57以降も設定を変更することにより完全テーマを使用できることが明らかとなった。

*1:その構造についてはThe Future of Firefox Theming - Engineering Planを参照。

速度面でFirefox 52は振るわず Quantumによる飛躍に期待

当ブログでは、Firefoxの延長サポート版(ESR)のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 52のパフォーマンスをFirefox 45と比較してみたい。

この1年の間にマルチプロセス機能(e10s)が初期設定で有効化されるところまできた一方で、64bit版の本格投入は数バージョン先になる。そこで、今回は32bit版のみを対象としつつ、e10sの有無による差をテストすることにした。検証を行った具体的なバージョンを挙げると、32bit版のFirefox 45.7.0(ビルドID:20170118123525)および32bit版のFirefox 52.0 RC2(ビルドID:20170302120751)である。後者はさらにbrowser.tabs.remote.force-enableの設定を追加して値をtrueにしたもの(e10sオン)と、そうでないもの(e10sオフ)に分かれる。

動作環境についてだが、OSは64bit版Windows 10 Professional(Anniversary 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をバックエンドに使用している。

測定にあたって対象ごとに新規プロファイルを用意し、初期設定からフォントをメイリオに変更したほか、dom.max_script_run_timeの値を0にした(テストが途中で中断されるのを防ぐため)。また、拡張機能はすべて無効化し、プラグインは自動的にインストール・有効化されるものを除きShockwave Flash 24.0 r0だけを常時有効化している。

測定の際には、Turbo Boost機能を無効化し、定格の動作周波数でPCを動作させた。画面サイズは3840×2160で、表示を250%に拡大しており、測定の際のウィンドウは最大化している。なお、各ベンチマークの実行後はFirefoxを終了させて、メモリ上に前のベンチマークが残らないようにした。

最後に、対象となるベンチマークは、前回の記事で用いたものから一部を入れ替えた。

ページの読み込み速度およびメモリ使用量

10のWebサイト*1を同時に開いて、読み込み中であることを示すアイコン(throbber)が消えるまでの時間を手動で計測した。秒数の小数点以下は切上げている。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。

具体的な手順は次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル(JSON形式)をインポートし、「タブですべて開く」で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefoxのホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia(日本語版)になる。

1分間そのまま放置した後、新しいタブを開いてabout:memoryを呼び出し、"Show memory reports"欄のMeasureボタンをクリックし、Main Processのresidentの値を見る。ただし、e10sが有効化された環境では、子プロセスのresident-uniqueの値も合算する*2

そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。5分間*3そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてMain Processのresidentの値を(e10sオンのときは子プロセスのresident-uniqueの値も)見る。Firefoxをいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果を以下に示す。

Fx 45 ESR Fx 52 STD Fx 52 e10s
読込時間(1回目) 32 秒 27 秒 28 秒
読込時間(2回目) 18 秒 19 秒 21 秒

Fx 45 ESR Fx 52 STD Fx 52 e10s
使用メモリ(10タブ) 590.81 MB 553.88 MB 674.32 MB
使用メモリ(単タブ) 395.66 MB 349.95 MB 418.44 MB

読み込み速度、メモリ使用量ともにFirefox 52の非e10s版が優れている。e10sを有効化すると使用メモリが2割程度増えるが、Firefox 45よりも省メモリ化が進んでいることもあり、思ったほどメモリは喰われなかった。

ストレージ

HTML5 Offline Storage Benchmarkは、オフラインストレージの性能を計測するベンチマークだ。localStorage、WebSQLおよびIndexedDBを対象にできるが、ここではIndexedDBの結果(主に1ミリ秒あたりに処理されたオペレーション数)を掲載する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Clear 16.25 ms 15.88 ms 15.69 ms
Inject-L 0.38 op/ms 2.62 op/ms 2.39 op/ms
Inject-S 0.82 op/ms 3.19 op/ms 1.33 op/ms
InjectBulk-L 1.37 op/ms 1.86 op/ms 2.23 op/ms
InjectBulk-S 6.02 op/ms 5.94 op/ms 6.05 op/ms
Lookup 8.33 op/ms 5.84 op/ms 5.56 op/ms
Lookup2 11.74 op/ms 9.53 op/ms 7.05 op/ms

Firefox 52になって改善された部分もあれば、悪化した部分もあるが、非e10s版では改善された項目のほうが多い。Snappyライブラリのアップデート(Bug 768074)が影響しているかもしれない。ただ、e10sを有効化すると若干パフォーマンスが落ちるようだ。

レイアウトおよび描画処理

HTML5 Canvas

CanvasMark 2013 version 1.1は、HTML5ゲームでよく使用される処理(ビットマップ、Canvas描画、αブレンディングなど)に対するレンダリング・パフォーマンスをテストする。

Fx 45 ESR Fx 52 STD Fx 52 e10s
CanvasMark Score 9861 9759 9679

残念ながらFirefox 52で若干スコアが下がっており、e10sが有効になるとさらに下がる。

WebGL

Microsoft Edge TestDrive demosからFishGLをピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
秒間フレーム数 15 - 17 fps 16 - 17 fps 18 - 19 fps

大きな差はつかないものの、Firefox 52のe10s版がトップに立った。実際にフレームレートの動きを見てもらうとわかるが、安定度でもe10s版が優れている。

次に、Unity WebGL Benchmarks 2015年版での結果を見てみよう。このベンチマークは、Unityの開発したグラフィックスエンジンが一定時間内にどの程度のタスクを処理できるかをテストするものだ。Unity Blogの記事によれば、Unity 5.3がベースになっているらしい。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Overall Score 48634 45417 45684

Firefox 52の成績が悪い。e10sの有効・無効による差は誤差のレベルにとどまる。

最後に、OortOnline.gl v0.2.2でテストを行う。新しく加わったこのベンチマークは、Oort Onlineというオンラインゲームの世界を再現し、典型的なWebGLゲームの描画パフォーマンスを測定するという。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Total Score 4060 4220 3850

Firefox 52の非e10s版が良い結果を収める一方、e10s版はFirefox 45よりもスコアで劣ることになってしまった。

JavaScript/DOM処理

JavaScript

Octane JavaScript Benchmark は、Google製のJavaScriptベンチマークで、バージョン2.0はスループットに加えてレイテンシも重視している。言い換えれば、Webアプリのピーク性能だけでなく、動作のスムーズさも評価の対象となる。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Octane Score 20802 20765 20369
Richards 26169 26325 24817
Deltablue 34110 34038 39658
Crypto 22533 22070 21507
Raytrace 84507 79475 76885
EarleyBoyer 29506 28134 26960
Regexp 2521 3034 3085
Splay 15972 14872 13479
SplayLatency 18632 13668 14429
NavierStokes 21666 22740 23229
pdf.js 10389 8469 9868
Mandreel 17872 17207 15528
MandreelLatency 19550 18062 18261
GB Emulator 40996 45719 36439
CodeLoad 8680 11354 12421
Box2DWeb 25458 30844 27680
zlib 50938 46747 47194
Typescript 18729 20320 17682

Firefox 52 非e10s版の総合スコアはFirefox 45と同程度だが、個別の項目を見ると、上がったり下がったりしているので、たまたま近い結果になっただけのようだ。Mozillaは、CacheIRと呼ばれる仕組みを導入し、 BaselineとIonMonkeyの間でインラインキャッシュ(IC)の処理を共通化しようとしているが、目に見える成果が出るのは、まだ先なのだろう。

他方、e10s版はやや劣る結果となった。個別の項目の傾向は非e10s版と一致しておらず興味深い。

次に、JetStream 1.1を採り上げる。JetStreamはWebKitチームが提供するベンチマーク・スイートで、SunSpider 1.0.2やOctane 2.0からも一部のベンチマークを取り入れ、スループットとレイテンシの双方を計測する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 142.18 ± 3.0406 137.55 ± 2.2040 133.12 ± 2.5195

Firefox 52でスコアが落ち込み、e10sの有効化でさらに下がるという良くないパターンに陥っている。

JavaScript+DOM

Speedometer 1.0は、WebKitチームが提供するベンチマーク・スイートで、DOMオブジェクトの操作に焦点を当て、Webアプリの応答性を測定する。jQueryなど6つのポピュラーなJavaScriptフレームワークを採用し、ユーザーの行動をシミュレートするという。GoogleのV8開発チームが、Octaneよりも実環境に近いスコアが出るとお墨付きを与えたエピソードもある。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Runs / Minute 42.9 ± 0.87 41.7 ± 0.56 41.83 ± 0.36

若干だがFirefox 52が劣る結果となった。e10sの有無による差はほぼなさそうだ。

次に、Esprima: Speed Comparisonsは、各種JavaScriptパーザを用いて、jQuery.Mobile 1.4.2、Angular 1.2.5およびReact 0.13.3という3つのフレームワークを処理させた結果を示すものだ。Esprimaの作者が、自作のパーザの優秀さを示す目的で作成したベンチマークのようだが、ここではEsprima 3.1.3による処理結果のみを掲載する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
処理時間(ミリ秒) 307.1 ms 304.6 ms 301.0 ms

Firefox 52で処理時間が短縮され、e10s有効化でさらに短縮されるという良いパターンだ。ただ、速度向上の程度はそれほど大きくない。

asm.js

Emscriptenプロジェクトの一環として公開されているベンチマーク・スイートMASSIVE v1.2を走らせて、asm.jsの処理性能を見る。このベンチマークは大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とする。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 4929 4856 4975

Firefox 52でスコアがいったん落ち込むが、e10sを有効にすると盛り返すという不思議な結果に。MozillaはWebAssemblyの開発に力を入れており、Firefoxの処理能力はChromeやSafariを凌ぐほどだが、asm.jsの処理に関しては据置きといったところか。

総合的なベンチマーク・スイート

MotionMark

新たに加わったMotionMark 1.0は、WebKitチームが提供するベンチマーク・スイートで、複雑なシーンを目標フレームレートでアニメーションさせる能力を測定する。描画処理のパフォーマンスに焦点を当ててはいるものの、重いテストであり、ブラウザの総合力が問われそうだ。画面サイズがMedium(900 x 600)の場合の結果は、以下のようになった。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 127.02 ± 3.71% 98.63 ± 4.72% 96.76 ± 1.87%
Multiply 62.48 ± 5.76% 119.84 ± 3.53% 117.41 ± 1.51%
Canvas Arcs 722.68 ± 1.17% 703.10 ± 1.60% 705.42 ± 1.11%
Leaves 159.17 ± 7.78% 150.33 ± 4.47% 135.42 ± 2.15%
Paths 2297.41 ± 1.30% 2291.85 ± 0.82% 2268.73 ± 0.98%
Canvas Lines 1905.91 ± 2.01% 1804.97 ± 0.80% 1760.05 ± 0.96%
Focus 6.81 ± 2.16% 6.66 ± 2.21% 6.79 ± 1.54%
Images 20.57 ± 5.38% 15.30 ± 23.45% 15.82 ± 3.75%
Design 12.43 ± 4.04% 5.66 ± 2.77% 5.57 ± 3.16%
Suits 157.22 ± 7.77% 29.23 ± 1.71% 27.75 ± 2.34%

Firefox 52では一部の項目でスコアが大幅に低下しており、そこが足を引っ張ったため、総合スコアでも大差がついた。e10sが有効だとダメ押しで下がってしまい、厳しい結果である。

Basemark Web

Basemark Web 3.0は、フィンランドのBasemark社が提供する総合ベンチマークで、従来はBrowsermarkの名称が用いられていた。最新のWeb標準と機能を用いて実環境のパフォーマンスを計測できるというのがセールスポイントで、WebGL 2.0を用いたテストもある。以下はConformanceとBatteryの各テストを除いて実行させた結果だ。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score N/A 237.66 269.57

Firefox 45はWebGL 2.0テストが実行できなかったので、Firefox 52のスコアだけを掲載した。e10sを有効化すると約13%もスコアが上昇しており、今回の一連のベンチマークの中では異色と言える。

RoboHornet

RoboHornet RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い(FAQ)。ここでは、標準的なCore Suiteを選んで計測した。

Fx 45 ESR Fx 52 STD Fx 52 e10s
RoboHornet index 99.93 90.87 93.33
Add Rows to Table 3.44 3.43 5.14
Add Columns to Table 1.68 1.97 2.51
Descendant Selector 30.74 26.11 22.10
2D Canvas toDataURL 5.05 5.02 4.95
2D Canvas clearRect 4.97 4.83 4.65
innerHTML Table 4.03 3.32 2.80
Table scrolling 6.11 4.26 4.33
Resize columns 6.15 5.35 5.14
Object Scope Access 3.23 3.28 3.00
ES5 Property Accessors 13.87 13.60 17.83
Argument instantiation 2.79 1.73 1.74
Animated GIFS 0.76 0.66 0.78
offsetHeight triggers reflow 1.26 1.51 1.57
DOM Range API 3.53 3.32 4.17
Write to localStorage 7.36 7.54 7.68
Read from localStorage 4.96 4.96 4.94

Firefox 52で総合スコアが低下した点が目立つ。e10sを有効化すると多少改善されるものの、Descendant Selectorの項目で足を引っ張られてしまい、伸び悩んだ。

WebXPRT 2015

WebXPRT 2015 v1.998.2は、米Principled Technologies社が提供するWebベンチマークである。オフィスワーカー向けWebアプリを念頭に置いたらしきタスク設定となっており、各ベンチマークを繰り返し7回実行することで、判定の精度を高めている。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間(ミリ秒)を示しており、数値が小さい方がよい。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Overall Score 372 ± 11 319 ± 9 328 ± 9
Photo Enhancement 347ms ± 11.04% 342ms ± 7.48% 314ms ± 9.38%
Organize Album 1920ms ± 8.36% 1972ms ± 6.49% 1977ms ± 8.14%
Stock Option Pricing 326ms ± 9.22% 332ms ± 6.61% 323ms ± 5.83%
Local Notes 110ms ± 10.06% 158ms ± 9.29% 161ms ± 8.93%
Sales Graphs 622ms ± 7.63% 701ms ± 7.92% 670ms ± 1.1%
Explore DNA Sequencing 3176ms ± 5.34% 4711ms ± 6% 4663ms ± 7.19%

RoboHornetと同じ傾向が見られる。Explore DNA SequencingやLocal Notesの項目でFirefox 45よりも明らかに処理速度が低下しており、総合スコアにも響いたとみられる。

総合評価

全般的に、Firefox 52の成績は振るわなかった。過去を振り返ると、Firefox 38がほぼ全面的にFirefox 31よりも好成績となっていたのに対し、Firefox 45はスコアが伸びたベンチマークもあれば逆のものもあって、すっきりしない感じになっており、重量級のベンチマークで底力を見せて面目を保っていた。しかし、Firefox 52は、Firefox 45よりも劣る結果となったケースがあまりにも多い。

e10sの有効化に関しても、消費メモリの20%増加と、おそらくプロセス分離のオーバーヘッドがもたらすパフォーマンスの低下が突き付けられた形だ。ただ、Basemark Webのように希望の持てる結果も一部では出ている。いずれにせよ、ベンチマーク結果を眺めていると、e10sを有効化したFirefoxは別のブラウザのような印象を受ける。

この1年間、Mozillaはe10sの段階的導入やWebAssemblyの実装などにリソースを取られすぎたのかもしれない。それとも、性能が頭打ちになりつつあり、従来のような漸進的な手法では改善が見込めないところまで来ているのだろうか。MozillaがQuantumプロジェクトに賭けているのは、そうした状況を打破する面もある、というのは深読みのしすぎか。

次のESRは、Firefox 59がベースとなる。この時点で、Quantum Compositor(GPUプロセス)とQuantum CSS(Stylo)は当然有効化されているだろう。MozillaがQuantum Renderの開発を急ピッチで進めているところからすると、これも有効化までいくかもしれない。また、64bit版が主流になっていることは間違いないし、Flashプラグインは初期設定で無効化されている可能性が高い。旧来型アドオンと訣別するなど代償が大きいだけに、パフォーマンスの飛躍的な向上を期待したい。

*1:対象は今回一部入れ替えた。HTTPS接続の割合も増えている。

*2:Memory Usage of Firefox with e10s Enabled参照

*3:Bug 1188834参照