Twitter からのユーザーを失望させない AMP の高速化対策

Akira

福岡在住の Web デザイナー。Web サイト制作に役立つ情報を紹介しています。AMP が大好き。

FacebookTwitter で記事の更新をお知らせしています。

  • AMP には 3 つの URL がある。
  • そのうちの 1 つ「オリジナル URL」は、AMP キャッシュが返ってこない。また、ページの読み込みが最適化されない。そのため、AMP にしてはサイト表示が速くない。
  • しかも、「オリジナル URL」には、主に Twitter からのユーザーの流入が予想される。
  • Twitter からのユーザーにも高速体験を提供するには、rel="preload" などによる「オリジナル URL」の自前での高速化対策が必要。

必要性

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 。

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

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

「オリジナル URL」に誰もアクセスしなければ、速くなくとも問題ありません。しかし、多くのサイトで、ユーザーは訪れているはずです。その主な流入経路が Twitter です。

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

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

ユーザーが訪れる可能性が高いため、「オリジナル URL」の最適化を AMP は推奨しています。

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

AMP ランタイム

AMP ページは、AMP ランタイムが実行されない限り表示されません。

AMP ランタイム
AMP ページで実行される JavaScript の一部。AMP の基本的な動作の提供に加え、リソースの表示と優先順位付けの管理などを行う。AMP ページで必須の <script src="https://cdn.ampproject.org/v0.js"></script> で読み込む。

AMP ランタイムの実行タイミングが早ければ早いほど、ページの表示速度は速くなります。

少しでも早く AMP ランタイムを実行するために、rel="preload" による先読みを行います。

方法は、<head> 内の可能な限り最初に <link> を追加するだけです。

<link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">

AMP では、charset="utf-8"name="viewport" など重要な <meta> の次に <link> の追加を推奨しています。

また、以下の拡張コンポーネントのライブラリも rel="preload" で先読みします。

<link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-dynamic-css-classes-0.1.js">
<link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-1.0.js">
<link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-story-1.0.js">

各拡張コンポーネントのバージョンは、2020 年 5 月時点のものです。今後のアップデートで変わる可能性があります。

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 フォントは、rel="preconnect dns-prefetch" でブラウザにリソースヒントを提供します。

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

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

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

dns-prefetch に疑問を感じますが、AMP 公式サイトに記載のまま書いています。

@font-face

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

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

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

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

ヒーローの画像や動画

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

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

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

ヒーロー画像がなかなか表示されなければ、UI やユーザー体験を損ねます。そこで必要であれば、ヒーロー画像も rel="preload" で先読みします。

<link rel="preload" as="image" href="画像のパス">

追加場所は、<head> 内の可能な限り最初です。

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

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

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

ただし、本当に必要なケースでのみ、画像や動画を先読みします。何もかも rel="preload" で先読みしては、サイトの表示速度が遅くなります。

Service Worker

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

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

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

さらに、Google Developers コードラボにて、詳細な解説を確認できます。

もし、AMP ページのみで作られたサイト(非 AMP ページがないサイト)であれば、わずか 1 行で Service Worker を利用できる AMP Service Worker の使用がおすすめです。使い方は、下記のページで解説しています。

サーバーサイドレンダリング

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

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

この仕組みのメリットは、ページ表示の際にコンテンツの移動が生じないことです。

コンテンツの移動とは、「ページの読み込みの最中にテキストや画像などの位置が移動する」ことです。何かをタップしようとしたら位置が突然ずれ、違う場所をタップした経験はありませんか?

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

そこで AMP が推奨しているのが、サーバーサイドレンダリングを実現する AMP Optimizer の使用です。

AMP Optimizer の使用により、コンテンツの移動が生じないメリットを維持しつつ、レンダリングの開始が早くないデメリットを排除できます。

AMP いわく、レンダリング時間が最大 50% も速くなるとのこと。使用前と後でどれほど違いが出るかは、How to make AMP even faster で確認できます。

現在 AMP は、AMP Optimizer の普及に力を入れているに思えます。執筆時点において、このような AMP Optimizer のツールが提供されています。

今後、より多くのフレームワークや CMS でサポートする予定とのことです。

送信に失敗しました

ボットと判定された可能性があります。

大変お手数をおかけしますが、以下の内容をご確認の上、再度のコメントの送信をお願い申し上げます。