Core Web Vitals の採用について、ステークホルダーをなかなか説得できなかったり、実際にビジネスに役立つかどうか疑問に思ったりしていませんか？この記事では、すでにユーザーやビジネスに好影響が出ている企業の例を紹介し、Core Web Vitals と重要なビジネス指標にどのような相関関係があるのかをわかりやすく説明します。
動画で見たい方は、Google I/O のこちらのトークをご覧ください（日本語字幕付き）。
組織では、ステークホルダーによって優先度が異なる場合があります。Core Web Vitals を導入すると、ユーザー中心の指標の最適化と、その結果としてのビジネスの成長に重点を置くことで、全員で共通の認識を持つことができます。
Core Web Vitals のスコアを上げるまでの道のりは、サイトのパフォーマンスが現在どの段階にあるか、デザインがどれだけ複雑かによって、サイトごとに異なります。すぐにたやすく取り組めて有意義な結果につながる場合もあれば、複雑なソリューションを実装して困難な問題を解決しなければならない場合もあります。意思決定者は、費やす時間にかかわらず、これをビジネスの成長のための長期的な投資として扱うべきです。高速でシームレスなナビゲーション体験を提供すれば、ユーザーは喜び、忠実なリピーターになります。プロダクト マネージャーにとって、パフォーマンスは新しいプロダクト機能の質と成功を定義する重要な基準です。また、優れたプロダクトを生み出すことや、やりがいのある課題に取り組むことは、デベロッパーの満足度の向上にもつながります。
ランキング シグナルとしての Core Web Vitals は、パフォーマンスに時間をかけて取り組むもう 1 つの動機となりますが、Core Web Vitals を採用すると、ランキングにとどまらず、さまざまな短期的、長期的メリットが得られます。Core Web Vitals を（ランキングに反映される前に）採用したいくつかのグローバル ブランドやローカル ブランドの事例を確認してみましょう。採用の理由は、Core Web Vitals がユーザー エクスペリエンスに注目しているからです。
Vodafone（イタリア）は、LCP を 31% 改善することで、売上が 8% 増加しました。
iCook は、CLS を 15% 改善することで、広告収入が 10% 増加しました。
フィルレートに影響が出る可能性があるが、広告の視認性が上がるにつれて収益が向上する
Tokopedia は、LCP を 55% 改善することで、平均セッション時間が 23% 増加しました。
以上のケーススタディから、ベスト プラクティスを採用してすばやく成果を上げることで、大きな効果が得られることがわかります。この点に関する実例を、さらにいくつか紹介します。
以上の結果は、以下のようなすぐにたやすく行えることを実施した結果です。
その他のベスト プラクティスについては、Web Vitals ガイダンスを参照してください。PageSpeed Insights を使うと、ウェブサイトを監査して即座に実用的な推奨事項を確認できます。
ほかにもいくつものグローバル ブランドが Core Web Vitals に投資して、そのメリットを享受しています。
最初に、フィールド ツールを使ってサイトを計測しましょう。Google を含むプロバイダが、さまざまなツールを公開しています。
皆さんにとって最適なツールを選択してください。もう一歩踏み込んで Google アナリティクス 4 を組み込むことで、Core Web Vitals とビジネス指標の相関関係を確認することもできます。
最後になりますが、Google では、パフォーマンスは目的ではなく過程であると考えています。そのため、注目すべき最新のケーススタディを紹介できるように、今後もこの記事を更新する予定です。ビジネスですばらしい成功を収め、この記事で取り上げてほしい事例がある方は、コンテンツの提案をお送りください。
Core Web Vitals は、サイトオーナーがウェブサイトのユーザー エクスペリエンスを改善する場所や方法を理解するために役立つ重要な一歩です。Google のページ エクスペリエンス シグナルでも、このような客観的な指標群に注目することを推奨する予定です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。
世界中の AMP Project の貢献者のおかげで、サイトオーナーは AMP ページを作成する際に、パフォーマンスに優れた体験の構築に向けて良いスタートを切ることができます。ただし、他の多くのフレームワークと同様に、AMP でもウェブ開発のベスト プラクティスをすべて実装することはできません。このブログ投稿では、AMP ページを確実に最適化するためにデベロッパーが行うべきことについて共有します。この内容は、AMP ページがパブリッシャーのサイトから提供される場合と、AMP キャッシュから提供される場合の両方に適用できます。
AMP の目的は、優れたユーザー エクスペリエンスを簡単に作れるようにすることです。しかし、優れたユーザー エクスペリエンスに不可欠だと AMP チームが確信しているいくつかの開発プラクティスでは、追加の作業が必要になる場合があります。
ページの Core Web Vitals 指標は、ウェブページで実際のユーザー インタラクションを測定して算出されます。AMP では、ユーザーがどのようにコンテンツにアクセスしたかによって、パブリッシャーのドメインか AMP キャッシュのどちらかからページが提供されます。多くの場合、AMP へのアクセスの大部分（半分以上）が自分のドメインで発生します。こちらのガイドに従うと、AMP デベロッパーが AMP キャッシュ上とそれ以外での Core Web Vitals 指標を測定できます。
Google の調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。
font-display: optional
data-hero
<amp-img data-hero src="…">
AMP ページで可能な限り充実したユーザー エクスペリエンスを実現するため、すべてのサイトオーナーの皆さんに、ご自身で対応できるさまざまな最適化を追加で実施することを強く推奨します。最も簡単な方法は、最新の AMP Optimizer を使うことです。これにより、AMP の新しいサーバー側最適化をすべて自動で適用できます。また、昨年には、AMP Page Experience Guide（下図）も公開しました。公開以降、アクションにつながるフィードバックが AMP Page Experience Guide にさらに追加され、利便性が高まりました。この取り組みを推進する原動力となっているのは、このツールを使って AMP ページをテストするウェブサイトです。たとえば、カスタム フォントの読み込みに関する推奨事項が表示されるようになったので、LCP と CLS を最適化できます。
AMP ページをこれらの基準に適合させるためのアクションにつながる推奨事項が存在しない場合は、お知らせください。直接サポートいたします。次に示すように、リクエストは AMP Page Experience Guide の中から送信できます。または、Github から直接連絡することもできます。
AMP Project は、ユーザー ファーストなオープンウェブを作るというビジョンただ一点に集中しています。AMP Page Experience Guide を使うと、Core Web Vitals に基づく AMP ページのパフォーマンスを確認できます。パブリッシャーのドメインと AMP キャッシュで、推奨された最適化を実施することをお勧めします。
AMP 開発コミュニティや、皆さんのフィードバックに感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください。
すべての人は、安全で強力、そして高速なオープンウェブの恩恵を受けています。私たちはここ 1 年で、次にあげる 3 つの領域について、集中的にウェブの強化を行ってきました。
この投稿では、本日（元記事公開当時）の Chrome Dev Summit の基調講演で共有したアップデートの概要をまとめます。
私たちはプライバシー サンドボックスの作業を継続し、ウェブのプライバシーを抜本的に強化するオープンな基準を作ろうとしています。そして、ウェブ コミュニティと協力しつつ、サードパーティ Cookie やクロスサイト トラッキング メカニズムに代わり、プライバシーを守ることができる新たな仕組みを構築しようとしています。Client Hints API では Chrome でフィンガープリンティングに使える領域を減らし、Chrome オリジン トライアルを通して実験できる 2 つのソリューションも提供しています。Click Conversion Measurement API は、クロスサイト識別子を使わずに広告コンバージョンを測定します。Trust Token API は、パッシブなトラッキングを行うことなく、あるコンテキストから別のコンテキストに信頼を伝える際に役立ちます。
同様に、数億人のユーザーが利用する Chrome ウェブストアの 250,000 件以上の拡張機能でも、セキュリティとプライバシーが最重要になっています。私たちは、拡張機能はデフォルトで信頼できるものでなければならないと考えています。そのため、拡張機能プラットフォームにたくさんの変更を行うドラフト提案についてお知らせしました。拡張機能デベロッパーからのさまざまな提案を反映すれば、Manifest V3 の安定版リリースに向けた準備が整います。その目的は、セキュリティの強化、ユーザーの制御とプライバシーの向上、パフォーマンスの改善です。
Manifest V3 と合わせて、リモートでホストされたコードは許可されなくなります。これは、ユーザーのプライバシーやセキュリティを侵害する悪意のある拡張機能を防ぐためです。また、新しい拡張機能モデルでは、ユーザーがインストール時にセンシティブな情報へのアクセスを許可しないことを選択できるようになります。さらに、バックグラウンド ロジックに新たなアプローチを導入します。バックグラウンド ページに Service Worker を導入し、拡張機能 API に新たな宣言的モデルを適用することで、ユーザーに一貫したパフォーマンス保証を提供します。現在、Manifest V3 は Chrome 88 ベータ版で試験運用版として利用できます。Chrome ウェブストアは、Chrome 88 が安定版になる 1 月中旬から、Manifest V3 拡張機能を受け付ける予定です。
ウェブで新しい体験を構築しているデベロッパーから、すばらしい活用例が登場しています。Gravit Designer は、File System Access API を使ってユーザーが簡単にファイルの読み書きを行えるようにし、さらに新しい Local Font Access API でローカルにインストールした特別なフォントを利用できるようにしています。Adobe は、Spark ウェブアプリでユーザーがすばらしいビジュアル ストーリーや美しいデザインのコンテンツを簡単に作れるようにしています。
本日（元記事公開当時）、Progress Web App（PWA）に新機能を追加します。これによって、PWA を Google Play ストアに掲載して見つけてもらいやすくすることができます。Chrome 86 では、Trusted Web Activity を使っている PWA を Play ストアで一覧表示できるようになります。また、Chrome 88 では、新しい Digital Goods API を使って支払いを受け取れるようにしています。
デベロッパーの皆さんがすべてのユーザーに最適な体験を提供できるようにするため、Chrome のパフォーマンス（スピードのほか、電力、メモリ、CPU などのリソースの使用量）は常に私たちの最優先事項になっています。
今年は、プロファイルによる最適化とタブ スロットリングによって、スピードに関するいくつかの重要な改善を行いました。そして本日は、V8 のメモリ フットプリントを大幅に削減したことをお知らせします。V8 ポインタ圧縮でメモリの節約に向けた大きな一歩を踏み出したことに加え、ウェブページの JavaScript ファイルを並列に読み込むことで解析による中断を完全に無くしました。これによって、ページで必要になるときには既にスクリプトの実行準備が整っているように、スクリプトの解析とコンパイルを実行できます。
Web Vitals の取り組みについて発表して以来、ウェブページのパフォーマンスを測定する際にこの基準が使われることが多くなっています。Google 検索は、2021 年 5 月より、検索ランキングの新たなシグナルに Core Web Vitals を含めることを発表しました。Chrome ユーザー エクスペリエンス レポートに加え、Search Console の Core Web Vitals レポートやその他多くの Google 製ツール、Cloudflare などの他のプロバイダで、Core Web Vitals がウェブページのパフォーマンス指標として表示されています。
この夏、Google アナリティクスを使っているサイト向けに、web-vitals Javascript ライブラリをリリースしました。本日、オープンソースのウェブサイトおよびツールである Web Vitals Report についてお知らせしました。これを使うと、Google アナリティクスで Web Vitals 指標データのクエリや視覚化ができるので、セグメント間で簡単にパフォーマンス データを比較することもできます。
最後になりますが、皆さんのフィードバックや、ウェブ インターフェースの構築が難しい点についてのご意見をお待ちしています。私たちは、ウェブのスタイリング機能の改善を進めており、レンダリング パフォーマンスを大幅に向上させる content-visibility CSS 機能を公開しました。簡単に CSS を拡張できる API セットである Houdini.how のお知らせなど、UI スタイリングを改善するアップデートやツールにご期待ください。
Chrome Dev Summit は、常にコミュニティとのつながりを大切にしています。今回は直接顔を合わせることはできませんでしたが、Chrome チームは、偶然の会話や新しい発見、記念品の収集など、実際のカンファレンスのいい所を集めた PWA、Chrome Dev Summit Adventure をリリースしました。この実験について皆さんからの感想を聞いたり、リアルタイムでチャットしたりするのが楽しみです。
コミュニティの一員になり、世界中の Google Developer Group に参加しましょう。CDS Extended イベントでは、地域のデベロッパー コミュニティを集めて、Chrome Dev Summit 2020 のハイライトを確認したり、インタラクティブなセッションがライブで行われたりします。このイベントのすべてのリストをチェックしてください。
YouTube チャンネルでは、いつでもセッションを視聴できます。また、web.dev ニュースレターにサインアップしてウェブの最新アップデートを受け取ってください。
また来年にお会いしましょう！
※ 日本では Chrome Dev Summit の日本版となる Chrome Dev Summit Recap 2020 を開催しました。アーカイブは 2021 年 1 月中旬まで閲覧可能ですので、ぜひ今からでも登録・ご視聴下さい。
今週、Google は Web Vitals の取り組みについてお知らせしました。Web Vitals は、優れたウェブのユーザー エクスペリエンスに不可欠と Google が判断した一連のガイドラインです。AMP Project の目標は常に変わることなく「すべての人に、すべての場所で、より良く高速に表示されるウェブ」です。そこで、Web Vitals で推奨されているパフォーマンス目標をサイトオーナーが達成するにあたって、AMP がいかに役立つのかをご説明します。また、高速でさらに優れたウェブにするための作業についても詳しくお知らせします。
Web Vitals についてお話しすべきことはたくさんありますが、この投稿では Core Web Vitals について取り上げます。この 2 つの違いについては、web.dev をご覧ください。このサイトから、最も関連する部分を引用します。
Core Web Vitals は、すべてのウェブページに適用される Web Vitals のサブセットで、すべてのサイトオーナーが測定すべき内容です。また、すべての Google 製のツールで表示されるようになります。Core Web Vitals の各項目は、ユーザー エクスペリエンスの個々の側面を表します。いずれも現場で測定でき、ユーザーを重視する視点で重要になる実際のパフォーマンスを反映しています。Core Web Vitals に含まれる指標は、時間とともに進化します。2020 年時点での項目は、読み込み、 インタラクティブ性、 視覚的な安定性というユーザー エクスペリエンスの 3 つの側面に注目しており、以下の指標（とそれぞれのしきい値）が含まれます。
Core Web Vitals は、すべてのウェブページに適用される Web Vitals のサブセットで、すべてのサイトオーナーが測定すべき内容です。また、すべての Google 製のツールで表示されるようになります。Core Web Vitals の各項目は、ユーザー エクスペリエンスの個々の側面を表します。いずれも現場で測定でき、ユーザーを重視する視点で重要になる実際のパフォーマンスを反映しています。
Core Web Vitals に含まれる指標は、時間とともに進化します。2020 年時点での項目は、読み込み、 インタラクティブ性、 視覚的な安定性というユーザー エクスペリエンスの 3 つの側面に注目しており、以下の指標（とそれぞれのしきい値）が含まれます。
Largest Contentful Paint（LCP）: 読み込み パフォーマンスを測定します。優れたユーザー エクスペリエンスを実現するには、LCP はページの最初の読み込みが始まってから 2.5 秒以内である必要があります。First Input Delay（FID）: インタラクティブ性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの FID が 100 ミリ秒未満である必要があります。Cumulative Layout Shift（CLS）: 視覚的な安定性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの CLS が 0.1 未満である必要があります。
Largest Contentful Paint（LCP）: 読み込み パフォーマンスを測定します。優れたユーザー エクスペリエンスを実現するには、LCP はページの最初の読み込みが始まってから 2.5 秒以内である必要があります。
First Input Delay（FID）: インタラクティブ性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの FID が 100 ミリ秒未満である必要があります。
Cumulative Layout Shift（CLS）: 視覚的な安定性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの CLS が 0.1 未満である必要があります。
専門用語に惑わされないようにしてください。重要な点は、サイトに期待される重要なユーザー エクスペリエンスを実現する上でこれらの指標が役立つこと、そして新しいクロスブラウザ API を使って現場で測定できることです。
すべてが現場で測定できるので（そして測定すべきです）、単なる理論的な結果ではなく、ユーザーが実際に経験していることを追跡できます。それでは、新しいガイドラインの内容がわかったので、これを満たすために AMP がどう役立つかについて見ていきましょう。
FID スコアが低い場合、ユーザーがボタンをクリックしたり入力項目をタップしたりすると、サイトがほぼ瞬時に応答し、待たされることはありません。web.dev のドキュメントによれば、ここでの目標は 75 パーセンタイルで 100 ミリ秒です。 これは、ユーザーが初めて入力項目を操作するとき、ページが表示されている時間の 75% 以上において、100 ミリ秒未満で反応するという意味になります。すべての Core Web Vitals と同じく、この情報はユーザーから収集する必要があります。まだ収集していない場合は、開発マシンで測定するだけでなく、実際のユーザーデータ（ヒント: まずは PageSpeed Insights から始めるのがおすすめです）に関するレポートを参照して、しきい値を満たしているかどうかを確認してください。
開発環境で実際の FID を測定することは できません 。意味のあるデータを得る唯一の方法は、実際のサイトのユーザーのインタラクションにかかる時間を確認することです。開発中に使える類似指標として、合計ブロック時間を表す Total Blocking Time があります。この 2 つは同じものを測定しているわけではありませんが、TBT が下がれば FID も下がるのが一般的です。FID 値が高くなっていることが多い場合、ほとんどはブラウザのメインスレッドが別の作業（コードのパースやサードパーティ製のリソースの読み込みなど）を行っています。FID スコアを改善する詳しい方法については、web.dev をご覧ください。
AMP は、さまざまな方法を用いて低い FID スコアを維持しています。
AMP のコードはユーザーをブロックしない
AMP は非同期 JavaScript のみを許可しており、遅い操作や負荷がかかる計算操作が紛れ込むことはありません。そうでなければ、このような操作によって実際のサイトの利用がブロックされる可能性があります。
遅延レイアウト
AMP は、サイトの即時性を保つため、読み込み時にすぐには表示されないと思われる要素のレンダリングを遅らせます。つまり、AMP では、サイトの下部に JavaScript を使った重い動画プレーヤーがあっても、サイトの読み込み中にプレーヤーの処理が行われているという理由でユーザーのクリックやタップがブロックされることはありません。
プロセスの分割
AMP は、ページが無応答にならないように、プロセスのチャンク化を実装して長時間実行されるタスクを分割しています。大きなタスクを小さく分割し続けることで、すべての操作がすぐに応答するように感じるサイトを実現しています。
その他すべてをサンドボックス化
AMP の外側のコードが必要になる場合、それは専用の iframe で実行されます。コードを専用のコンテナで実行することで、ユーザーによるページ操作がブロックされないようにしています。つまり、遅い広告やたくさんのコードが必要な動画プレーヤーによって、ユーザーのサイトの利用が妨げられることはありません。
AMP ブログで CLS について詳しく取り上げた最近の記事をご覧になったかもしれませんが、読み込みが遅いコンテンツや大きすぎるイメージや動画があるためにウェブページが動き回ることがあり、それが現在のユーザーのさまざまな不満につながっています。優れたサイトに優れた CLS スコアが不可欠なのはそのためです。Google は、CLS を 0.1 未満にすることを推奨しています。これは、他の Core Web Vitals よりも少々複雑な測定が必要になるので、web.dev のドキュメントに目を通して理解を深めることをおすすめします。理解しておくべき重要な点は、CLS が低ければ、ユーザーに予測可能な安定したレイアウトが表示され、要素が動き回らないことです。
CLS は、AMP が非常に効果を発揮するもう 1 つの領域です。AMP は、CLS スコアが悪いサイトがよくはまる落とし穴を回避するためにゼロから開発され、以下のようなたくさんのルールを設けることで、この数値を低く保っています。
静的サイズ レイアウト システム
AMP のレイアウト システムは、リソースをダウンロードする前にサイズを推定できるように作られています。たとえば、イメージや動画、iframes などのテキスト以外の要素が必要な AMP では、ビルトイン コンポーネントを通して読み込みを行う必要があります。その際に、デベロッパーはリソースの高さと幅をブラウザに伝えなければなりません。
<amp-img height="200" width="400" src=...
これらの属性には、コンテンツがダウンロードされる前でもアクセスできるので、ブラウザはイメージを読み込んだ後のようにページをレイアウトすることができます。これがなければ、ダウンロードが完了して各要素に必要なスペースが決まったタイミングでレイアウトをずらすしかありません。
動的コンテンツに必要なインタラクション
再レイアウトが発生する可能性のあるページのアップデートを行う場合は、ユーザーによるインタラクションが必須になっています。ユーザーが何かをタップする前に、ウィジェットをポップアップさせることはできません。アップデートをインタラクションの応答時に限定することで、ユーザーが不快な驚きを経験する可能性は低くなります。
効率的なフォントの読み込み
多くのウェブサイトは、外部フォントを使ってページのスタイルを設定しています。外部 CSS ファイルをダウンロードし、参照先を見つけて、フォントをダウンロードしなければならない場合、ページの読み込みはスムーズではなくなり、ユーザーも混乱しやすくなります。AMP では、すべての CSS をインラインにしてウェブサイトのソースコードの上部に記述しなければならないので、これが緩和されます。すべてのフォントはすぐに検出され、ダウンロードされます。また、FID の説明で触れたように、JavaScript の読み込みは非同期なので、JavaScript のダウンロードによってブラウザのカスタム フォントの処理がブロックされることはありません。
ユーザーは、ページを読み込んでも、ネットワークのコールバックなどのパフォーマンス インジケーターを見ることはできません。見ることができるのは、視覚的な出力、あるいはその出力がないことだけです。LCP は、最大の要素がレンダリングされたタイミングを測定します。LCP のタイミングを測定することで、ユーザーが実際にページをどのくらい速く 感じているか に関するさまざまな知見を得ることができます。LCP が非常に重要な指標である理由はこの点にあります。web.dev の推奨では、LCP は 75 パーセンタイルで 2500 ミリ秒以内です。
Largest Contentful Paint をできる限り高速にするために、AMP では以下のようなたくさんの最適化が行われています。
インテリジェントなリソースの読み込み
AMP の目的は、常に体感速度の向上にあります。この実現には多くのことが必要ですが、その 1 つは、イメージや広告を最初にダウンロードするのは、それが画面の表示範囲に含まれているか、ユーザーがすばやくスクロールした場合に限ることです。AMP は、ページの読み込み時に取得するリソースの量を限定し、ユーザーが実際に目にするコンテンツを優先します。その結果、ユーザーが速いと感じられるサイトになります。
プリロードとプリレンダリング
AMP ページを AMP キャッシュにホストする場合、コンテンツのプリロードなど、ページに対してさらに多くの最適化が行われ、極限まで高速化されます。通常、ユーザーがプリレンダリングされた AMP ページをタップするときには、ブラウザは既にすべてのダウンロードとレンダリングを終えています。そのため、速く感じられます。
ここまで紹介したのは、特に手を加えていない AMP の動作です。しかし、私たちのチームは、優れたユーザー エクスペリエンスには、実行時では実現できない開発作業が欠かせないと考えています。私たちは、AMP が Core Web Vitals の基準を大きく上回るよう懸命に努力していますが、それに到達しない可能性もあります。AMP のパフォーマンスを さらに高めるために、皆さん自身でできる追加の最適化はたくさんあります。私たちの調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。
サーバーの応答時間を改善する
サーバーが遅いと、ほぼすべてが遅くなります。CDN と同じように、配信は AMP キャッシュによって最適化されますが、ほぼすべての AMP サイトには いくらかの AMP キャッシュ以外のトラフィックも存在します。つまり、優れた Core Web Vitals の実現には、サーバーが高速で素早く応答することが欠かせません。
大きすぎるイメージの使用を控える
サイトをできる限り速くするには、実際の表示よりも大きいイメージの利用を避ける必要があります。多くの場合、ウェブサイトで最適化されていないイメージを読み込むと、ダウンロード サイズが数百キロバイト単位で増加し、Core Web Vitals の LCP が直接的に損なわれます。AMP オリジンのイメージを最適化し、ユーザーが時間や帯域幅を節約できるようにしてください。
AMP キャッシュでは、こういった問題を避けるためにコードが最適化されますが、この最適化はキャッシュ上でのみ行われる点に注意してください。ソーシャル メディアで共有されたリンクを経由する場合や、直接サイトに移動する場合など、サイトに直接アクセスしたユーザーは同じ動作にはなりません。 あらゆる ユーザーに対して優れた Core Web Vitals スコアを実現するには、オリジンでサイトを最適化することが非常に重要です。
AMP チームは、サイトを最適化するためのさまざまなオープンソース ツールを提供しています。
AMP Optimizer
AMP Optimizer は、AMP のレンダリング パフォーマンスを改善するためのすばらしい選択肢です。サーバー側レンダリングやコード圧縮などの機能が搭載されており、サイトの読み込みの高速化に向けた大きな一歩となります。
AMP for WordPress Plugin
WordPress を使っていて AMP に興味がある方は、公式 AMP プラグインを確認してみてください。開発とメンテナンスは AMP チームが担当しており、WordPress から WordPress 的に AMP コンテンツを生成できるようになります。そのため、パフォーマンス最適化技術についての深い専門性がなくても、高速な AMP ページをすぐに公開できます。また、公式 AMP プラグインは、WordPress で AMP 開発を行うための高度なツールも提供しています。
Next.js
Next を使うと、1 行のコードを追加するだけで React サイトを AMP サイトに変えることができます。これにより、サーバー側レンダリング（LCP の高速化が可能）や AMP Optimizer 統合など、さまざまなパフォーマンス最適化が自動的に行われます。どうぞご覧ください！
パフォーマンスの最適化は、早く行うほどメリットがあります。ここで紹介したようなツールを使えば、キャッシュされたページからアクセスするユーザーだけでなく、すべてのユーザーに対して高速でスムーズな体験を提供できるようになります。
Web Vitals と Core Web Vitals は、サイトオーナーにウェブのユーザー エクスペリエンスを改善する場所や方法を理解してもらうための重要な一歩です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。
世界中の AMP Project の貢献者のおかげで、AMP ページを作成したサイトオーナーは、最大限のパフォーマンス保証を得ることができます。AMP チームは、ウェブ上の AMP ページのパフォーマンスを継続的に監視し、定期的に AMP ライブラリのパフォーマンスを強化するアップデートを行っています。AMP は常に最新のライブラリなので、デベロッパーやユーザーは何もしなくても最新の AMP の改善による恩恵を得られます。
質問がある方はお知らせください。それ以外の方は、Twitter をフォローするかニュースレターにサインアップして、AMP の変更についての最新情報を受け取れるようにしてください。
投稿者: Patrick Kettner、 Google、AMP Project、デベロッパー チアリーダー
// web-vitals を使って CLS、FID、LCP を測定、レポートする例 import {getCLS, getFID, getLCP} from 'web-vitals'; function reportToAnalytics(data) { const body = JSON.stringify(data); (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) || fetch('/analytics', {body, method: 'POST', keepalive: true}); } getCLS((metric) => reportToAnalytics({cls: metric.value})); getFID((metric) => reportToAnalytics({fid: metric.value})); getLCP((metric) => reportToAnalytics({lcp: metric.value}));
