Google Developers Japan: AMP をさらに高速化する方法

Local blog for Japanese speaking developers

AMP をさらに高速化する方法

2018年11月27日火曜日

この記事は Google パートナーデベロッパーアドボケート、Sebastian Benz による Accelerated Mobile Pages Project の記事 "How to make AMP even faster" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }ampproject.org に新しいガイド「ホストした AMP ページを最適化する」を公開しました。ここでは、AMP ドキュメントを最適化してさらに速く読み込めるようにする方法を説明しています。AMP はそのままでも高速化されるはずでは、と思う方もいらっしゃるかもしれません。おっしゃる通りです。AMP ランタイムは最速になるように最適化されており、有効な AMP ページはすべて高速に読み込むことができます。そこでさらにパフォーマンスを最適化すれば、ブラウザがさらに速く AMP ページを読み込めるようになります。細かな変更ではありますが、AMP の有効性を損なわずに、読み込みパフォーマンスを大幅に向上できます。たとえば、XWP が開発している AMP WordPress プラグインには、ガイドに記載されているテクニックが既にいくつか実装されています。その結果、xwp.co の読み込み時間は 12.6% 短縮されました。もう 1 つの例である Evening Standard は、さらにその先を行き、最適化してサーバーサイドレンダリング（SSR）に対応した AMP を公開しています。これにより、有効な AMP 版よりも FCP が 69% 速くなっています。
なぜ必要か落ち着いて考えてみましょう。これは必要なことでしょうか？AMP ドキュメントは AMP キャッシュから提供され、そこであらゆる最適化が自動的に行われるのではないでしょうか？AMP ドキュメントが Google や Bing の検索結果で表示される場合など、特定のケースではこれは正しいと言えます。しかし、次のような場合には、AMP ドキュメントがオリジンから提供されます。

https://tasty.co のように、カノニカルウェブページやモバイルウェブページを AMP で構築した場合。

他のプラットフォームからオリジン上の AMP ドキュメントにリンクする場合。たとえば Twitter は、標準のモバイル版に代わって、AMP ページへのリンクを提供し始めています。つまり、ユーザーが Twitter のモバイルアプリでリンクをクリックすると、そのリンクから独自サーバー上にある AMP 版のページが開きます。

このような場合には、AMP ページが独自サーバーから提供されるので、その AMP ページが最適な読み込みパフォーマンスを発揮できるかを確認することが重要になります。
ブラウザが AMP ページを高速に読み込めるようにするにはでは、AMP の読み込みパフォーマンスを最適化する仕組みを簡単に説明しましょう。amp-img や amp-video などの AMP 固有の要素が動作するためには、AMP ランタイムが読み込まれていなければなりません。つまり、amp-img がイメージのダウンロードを始めるのは、AMP ランタイムが読み込まれてからになります。ここから、2 つの方法で AMP ページの読み込みを高速化できることがわかります。

ブラウザができる限り速く AMP ランタイムをダウンロードできるようにする。

AMP ランタイムが利用可能になる前であっても、イメージなどの重要なアセットのダウンロードを始めるようブラウザに指示を出す。

これを実現するためのポイントは、rel=preload などのリソースヒントを使って重要なリソースのダウンロードを優先させることです。AMP 最適化ガイドでは、リソースヒントを使って AMP ページを最適化するさまざまな方法が説明されています。また、最適化済みの AMP テンプレートをすばやく生成できる AMP Boilerplate Generator を参照するのもよいでしょう。
first-contentful-paint を改善するにはもう 1 歩踏み込んだパフォーマンス最適化を行うこともできます。AMP ランタイムは、静的なページレイアウトシステムを実装することで、レンダリングとスクロールの際のジャンクを軽減しています。AMP Boilerplate のコードは、AMP ランタイムが読み込まれるまでドキュメントを非表示にすることでこれを実現します。ランタイムが読み込まれると、レイアウトが計算され、コンテンツが表示されます。このアプローチの欠点は、AMP ランタイムが読み込まれるまでユーザーに空のページが表示されること、そしてプログレッシブレンダリングがサポートされないことです。この欠点に対処するために、AMP サーバーサイドレンダリングを使って first-contentful-paint（FCP）時間を改善します。そうすれば、AMP ランタイム JavaScript を実行せずに AMP ドキュメントを描画でき、AMP ボイラープレートを削除することができます。たとえば、サーバーサイドレンダリングを行うバージョンの AMP Boilerplate Generator2 倍高速にレンダリングすることができます。 blog-how-to-make-amp-faster-filmstrip

blog-how-to-make-amp-faster-filmstrip

独自サーバー上の AMP ドキュメントを最適化する方法については、AMP Optimizer をご覧ください。

どれほどパフォーマンスが改善するか最適化がどのくらい読み込みパフォーマンスに影響するかを確認するために、以下の 3 種類の AMP Start Bike Shop テンプレートのランディングページを作ってみました。

イメージなし: 最善のシナリオ、すなわち、読み込まれる AMP ランタイムに依存する視覚的コンテンツがない場合をシミュレートする
イメージ: 読み込まれる AMP ランタイムにコンテンツが依存している場合に、読み込み時間を確認する
セルフホスティングフォント: カスタムフォントの読み込みによる影響を確認する

それぞれのページについて、4 種類のテストを行いました。

オリジナル: オリジナルの有効なバージョンの AMP

最適化: 以下の最適化を行った有効なバージョンの AMP

ランタイム読み込みの最適化
メイン画像のプリロード（該当する場合）
カスタムフォントの最適化（該当する場合）

最適化 + SSR: 上のバージョンと同じ最適化を行い、さらに AMP Optimizer によるサーバーサイドレンダリングを行ったもの。注: このバージョンは、有効な AMP ではありません。

キャッシュ: Google AMP Cache から提供されるバージョン

300 ミリ秒の遅延がある 1.6 Mbps 3G 接続環境において、Motorola G（第 4 世代）の Chrome で Webpagetest を使ってすべてのテストを 3 回実行します。Webpagetest へのリンクを含むすべての結果は、このドキュメントに掲載しています。テストは実際の端末で実行するので、実行時間は異なる場合があります。では、結果を確認してみましょう。 イメージなし

読み込み時間（秒）

レンダリング開始（秒）

最初のインタラクション（秒）

オリジナル

4.569

4.569

4.424

最適化

4.564

-0.11%

4.564

-0.11%

4.423

-0.02%

最適化 + SSR

2.233

-51.13%

2.233

-51.13%

4.48

1.27%

AMP Cache

2.039

-55.37%

2.039

-55.37%

3.508

-20.71%

サーバーサイドレンダリングを行うバージョンの読み込み時間は、50% 以上高速になっており、サーバーサイドレンダリング AMP のメリットを明らかに実証しています。しかし、最初のインタラクションまでの時間が変わらないのは、読み込まれる AMP ランタイムに依存するからです。 イメージ

読み込み時間（秒）

レンダリング開始（秒）

最初のインタラクション（秒）

オリジナル

5.435

4.591

5.367

最適化

4.591

-15.53%

4.566

-0.54%

5.094

-5.09%

最適化 + SSR

4.095

-24.66%

1.892

-58.79%

4.818

-10.23%

AMP Cache

3.827

-29.59%

1.834

-60.05%

4.13

-23.05%

イメージのプリロードによって、読み込み時間が大幅に短縮されたことがわかります。最適化された有効なバージョンの AMP は、15% 高速に読み込むことができますが、最適化 + SSR バージョンは 24%「しか」早くなっていません。これはイメージのレンダリングが、読み込まれる AMP ランタイムに依存しているためです。
セルフホスティングフォント

読み込み時間（秒）

レンダリング開始（秒）

最初のインタラクション（秒）

オリジナル

5.509

4.609

5.424

最適化

4.55

-17.41%

4.53

-1.71%

5.112

-5.75%

最適化 + SSR

4.478

-18.71%

1.989

-56.85%

5.203

-4.07%

AMP Cache

3.978

-27.79%

1.847

-59.93%

4.317

-20.41%

ここでは、最適化と最適化 + SSR の読み込み時間の差は、ほとんどなくなっています。これは、フォントのダウンロードが増えたことにより、サーバーサイドレンダリングを行うバージョンが遅くなっているためです。それでもサーバーサイドレンダリングを行うと、レンダリング開始までの時間はかなり短縮されます。注: すべての場合で、AMP Cache が最も高速です。これには、次の 2 つの理由があります。

さらにイメージの最適化が行われる

AMP ランタイムが同じドメインから提供されるので、2 つ目の https 接続を確立してランタイムをダウンロードする必要がない

まとめ独自サーバー上の AMP ページの読み込みは、さらに高速化できることがおわかりいただけたかと思います。AMP ページを公開する方に必ず覚えておいていただきたいのは、以下の点です。

ペア設定された AMP をホストするウェブサイトでは、AMP 最適化ガイドの推奨事項を実装してください。Twitter などのプラットフォームからキャッシュされていない AMP ドキュメントにリンクされている場合でも、確実に最高の読み込みパフォーマンスを発揮できるようにします。いくつかの細かい変更を行うだけで、AMP ページの読み込みが 1 秒早くなるかもしれません。

AMP で構築したウェブサイトでは、AMP Optimizer を使うことを検討してください。プログレッシブレンダリングによって、FCP 時間を大幅に改善することができます。

私たちは新たな最適化手法を模索し、AMP 読み込みエクスペリエンスを改善する作業を続けています。Yusuke Utsunomiya - Mobile Solution Consultant, gTech

ラベル

ブログアーカイブ

2024
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2023
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2022
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2021
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2020
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2019
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2018
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2017
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2016
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2015
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月

2014
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2013
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2012
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2011
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2010
- 12月
- 11月

Feed

"プロダクトに関するご意見はプロダクトフォーラムにお願いします"

Google
Privacy
Terms