今週、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、デベロッパー チアリーダー
オープンウェブが強力なのは、あらゆる人が同じ情報にアクセスできるからです。つまり、ウェブは、場所やハードウェアの好み、言語、能力によらず、誰が使っても動作するように設計する必要があります。AMP は、すべての AMP エクスペリエンスをデフォルトで WCAG AA 対応にすることを目指し、UI およびアクセシビリティ ワーキング グループがこの作業に注力しています。これは、AMP を使うとアクセシビリティが高いサイトを簡単に作れるだけでなく、デフォルトの状態でもアクセシビリティの低いエクスペリエンスが生成 されなくなる ことを意味します。
このブログでは、アクセシビリティの高いコンポーネントを作るために AMP Project が注力してきた作業と、デベロッパーがウェブ エクスペリエンスを作成する際に最優先すべきいくつかの重要な原則、そしてツールについて紹介します。
AMP コンポーネントを設計するとき、アクセシビリティは早い段階で検討すべき重要な内容です。私たちは、さまざまなアクセシビリティのニーズがある人々が、リリースされるコンポーネントを利用できないという事態が起こらないように、設計レビューや実装の意図のプロセスで徹底的な確認を行います。その結果、AMP で W3C WCAG 2.0 の Level A および AA ガイドラインを満たすページを作成できるようになりました。このガイドラインは、国際的に見ても、アクセシビリティに配慮した法律の重要な部分となっています。
しかし、AMP を使えばアクセシビリティが高いエクスペリエンスを作成でき、それを推奨する声もあがっているものの、AMP を使うすべてのウェブサイトが WCAG ガイダンスを満たすことを強制してはいません。この点は他のフレームワークも変わりません。たとえば、<amp-img> には代替テキストを指定できますが、すべてのイメージに代替テキストを指定することは強制しません。たとえ強制したとしても、提供された文字列が実際にそのイメージの説明になるように強制することはできません。それには、大規模な機械学習モデルの実行が必要になります。
以下に示すのは、よく使われる AMP のコンポーネントやアクションのデフォルトのアクセシビリティを向上させるため、私たちのチームが行った重労働の一部です。
アクセシビリティは UI およびアクセシビリティ ワーキング グループの最優先事項であるため、今後も AMP のデフォルト アクセシビリティの改善を続けることを計画しています。以下に、今後の計画の一部を示します。
皆さんのサイトが WCAG AA ガイドラインを満たせるようにするために、以下のツールを使ってテストを自動化することをおすすめします。
ただし、自動ツールですべての問題を認識できるとは限りません。最高のリソースは、WCAG ガイドラインを理解しているデベロッパーにマークアップや CSS をレビューしてもらい、確実にベスト プラクティスが反映されるようにすることです。
いつものように、問題や機能リクエスト、特にアクセシビリティ関連の内容がありましたら、遠慮なくお知らせください。
投稿者: AMP Project、プロダクト マネージャー、Naina Raisinghani
