デベロッパーの皆様からよく、「ウェブ上の変更についていくのが難しい」、「なぜそのような変更が行われるのかを把握するのが難しい」という声が寄せられています。本日、Chrome Dev Insider という新しいシリーズを開始します。このシリーズでは、（1）画期的で報道価値のあるもの、（2）重要なトピック（FLOC の変更など）の決定やエコシステムとの連携（Interop 2022 など）、（3）ユーザー ストリングスにおける非常に重要な変更（例: ユーザー ストリングスの変更）についてご紹介します。
Google の取り組みを共有する際には、2022 年の 4 つの優先事項
- 快適なユーザー エクスペリエンスを実現する: ユーザーが物事を直感的に理解できるようにします。さまざまな問題があります。
- ウェブ機能の進化: コンテンツ消費プラットフォームから、OS やハードウェア レベルの緊密な統合を必要とする幅広いエクスペリエンスに対応するプラットフォームに至るまで、ウェブにおける進化する役割をサポートします。
- ウェブ開発の簡素化: 意思決定を容易にし、デベロッパーの生産性を高めます。
- ウェブのプライバシーを強化する: ウェブユーザーにデータ プライバシー保護の強化に対する期待が高まっています。
最新情報: 相互運用 2022
ロードマップを計画する際には、特にウェブ デベロッパーの主な課題やニーズを理解するために、デベロッパーからのフィードバックに注目しています。繰り返し表示される主なテーマはブラウザの互換性です。これにより、どのブラウザでも同じエクスペリエンスが実現します。過去 1 年間、Google は「ウェブ開発を簡素化する」という優先事項の一環として、このテーマに取り組むためにエコシステムと協力して取り組んできました。
昨年、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 の優先領域に焦点を当てています。
情報通: 他のブラウザとの連携
相互運用 2022 を念頭に置いて、Robert Nyman と Philip Jägenstedt にインタビューを行い、裏話を伺いました。こちらが編集部のカットです。
この取り組みが生まれたきっかけは何ですか？
Robert: その始まりは 2019 年の MDN DNA 2019 調査から始まりました。ウェブ向けの開発を行うデベロッパーにとって、互換性の問題は明らかに主な問題でした。詳細については、MDN Browser Compatibility Report 2020 をご覧ください。これにより、Compat 2021 の取り組みを開始するための十分な情報と実用的なデータが得られ、この取り組みを継続し、Interop 2022 でそのスコープを拡大することができました。
Philip: web-platform-tests と State of CSS 2021 についてもお伝えしたいと思います。Google は、何年も前から他のブラウザ ベンダーと緊密に連携して WPT を使用したテストを行ってきましたが、それも積極的に活用したいと考えていました。これらの機能のテストのほとんどは作成済みなので、テストをレビューし、不足しているカバレッジを追加するだけで済みました。Google は wpt.fyi に多額の投資を行ってきましたが、現在の WPT の成功には Mozilla が感謝しています。もちろん、Mozilla は MDN DNA の調査でも大きな役割を果たしました。他にも、State of CSS 2021 もあります。Interop 2022 のような取り組みをまとめるためには、ウェブ デベロッパーのニーズについて新たな情報が必要であるため、アンケート管理者の Sacha と協力し、ブラウザの互換性の問題に関する新しい質問をいくつか含めました。これは、Interop 2022 の計画プロセスで非常に役立ちました。
Compat 2021 から学んだことやフィードバックはありますか？
Robert: 各ブラウザ エンジンの稼働状況を測定し、スコアや分析情報を得ることはとても役に立った。これにより、進行状況を確認して、不明瞭な問題や優先する必要がある問題について話し合い、対処することができました。また 「相互運用」は取り組みの方がよいでしょう。「互換性」と「相互運用性」という用語は通常、ブラウザ ベンダーによって区別されます。「互換」とは、同じ動作をする 2 つ以上のブラウザを指します。この用語では、この取り組みは相互運用性に関するものであるため、プロジェクトはその名称に沿ったものとなっています。
Google のビジョン
Robert: ウェブを常にオープンにしておくためには、ブラウザとレンダリング エンジンの多様性が非常に重要です。残念ながら、この方法は現時点で、各エンジンで機能に対するさまざまなレベルのサポートに対応していかなければならないため、デベロッパーにとっては高額です。私たちのビジョンは、開発者がウェブ プラットフォームを最も実行可能な選択肢、ニーズにとって最も魅力的な選択肢であるとみなし、相互運用性の問題に多くの時間を費やすのではなく、可能な限り最良のエクスペリエンスを構築することに集中できるようにすることです。この目標を達成するには、デベロッパーがウェブ プラットフォームで成功を収められるように、最も要望の多かった機能をすべての主要なブラウザ エンジンに組み込む必要があることは明白です。
（場合によっては）異なる目標を持つブラウザが連携して作業を進めるとき、どのように連携すれば前進しますか？
Philip: Google のアプローチは、共通の関心分野を探し、双方にメリットのあるコラボレーションを見つけることでしたが、同時に取り組むべき優先順位を限られたものにすることで、それらの分野に重点を置き、単独で作業する場合よりも迅速に前進し、より高い品質を実現します。そういう考え方です。
このコンセンサスに基づくアプローチには限界があることを認識しておくことが大切です。目標が十分に合致していないと、他のなんらかの方法で前進する必要があります。ウェブ デベロッパーやユーザーのニーズを裏付ける証拠をより多く提供できることもありますが、最終的にはブラウザ ベンダーが幅広い合意がないものも提供する可能性があります。ウェブ デベロッパーがこの機能を試し、ニーズを解決できると判断し、すべてのブラウザで同じ機能を求めることで、機能の価値が実証されることが最良と言えます。
Interop 2022 に話を戻して、今後パイプラインに非設計機能やレイアウト機能が追加されることはありますか？
フィリップ: もちろんです。相互運用 2022 は、スタイル設定とレイアウト機能にとどまらず、最終的に CSS に大きく依存することになりました。State of CSS 2021 が新鮮だったことも、ブラウザの違いによる問題が最も大きいとウェブ デベロッパーから指摘されたことも理由の一つです。フォームやダイアログの要素など、複数の重点分野は CSS の枠にとどまりません。API やポインタやマウスイベントの編集に関する調査も行っています。Interop 2023 では、ウェブ全体におけるデベロッパーのニーズに関する最新のデータを増やし、そのような機能をさらに追加していきたいと考えています。
今後の主な変更
このシリーズでは、今後予定されている主な変更について、デベロッパーにあらかじめお知らせすることを意図しています。ユーザーエクスペリエンスとプラットフォームの機能を改善するために 重要な役割を果たします
下記のスケジュールは、これらの変更が行われる見込みの時期です。ただし、機能のリリース バージョンは変更される可能性があります。
User-Agent の情報量削減
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" 権限を付与する必要があります。
将来的には、同じ「local-fonts」フォントを使用するローカル フォントへのアクセスを提供する他の API を使用する前に、この権限が付与されている必要があります。
Cache-control: no-store で BFCache を機能させる
バックフォワード キャッシュが瞬時に戻る / 進むナビゲーションを提供できる頻度は、改善の余地があることがわかりました。そのためには、Cache-control: no-store HTTP ヘッダーで配信されるページでの BFCache の動作を変更する必要があります。Google では、さまざまなシグナルをモニタリングすることで（HTTP のみの Cookie が変更されるたびに BFCache からページを削除するなど）、独自のコンテキストのカーブアウト（企業/教育機関のお客様向けのグループ ポリシーなど）を行うことで、大きな意外な事態を防ぐための計画を公開しています。これは複雑ですが、刺激的な機会です。さらなる精査とフィードバックをお寄せください。
- タイムライン: Chrome 104（2022 年 7 月）を予定。大きな想定外の展開は予定していない。
- 行動喚起: 進行中の実装を実現する方法や、このアプローチが新たなハードルを生み出す実際のシナリオなどのフィードバックを共有する方法など、詳細については提案をご覧ください。
このシリーズを通じて、デベロッパー コミュニティが私のチームと仕事を身近に感じられるようにすることで、デベロッパー コミュニティが集中力とつながりを感じられるようになれば幸いです。今後も最新情報を随時ご確認ください。
今後ともどうぞよろしくお願いいたします。
Chrome Dev Insider の初版についてご意見をお聞かせください。フィードバックをお寄せください。