FirstLayout

AMPキャッシュが返ってこない時も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」に誰もアクセスしなければ、速くなくとも問題ありません。しかし、多くのサイトで、ユーザーは訪れているはずです。その主な流入経路が Twitter です。

Twitter は下記の 2 つの条件のいずれにも当てはまる場合に、「オリジナル URL」にユーザーを誘導します。

  • ユーザーがモバイル端末を使用している時
  • ユーザーがアクセスするページに AMP ページがある時

また、非 AMP ページがなく AMP ページのみで作られたサイトの場合は、パソコンからアクセスする全てのユーザーは「オリジナル URL」を閲覧します。

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

参考 Optimize your hosted AMP pages – amp.dev

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

AMP Optimizer

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

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

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

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 のツールは以下のものです。

まだ他にもありますが、より多くのサイトジェネレーターや 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 ランタイムが実行された後でしか画像を読み込みません。この仕組みにより影響を受けるのが、ヒーロー画像です。

ヒーロー画像がなかなか表示されなければ、UI やユーザー体験を損ねます。そのため、ヒーロー画像も最適化します。最適化には 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 dns-prefetch"> でブラウザにリソースヒントを提供します。

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

<link rel="preconnect dns-prefetch" 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」の使い方にて解説しています。

メニュー 閉じる 検索 記事を読む Facebook Twitter はてなブックマーク Pocket LINE ダウンロード 全ての記事 Web制作 便利ツール