Mozillaの開発者が、Windows上で既に起動しているFirefoxへ、リンクの起動要求を直接届ける新しい仕組みを試作している。公開された開発課題「Bug 2087194」によると、ローカルビルドを使った簡易テストでは、リンクの起動要求が実行中のFirefoxに届くまでの時間が、従来の約70ミリ秒から約3ミリ秒へと大幅に短縮された。現在のFirefoxでは、別のプロセスを起動して既存のブラウザへ要求を中継しているが、新方式ではWindowsの機能を利用してこの処理を省略する。ただし、今回の測定値はWebページの読み込みや表示にかかる時間ではなく、あくまで起動要求の配送に要した時間だ。
開発はまだ試作段階にあり、新機能は既定では無効になっている。正式に導入されるFirefoxのバージョンや提供時期も明らかにされていない。また、仕事用と個人用など、複数のFirefoxプロファイルを同時に使用している場合に、どのインスタンスへ要求を届けるかという課題も残っている。
起動済みのFirefoxへ直接リンクを届ける新方式
今回の改善対象は、既に起動しているアプリケーションを再利用する「ウォーム起動」だ。例えば、メールやチャットなど別のアプリケーションでWebリンクをクリックした際、Firefoxが既に動作していれば、そのインスタンスを使ってページを開く。従来のFirefoxでは、このとき新たなfirefox.exeプロセスを一時的に起動し、既存のインスタンスへ要求を中継してから終了する仕組みになっていた。スタートメニューやタスクバーからFirefoxを起動する場合にも、同様の中継処理が使われている。
Mozillaの開発課題「Bug 2087194」で試されているのは、Windowsの「Accelerated App Launches」を利用して、この中継プロセスを省く方法だ。Microsoftの開発者向け資料によると、Accelerated App Launchesでは、起動要求を受け取るウィンドウをアプリケーションがあらかじめ登録できる。URIを開く要求はWindowsのメッセージWM_COPYDATAを使って通知し、スタートメニューやタスクバーからの起動には別のウィンドウメッセージを使用する。Mozillaの試作では、Webリンクだけでなく、スタートメニューからの起動要求も直接受け取れることを確認したという。
この方式では、新しいプロセスを起動して要求を中継する処理が不要になるため、実行中のFirefoxへ起動要求を届けるまでの時間を短縮できる。ただし、改善されるのは既存のブラウザへ要求を渡す経路であり、Firefoxが起動していない状態からのコールドスタートとは異なる。また、Webページのデータ取得やJavaScriptの実行、画面描画といった処理が同じ割合で高速化するわけでもない。今回の改善が利用者の体感速度にどれほど影響するかは、リンクをクリックしてから実際にページが表示されるまでの時間を測る必要がある。
約70ミリ秒から3ミリ秒に短縮、Edgeの高速化とは測定条件が異なる
Mozillaの開発課題では、従来方式で約70ミリ秒かかっていたリンク要求の配送が、新方式では約3ミリ秒で完了したと報告されている。単純に計算すると配送時間は約96%短縮されたことになるが、これはローカルビルドを使った簡易テストの結果だ。試験に使用したPCの仕様やWindowsのビルド番号、測定回数、結果のばらつき、測定開始点の厳密な定義などは示されていない。そのため、約3ミリ秒という数値を一般的なWindows環境で再現できる性能として扱うことはできない。
一方、Microsoftは2026年10月29日、EdgeがAccelerated App Launchesに対応した最初のブラウザになったと発表している。Microsoftの公式ブログによると、Edgeが既に動作している状態で高速化機能の有無を比較した結果、ウォーム起動の速度が15%改善し、負荷の高いマルチタスク環境では最大33%改善したという。ただし、Microsoftが示したのはウォーム起動全体の改善率であり、Mozillaが測定した起動要求の配送時間とは対象が異なる。
両社の発表内容と測定条件を整理すると、次のようになる。
| 報告主体・対象 | 公表された結果 | 測定対象・前提条件 | 公開されていない情報 |
|---|---|---|---|
| Mozilla：Firefox | 従来約70ミリ秒、試作版約3ミリ秒 | ローカルビルドでの簡易試験。実行中のFirefoxへリンク要求が届くまでの時間 | 試験機、Windowsのビルド、測定回数、結果のばらつき、厳密な測定開始点 |
| Microsoft：Edge | ウォーム起動が15%改善、高負荷のマルチタスク環境では最大33%改善 | Edgeが既に動作している状態で、高速化機能の有無を比較 | 絶対的な所要時間、詳細な試験条件 |
Firefoxの約70ミリ秒から約3ミリ秒への短縮は、要求の配送処理に限定された測定結果だ。これに対し、Edgeの15%および最大33%という数値は、Microsoftが報告したウォーム起動の改善率である。測定範囲が異なるため、これらの数値を直接比較してFirefoxとEdgeの速度を順位付けすることはできない。また、Firefoxの配送時間が約96%減少したとしても、利用者が感じる待ち時間全体が同じ割合で短くなるとは限らない。
複数プロファイルへの対応とWindows側の利用条件が課題
新方式を正式に導入するうえでは、起動要求をどのFirefoxインスタンスへ届けるかという問題が残っている。Mozillaの開発課題では、複数のプロファイルが同時に動作している場合、どのインスタンスが起動要求を受け取るべきかが未解決事項として挙げられている。Firefoxのプロファイルは、閲覧履歴や設定、拡張機能などを用途ごとに分けて管理するための仕組みだ。例えば、仕事用と個人用のプロファイルを同時に開いている場合、外部アプリケーションからクリックしたリンクをどちらで開くかによって、利用者の操作環境が変わる。
従来の中継方式を省略する場合も、この振り分けを適切に処理する必要がある。ただし、Mozillaの開発課題で指摘されているのは配送先をどのように決定するかという設計上の問題であり、試作版で実際に誤ったプロファイルへリンクが配送されたという報告ではない。複数プロファイルの利用を想定したうえで、従来と同等の動作を維持できるかが正式導入に向けた課題となる。
Windows側にもAccelerated App Launchesを利用するための条件がある。Microsoftの仕様では、URIスキームを使った起動要求を高速化できるのは、アプリケーションがそのスキームの既定のハンドラーとして登録されている場合に限られる。URIスキームとは、https:などURIの先頭に付く識別部分であり、既定のハンドラーは、その種類のURIを開く標準アプリケーションを指す。つまり、アプリケーションが高速化対象として登録したURIスキームであっても、別のアプリが既定のハンドラーになっていれば、そのURI要求は高速化の対象にならない。ただし、これはURIを使った起動に関する条件であり、スタートメニューやタスクバーなど、すべての起動経路に同じ条件が適用されるわけではない。
さらに、Accelerated App LaunchesのAPIは利用制限付きの機能となっている。Mozillaの開発者は、Firefoxがパッケージ化されていないアプリケーションであることは障壁にならず、タスクバーへのピン留め機能で既に使用している制限解除コードによって、今回のAPIも利用できたと説明している。一方で、正式に使用する前にMicrosoftへ連絡する必要があるかどうかは、未解決事項として残されている。今回の試験結果だけでは、このAPIがすべてのアプリケーションに無条件で開放されているとは判断できない。
従来の起動経路を維持することも必要だ。Microsoftの開発者向け資料では、Accelerated App LaunchesがすべてのWindowsバージョンや起動方法に対応するわけではないため、既存のインスタンスへ要求を中継する従来の仕組みを残すよう推奨している。したがって、Firefoxが新方式に対応した場合も、利用できない環境では従来の中継プロセスを使って要求を届ける必要がある。新方式への対応だけでなく、利用可能な条件を判定し、必要に応じて従来方式へ切り替える仕組みも求められる。
正式導入は未定、体感速度の改善には追加検証が必要
Mozillaの開発課題は、確認時点で「ASSIGNED」となっており、作業が継続していることを示している。試作機能は設定項目widget.windows.accelerated_launch.enabledによって制御され、既定では無効になっている。また、Mozillaの機能管理システム「Nimbus」による制御にも対応するが、この機能が一般ユーザー向けに配信されているかどうかは確認できない。正式に対応するFirefoxのバージョンや提供開始時期についても、現段階では公表されていない。
MicrosoftはEdgeへのAccelerated App Launches導入に伴い、その成果をChromiumプロジェクトへ還元し、PDFファイルを開く処理にも高速化の対象を広げる方針を示している。一方、Mozillaの今回の取り組みは、Firefox自身がWindowsのAPIを直接利用するための独立した実装だ。そのため、Windowsの更新だけで既存のFirefoxに同じ仕組みが自動的に追加されるわけではない。Firefox側で必要な開発や検証を終え、正式版へ組み込む必要がある。
今後の焦点は、複数プロファイルが起動している場合の配送先の決定方法と、Accelerated App Launchesを利用できる環境の判定、従来方式への切り替えをどう実装するかにある。加えて、リンクのクリックからウィンドウの表示、ページの読み込みまでを含む実際の操作時間を測定することで、今回の高速化が利用者の待ち時間にどの程度反映されるかを評価できる。要求の配送時間を約70ミリ秒から約3ミリ秒へ短縮した試作結果は有望だが、その効果が日常的なブラウザ操作でどれほど実感できるかは、今後の検証次第だ。
