特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。（2021 年 1 月 28 日に Chrome 89 がベータ版としてリリースされた時点の情報です）

WebHID API

ヒューマン インターフェース デバイス（HID）には、新しすぎる、古すぎる、あまりにも一般的でないなどの理由で、システムのデバイス ドライバからアクセスできないロングテールなものがあります。WebHID API は、デバイス固有のロジックを JavaScript で実装する方法を提供することで、この問題を解決します。

ヒューマン インターフェース デバイスは、人間からの入力を受け取ったり、人間に対して出力を提供したりします。デバイスには、キーボード、ポインティング デバイス（マウス、タッチスクリーンなど）、ゲームパッドなどがあります。

たとえば、ゲームパッドのサポートにおいては、一般的でない HID デバイスにアクセスできないのは特に苦痛です。ゲームパッドの入出力はうまく標準化されておらず、多くの場合、ウェブブラウザに特定のデバイス向けのカスタム ロジックが必要となります。これはサステナブルでなく、古いデバイスや一般的でないデバイスといったロングテールがサポートされないことになります。

WebHID のオリジン トライアルは終了し、PC 向けの Chrome 89 でデフォルトで有効になります。使用方法については、一般的でない HID デバイスに接続するで確認できます。ウェブのヒューマン インターフェース デバイス : いくつかの簡単な例のデモもご覧ください。

Web NFC

NFC とは少量のデータを転送する近距離無線通信のことで、通常は専用の NFC デバイスとリーダー間の通信に使用します。建物に入るためにバッジをスキャンしたことがある方なら、NFC を使っているかもしれません。

Web NFC を利用すると、ウェブアプリから NFC タグの読み書きができます。これにより、博物館で展示情報を提供する、在庫を管理する、カンファレンスのバッジに情報を登録するなど、ウェブでさまざまな新しいユースケースを実現できるようになります。Web NFC は、Android 版の Chrome 89 でデフォルトで有効になります。

Chrome Dev Summit での Web NFC カードのデモ

NFC の読み書きは簡単なオペレーションで行うことができます。ペイロードの構築や解釈にいくつかの命令が必要になりますが、複雑ではありません。うれしいことに、ウェブで NFC デバイスと連携するという記事もありますので、ぜひご覧ください。実際に試してみることができるいくつかのサンプルもあります。次のようなイメージです。

NFC タグに文字列を書き込む :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.write("Hello world!");
}

NFC タグのメッセージをスキャンする :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.scan();
  ndef.onreading = ({ message }) => {
    console.log(`Records read from a NFC tag: ${message.records.length}`);
  };
}

Web Serial API

シリアルポートは、データをバイト単位で送受信できる双方向通信インターフェースです。Web Serial API は、この機能をウェブサイトで実現し、マイクロコントローラや 3D プリンタなどのデバイスを制御できるようにします。

教育、趣味、工業の分野では、すでにウェブページから周辺機器を制御しています。その場合、デバイスの制御にはアダプターやドライバのインストールが必要です。Web Serial API は、ウェブサイトと周辺機器の直接通信を可能にすることで、ユーザー エクスペリエンスを改善します。

Web Serial API のオリジン トライアルが終了し、PC で有効になります。GitHub でデモが公開されています。使用方法については、シリアルポートの読み書きを行うをご覧ください。

PC でのウェブ共有

デベロッパーは、ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするため、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込んでいます。このため、ユーザーが実際に使っているサービスで共有できないことが多く、ページサイズの肥大化やサードパーティ製コードによるセキュリティ リスクも発生しています。受信側では、共有ターゲットとして登録して他のアプリからの共有を受け取ることができるのは、プラットフォームのアプリのみです。

Android 版の Chrome では、Chrome 61 から 75 の間でこれらの機能の追加を始めました。Chrome 89 では、ウェブ共有が Windows と ChromeOS でも利用できるようになります。ただし、共有ターゲットとしての登録は ChromeOS のみでサポートされます。これらのプラットフォームでは、PC のサイトで navigator.share() を使うと、共有ダイアログ ボックスを開くことができます。また、ウェブアプリ マニフェストのエントリを追加すると、PWA を共有ターゲットにすることができます。

ウェブ共有についての情報は、Web Share API で OS の共有 UI を組み込むをご覧ください。PWA を共有ターゲットにすることについての詳しい情報は、Web Share Target API で共有データを受け取るをご覧ください。

オリジン トライアル

このバージョンの Chrome には、新しいオリジン トライアルはありません。現在のオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

今回のリリースに追加されたその他の機能

AVIF 画像のデコード

Chrome が AVIF コンテンツのデコードをネイティブにサポートします。Android と WebView は既存の AV1 デコーダを利用します（PC 版でのサポートは、Chrome 85 で追加されました）。AVIF は次世代の画像フォーマットで、Alliance for Open Media が標準化しています。AVIF のサポートには、主に 3 つの目的があります。

• ページ読み込みを高速化して全般的なデータ消費量を削減するため、使用する帯域幅を減らします。AVIF を使うと、JPEG や WebP に比べて画像のファイルサイズを大幅に削減できます。
• HDR カラーをサポートします。AVIF は、ウェブでの HDR 画像のサポートに向けた一歩です。JPEG の色深度は、実質的に 8 ビットに限られています。輝度、色ビット深度、色域の面でディスプレイの機能が強化されていることから、JPEG では失われる画像データを保存したいと考えるウェブ関係者が増えています。
• エコシステムの関心に対応します。ウェブにおいて大きな存在感を持つ企業が、ウェブに AVIF 画像を掲載することに興味を示しています。

Cross-Origin Opener Policy Reporting API

新しい Reporting API は、Cross-Origin Opener Policy (COOP) のデプロイに役立ちます。この API は、COOP が強制される際の違反の報告に加え、COOP の報告のみのモードも提供します。COOP の報告のみのモードは COOP を強制しませんが、COOP を強制していれば発生していた潜在的な違反を報告します。デベロッパーは、Chrome DevTools で Reporting API が有効になっているかを確認できます。

ウェブアプリ マニフェストでの display のオーバーライド

ウェブアプリ マニフェストに display_override フィールドが新しく追加されます。これにより、デベロッパーが display フィールドのフォールバック チェーンを明示的に指定できるようになります。次の例では、"minimal-ui" を "standalone" にフォールバックする指定をしています。

{
  "display": "standalone",
  "display_override": ["minimal-ui"],
}

この API は、高度なユースケースと表示モードを想定したもので、機能は限られています。詳しくは、Chrome Status のエントリをご覧ください。

ReadableStreamDefaultController インターフェースの公開

Chrome は、他の ReadableStream 関連のクラスと同じように、グローバル オブジェクトで ReadableStreamDefaultController インターフェースを公開します。これにより、インスタンスをストリームのコンストラクタの内部で作成しなければならないという、これまでの制限がなくなります。

performance.measureUserAgentSpecificMemory()

この機能により、ウェブページのメモリ使用量を見積もる performance.measureUserAgentSpecificMemory() 関数が追加されます。このメソッドは COOP/COEP の制限を受けるので、これを使うにはウェブサイトがクロスオリジン分離されている必要があります。

潜在的に信頼できる data: URL

現在のウェブ標準に準拠するため、Chrome はすべての data: URL を潜在的に信頼できるものとして扱います。
これは、認証や機密性に関して最低限の基準しか満たされていない場合でも、ある機能を有効化するためには、URL が安全かどうかを評価しなければならないことがあるためです。ウェブ標準は、それを実現するために「潜在的に信頼できる URL」の定義を使いますが、最新版の Secure Contexts 仕様では、そこに "data" スキームの URL が含まれています。これまでの Blink は、いくつかの data: URL のみを潜在的に信頼できるものとして扱っていました。

Streams API: バイト ストリーム

ストリーム API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。Chrome は、バイトを表すストリームで拡張バージョンの読み取り可能ストリームをサポートし、バイトを効率的に扱います。具体的には、コピーの回数を最低限にとどめます。

バイト ストリームは、Bring Your Own Buffer（BYOB）のリーダーを取得できます。デフォルトの実装では、ウェブソケットの場合は文字列や配列バッファなどのさまざまな種類の出力を指定できますが、バイト ストリームではバイト出力が保証されます。さらに、BYOB リーダーを扱えることで、安定性のメリットももたらされます。バッファがデタッチされれば、同じバッファに 2 回書き込まれないことが保証され、競合状態を回避できるためです。BYOB リーダーではバッファが再利用されるため、読み取りのたびにガベージ コレクションを行う必要もありません。

SVG 要素での完全な 'filter' プロパティ構文のサポート

Chrome の SVG 要素で 'filter' プロパティの完全な構文が利用できるようになります。これまでは、1 つの url() 参照しかサポートされませんでした。これにより、blur()、sepia()、grayscale() などのフィルタ関数を SVG 要素と非 SVG 要素の両方に適用できるようになります。また、'filter' のプラットフォーム サポートの均一性が増し、一部の「定型」エフェクトを適用しやすくなります。この機能がないときは、grayscale() や blur() といった基本的なフィルタを使う場合でも、SVG の完全な <filter> 要素定義を使う必要がありました。

WebAuthentication API: ResidentKeyRequirement と credProps エクステンション

Chrome で Web Authentication API に関連する 2 つの新機能がサポートされます。AuthenticatorSelectionCriteria.residentKey プロパティは、ウェブ認証のクレデンシャル登録において、クライアント側で検出可能なクレデンシャルを作成するかどうかを指定します。

Web Authentication の credProps エクステンションは、作成したクレデンシャルがクライアント側で検出可能（discoverable）かどうかをリライング パーティに示します。「クライアント側で検出可能なクレデンシャル」とは、WebAuthn API リクエストでリライング パーティがクレデンシャル ID を提供することなくチャレンジを行えるタイプの WebAuthn クレデンシャルです。ブラウザは、指定された認証器（外部セキュリティ キーか組み込みのもの）からのすべての検出可能なクレデンシャル（discoverable credentials）のリストを表示し、ユーザーがログインに使うものを選択できるようにします。

CSS

::target-text 疑似要素

scroll-to-text フラグメントにデフォルトのユーザー エージェントのハイライトとは違うスタイルを設定できるようにするため、ハイライト疑似要素を追加します。

フロー関連の角丸プロパティ

フロー関連の角丸プロパティで、物理プロパティではなく論理マッピングを使って角を制御できるようになります。これにより、ページの向きや表記の方向によって異なる角丸の半径を設定することも可能になります。また、Chrome が CSS Logical Properties and Values 仕様に準拠することになります。以下の論理プロパティが追加されました。

• border-start-start-radius
• border-start-end-radius
• border-end-start-radius
• border-end-end-radius

強制カラー プロパティ

forced-colors メディア機能は、ページでユーザーが選択した限定カラーパレットをユーザー エージェントが強制しているかどうかを検出します。

強制カラー調整プロパティ

forced-color-adjust プロパティを使うと、強制カラーモードから特定の要素を除外し、CSS で完全にカラーを制御する状態に戻すことができます。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.9 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

トップレベルの await

Chrome では、JavaScript モジュールのトップレベルで await キーワードが許可されるようになりました。これにより、モジュールの読み込み処理に非同期呼び出しをシームレスに統合できるようになります。現在のところ、この機能はモジュールを async 関数でラップすることで実現していますが、これにより複雑さを依存モジュール側にとどめつつ、実装の詳細を公開しています。

デベロッパー ノート

EXIF の画像の向き

クロスオリジン画像の向きの判定に常に EXIF 情報が利用されるようになります。つまり、CSS で image-orientation: none を設定しても、安全でないオリジンの画像には反映されなくなります。この仕様変更に関する議論は、CSS ワーキング グループ ドラフトに記載されています。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

<link rel=prerender> のプレフィックス付きイベントの削除

<link rel=prerender> から発行されるレガシーなプレフィックス付きイベント（webkitprerenderstart、webkitprerenderstop、webkitprerenderload、webkitprerenderdomcontentloaded）が Chrome から削除されます。

noopener で開いたウィンドウでの sessionStorage の複製停止

ウィンドウを noopener で開いた場合、Chrome はオープン元の sessionStorage を複製しなくなります。代わりに、空の sessionStorage 名前空間が開始されます。これにより、Chrome が HTML 仕様に準拠します。

• ConversionAdjustment
• ConversionAdjustmentLagBucket
• ConversionAttributionEventType
• ConversionCategoryName
• ConversionLagBucket
• ConversionTrackerId
• ConversionTypeName

• AllConversionRate
• ConversionRate
• CostPerAllConversion
• CostPerConversion
• CostPerCurrentModelAttributedConversion

パスワードはオンライン情報の保護に役立ちます。パスワードを安全に保つことが何よりも重要なのはそのためです。しかし、ショッピングやエンターテイメントから個人の金融取引まで、さまざまなウェブサイトで数十個（場合によっては数百個）のパスワードを扱うとなれば、常に新しいアカウントの設定や管理に追われているように感じます。もちろん、アカウントごとに強固で一意なパスワードを設定することがベスト プラクティスではありますが、それらすべてを記憶しておくのは難しいことかもしれません。そこで、皆さんをサポートするため、Chrome にパスワード マネージャーを設けています。

スマートフォンやコンピュータ、タブレットでウェブをブラウズするとき、Chrome なら、1 クリックでパスワードを作成、記憶、自動入力できます。サイトにログインした後、パスワードが侵害されていた場合は警告が表示されます。また、Chrome の設定から常に自分でチェックすることもできます。そして、うれしいお知らせがあります。新しいアップデートにより、パスワードをさらに細かく管理できるようになりました。

脆弱なパスワードを簡単に修正

皆さんもきっと、急いで新しいログインを設定したくて、単純な「ペットの名前」のようなパスワードを設定してしまったことがあるはずです。しかし、脆弱なパスワードはセキュリティのリスクとなるので、避けるべきです。Chrome 88 では、シンプルなチェックで脆弱なパスワードを見つけて、簡単に対応できるようになります。

パスワードをチェックするには、プロフィール画像の下にある鍵アイコンをクリックするか、アドレスバーに chrome://settings/passwords と入力する

Chrome には、ウェブサイトにログインする際に保存済みのパスワードの更新を促す機能がすでに組み込まれています。しかし、1 か所で複数のユーザー名とパスワードを簡単にアップデートできれば便利だと思う方もいるでしょう。そこで、PC 版と iOS 版の Chrome 88 より、Chrome の設定からすべてのパスワードをすばやく簡単に管理できるようにします（Chrome の Android アプリも近日中に対応予定）。

2020 年の改善に続いて

今回の新たなアップデートは、昨年行われたたくさんの改善が土台になっており、そのすべてが、オンラインの安全性を向上させ、ウェブのブラウズをさらに簡単にするために貢献しています。

• パスワードの漏洩は、オンラインの重大な関心事であり続けています。うれしいことに、Chrome の安全確認は毎週 1400 万回も使われています。2020 年に安全確認などの改善を導入した結果、Chrome に保存した認証情報の侵害は 37% 減少しています。
• 昨年 9 月より、iOS ユーザーは保存したパスワードを他のアプリやブラウザに自動入力できるようになりました。現在、Chrome はさまざまな iOS アプリで毎週 300 万回のログインを効率化しています。また、iOS ユーザーの Chrome に生体認証を追加することで、パスワードの自動入力がさらに安全になりました（Android 版 Chrome も近日中に対応予定）。
• Google は、ユーザー エクスペリエンスを改善する方法を常に探しています。タッチして自動入力などの機能で Android 版のパスワード マネージャーをさらに使いやすくしました。

パスワードを安全に保つため、ぜひ新しいアップデートを利用しましょう。2021 年もすばらしいパスワード機能が登場する予定なので、ご期待ください。

AMP コミュニティから特に多く寄せられている要望の 1 つは、高パフォーマンスな AMP コンポーネントを AMP 以外のページでも利用できるようにすることです。AMP Project はこの要望に対処するため、2 年にわたって Bento AMP と呼ばれる取り組みを懸命に進めてきました。その具体的な目的は、完全な AMP ランタイムを使わなくても、AMP コンポーネントがもたらすパフォーマンスとユーザー エクスペリエンスのメリットを活用できるようにすることです。今日のデベロッパー プレビューのリリースにより、その実現に向けて 1 歩前進したことをお知らせします。Bento コンポーネントを試してみたい方は、スタートガイドをご覧ください。

あらゆる場所で AMP コンポーネントを使う理由

AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。この価値提案の中核にあるのは、高パフォーマンスでユーザー中心の AMP コンポーネントです。今回、Bento AMP によって、必要な場所で AMP コンポーネントを使えるようになります。お気に入りのフレームワークや CMS と AMP コンポーネントを組み合わせることができるのです。

たとえば、カルーセルを AMP 以外のページに追加する、有効な AMP を作成する過程で AMP コンポーネントをテストするなど、1 回限りのケースで Bento コンポーネントを使うことができます。Bento AMP プロジェクトの最新の進捗状況は、GitHub のワーキング グループで確認できます。または、AMP の次の展開をご覧ください。

デベロッパー プレビュー

現在のリリースは、いくつかのスタンドアロン AMP コンポーネントのデベロッパー プレビューです。その目的は、今回の実装の技術的な成否に関するフィードバックを集めることです。現在の Bento AMP コンポーネントにはまだ AMP ランタイムが必要ですが、コンポーネントはページが「有効な AMP」でなくても動作します。つまり、ページにスタンドアロン AMP コンポーネントをインポートし、必要に応じて他のカスタム JavaScript と連携できます。

Bento AMP コンポーネントを試す

始めるにあたっては、まずこちらのガイドをお読みください。今回のデベロッパー プレビューの期間中は、以下の Bento コンポーネントを試験運用版として利用できます。

• amp-accordion
• amp-base-carousel
• amp-inline-gallery
• amp-stream-gallery
• amp-date-countdown
• amp-date-display
• amp-fit-text
• amp-instagram
• amp-lightbox
• amp-selector
• amp-social-share
• amp-timeago
• amp-youtube
• amp-video

なお、これはデベロッパー プレビューなので、AMP ページで Bento コンポーネントを利用すると、ページは有効でなくなります。この点は、正式版をリリースする際には対応したいと考えています。デベロッパーの皆さんからフィードバックを集めるため、これら最初の Bento AMP コンポーネントを提供できるのはうれしいことですが、Bento コンポーネントのデベロッパー プレビュー期間中に AMP エクスペリエンスをデプロイする場合は、最新の本番バージョンの AMP コンポーネントを使って有効な AMP ページを作成することをお勧めします。

Bento の未来

将来的には、完全版をリリースして Bento コンポーネントをすべての HTML ドキュメントで利用できるようにする予定です。それにより、高パフォーマンスなコンポーネントを使ってすばらしいページ エクスペリエンスを作成できるようになります。そのための変更は今年中に行う予定なので、ご期待ください。

その次は、React バージョンの Bento コンポーネントを npm パッケージとして公開することも計画しています。これにより、React アプリが Bento AMP コンポーネントをさらに簡単に使えるようになります。

今すぐ Bento をお試しください！

Bento AMP コンポーネントを試してみたい方は、スタートガイドをご覧ください。AMP チームは、GitHub や Slack チャンネルからフィードバックを送ることを推奨しています。フィードバックは大歓迎です。ぜひご協力ください。質問や問題がある方も、遠慮なくご連絡ください。

投稿者 : Naina Raisinghani（AMP Project、プロダクト マネージャー）

• APP_AD
• APP_ENGAGEMENT_AD 
• CALL_ONLY_AD
• EXPANDED_DYNAMIC_SEARCH_AD
• GMAIL_AD
• HTML5_UPLOAD_AD
• IMAGE_AD
• LEGACY_APP_INSTALL_AD
• LOCAL_AD
• RESPONSIVE_DISPLAY_AD
• RESPONSIVE_SEARCH_AD
• VIDEO_RESPONSIVE_AD

• リクエスト : それぞれのオペレーションについて、Google Ads API は、フィールド policy_validation_parameter の PolicyValidationParameter.ignorable_policy_topics にリストされ、リクエストされた免除のみを考慮します。PolicyValidationParameter.exempt_policy_violation_keys は考慮されません。
• レスポンス : Google Ads API は、フィールド GoogleAdsError.error_code の PolicyFindingErrors として広告ポリシーエラーのみを返します。詳細はフィールド GoogleAdsError.details の PolicyFindingDetails で提供されます。PolicyViolationErrors や PolicyViolationDetails では提供されません。

• すべての広告ポリシーはそのままで、すべての広告ポリシー チェックも引き続き行われます。
• AdWords API
• 広告ポリシー ステータス情報 AdGroupAdPolicySummary には、フィールド AdGroupAd.policy_summary に対してクエリを実行することで、引き続きアクセスできます。

Google Ads API チーム、Pierrick Voulet

この記事は The AMP Blog の記事 "Correlation between Core Web Vitals and AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ : 以下の抜粋記事の出典は、Google のデータ サイエンティスト、Sixing Chen による HTTP Archive Blog への投稿です。より広い AMP コミュニティで共有するため、著者の許可を得た上で以下に転載します。詳細については、出典元のブログ投稿をご覧ください。

はじめに

HTTP Archive Blog に掲載された最近の分析は、Core Web Vitals（CWV）とさまざまなウェブの特性との相関関係に着目しています。CWV はウェブ体験の質を表し、Google が特に重視する指標です。この調査では多くの技術を分析しており、因果関係を示唆するものではありませんが、AMP に関する結果は早い段階で AMP の大きな可能性を示しています。すなわち、AMP はユーザーにすばらしい体験を提供し続け、デベロッパーにとって費用対効果の高いソリューションとなる可能性をもっています。

この調査の目的は、「さまざまなウェブ開発の選択肢を評価する際の参考として、CWV とウェブの特性との関連性について理解を深めるために役立ててもらうこと」にあります。この調査では、HTTP Archive のデータを使用して、CWV といくつかのウェブ技術（JavaScript フレームワーク、JavaScript ライブラリ、CMS、UI フレームワーク、ウェブ フレームワーク、ウィジェットなど）との相関関係を分析しました。 

AMP についての結果を以下に掲載します。斜体になっている部分は、すべて元の調査からの転載です。 

結果

ここでは、関連性についての結果を示すとともに、特に CWV への影響が大きいと思われる特徴的な点について記載します。

関連性についての結果を解釈するうえで重要な点があります。それは、特定のウェブ特性への正の影響と負の影響は、他のウェブ特性との比較においてのみ、また、多くのウェブ技術、多種多様なコンテンツ、さまざまなサードパーティ リクエストが混在したウェブサイトという前提でのみ解釈すべきであるという点です。たとえば、あるウェブ技術が強い正の影響を示していた場合、その技術は他の技術と比べてパフォーマンスが優れているようだと解釈すべきです。その技術をウェブサイトに導入すれば、ウェブのパフォーマンスが向上すると解釈することはできません。

LCP

LCP は数値の対数としてモデリングするので、高いほど悪いことになります。

%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と高い LCP 値には強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が高くなるほど悪化する）。

同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、LCP に強い負の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな正の数になるほど悪化する）。

…

ほとんどの JavaScript フレームワークは LCP と強い正の相関を示すので、悪影響が生じることになりますが、AMP は例外です。特に影響が大きいのは、AngularJS、GSAP、MooTools、RequireJS です。

…

CLS

CLS は、与えられたしきい値を満たすかどうかを示すバイナリ インジケーターとしてモデリングします。1 はウェブサイトの CLS が 0.1 未満、0 はそれ以外であることを示します。そのため、1 は 0 より優れています。

%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と CLS がしきい値を満たすことに強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が低くなるほど悪化する）。

同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、CLS がしきい値を満たすことに強い正の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな負の数になるほど悪化する）。

いくつかの JavaScript フレームワークは、CLS がしきい値を満たすことと強い負の相関を示すので、悪影響が生じることになります。ただし、AMP、GSAP、React では相関性と影響が低くなっています。AngularJS、Handlebars、Vuejs は特に負の影響が強いものでしょう。

…

AMP にとっての意味

AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。AMP Performance Working Group は、ウェブ上の AMP ページのパフォーマンスを継続的に管理し、定期的に AMP ライブラリのパフォーマンスを強化するアップデートをています。また、AMP は常に最新の状態を維持するライブラリなので、デベロッパーは何の追加作業も必要なく改善点を活用できます。AMP Project には、デベロッパーが簡単に Core Web Vitals のしきい値を満たせるようにするという役割があります。それを果たしている証拠として、上のような相関性についての調査結果を確認できることは私たちの喜びです。 

Google 検索では、ランキングにおけるページ エクスペリエンス シグナルの利用がまもなくロールアウトされる予定です。それに向けて、AMP はウェブ パフォーマンスのベスト プラクティスの遵守に役立っており、すべての AMP ページが Core Web Vitals に準拠できるように最大限のチャンスを与えています。私たちは、そこまで到達できたことをうれしく思っています。以上のような理由から、デベロッパーの皆さんには AMP ページ エクスペリエンス ガイドの活用をお勧めしています。このガイドは、アクションにつながるアドバイスを AMP デベロッパーに提供し、AMP ページのページ エクスペリエンスの改善に役立つツールです。 

いつものように、問題や機能リクエストがありましたらお知らせください。AMP ページ エクスペリエンス ガイドに関することは、特に遠慮なくご連絡ください。