- 世界的に Chromium ベースのブラウザのシェアが高まるにつれ、Web 標準の多様性や オープンウェブの将来 への懸念が高まっている
- Rust で開発された Servo エンジン は、マルチスレッド性能とメモリ安全性という2つの強みを持ち、ウェブレンダリングエンジン分野で新たな代替候補として注目を集めている
- まだ初期段階のため、多くのウェブサイトで レンダリングバグ が存在するが、Wikipedia や一部のデモページなど単純なサイトでは正常に動作する
- Servo プロジェクトは過去に Mozilla 主導で始まったが、現在は Linux Foundation Europe が管理しており、技術的独立性とコミュニティ中心の意思決定構造を持つ
- ブラウザエンジンの一極化の流れの中で、Gecko、Servo など 代替エンジン を継続的に開発することが Web 生態系の多様性を守るうえで重要であるという示唆がある
ウェブエンジンの寡占化とそのリスク
- 1990年代〜2000年代初頭には Internet Explorer の Trident、Opera の Presto、Netscape の Gecko、Konqueror の KHTML など、さまざまなウェブブラウザエンジンが共存していた
- 時代が進むにつれ KHTML は WebKit へ、Presto や Trident（および Tasman）は Blink（Chromium エンジン）へ統合または置換された
- 現代の主要ブラウザ（Chrome、Edge、Opera など） がほぼすべて Chromium/Blink ベースになることで、実装がすぐに標準化されていく現象が発生
- セキュリティ脆弱性や拡張性の制限など、1つのエンジンへの依存時にウェブ生態系全体が同時に影響を受ける問題が顕在化している
Servo エンジンの登場
- Servo は Rust で最初から新しく開発されたブラウザレンダリングエンジン である
- Rust の長所である マルチスレッド処理 と メモリ安全性 を基盤に、従来の C/C++ ベースエンジンが抱える脆弱性（例: メモリバグ）を構造的に減らそうとする取り組みである
- Servo の主な目標は 組み込み型ウェブレンダリングエンジン であり、独立型ブラウザだけでなく Electron や Android WebView の代替としても活用可能である
- Linux Foundation Europe の配下で、技術的意思決定は大企業ではなく技術委員会中心で運営されている
- 10 年以上ぶりに登場した完全に新しいウェブブラウザエンジンとして、完成度向上のため既存の主流エンジンの経験が反映されている
Servo の使用体験と現状
- 公式サイトで公開されている ナイトリー（Nightly）ビルド（Windows、macOS、Android、Linux 用）で Servo を体験できる
- ブックマーク、拡張機能、データ同期などの 基本ブラウザ機能未対応 の状態である
- 多くのウェブサイトで レンダリングバグ が発生し、Google 検索や一部のサイトではレイアウト崩れやクラッシュが起きる
- Wikipedia や CNN Lite など、構造が単純なページ は正常に動作する
- Servo のデモページでは グラフィック性能のデモ が可能で、Particle Physics などのベンチマークでは最新の MacBook Pro（x86 エミュレーション）基準で 55~60FPS の結果を確認した
- Acid3 テストでは 83/100 点 と、主要ブラウザ（95 点程度）より低い点数だった
- 今後 Shadow DOM、CSS Grid など主要 Web 標準のサポートをロードマップに含め、ウェブ互換性の改善に重点を置いている
Servo の歴史と主な転換点
- Servo は 2012年 Mozilla で開始 され、2013年には Samsung が開発に加わった
- 当初の目標は 安定化後の Gecko エンジンの代替 を考慮していたが、現実的には Gecko の各部分を Servo コードで段階的に置き換える戦略へと舵を切った
- Firefox 57（Quantum）アップデートで CSS エンジン（Quantum CSS、Stylo）を Servo コードに置き換え、パフォーマンスとメモリ効率で顕著な改善効果を確認した
- 2020年 Mozilla の大規模な組織再編（Servo 開発者を含む）後、Servo は Linux Foundation の配下に移管され、資金支援の再確保を果たした後、Igalia などオープンソース企業の支援を受け、現在もコミュニティ中心の開発が継続している
ブラウザエコシステムの将来性
- 米国法務省が Google の 独占的地位（Chrome、Android） に関する訴訟に勝訴したことで、Chrome の売却や他社ブラウザとの検索契約禁止措置について議論が進んでいる
- Mozilla は Firefox のデフォルト検索収益への依存度が高く（Gecko 開発の維持に不可欠）であるため、こうした措置に反対意見を表明している
- もし Mozilla が Google の収益を失った場合、Firefox は開発コスト削減のため WebKit や Chromium/Blink へ移行する可能性がある
- その場合 Gecko コードのフォークとコミュニティ運用 の可能性、あるいは Gecko の段階的な衰退など、さまざまなシナリオが想定される
- Servo と Gecko などの代替エンジンの存続 が、ウェブプラットフォームの多様性とバランス維持にとって重要な要素として再び浮上している
まとめと示唆
- 主流ブラウザエンジンの一極化の中でも、Servo のような革新的な代替技術 の登場は、ウェブエコシステムの多様性と健全性を守るうえで重要な役割を果たす
- 短期的に実用ブラウザとして完成するのは難しいが、技術的な実験と進化は継続的に行われている
- Servo の今後の進展方向と業界への波及効果に対する期待感が高まっている
4件のコメント
まともに動きもしないものを受け取って使えというのか？ そんな傲慢さはいったいどこから出てくるんだ。
rust は Servo を開発するために作られた言語だと聞きましたが……Servo がうまくいってくれるといいですね
Hurdプロジェクトをつい思い出してしまうのは……私の思い違いですよね？
Hacker Newsの意見
現在のロードマップでは Shadow DOM と CSS Grid が優先事項になっている。自分は CSS Grid 対応に取り組んでいて、まもなく "named grid lines and areas" のサポートが追加される予定。これによって、より多くの Web サイトのレイアウトが正しく動作するようになると期待している。自分のプロジェクトなので多少ひいき目かもしれないが、Servo の CSS Grid 実装方法はかなり見事だと思う。中核実装が外部ライブラリの Taffy（GitHubリンク）として分離されていて、このライブラリは Rust UI エコシステムで幅広く使われている。たとえば Blitz（リンク）Web エンジン、Zed（リンク）テキストエディタ、そして Bevy（リンク）ゲームエンジンで、Flexbox や Block layout などさまざまな役割に使われている。Servo は Stylo や html5ever などのモジュール型ライブラリ開発経験を土台に、Web エンジンを独立モジュールと公開 API に分割する方式を取っており、これが今後 Web エンジン開発者への参入障壁を下げ、新しい Web エンジン開発者に大いに役立つことを期待している
Blitz は初めて聞いた。かなり興味深く野心的なプロジェクトに見える。まるで本物の「隠れた」Web エンジンのような印象を受ける。Servo は Rust が登場した頃から広く知られていたが、Blitz もそれに劣らず印象的だ
Web ブラウザエンジンの機能を自分で実装した経験が、HTML や CSS の書き方に影響するのか気になる。今でも週に3回くらい "css grid cheatsheet" を検索しているのかも聞いてみたい
機能を分割してモジュール化するアプローチが、かえって機能過剰や断片化につながらないか心配だ。Google に対抗するには集中した戦略が重要だと思うので、その点が気になる
taffy を使って、自分の小さな Rust ベースの E Ink カレンダーでレイアウトを組んでいる。こういう話はとても面白い
Web エンジンを独立して使える公開 API モジュールに分けるやり方が本当に好きだ。以前 WebRTC を見ていて、どうしてしょぼい Skype もどきを作るのが、50行の JavaScript か、1週間かかる Chromium の C++ ビルド地獄のどちらかでなければならないのかと思っていた。今では WebRTC の Rust crate もあるので、こうした投資の恩恵を受けるのが Web アプリだけではないのはありがたい
Mozilla は Xerox のように「未来の技術を作ったのに、うっかり競合に奪われた企業」の殿堂入りをしそうな気がする。Rust と Servo で一時はブラウザ開発で Google をリードしていたのに、結局それを推し進めなかったのが本当に理解できない
Mozilla は Xerox とは違う。もし誰かが新たな Xerox だとしたら、むしろ Google だ。Google は莫大な資金で、事業計画のない研究開発部門に投資している。代表例が Transformer モデルで、実質的に LLM を先に作ったのは Google なのに、結局 OpenAI に後れを取った。Mozilla の成功は常に Netscape や Firefox など Web ブラウザへの集中にあった。Rust も本質的にはブラウザのために作られた言語であり、それが他の分野でも有用なのは良い副次効果にすぎない
Google は 2006 年から Mozilla の主要な収入源だった。Mozilla が存続するには Google を満足させればよく、そこには利害衝突の余地もあるが、Mozilla にとってはかなり悪くない取引だ
Mozilla はもう終わりだと思う。Google に依存しすぎていて、その依存すら失いかねない状況だ。今後の未来は Servo と Ladybird で、少人数で急速に進歩している Ladybird の姿は本当に印象的だ
もし Mozilla が Gecko を捨てるなら、そのときこそハードフォークして Mozilla から脱出すべき時だ。ちなみにここでいう Gecko 放棄とは Servo ではなく Chromium への移行を意味している
人々にブラウザのためにお金を払ってもらうのは難しい気がする。10ユーロのビールには気前よく払うのに、WhatsApp の生涯 0.99 ユーロライセンスを避けようとする人が身の回りには多かった
Mozilla が Firefox の技術的未来を手放したのはいまだに理解できない。ただ Mozilla を見ると、結局は資金の流れを見ればいろいろ腑に落ちる
Pocket サービス終了も悲しい例だ。エイプリルフールの冗談として、Mozilla が Firefox を終了して中核事業に集中すると発表したらどうなるだろうと想像したことがある。人気製品を美しく終了させる「プラトニックな理念」こそが本当の中核事業なのでは、という苦い冗談だ
いくつもの離脱やコミュニケーションのあり方を見ると、当時の Mozilla は極度に政治的な会社だったように思う。Servo は非常にコミュニケーションが活発で、Rust も雰囲気が良かったので、むしろそれが上層部には気に障ったのかもしれない。Mozilla は今でも古いメンバーを中心に運営されており、経営陣の失策が大きいと感じる
いまだに Servo は Chrome / Chromium の独占に対する実質的な対抗馬になれると強く信じている。Mozilla がなぜこれを捨てたのか、Linux Foundation がなぜほとんど支援しないのかよくわからない
Mozilla の戦略を長期的に Google 資金からの独立という観点で見れば、理屈は通っている。実際、Google 以外の収入は 2022 年の 8,000 万ドルから 2023 年には 1.5 億ドルに増えた。総資産も毎年 1 億ドルずつ増えて 2023 年には 10 億ドルに達している。Google 資金の比率も 2020 年の 90% から 2023 年の 75% に下がっており、完全に独立しているわけではないが方向性はある。よく言われる話とは違って、資金の流れだけを見れば結論は変わりうる。人々は Servo を継続すべきだったと批判するが、実際には Quantum 以降の Firefox で Servo が大きな役割を果たしたわけではないと思う
Mozilla の収入の大半が Firefox 由来だという理解で合っているのかと尋ねている
Blink 独占に挑む Ladybird（公式ホームページ）もある。今後どうなるかは確かではないが期待している
Ladybird の目的がよくわからない。元職のエンジニアもいて寄付も集めているなど、単なる趣味プロジェクトではないのは確かだ。だが、機能・セキュリティ・性能の面で Blink、Webkit、Gecko と競争できるのかは想像しにくい。そもそも大規模チームではないので、一般的な採用がなければエンジンだけ作っても大きな効果はないと思う。この点は Servo にも当てはまるが、Servo のほうが技術的目標はもう少し説得力がある。Ladybird にはそうした明確な情報があまり見えない
技術面だけで見ると、Ladybird の魅力がよくわからない。基本的に C++ で書かれていて Gecko や Blink と差別化されていないように見える。Servo にはセキュリティや並列性など、明確な技術設計上の差別化があるので魅力を感じる
Ladybird の成功を願っている。今は直接支援もできるようになったので意義があると思う。Mozilla と違って、集まった寄付金は全面的にブラウザ開発に使われると確信している
Ladybird は Swift への移行を試みているのか気になる。C++ でブラウザエンジンを開発するのはあまり好みではないが、現実的で成果物重視という印象はある。Rust なら未来志向だという点は認める。ただ、Swift など別の言語でエンジンを作るのは、社内政治的な決定のようにも見える。サポートエコシステムがまだ不足している言語を、あえて選ぶことには疑問がある（参考ツイート）
Dogemania テストは M4 Pro MacBook Pro で 400 枚の画像までは滑らかに 60 FPS で動作した。だが Chrome では 1400 枚まで 60 FPS を維持していて、それ以上は試すのが面倒で閉じてしまった
自分も同じ実験をしてみたが、Firefox と Chromium の差はがっかりするほど大きい。Chromium では 1000 枚を超えても 100 FPS が出続けたのに、Firefox では 500 枚を超えたあたりですぐ 60 FPS を下回った。完全に公平なテストではなかったかもしれないが（Chromium にはアドオンもなく、普段あまり使わないブラウザだったので）、相対的な性能差を確認していろいろ考えさせられた
dogemania では、画像がアニメーション後に静止しているなら、本当に簡単に最適化できるケースではないのか気になる。Amiga のような昔のコンピュータでも、無限に近い量を処理できそうな気がする
Servo を「新しい」エンジンと呼ぶのは少し無理がある
Rust は Web ブラウザの Servo のために作られたと認識していた
「標準の唯一の実装が1つしか残らなければ、それ自体が標準になってしまう危険がある」という意見について、なぜそれが問題なのかよくわからない。実装がオープンソースで、複数の主体が管理する委員会で仕様を決めるなら問題ないと思う。今のようにリソースを大量投入して複数のエンジンを作る状況のほうが、むしろ無駄だ。ブラウザエンジンも Linux カーネルのように1つだけにして、ディストリビューションだけを多様化するほうが効率的だと思う
どれだけ善意で作られていても、実装にはバグや細かな欠陥が残る。独立した第2の実装がなければ、結局「全部動く」という理由でバグそのものが標準になってしまう。Web ページがそうしたバグに依存するようになると、最終的には仕様ではなく特定実装の細部の欠陥に従って動くことになる。MS Windows で古い UI が何層にも積み重なり、互換性維持が悪夢になったのはそのためだ。複数の独立実装があれば、標準は本当に維持・進化でき、最適化もしやすくなる
理論上はよさそうだが、現実には単一の開発主体の利益が常にユーザーの利益と一致するわけではないので、独占は望ましくないと思う。特に最近の Blink ベースでの manifest v2 廃止はユーザーから不評だった
ブラウザエンジンが多いほど、セキュリティ脆弱性が1つに集中するリスクを減らせる。メモリ安全な言語でも論理的なミスは被害をもたらしうるので、多様性は重要だ
「1つのエンジンに複数のディストリビューション」という戦略を語っていたが、BSD 環境や ZFS などに慣れた人からすると、むしろ昔のやり方から離れたときに安定感や完成度の違いがはっきり感じられる
すでに Google やその周辺の人脈の意見が標準化に大きく反映されている。すべてが Chromium によって回るようになれば、状況はさらに悪化するだろう。もしかすると本当の破局が来て初めて、W3C や WHATWG のような組織の限界をみんなが認めるのかもしれない
「大半の Web サイトには多少のレンダリングバグがあり、一部は完全に動かない。Google の検索結果には要素の重なりが多く、MacRumors のホームはスクロール後にクラッシュする。しかし Wikipedia、CNN Lite、個人サイト、NPR のテキストなどは完璧に動く」――こうした観察を見ると、Google や MacRumors 側を Servo に合わせて直すべきだという話はほとんど見かけない。代わりに、Servo が Chrome / Chromium のように動くべきだという結論ばかりになりがちで、それがとても残念だ。そうなると、(a) 結局は広告企業が標準を決めることになり、(b) Web ページを作る側の動機も間違ったものになってしまう。Wikipedia や CNN Lite のように簡素な方向に合わせるほうが、むしろ簡単だ。自分は「標準」ブラウザとは人気順ではなく、本当の標準に近いものを目指すべきだと思う。不人気なブラウザでも人気ブラウザでも動くようにすることが、本当の標準だ。結局のところ答えは Web ブラウザではなく Web ページを直すことにあると主張したい。自分は今でも W3C の元祖 libwww ライブラリとツールで実験していて、少し手を入れるだけで、今でもテキストベースの Web ページ最適化用途として 30 年以上にわたり十分動作する。インターネットは公共財なのに、今日のブラウザやページは広告最適化や個人情報収集に偏りすぎていて残念だ。本当に WWW ユーザーのためのページやブラウザが優先されてこそ意味があると思う。以下は libwww を静的バイナリとしてビルドする簡単なスクリプトだ
Mozilla が競争力のあるブラウザ企業から、だんだん活動家っぽい組織に変わっていくのを見るのは本当に悲しい。そのせいで中核製品がどんどん弱くなっていったように感じて、なおさらつらい