AMP の仕組み
AMP ページが非常に高速で、瞬時に読み込まれるように見えるのは、次の最適化を組み合わせていることが理由です。理由は全部で7つだけですが、それでも読みきれない場合はこの説明動画をご覧ください。
すべての AMP JavaScript を非同期に実行
JavaScript は強力で、ページのほぼすべての要素を変更することができますが、DOM の構築をブロックしたりページのレンダリングを遅延したりする場合もあります(「JavaScript を使用してインタラクティブにする」もご覧ください)。JavaScript によってページのレンダリングが遅延しないよう、AMP は非同期の JavaScript のみを許可しています。
AMP コンポーネントは内部的に JavaScript を使用している場合がありますが、パフォーマンスが低下しないように慎重に設計されています。
独自の JS は amp-script
で許可されており、サードパーティの JS は iframe で許可されていますが、それによってレンダリングがブロックされることはありません。例えばサードパーティのJSが 非常にパフォーマンスの悪い document.write
API を使用していても、メインページのレンダリングがブロックされることはありません。
すべてのリソースを静的にサイズ設定
画像、広告、iframe などの外部リソースについては、リソースがダウンロードされる前に AMP が各要素のサイズと位置を判定できるよう、HTMLでサイズを指定する必要があります。AMP はリソースのダウンロードを待たずにページのレイアウトを読み込みます。
AMP はリソースのレイアウトとドキュメントのレイアウトを切り離します。ドキュメント全体(およびフォント)をレイアウトするために必要な HTTP リクエストは1つだけです。 AMP はコストのかかるブラウザでのスタイルの再計算とレイアウトを回避することを目的に最適化されているため、リソースの読み込み時に再レイアウトが発生することはありません。
拡張機能メカニズムによるレンダリングのブロックを阻止
AMP では、拡張機能メカニズムによってページのレンダリングがブロックされることはありません。AMP はLightbox、Instagram の埋め込み、ツイートなどの拡張機能をサポートしています。これらの拡張機能は追加の HTTP リクエストを必要としますが、これらのリクエストがページのレイアウトとレンダリングをブロックすることはありません。
独自スクリプトを使用するページでは、最終的に独自タグが含まれることを AMP システムに通知しなければなりません。例えば、amp-iframe
スクリプトは amp-iframe
タグが含まれていることをシステムに通知します。AMP は iframe ボックスを作成しますが、作成する前にその中身を把握することはありません。
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
すべてのサードパーティ JavaScript をクリティカルパスから除外
サードパーティのJSは、同期的な JS の読み込みを好んで使用します。また、document.write
などの同期スクリプトも好んで使用されます。例えばページ上に5つの広告があり、その広告によって3つの同期読み込みが発生し、かつそれが1秒ずつ接続遅延を起こしている場合、JS を読み込むだけで 15秒かかることになります。
AMP ページではサードパーティの JavaScript を使用できますが、使用できるのはサンドボックス化された iframe の中だけです。使用範囲が iframe に限定されているため、メインページの実行がブロックされることはありません。このような JavaScript により複数のスタイルが再計算されたとしても、そのごく小さな iframe にはほとんど DOM が含まれていません。
スタイルの再計算とレイアウトにかかる時間は DOM のサイズに限定されるため、iframe の再計算はページのスタイルとレイアウトの再計算に比べて非常に高速に行われます。
すべての CSS のインライン表示とサイズ制限を義務化
CSS はすべてのレンダリングをブロックし、ページの読み込みをブロックし、肥大化する傾向があります。AMP HTML ページでは、インラインスタイルのみが許可されています。そのため、大多数のウェブページと比較してクリティカルレンダリングパスから1つ以上のHTTPリクエストが削除されます。
また、インラインスタイルシートの最大サイズは50キロバイトです。このサイズは非常に洗練されたページには十分に大きいものですが、それでもページ作成者はCSS をクリーンにしておく必要があります。
フォントの呼び出しを効率化
ウェブフォントは非常に大きいため、ウェブフォントの最適化はパフォーマンスにとって非常に重要です。少数の同期スクリプトと少数の外部スタイルシートを含む典型的なページでは、ブラウザがこれらの要素がすべて読み込まれるのを待ってから 巨大なフォントのダウンロードが開始することになります。
AMP システムは、フォントのダウンロードが開始するまで HTTP リクエストを一切宣言しません。これが可能なのは、AMP のすべての JS に async 属性があり、インラインスタイルシートのみが許可されているためです。ブラウザによるフォントのダウンロードをブロックするような HTTP リクエストはありません。
スタイルの再計算を最小限に抑制
皆さんが何かを測定するたびにブラウザはページ全体をレイアウトする必要があるため、コストのかかるスタイルの再計算が発生します。AMP ページでは、すべての DOM が読み込まれてからすべての書き込みが発生します。これにより、フレームごとに発生するスタイルの再計算を1回までに抑制しています。
スタイルとレイアウトの再計算がレンダリングパフォーマンスに与える影響の詳細をご覧ください。
GPUで高速化されたアニメーションのみを実行
手っ取り早く最適化を行うには、GPU 上で最適化を行うしかありません。GPU はレイヤーやレイヤー上での要素の実行方法を理解しており、要素を移動したりフェードしたりできますが、ページのレイアウトを更新することはできません。そのようなタスクはブラウザに引き渡されますが、それは優れたやり方とは言えません。
アニメーション関連のCSSのルールにより、アニメーションをGPUで高速化できます。具体的には、AMPではページレイアウトが不要になるように、transform と opacity のアニメーション化と遷移のみが許可されています。詳細については、「アニメーションの変更に transform と opacity を使用する」をご覧ください。
リソースの読み込みを優先
AMP はあらゆるリソースのダウンロードを制御します。具体的には、リソースの読み込みを優先し、必要なものだけを読み込み、遅延読み込みされたリソースをプリフェッチします。
AMP はリソースをダウンロードする際にダウンロードを最適化し、その時点で最も重要なリソースが最初にダウンロードされるようにします。画像と広告がダウンロードされるのは、ユーザーが見ている可能性が高い場合、スクロールせずに見える範囲にある場合、またはユーザーがすばやくスクロールする可能性がある場合のみです。
AMP は遅延読み込みされるリソースもプリフェッチします。リソースはできる限り後から読み込まれますが、できる限り先にプリフェッチされます。このようにリソースは非常に高速に読み込まれますが、CPU はリソースが実際にユーザーに表示されるときにのみ使用されます。
瞬時にページを読み込み
新しい preconnect API は、HTTP要求が行われたときに可能な限り高速化するために頻繁に使用されます。これにより、ユーザーがページへの移動を明示的に指定する前にページをレンダリングできます。ページはユーザーが実際にページを選択するまでにすでに利用できる状態になっているため、すぐに読み込まれます。
事前レンダリングはあらゆるウェブコンテンツに適用できますが、多くの帯域幅とCPUを消費する場合もあります。AMP はこれらの両方の要因を減らす目的で最適化されています。事前レンダリングではスクロールせずに見える範囲のリソースのみがダウンロードされ、事前レンダリングでは CPU 的にコストがかかる可能性のあるものはレンダリングされません。
AMP ドキュメントが事前レンダリングされて瞬時に読み込まれる際、実際にはスクロールせずに見える範囲にあるリソースのみがダウンロードされます。AMP ドキュメントが事前レンダリングされて瞬時に読み込まれる際、CPU を大量に使用する可能性のあるリソース(サードパーティの iframe など)はダウンロードされません。
詳細については、「AMP HTML がプリロードスキャナーを最大限に活用しない理由」をご覧ください。