多くのデベロッパーから、ウェブの変更についていくのが難し、その理由を理解するのが難しいというご意見をいただいています。本日より、Chrome Dev Insider という新しいシリーズを開始します。（1）クールでニュースとして価値のある機能、（2）主要なトピックについて Google がどのように決定したか（FLOC の変更など）、エコシステムとの Google の取り組み（Interop 2022 など）、（3）エージェントについて知っておくべき重要な変更点（例: ）についてご説明します。
Google が取り組んでいることについてお伝えしますが、それは 2022 年の 4 つの優先事項のコンテキスト、
- 快適なユーザー エクスペリエンスの実現: パフォーマンス、トランザクション、ID、移行など、ユーザーが直感的に操作できるようにします。
- ウェブ機能の進歩: コンテンツ消費プラットフォームから、OS やハードウェア レベルの緊密な統合を必要とする幅広いエクスペリエンスのためのプラットフォームまで、進化するウェブの役割をサポートします。
- ウェブ開発の簡素化: 意思決定が簡単になり、デベロッパーの生産性が向上します。
- ウェブのプライバシーの向上: デベロッパーによるトラッキングとターゲティングの高度化に伴い、より優れたデータ プライバシー保護を求めるウェブユーザーの期待に応えます。
ニュース: 相互運用 2022 年
ロードマップの計画では、デベロッパーからのフィードバックに目を向け、特にウェブ デベロッパーが抱える課題やニーズを理解しています。繰り返し登場する主要なテーマは、ブラウザの互換性です。これにより、どのブラウザでも動作が統一されます。Google ではこの 1 年間、エコシステムと連携して「ウェブ開発を簡素化する」という優先課題の一環として、このテーマへの取り組みを続けてきました。
昨年、Microsoft、Chrome、エコシステムのプレーヤーが Compat 2021 を発表した結果、すべての一般的なブラウザ エンジン（Chromium、Gecko、Webkit）は、その年に特定された 5 つの重点分野において 90% 以上のスコアを獲得しました。特に Compat 2021 は、CSS Grid（使用率 12% で着実に増加）や CSS Flexbox（使用率 77%）といったパワフルな機能のための強固な基盤の構築につながりました。
先月には、Apple、Bocoup、Google、Igalia、Microsoft、Mozilla がサポートとして協力して、ウェブ デベロッパーが特定したブラウザの互換性に関する主な問題を解決し、共通のベンチマークで合意しました。その結果として作られたのが Interop 2022 で、プラットフォームの均一性を高めることを目的とするプロジェクトです。このベンチマークは、開発者が生産性向上の鍵として特定した 15 の優先分野に焦点を当てています。
情報通向け情報: 他のブラウザとの連携
私は、Interop 2022 を念頭に置いて、これらの会話に関わった Robert Nyman と Philip Jägenstedt に話を聞きました。編集長から入手したコンテンツを紹介します。
この取り組みのきっかけは何ですか？
Robert:すべては 2019 年に MDN DNA 2019 調査を行ったときに始まりました。互換性の問題が、ウェブ向けの開発を行うデベロッパーにとって特に大きな問題として際立っていました。これについては、2020 年の MDN ブラウザ互換性レポートで詳しくご紹介しています。これにより、Compat 2021 の取り組みを開始するのに十分な情報と実用的なデータが得られ、この作業を継続するとともに、Interop 2022 でこの範囲を拡大することができました。
Philip: web-platform-tests と State of CSS 2021 についてもお伝えしたいと思います。ここ数年、他のブラウザ ベンダーと緊密に連携して WPT を使用したテストを行ってきました。ぜひ協力したいと考えました。これらの機能のテストの大部分は作成済みのものであるため、必要なのはテストを見直し、不足しているカバレッジを追加することだけです。Google は wpt.fyi に多額の投資を行ってきましたが、Mozilla も Mozilla を使用して、現在の WPT の成功に感謝しています。もちろん、Mozilla も MDN DNA 調査で大きな役割を果たしました。それ以外に、State of CSS 2021 もあります。Interop 2022 のような取り組みをまとめるには、ウェブ デベロッパーのニーズについて最新の情報を得る必要があるため、アンケートのメンテナンス担当者である Sacha と協力し、ブラウザの互換性の問題に関する新しい質問をいくつか追加しました。このことは、Interop 2022 のプランニング プロセスで大いに役立ちました。
Compat 2021 で得られた知見やフィードバックはありますか。
Robert:各ブラウザ エンジンのパフォーマンスを測定してスコアと分析情報を取得できたことで、進捗状況を追跡し、不明瞭な問題や優先すべき問題を確実に議論して対処することができました。また、「相互運用」の方がイニシアチブの名称が適切であることもすぐにわかりました。通常、互換性と相互運用性という用語は、ブラウザ ベンダーによって区別されます。互換とは、サイトの互換性のこと、相互運用性は、同じ動作をする 2 つ以上のブラウザを指します。その用語では、この取り組みは相互運用性に関わるため、プロジェクトはその名称と一致しています。
Google のビジョン
Robert: ウェブをオープンな状態に維持するには、ブラウザとレンダリング エンジンの多様性が不可欠です。残念ながら、開発者にとっては今のところ高額なものになっていて、各エンジンの機能に対する異なるレベルのサポートに対応しなければなりません。Google のビジョンは、開発者がウェブ プラットフォームをニーズを満たす最も現実的な選択肢であり、最も魅力的な選択肢と考え、相互運用性の問題に多くの時間を費やすことなく、可能な限り最良のエクスペリエンスを構築することに集中できるようにすることです。この目標を達成するには、開発者がウェブ プラットフォームで成功するためには、最も求められているすべての機能を主要なブラウザ エンジンのすべてに対応させる必要があります。
異なる（ときには）異なる目標を持つブラウザが登場する場合、全体として物事を進めるにはどうすればよいのでしょうか。
Philip: 私たちのアプローチは、共通の関心領域を探し、双方にメリットがある、目標がだいたい一致しているコラボレーションを見つけるというものです。限られた数のことを優先して同時に取り組むことで、そうした分野に焦点を合わせることで、単に個別に作業した場合よりも速く前に進展し、より高い品質を実現しています。以上です。
私は、このコンセンサスに基づくアプローチには限界があることを認識することが重要です。目標が十分に一致していないので、別の方法で前進する必要があります。ウェブ デベロッパーやユーザーのニーズの証拠となる証拠も提供できることもありますが、最終的にはブラウザ ベンダーが提供できる範囲が広範に及ばないこともあります。最良のケースは、ウェブ デベロッパーがその機能を試してニーズを解決し、すべてのブラウザで同じ機能を求めることで、その機能の価値を実証することです。
相互運用 2022 年を振り返って、デザイン以外の機能やレイアウト機能を組み込む予定はありますか？
Philip: はい。相互運用 2022 は、スタイル設定とレイアウト機能に限定されるものではありませんでしたが、CSS の活用も進んでいます。その理由の 1 つは、State of CSS 2021 が新鮮だったことです。それだけでなく、ウェブ デベロッパーがブラウザの違いによって最も難しいという声を聞いているところでもあります。CSS だけでなく、フォームやダイアログの要素など複数の重点分野があります。また、API、ポインタおよびマウスイベントの編集に関する調査も行っています。Interop 2023 では、ウェブ全体でのデベロッパーのニーズに関する最新のデータを入手し、より多くの機能を組み込むことを願っています。
今後予定されている主な変更
このシリーズの目的の一つは、今後予定されている重要な変更点をデベロッパーに前もって提供することです。これらは、ユーザー エクスペリエンスやプラットフォームの機能を向上させるために重要なことです。
下記のタイムラインは、これらの変更の発生が見込まれる時期です。ただし、機能のリリース バージョンは変更される場合があります。
ユーザー エージェントの情報量削減
User-Agent ヘッダーとそれに関連付けられた JS インターフェースは、ブラウザやデバイスの有用な情報を伝えるだけでなく、リネージや不正確な情報というレガシー情報も保持します。UA 文字列の解析バグがほぼ無限に増加するなかで問題となるのは、すべてのナビゲーション リクエストとサブリソース リクエストに対して、UA 文字列が受動的にサーバーに送信されることです。これは約 10 ビットのエントロピーを表します。ユーザーがウェブ上を移動する際に、それを使用して安定したトラッキング ID を作成できます。
現在の計画では、低エントロピーのブラウザのメジャー バージョン、プラットフォーム名、モバイルネスのリリースを継続し、高エントロピー情報を凍結することで、既存の UA 文字列を削減します。ヘッダーに含まれている情報よりも追加情報が必要なユースケース向けに、Chrome 89 以降、User-Agent Client Hints API を提供しています。
Google は実験とフィードバックのためにオリジン トライアルを 6 か月間実施しましたが、参加者は 200 人を超えていましたが、障害に関するフィードバックはありませんでした。
- タイムライン: Chrome 101 では、フェーズ 4 として UA 文字列の
MINOR.BUILD.PATCH情報を0.0.0に減らす取り組みを進めています。各サイトには、今後もフェーズ 5 以降に向けた準備について事前にお知らせし、準備期間を設けます。また、この変更をオプトアウトするためのエンタープライズ ポリシーも作成しています。また、Chrome 113 まではサポート終了トライアルを実施し、サイトがこの変更に対応するための猶予期間を設ける予定です。 - 行動を促すフレーズ: サイトを UA Client Hints に移行するか、サポート終了トライアルに参加してください。
Local Fonts Access API
Chrome で Local Font Access API がリリースされます。サイトでは長い間ローカル フォントを使用できましたが、この API はローカル フォントのリストを列挙し、フォントデータ自体にアクセスできるようにします。この機能により、ユーザーはウェブベースのデザインやその他のアプリケーションですべてのフォントを使用できます。
ローカル フォントは長い間、フィンガープリント ベクターとして知られています。この新しい API でフィンガープリントにフォントを使用できる機能が増えることはありませんが、Chrome で新しい Local Font Access API を使用するには、サイトに対して新しい "local-fonts" 権限を付与する必要があります。
将来的には、ローカル フォントへのアクセスを提供する他の API を使用する前に、同じ「local-fonts」権限を付与する必要があります。
BFCache を Cache-control: no-store と連携させる
Google は、戻る/フォワード キャッシュが即座に「戻る/進む」ナビゲーションを提供する頻度を向上させる可能性が高いことを発見しました。そのためには、Cache-control: no-store HTTP ヘッダーで配信されたページでの BFCache の動作を変更する必要があります。Google では、さまざまなシグナルをモニタリングし（HTTP のみの Cookie が変更されるたびに BFCache からページを削除するなど）、固有のコンテキストのカーブアウト（Enterprise/Education のお客様向けのグループ ポリシーなど）を行うことで、想定外の事態を防ぐように設計された公開提案を行っています。今回のプログラムは複雑ですが、エキサイティングなプログラムですので、詳しい調査とフィードバックをお待ちしています。
- タイムライン: Chrome 104（2022 年 7 月）を対象にしていますが、特に大きな変更はありません。
- 行動喚起: 詳細については、提案をご覧ください。進行中の実装を可能にする方法や、Google のアプローチが新たなハードルをもたらす実際のシナリオなどのフィードバックを共有する方法などが記載されています。
このシリーズを通じて、デベロッパー コミュニティが私のチームやその仕事をより身近に感じられるようにすることで、集中力とつながりを感じられるようにしたいと考えています。今後の最新情報にもご注目ください。
どうぞよろしくお願いいたします。
Chrome Dev Insider の初版についてどう思われましたか。フィードバックをお寄せください。