なぜAMP⚡はコアウェブバイタルに優れているのか？

[レベル: 上級]

この記事では、AMP が Core Web Vitals（コア ウェブ バイタル）に優れている理由を説明します。

AMP ドメインの 60% が CWV に合格

Google によれば、AMP を導入しているドメインのうち 60% が コア ウェブ バイタル に合格しているとのことです。
対して、AMP 対応していないドメインの合格率は 12% だそうです。
AMP のほうが 5 倍多く コア ウェブ バイタル に合格している計算になります。
※ 合格とは、サイト内の 75% のページがコア ウェブ バイタルのしきい値を満たしている状態

AMP ファーストにしたサイトのコア ウェブ バイタルがまさしく劇的に改善した事例を Web担当者Forum の連載コラムで紹介しました。

AMP が CWV に優れる理由

どうして AMP はコア ウェブ バイタルに優れているのでしょうか？

Google は次のように説明しています。

AMP が LCP に優れる理由

LCP は Largest Contentful Paint の略で、ビューポート内の最も大きな要素が読み込まれるまでにかかる時間を表す指標です。

LCP に関して、AMP は次のように最適化できています。

• JavaScript と CSS が少ないから読み込みが速い
  • CSS の上限が 75 KB
  • JavaScript を非同期読み込み
• AMP キャッシュは可能であればプリロード/プリレンダリングする

AMP が FID に優れる理由

FID は First Input Delay の略で、ユーザーの最初の入力に反応するまでにかかる時間を表す指標です。

FID に関して、AMP は次のように最適化できています。

• JavaScript が少ないのでインタラクティブになるまでの時間が短い
• 非同期で JavaScript を読み込む
• 可能であれば、プリロード/プリレンダリングする
• Lazy-load を使う
• プロセスをチャンクする（ロングタスクを細かくする）
  ※すずき補足: 1 つのタスク処理にかかる時間が長いと、ほかのプロセスの処理を止めてしまう。特に 50 ミリ秒を超えると TBT (Total Blocking Time）が長くなり FID を悪くする原因になりうる

AMP が CLS に優れる理由

CLS は Cumulative Layout Shift の略で、ユーザーが予測しないレイアウトのずれを表す指標です。

CLS に関して、AMP は次のように最適化できています。

• すべての要素のサイズを事前に定義しているので、読み込んでもほかの要素を移動させることがない
• ページ要素を変更するにはユーザーのインタラクションが必要（※ CLS はユーザーが予測しないレイアウトのズレを示す指標）

AMP じゃなくてもコアウェブバイタルの最適化はもちろん可能です。
しかしながら、コア ウェブ バイタルに優れた特徴を AMP は内在しています。
AMP 対応は、コアウェブバイタル改善の選択肢として検討するに値するでしょう。

AMP は CWV のすべてを解決しない

とはいえ、AMP にしたからといって確実にコア ウェブ バイタルに合格するというとでもありません。

「AMP ドメインの 60% がコア ウェブ バイタルに合格している」は裏を返せばAMP でも 40% は不合格ということを意味します。

AMP でも問題になりやすいのは、LCP です。
たとえ、AMP といえど、圧縮やサイズ調整といった画像の最適化は必要です。
Google は Squoosh という画像最適化のツールを提供しています。
またサーバーサイドでの画像最適化を自動化するモジュールも利用できます。

AMP では CSS はすでに限定されていますが、さらに少なくできるかもしれません。
そのページで必要な CSS だけにすることでさらに最適化できます。

Service Worker の利用やフォントの最適化も役立ちます。
独自の AMP キャッシュや AMP の SSR を導入するツールも Google は提供しています。

この記事で紹介した内容は、AMP Fest 2020 の “The road to great page experiences” のセッションから抽出したものです。
セッション動画を埋め込んでおきます（日本語字幕を利用可能）。