さらなる高速表示のための AMP ページの最適化

必要性

AMP に対応したサイトは高速です。高速の理由の 1 つが、AMP キャッシュでページが表示されるためです。

ただ、AMP には 3 つの URL があり、必ずしも AMP キャッシュでページが表示されるわけではありません。

AMP の URL 一覧
URL	説明
オリジナル URL	AMP ページのコンテンツを配信する大本の URL 。大抵は、非 AMP ページの URL の末尾に /amp や /?amp=1 などが付く。サイトで使用しているサーバーにアクセスするため、AMP キャッシュは返ってこない。
AMP キャッシュ URL	オリジナル URL のコンテンツなどをキャッシュし、CDN で配信する URL 。現時点では、「Google AMP キャッシュ」「Bing AMP キャッシュ」の 2 つの AMP キャッシュプロバイダがある。一般ユーザーが、この URL を目にすることはほぼない。
AMP ビューアー URL	AMP ビューアーによりアクセスする URL 。代表例が、モバイル端末の検索結果から訪れる AMP ページ。AMP ページと言えば、この URL を指すことが多い。実体は、セキュリティ上の観点から変換された AMP キャッシュ URL 。

参考：Google Developers Japan: AMP URL の正体

「AMP キャッシュ URL」と「AMP ビューアー URL」へのアクセスは、AMP キャッシュが返ってきます。また、様々な面でページの読み込みが最適化されています。

それに対し、「オリジナル URL」は AMP キャッシュは返ってきません。さらに、ページの読み込みの最適化がされておらず、AMP ページにしては表示速度が速くありません。

「オリジナル URL」に誰も訪れなければ、速くなくとも問題ありません。しかし、非 AMP ページがなく AMP ページのみで作られたサイトの場合は、パソコンからアクセスする全てのユーザーは「オリジナル URL」を訪れます。

そのため、「オリジナル URL」の最適化を AMP は推奨しています。

参考：Optimize your hosted AMP pages - amp.dev

詳しい方法は上記リンク先で説明されていますが、主だった最適化をご紹介します。

AMP Optimizer

「オリジナル URL」の AMP ページは、おおまかに 3 ステップを経て表示されます。

AMP ページに必須の AMP ボイラープレートにより、ブラウザの描画が始まると opacity の 0 で <body> を非表示にする
AMP ランタイムが実行され、ページレイアウトの計算が始まる
計算が終わると opacity が 1 になり、<body> を表示する

この仕組みのメリットは、ページ表示の際に Cumulative Layout Shift (CLS) が生じないことです。

しかし、デメリットもあります。AMP ランタイムが実行されない限り、レンダリングが始まりません。

そこで AMP が推奨しているのが、サーバーサイドレンダリングを実現する AMP Optimizer の使用です。AMP Optimizer は、「オリジナル URL」を「AMP キャッシュ URL」と同等に最適化します。

参考：Using an AMP Optimizer - amp.dev

AMP Optimizer の使用により、コンテンツの移動が生じないメリットを維持しつつ、レンダリングの開始が早くないデメリットを排除できます。AMP いわく、レンダリング時間が最大 50% も速くなるとのこと。使用前と後でどれほど違いが出るかは、How to make AMP even faster で確認できます。

主だった AMP Optimizer のツールは以下のものです。

Next.js 向け next/amp
Node.js 向け amp-toolbox-optimizer
Node.js のフレームワーク Express 向けミドルウェア amp-optimizer-express
静的サイトジェネレーター Eleventy のプラグイン Eleventy AMP Plugin
Go 向けコマンドラインツール amppackager
PHP ライブラリ AMP Toolbox for PHP
WordPress プラグイン AMP
Cloudflare Workers Cloudflare AMP Optimizer

まだ他にもありますが、より多くのサイトジェネレーターや CMS などで今後サポートが開始されるかもしれません。

参考：Easier AMP development with the new AMP Optimizer – The AMP Blog

AMP のリリース当初は、AMP ページを作れば AMP に対応したと言えました。しかし、現在は AMP Optimizer を使わなければ、AMP に対応したと言えないかもしれません。

尚、AMP Optimizer は、ページで使われている拡張コンポーネントのライブラリの自動読み込みなど、開発者の負担を減らすメリットもあります。

ヒーローの画像や動画

AMP では、<amp-img> を使い画像を表示します。

AMP ランタイムに組み込まれている <amp-img> は、画像を遅延で読み込みます。画像がレンダリングをブロックせず、ページの表示速度が速くなるのが魅力です。

しかし、<amp-img> は、AMP ランタイムが実行された後でしか画像を読み込みません。この仕組みにより影響を受けるのが、ヒーロー画像です。

ヒーロー画像がなかなか表示されなければ、ユーザー体験を損ねます。そのため、ヒーロー画像を最適化します。最適化には 2 つの方法があります。

data-hero 属性

1 つ目の方法は、ヒーロー画像の <amp-img> に data-hero 属性を追加するものです。

<amp-img
  data-hero
  alt="hero"
  src="hero.jpg"
  width="900"
  height="675"
  layout="responsive"></amp-img>

data-hero 属性を追加すれば、AMP キャッシュと AMP Optimizer がサーバー側で画像をレンダリングできるようになり、読み込み時間が大幅に短縮されます。

link rel=preload

2 つ目の方法は、<link rel="preload"> での先読みです。<head> 内の可能な限り最初に <link> を追加します。

<link rel="preload" as="image" href="ヒーロー画像のパス" />

<amp-img> で media 属性を使用している場合は、<link rel="preload"> にも media 属性を追加します。

<head>
  <!-- 画面幅 839px 以下の画像-->
  <link
    rel="preload"
    href="hero-small.jpg"
    as="image"
    media="(max-width: 839px)" />
  <!-- 画面幅 840px 以上の画像-->
  <link
    rel="preload"
    href="hero-large.jpg"
    as="image"
    media="(min-width: 840px)" />
</head>
<body>
  <!-- 画面幅 839px 以下の画像-->
  <amp-img
    alt="hero"
    src="hero-small.jpg"
    width="400"
    height="400"
    layout="responsive"
    media="(max-width: 839px)"></amp-img>
  <!-- 画面幅 840px 以上の画像-->
  <amp-img
    alt="hero"
    src="hero-large.jpg"
    width="900"
    height="675"
    layout="responsive"
    media="(min-width: 840px)"></amp-img>
</body>

参考：リンク種別: preload - HTML: HyperText Markup Language | MDN

また、動画も同様に先読みできます。動画自体を先読みするか、<amp-video> の poster 属性に指定するポスター画像を先読みします。

<!-- 動画を先読み -->
<link
  rel="preload"
  as="video"
  type="video/mp4"
  href="type属性で指定した形式の動画のパス" />

<!-- 動画のポスター画像を先読み -->
<link rel="preload" as="image" href="ポスター画像のパス" />

Web フォント

Web フォントの読み込みの最適化も必要です。ただし、<link> で読み込む場合と @font-face で読み込む場合とで、最適化の方法が異なります。

link タグ

AMP では、以下の 5 つのフォントは <link> での読み込みが可能です。

<link> での読み込みが許可されているフォントの一覧
フォント提供サービス名	許可されている URL
Typography.com	https://cloud.typography.com
Fonts.com	https://fast.fonts.net
Google Fonts	https://fonts.googleapis.com
Typekit	https://use.typekit.net
Font Awesome	https://maxcdn.bootstrapcdn.com https://use.fontawesome.com

これら <link> で読み込む Web フォントは、<link rel="preconnect"> でブラウザにリソースヒントを提供します。

例えば、Google フォントであれば、このような <link> を <head> 内の可能な限り最初に追加します。

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin />

使用している各フォント提供サービスの URL を href 属性に指定します。

@font-face

AMP では、CSS の @font-face を使いカスタムフォントを読み込めます。

@font-face で読み込んでいる場合は、<link rel="preload"> でフォントファイルを先読みします。

<head> 内の可能な限り最初に <link> を追加します。

<link rel="preload" as="font" href="フォントファイルのパス" crossorigin />

Service Worker

PWA の基盤技術である Service Worker の利用でサイトを高速化できます。

AMP では、拡張コンポーネントの amp-install-serviceworker を使い Service Worker のインストールが可能です。AMP での PWA の実装方法は、AMP 公式サイトで説明があります。

また、Google のエンジニアさんが、GitHub でサンプルコードを公開しています。

さらに、Lab: Build a Progressive Web AMP にて、詳細な解説を確認できます。

もし、AMP ページのみで作られたサイト（非 AMP ページがないサイト）であれば、わずか 1 行で Service Worker を利用できる AMP Service Worker の使用がおすすめです。使い方は、AMP に最適な PWA を 1 行で実装する AMP Service Worker の使い方にて解説しています。