Firefox 58でWebAssemblyの起動を大幅に高速化

WebAssemblyは既にメジャーなブラウザすべてでサポートされており、その用途も、たとえばGoogle Earthが移植されるなど、ゲームに限られなくなってきている。もっとも、これまではダウンロード後のコンパイルに時間がかかるという問題があった。Firefox 58では2つの新技術でこの問題に対処し、WebAssemblyアプリケーションの起動を大幅に高速化する。

Making WebAssembly even faster: Firefox’s new streaming and tiering compiler – Mozilla Hacksによれば、1つ目の新技術はストリーミング（Streaming）という。ダウンロードの完了を待たずにコンパイルを開始するもので、この技術はWebAssemblyのファイル形式と相性がいい。単一のファイルのうち、最初にコード部分がダウンロードされるため、これをコンパイルしながら、データ部分のダウンロードの完了を待つことができるのだ。

WebAssemblyファイルの構造

もう1つの技術は、段階的（tiered）なコンパイルである。動作は高速だが生成されるコードの最適化が弱いコンパイラと、動作は低速だが生成されるコードの最適化が強力なコンパイラを用意しておき、初めに前者のコンパイラがメインスレッドでWebAssemblyファイルのコンパイルを行う。コードの実行が始まったところで、これと並行して後者のコンパイラが別スレッドで動き出し、コードのコピーに対し最適化を施す。最適化が完了したコードは、メインスレッドのコードと置き換えられる仕組みだ（ホットスワップ）。

WebAssemblyファイルの段階的なコンパイル

1段階目のコンパイラは、2段階目のそれよりも10倍から15倍も高速にコンパイルを行うことができる一方、生成されるコードの速度は2段階目のコンパイラと比較して、半分程度を確保している。この2段階のコンパイルはWebAssemblyのすべてのコードに対して適用されるが、それによってWebAssemblyの強みである処理速度を損なうことはない。

このように、Firefox 58では、1段階目のコンパイラがWebAssemblyファイルのダウンロード完了を待たずにコンパイルを開始し、実行中のコードは2段階目のコンパイラが最適化したコードに後で置き換えられるわけだ。では、実際にどの程度の威力を発揮するのだろうか。

GitHub上でMozillaの開発者が公開しているベンチマークを、Firefox 57.0.4（ビルド ID: 20180103231032）とFirefox 58 RC1（ビルド ID ：20180115093319）の双方で走らせてみた。12.4MBのWebAssemblyファイルについて、WebAssembly.instantiate()の所要時間を計測するもので、単位はミリ秒（ms）。例えばダウンロード完了からの所要時間が1000msだとすると、1秒あたり12.4MBのコードを処理できていることになる。ベンチマークでは、そのスループットも結果として表示される。5回計測した平均は、以下のとおり。

	Firefox 57	Firefox 58
所要時間	2611.9 ms	319.0 ms
スループット	4.8 MB/s	38.9 MB/s

Firefox 58のほうが約8.1倍も高速という結果になった。これだけ速ければ、実環境でも違いを体感できるはず。さらにそう遠くない将来、WebAssemblyのコンパイル結果はHTTPキャッシュに保存され、2回目以降の起動が加速される見通しだ。実行開始から一貫して速いと開発者に知れ渡れば、WebAssemblyアプリケーションの普及に弾みが付くことだろう。

Firefoxのパスワードマネージャーを刷新するLockboxプロジェクトが本格始動中

Firefoxにはパスワードマネージャー機能が搭載されており、Webサイトへのアクセスに利用するユーザー名とパスワードを安全に保存して、同じサイトに再びアクセスした際にそのアカウント情報を自動的に入力してくれる。このパスワードマネージャーの全面的な書き換えを目指すのがLockboxプロジェクトであり、既に拡張機能の形式で開発者向けα版の提供が開始されている。

Lockbox α版のスタート画面

今のところα版は、Firefox本体のパスワードマネージャーを置き換えるものの機能面ではかなり限定されており、ユーザーが自分でアカウント情報を登録したエントリーを作成せねばならない。だが、マスターパスワードに代えてFirefoxアカウントによる暗号化が可能になっている点は目新しい。FAQによれば暗号化処理にAES256-GCMを、ハッシュ処理にHMAC SHA-256をそれぞれ利用しており、保存された情報は強力に保護されるそうだ。

今後、Lockboxが現行のパスワードマネージャーの機能を取り込んでいくのは当然として、さまざまな新機能についても検討されている。パスワードの生成やエクスポート、LastPassなど他のサービスからのインポートは有用だろう。Webサイトで新規アカウントが作成されたことを検知してエントリーを自動で追加してくれる機能も便利そうだ。モバイル向けに指紋認証をサポートする話もある。

Lockboxのβ版はTest Pilotで公開される予定だ。ユーザーからのフィードバックを経て、Firefox本体に取り込まれることになるとみられる。パスワードマネージャーの刷新時期は不明だが、2018年11月にリリースされるFirefox 64がターゲットということは十分に考えられそうだ。また、モバイルアプリ版の開発や（拡張機能として）Firefox以外のブラウザへの展開も視野に入れているそうなので、Firefoxアカウントを普及させるためのツールとしての役割も期待されている可能性がある。

次のFirefox ESRはバージョン59ではなく60 その影響を探る

Firefox ESR（延長サポート版）は年に1回、メジャーアップデートが実施される。その時期には法則性があって、Firefoxのバージョン番号から10を引くと7の倍数になる。直近だとFirefox 52なわけだが、最初のESRがバージョン10からスタートしたため、こうした中途半端な数字になっている。

本来であればFirefox 59が次のESRとなるはず。ところが、Firefox/EnterprisePolicies - MozillaWikiによれば、Firefox 60を次のESRとするという。言い換えると、次のESRのリリース時期が、2018年3月から5月へと延期されたわけだ。

延期の背景には、法人ユーザー向けに"Policy Engine"と呼ばれるFirefoxのカスタマイズ機能を提供する計画があるようだ。従来、こうしたカスタマイズはおおむね旧式拡張機能によってカバーされてきた。だが、Firefox Quantumで拡張機能のWebExtensions限定化が実施され、状況が大きく変わった。たとえばCCK2 WizardはFirefox ESR 52での利用が推奨され、globalChrome.cssはuserChrome.css/userContent.cssへの移行を検討せねばならなくなっている。Mozilla公式のカスタマイズ機能が求められるゆえんだ。

Firefoxの新コンポーネントとなるPolicy Engineの開発に一定の期間を要するため、ESRのリリース時期がイレギュラーとなった。この理由を見るかぎり、おそらくリリース時期の変動は今回限りの措置だろう。Firefox ESR 60の次は、ESR 67ではなく66になるとみられる。

次期ESRの登場が後ろ倒しになった影響で、Firefox ESR 52系列のサポート期間は延びることになりそうだ。新ESRと旧ESRは2バージョンの間並行してリリースされ、これが移行の猶予期間になっている。猶予期間を削るわけにはいかないだろうから、新ESRのリリース時期を遅らせた分だけ、旧ESRつまりESR 52のサポートを長く続けざるをえないというわけだ。サポート終了が2018年8月下旬になるので、旧式アドオンを使うためESRチャンネルに乗り換えたユーザーや、Windows XP/Vista上のユーザーにとっては朗報と言える。

また、ThunderbirdもFirefox ESRと同じWebエンジン（Gecko）を使用しているので、メジャーバージョンアップの時期がずれてくるだろう。次期ThunderbirdはFirefoxと異なり旧式アドオンのサポートを続ける一方で、アドオン側の対応が求められており、未対応のアドオンは初期設定で無効化される。アドオン作者が開発に使える時間が増えれば、対応するアドオンが揃う可能性は高くなる。

ちなみに、Policy Engineはシステム管理者による利用が想定されているものの、ESRチャンネル以外でも有効化することは可能なようだ。カスタマイズ用の「ポリシー」は、一部機能の制限やブックマークの追加などが中心だが、初期設定でメニューバーを有効化するといったUIの調整についても議論されているという。仮にUIのカスタマイズが柔軟にできるようなら、部分的にuserChrome.cssを代替できるかもしれない。

（17/12/29追記）
本記事執筆後、次期「Firefox ESR」は「Firefox 60」ベースに ～現行版「Firefox ESR 52」は少し延命 - 窓の杜がこの話題を取り上げ、Firefox ESRの英語ページの図がアップデートされて、Firefox 60を次のESRとする一方、ESR 52系列のサポートが52.9まで続く形になっていることを指摘した。また、米国時間の2017年12月21日にはMozillaから正式なアナウンスも出ている。それによると、Firefox ESR 52.9のサポートが終わる2018年8月28日までは、Windows XP/Vistaのサポートも継続される。

また、上記アナウンス後にThunderbird開発者のJörg Knobloch氏は、次期安定版がThunderbird 60になると明言した。

なお、本文で触れたPolicy Engineは、プロトタイプの開発が進んでいる（Bug 1419102）。

日本語版Firefox 58では初期登録のフィードリーダーが3つに

以前の記事で紹介したように、日本語版Firefox 57において初期登録のフィードリーダーが大幅に変更された。具体的には、Live Dwango Reader（LDR）が削除された一方で、AOL Reader、Feedly、Feed WatcherおよびInoreaderが追加された（Bug 1383654）。

しかし、AOL Readerは2018年1月3日をもってサービスが終了する。これを受けて、同年1月23日（米国時間）にリリース予定のFirefox 58では、AOL Readerが初期登録から外される（Bug 1423585）。これで、残るフィードリーダーは次の3つに絞られた。

• Feedly
• Feed Watcher
• Inoreader

ちなみに、Firefox本体に登録されたフィードリーダーを使用する際は、まずメニューパネルからカスタマイズ画面を開き、「購読」アイコンをツールバーに追加する。

Firefox Quantumのカスタマイズ画面

Webサイトに登録可能なフィードがある場合は、この「購読」アイコンが有効になるのでクリックし、ドロップダウンメニューからライブブックマークの代わりに自分で使っているサービスを選択すればOKだ。

フィードリーダーの選択画面

Firefox 58以降も続く高速化と応答性向上 2018年もパフォーマンス2倍が目標

2018年も飛躍的進歩へ

Firefox Quantumのリリースは大きな注目を集め、そのスピードの速さと軽快さは、多くのユーザーから驚きをもって迎えられている。一方、非難の声が一部にあるのも事実だ。いわく、Chromeと同程度の速度でChrome互換の拡張機能が使えるだけであれば、Firefoxを選ぶ理由がない、と。

だが、Firefoxが2017年に達成した高速化を、2018年も達成するとしたらどうだろう。Mozilla Corp.でSenior Vice President, Firefoxを務めるMark Mayo氏は、「今年（2017年）Firefoxのパフォーマンスは2倍になった。2018年も再び2倍にするのが暫定的な目標だ」と米CNETの取材に対し答えている。同社のFellowを務めるDavid Bryant氏（Emerging Technologiesグループの事実上のトップ）も、Firefox 57時点のFirefox Quantumは序章に過ぎないと述べている。

通常、この手の表現はマーケティング的に「盛っている」ものだが、こと2018年のFirefoxに限っては、あながち誇張とも言えない。これは以前の記事に書いたことの裏返しになるが、QuantumプロジェクトはFirefox 57時点で半ばしか達成しておらず、残りの成果物が2018年前半に投入されていくスケジュールになっているのだ。また、Quantumプロジェクト以外にも、Firefox Quantumのリリースに間に合わなかったもろもろの新機能があって、完成したものから順にFirefox 58以降で有効化されていく。さらに、Quantum Flowが実証したように、細かな修正も積み重なると大きなパフォーマンスアップにつながるわけだが、2017年中に作られた下地がそこで生きてくる。

投入予定の新機能について

Firefox 58

処理速度の向上に関しては、JavaScript Start-up Bytecode Cache（Bug 1405738）が大きいだろう。Webページ閲覧時に生成されたJavaScriptのバイトコードを、アイドル時にキャッシュしておき、再訪時に利用する機能だ。GoogleやFacebookのようにJavaScriptを多用するページでは、読み込み速度が15～20％も短縮される場合があるという。加えて、Windows版ではビルド環境がVisual Studio 2017 v15.4.1に変更されており（Bug 1408789）、コンパイルされたバイナリの性能が上がる。

応答性の向上に関しては、Places Async Transactions（Bug 1404267）を挙げることができる。履歴とブックマークのデータベース（Places）におけるトランザクションが非同期化され、Firefox本体が行う他の処理が阻害されない。特にFirefox Syncを利用している場合に、効果を実感できるだろう。

また、Quantum DOMの成果となるBudget Throttling（Bug 1377766）も見逃せない。これまでもFirefoxにはバックグラウンドタブにおけるスクリプトの処理を抑制する技術が組み込まれてきたが、Budget Throttlingはその最新のものとなる。大まかな仕組みはこうだ。タブごとに処理時間の割当てが行われ、毎秒その処理時間が増加していく一方で、タスクが実行されるとその実行時間分だけ処理時間が減少する。割り当てられた時間がマイナスのときはタスクが実行されないので、バックグラウンドで繰り返し実行されるスクリプトは処理が抑えられる。ただし、音声を流す処理、リアルタイムコネクション絡みの処理（WebSocketsやWebRTC）とIndexedDBの処理はその例外となる。Budget Throttlingは、応答性の向上だけでなく、消費電力の低減にも効果があるとされる。

Firefox 59

Introduction to WebRender – Part 1 – Browsers today – Mozilla Gfx Team Blogで説明されているように、Geckoのグラフィックス・パイプラインは、DOMツリー → フレームツリー → ディスプレイリスト → レイヤーツリーの流れで処理されていき、compositorがレイヤーツリーを合成する。新機能のOff Main Thread Painting（OMTP）は、「ディスプレイリスト → レイヤーツリー」の処理であるPaintingをメインスレッドとは別のところで行い、Firefox本体の応答性を高める（Bug 1403957）。

Geckoのグラフィックス・パイプライン

また、Retained Display Lists（Bug 1352499）は、ディスプレイリストと呼ばれる描画命令のリストを構築するにあたって、常にスクラッチから行うのではなく、基本的にリストを保持しつつ部分的にアップデートしていく。YouTubeやTwitterで描画がスムーズになるという。

Firefox 60以降

Quantumプロジェクトの掉尾を飾るのがQuantum Renderである。このサブプロジェクトでは、ServoのグラフィックスエンジンであるWebRenderをGeckoに移植する。最近のGPUは強力で、高精細なゲームをスムーズに処理できるのだから、Webページも同じように処理できるはず。この発想をベースに、Rust言語製のQuantum RenderはWebページを表示する際、ゲームエンジンのようにGPUを活用。Painting/Compositingの区別を取り払い、スクリーン全体を描画することで常時60fpsを実現するのである。

もっとも、従来とはアーキテクチャがあまりに異なっているし、GPUやグラフィックドライバーによる差異も吸収しなければならないので、開発には予想以上に時間がかかっている。今のところ機能の範囲を絞ってFirefox 60に投入されるのではないかとみられているが、Mozilla Corp.でDirector, Firefox Browsersを務めるJeff Griffiths氏は、Firefox Quantumの名称をFirefox 61/62まで使い続ける可能性を示唆しており、Quantum Renderの有効化が遅れる可能性もある。

また、同様にGPUを活用したRustベースのフォントラスタライザとしてPathfinderがあり、Firefoxに統合されることが決まっている。現時点でもSVGレンダリングを含め基本的な処理は行えるようになっているので、リリース時期はQuantum Renderとそう変わらないだろう。

技術的負債の除去

2017年のFirefoxは、使用可能なプラグインをAdobe Flashに限定し、Windows版の動作環境もWindows 7以降とした。Firefox Quantumでは旧式アドオンのサポートを打ち切った。

これらの思い切った措置により、2018年のFirefoxは互換性の維持に煩わされることなく新機能を実装できるようになったし、古い環境を考えずにリファクタリングも行えるようになった。既にXBLはQuantum CSSやGeckoの処理を複雑化させるなど問題が多いとして段階的な削除が始まっている。こうした動きは2018年の間じゅう続くだろう。

シェアの拡大を目指して

Mozillaの目標は、デスクトップ版Firefoxのグローバルなシェアを2020年までに20％にすることだ。そのためにはChromeからシェアを奪う必要があるわけだが、Mozillaのマーケティング戦略としては、自己の価値観に沿って市場で積極的な選択を行う層（これを"Conscious Choosers"と呼んでいる）がネットユーザーの約23％を占めるので、その層を狙うということになっている。

だが、本当の意味でシェア拡大に寄与するのは、そうしたマーケティング上のあれやこれやではなくて、Firefoxの速さと軽さ、そしてそれがユーザーに受け入れられたときに生まれる「勢い」だ。もともとFirefoxはその方法で25％を超えるシェアを獲得した。逆に、痒いところに手が届くアドオンが豊富に使えることは、シェア低下の歯止めにはならなかった。Firefoxがかつてのシェアを取り戻そうとすれば、圧倒的な速さと軽さを実現し、維持するほかないし、旧式アドオンを支える仕組みはその足を引っ張っていたのだから、切り捨てる以外の選択肢はなかった。

WebExtensions移行プロジェクトの現場責任者であるAndy McKay氏は、プロジェクトの開始当初パニック状態にあり、落ち着いて取り組み始めてからも、Mozilla Corp.内でかなりの反対に遭ったと告白している。Mozillaが旧式アドオンを捨てることの重さをわかっていなかったはずはない。それでも、このタイミングでやらねばならなかったのである。決断の正しさは、2018年に明らかになるだろう。