Google の高速ページ表示フォーマット AMP (Accelerated Mobile Page) をちょっと紐解く
Google と Twitter が共同で AMP というフォーマットを制定しました。このフォーマットは、Facebook の Instant Articles のように高速なページ表示を実現するためのものです。
近年、広告や重度の JavaScript, 多すぎる/大きすぎる画像の増加が、ページを表示するために非常に長い時間がかかってしまう問題を引き起こしています。 この問題を解消するためのフォーマットが AMP (Accelerated Mobile Page) です。
実際どうなの?というところと、個人の感想を織り交ぜてちょっと紐解いてみます。
ほんとに速いの?
百聞は一見に如かず。実際に、スマホから下記のリンクにアクセスすることで AMP を試すことができます。
スマホからでないと動きません。
試してみると分かりますが、とんでもなくスムーズです。正直、ここまで変わるとは予想していませんでした。
(ところでどうでもいい個人の感想)
私個人としての驚きは、これが Web で実装されていることです。
高速ページ表示フォーマットといえば、FB Instant Articles のようにアプリを前提としているのが普通でした。なぜなら、高速化のために表現をそぎ落としたフォーマットをきちんと表示するためには、そのための専用のランタイムが必要だからです。従来は、アプリでネイティブにランタイムを積んで、ネイティブ UI で表示を行う、というのが当然な発想でした。
AMP が面白いのは HTML をベースにして仕様が定られており、ランタイムを AMP HTML から外部 JS でロードすることが規定されていることです(!) ですから、 AMP で書かれたページは通常どおりブラウザで読み込み、正常に表示することができます。 生粋の Web 屋であるところの Google らしい実装ですね。
どうやって速くしてるか
技術的なとこ。
AMP で特筆すべきは下記の 5 点です。
- AMP のランタイムは AMP Project の CDN から固定された URL で配信される
- AMP では JavaScript は一切使えない
- 画像や動画などは、大きさを固定で指定しなければならない
- CSS はインラインで記述することが勧められている(たぶん)
- 広告などは iframe 経由で表示される
これらについて書く前に、触れるべきことがあります。
モバイルにおいて速度を下げる天敵は、ずばり「リクエスト」です。「重さ(ファイルサイズ)」ではありません。
モバイルのネットワークは帯域幅こそ広くとられているのですが、リクエストに付随する遅延(レイテンシ)が大きいことが知られています。遅延とは、リクエストが実際に届くまでにかかる時間のことです。リクエストが実際に届いてからダウンロードが開始しますから、いかにダウンロードが速くとも、遅延が大きいと全体で見たダウンロード時間が長くなります。
先ほどの事実を言い換えると、モバイルのネットワークは、リクエストが届いてからのダウンロードこそ速いが、リクエストが届くまでが長いという性質があります。
以上より、全体でみたファイルのサイズを下げるよりも、リクエスト数を少なくする方が効果が上がりやすい、ということがわかります。
この点を踏まえ、さきほど挙げた 5 点の施策を振り返ります。
AMP のランタイムは AMP Project の CDN から固定された URL で配信される
- どうしても AMP HTML に付随してしまうランタイムが重ければ意味がありません。AMP のランタイムはそこそこ大きく、gzip 後で 38 KB です。(jQuery と同じくらい)
- しかし、ランタイムを単一の URL から配信することで、一度でも AMP HTML を開けばクライアント側でキャッシュされるよう設計がなされています。
AMP では JavaScript は一切使えない
- 少し専門的ですが、JavaScript でレンダリングがブロックされないよう配慮されています。重くなりがちな JavaScript のリクエストも不要になります。
- いまの Web でもっとも多くリクエストを発行しているのは広告、ソーシャル、計測の JavaScript です。これらを強制的に切ることは、多大なリクエスト数削減をもたらします。
- AMP HTML はホスト側(AMP HTML を表示するアプリ / サービス)でキャッシュすることが規定されています。JavaScript を切ることで、セキュリティを担保しています。
画像や動画などは、大きさを固定で指定しなければならない
- 大きさが固定されていることで、画像を取得し終わらなくても、その分の高さを空けておくことができます。画像がどんどん入って文字がどんどん下にいく…といった表示のがくつきを防止できます。(リフローといって、処理が重いです。)
CSS はインラインで記述することが勧められている(たぶん)
- 少し専門的ですが、CSS はレンダリングをブロックします。インラインで書くことで、HTML と一緒のリクエストで同時に配信でき、表示までが早くなります。
- サンプルプロジェクトがすべてインラインで書かれていたのですが、別に外部 CSS を使ってもいいのかもしれません。
広告などは iframe 経由で表示される
- 広告はリクエストも多いし、画像 / 動画のファイルサイズも大きいことが多いです。ですから、広告の表示は通常ページのスピードに大きな影響を与えます。
- AMP は iframe の表示の優先度を意図的に下げています(たぶん)ですから、広告はどこにあろうとコンテンツが先に表示されてから、あとになって表示されることになります。
- ちなみにページ全体が iframe で表示されたりしないように、iframe は違うドメインのものを指定しなければならないようになっています
つまり?
HTML を 1 つリクエストするだけで表示がほとんど完了するように工夫されています。ほとんど、と書いたのは画像や動画, 広告などをロードしなければ完了しないからです。しかしながら、これらのリソースが読み終わらなくても、高さはあらかじめ記述されているので、ページ全体はすぐに要素の配置が終えられるようになっています。
リクエスト数の圧倒的な削減、要素の再配置がないことにより事前レンダリング(裏側で事前に表示を始めておくこと)の負荷が極めて小さくなっています。この利点が、先に示した Google の AMP 実装のようなスムーズなページ遷移を実現しています。
ところで、アナリティクスは…できます!
心配になりますよね… Google Analytics ははたして動くのか…??
JavaScript は全く動きませんが、<amp-pixel>
という仕様があります。
これは、指定した src
に毎回リクエストを行うタグです。
この src
に解析用のピクセル(1px の画像)を指定すればよい、というわけです。
Google Analytics の場合は Measurement Protocol がというピクセルの実装がありますので、こちらを利用すればよいです。
原理はメルマガやガラケーのアナリティクスと同じです。
AMP があることをどうやって Google に教えるか?
おそらく次の様な仕様になりそうです。(まだ確定してない)
<link rel="amphtml" href="hoge.amp.html" />
まとめ?
- AMP ページはめっちゃ速いしサクサク。まるでネイティブ。
- AMP を実装すると、Google から URL 遷移せずにページが表示されます。ぶっちゃけそれはどうなの…
- Twitter も実装するらしい(策定に関わってます)
- Facebook は対応するのかな?知りません
- AMP のプレビューを見る限り、SEO アドバンテージあるみたいです…
最近の Google は自社の仕様を広めるためのバラマキに余念がないですね…