Web開発
卑屈な賞賛
Abject Praise (infrequently.org)
要約
この記事は、AppleのSafariブラウザエンジンの開発ペースとウェブ標準への対応状況について、FirefoxやChromiumと比較して批判的に論じています。Web Platform Tests (WPT) のデータに基づき、Safariは競合に比べて改善速度が遅く、多くのウェブ標準機能の実装で遅れをとっていると指摘しています。Appleの潤沢な資金を考慮すると、この状況はウェブ開発者にとって不満の種であり、iOSユーザーは選択肢が限られている現状に疑問を呈しています。
全文翻訳
ジェレミーほど賢明で思慮深い人物に異を唱えるのは危険ですが、過去2週間、AppleのiOS 27マーケティングに対する彼の投稿は、屋根裏のコオロギのように私の静かな時間を侵食しています。「なぜ、状況を理解している人が、最低限のことしかしていないAppleを賞賛し、一貫してそれ以上のことをしてきた人々をこき下ろす必要があるのだろうか?」と私は考え込みます。
Redux
Appleの以前のSafari 16.4およびSafari 26のマーケティングと同様に、SafariとiOS 27の同時リリースは、痛々しいほど遅いリリースサイクルを文書化しています。もし機能や仕様への適合性が世界最高水準であれば、それは一つのことですが、リリースノートを詳しく見ると、Safari 27は、概して競合エンジンが苦しまなかった問題に対する修正を提供する予定です。
誤解しないでください。Appleが品質に注力しているのは素晴らしいことです。それはSafariにとって依然として継続的な問題です。しかし、長年苦しんできたウェブ開発者はどれほどの救済を期待できるのでしょうか?
最も良い比較指標は、共同プロジェクトであるWeb Platform Tests (WPT) から得られます。現在の実験ビルドと安定版リリースを比較することで、次期メジャーバージョンの各ブラウザがリリースされる際に期待できる変化の規模を明らかにできます。
90%は、AppleがEUと日本で競合エンジンの全WPTテストに要求する最低ラインであり、そこでは(理論上)それらのエンジンを許可することが強制されています。Safariはかろうじてその基準をクリアしています。
SafariはFirefoxに追いつきつつあるように見えますが、これは誤解を招きます。Appleは過去1年間に7回のリリースを行いました。つまり、約8週間の間隔です。一方、MozillaとChromiumは安定版で12バージョン、つまり月に1バージョンリリースしています。これらを(7.4週間対4.3週間)改善率を計算する際の分母として使用します。
Safariのナイトリー版と安定版の間のテスト合格率の増加(Firefoxの990件に対し1558件)は大きく見え、Appleはそれを新たな注力によるものだと考えさせたいと思っています。しかし、時間あたりの重み付けで見ると、SafariはFirefoxよりも改善速度が遅く、前回の安定版リリース以降、週あたり207件のテストが改善されたのに対し、Firefoxは230件、Chromiumは460件です。
しかし、おそらく最近のリリースは例外かもしれません。より長い期間を調べると、状況を把握するのに役立ちます。WPTは柔軟であり、各エンジンの開発者向けチャンネルリリースを2025年7月のビルドと比較するクエリを構築できます。
Appleは、Safariがテストに合格していない一部の機能を実装することを気にしないかもしれませんが、それがすべてのiOSユーザーからそれらを奪う理由になるでしょうか?そして、他のブラウザがテストセット全体に対して改善できるのに、WebKitがさらに遅れをとっているというのは何を意味するのでしょうか?
総合格率が、エンジンが広範な互換性のブロッカーとしての役割を示唆していますが、それは確実な指標ではありません。例えば、すべてのエンジンが同じように失敗した場合、それは残念ですが、互換性があります。ウェブ開発者は他のブラウザよりも一つのブラウザを非難する理由はないでしょう。したがって、全体的なテスト失敗率は、明確にするよりも多くを隠しているのかもしれません。
幸いなことに、wpt.fyi は、単一のエンジンで失敗するテスト、つまり2つのブラウザが機能を正しく実装し、1つだけが適合していないケースのチャートも生成します。しかし、そのコードベースに固有のバグについては、ウェブはより能力が高く、開発コストも低くなるでしょう。数が高いほど、エンジンは進歩を妨げます。
過去8年間、SafariのWebKitナイトリービルドは、FirefoxのGeckoの平均の2倍のWPTテストに独自に失敗しています。WebKitは、同じ期間にChromiumのBlinkエンジンよりも3〜4倍多くの単一エンジン失敗を常に蓄積しています。
執筆時点では、WebKitのナイトリーは単独で約4,200のテストに失敗しており、Geckoが次に2,400件、Blinkは800件弱の独自の失敗で最も互換性があります。これらの相対的な率は長年安定しており、BlinkとGeckoと比較してWebKitへの継続的な投資が低いことを示しています。
JavaScriptのTest262テストスイートが最近追加されたことで、WebKitによる機能障害への寄与はさらに顕著になります。
テスト262 JavaScript適合スイートを含めると、WebKit固有のテスト失敗が大幅に増加していることがわかります。これは、BlinkとGeckoがこの春に新しいTemporal APIをリリースしたためです。Temporalは10年近く開発されており、Cupertinoに突然現れたわけではありません。Safari 27のブログ投稿から判断すると、そしてナイトリーテスト実行の状態によって確認されるように、9月に新機能がリリースされる際に含まれないでしょう。
Appleは規制当局に対し、Safariは十分に能力があり、チームは潤沢な資金を持っているため、iOSブラウザで真の選択肢は必要ない、と繰り返し主張しています。これらの主張が、長年期待されてきた機能に対する恥ずかしいほどのパフォーマンスとどのように整合するかは不明です。Appleはその機能に反対していません。
機能対テスト
この可視化によって提起される一つの批判は、テストは機能ではないということです。一部の領域(Temporalなど)には多くのサブテストを含む網羅的なテストスイートが含まれており、相対的な数値を押し上げています。他の機能は基本的または内部的に複雑かもしれませんが、相対的に少ないWPTテストしか持たない場合があります。
幸いなことに、webstatus.dev は同じデータの機能中心のビューを収集しています。過去10年間を見ると、WebKitが機能がユーザーや開発者にとって利用できない主な理由であり、Appleが30%のカットを要求するApp Storeへの強制を余儀なくされています。
2026年6月30日現在、Safariは59の機能を単独でブロックしており、Firefoxは43の機能を広く利用可能にするのを妨げており、Chromiumは9の機能をブロックしています。
Blinkは過去10年間、機能と適合性において一貫してリードを維持していますが、iOSユーザーは、どのブラウザを選択しても、Appleのバグが多く、能力の低いエンジンに閉じ込められています。
大規模で、十分にテストされ、議論の余地のないプラットフォームの領域を見ると、そのギャップは単にAppleが問題視している機能だけによるものではないことがわかります。Cupertinoが完全にコミットしている分野でさえ、一貫して遅れをとっています。
Mozillaはすべての収益源から年間約5億ドルを稼ぎ、その大部分をブラウザ開発に費やしていることを思い出してください。一方、AppleはGoogleとのウェブ検索契約から年間200億ドル以上を稼いでおり、その40倍です。それほど多くの現金が利用可能であれば、WebKitはすべての競合を打ち負かすはずです。それにもかかわらず、負けているわけではない場合でも、かろうじて中位に位置しています。
安定版FirefoxはCSSテストの84.9%に合格していますが、Safariは86%に達しており、1.1%の差です。
ナイトリー版の結果は、Safari 27がFirefoxに対するAppleのリードを1.6%に広げることを示唆していますが、Chromiumの安定版とカナリア版(それぞれ93.4%と95.5%)の両方に遅れをとっています。改善は改善ですが、Appleのレイアウトエンジンは依然としてO(n^2)の振る舞いに満ちています。MozillaとChromiumコミュニティは、レンダリングパフォーマンスを向上させるために複数年の再設計プロジェクトに資金を提供しましたが、Appleは同様の投資を行っていません。
ネットワーキングのような他の議論の余地のない分野でも、Appleのエンジンは、今日および将来において、大きく劣っています。fetch仕様はブラウザのネットワーキングの基盤であり、WPTスコアは再びWebKitの維持レベルの資金調達の結果を強調しています。