エニグモでWEBエンジニアをやっております、大宮です。 今回は、先日英語版BUYMAで行った、AMP対応についてまとめた記事をお届けしたいと思います。
そもそもAMPとは？
Acceralated Mobile Pagesの略です。 その名称が示す通り、モバイル端末で高速なWebページを表示させるためのプロジェクト、またはそのためのフレームワーク(AMP HTML)の事です。 フレームワークはGoogleとTwitterにより共同開発されています。2016年の2月にローンチされて以降、AMP対応を行っている企業は増え続けています。
Googleからは今のところは明言されていませんが、メインの開発にGoogleが入っているということで、いずれSEOの上位表示に影響してくるのではないかという予測も立てられているようです。 現に、一部の記事ページではスマホで検索するとカルーセルで検索結果の上位に表示されます。
近年は新興国でもスマホ文化が普及する一方、回線速度の遅さが問題視されることもあり、AMPはこうした時代の流れにも対応したものと思われます。 国内を見ても格安SIMや通信容量制限による低速化などにより、WEBページの体感速度の向上はますます重要な要素になってきています。 ページが速く表示されるだけユーザーの満足度は向上するというのは、想像に難しくないでしょう。
実際に見てみましょう
実際に対応された英語版BUYMAのサイトを見てみましょう。
AMP未対応のページ（ベンチマーク計測：11.5秒） AMP対応のページ（ベンチマーク計測：3.5秒） AMP対応のページをキャッシュしたAMP Projectページ（ベンチマーク計測：0.76秒）
ベンチマークは低速な回線で撮ったものです。 体感でも表示速度が一番下のキャッシュ速度が速い事がわかるかと思います。
なお、上記AMPのページはPC版で見ると崩れているように見えますが、CSSをモバイルに最適化した(PC対応のCSSを排除した)結果です。後述する実装でAMPを別URLとした場合、AMPのページがPCからみられることはありませんのでOKとしています。
なぜ速いのか？
AMP対応のHTMLは読み込みが非常に速いです。その理由を見てみましょう。
- AMPでは、非同期のAMP専用JSしか使用出来ない。 - CSSのサイズ制限＋外部ファイルに置く事を禁止している - 画像のLazy Load＋幅高さ指定の強制でブラウザの負荷を軽減 特に一番大きいのは最後のLazy Loadでしょう。 通常Webブラウザはページの表示時でページ内のすべての画像を読み込もうとしますが、AMPでは表示領域のみ非同期で画像をロードしてきています。 それを可能にしているのが<amp-img />タグです。ampページでは通常の<img />タグは使用できず、すべてこちらに置き換える必要があります。
また、CSSのサイズ制限があるので、リッチなコンテンツの量は増やしづらく、AMPページとしては余分なモジュールを削りおとすことになり、全体として読み込むファイルサイズが軽減されやすいということです。
さらに、これらのHTMLは、AMP-ProjectのCDNサーバーにキャッシュされ、検索結果での表示時にはキャッシュされたページを表示するようになります。 このキャッシュ時に、画像もモバイル用に圧縮をし、ファイルサイズを軽減しています。
さらに検索結果の表示時には、ユーザーが見ている検索結果の部分で、裏側でPreconnect / Prerenderingが走っています。 ユーザーが検索結果からページにアクセスしようとしてタップした時には、すでに裏側でページが読み込まれているため、ユーザー体験としては爆速に感じるということです。
AMPの三大制約
AMPを実装するにあたって、設計の段階で留意すべき制約は３つあります。
- JSが使えない* - CSSは50KBまで - Cookieが使えない
ということ。言い換えれば
- リッチなページは作れません。
- ログインユーザーに応じて出しわけ...などの機能は使えません。
ということです。
JSが使えないというのは、自前のJSは一切使用不可ということで、JSでよく使用される機能について、ある程度はAMP-Projectの方で用意されています。 例えば、サイドバー、カルーセル、フォームのバリデーション等。詳細は公式のこちらのページに記載されています。
また、JSに関しては、2017年6月現在、amp-bindという機能が開発中です。 リリースされればJSで自前のスクリプトを書いた時ある程度は同じような挙動を実現できるようになります。 具体的には、イベントトリガーでclassやInnerText, attributesの値を動的に変更するということが可能になります。
が、それでも既存のJSの流用はできないため、amp-bind用に書き直す必要があります。
URL方式の設計
まずは上述のように、できることとできないことをただしく把握する必要があります。 基本的に上の項目を把握されていれば問題はありません。
次に、AMP用に新規URLを作るのか、既存ページをAMP化させるのかを決めます。 モジュールを分けるかわけないかという選択ですね。 可能であれば、メンテナンス性を考えて同一モジュール...つまり今あるページをAMP化し、新規では作らないというアプローチが望ましいです。ただ前述の通り、AMPには制限がありますので、オリジナルページを残したい場合もあるかと思います。 その辺りはページのボリュームと、JS書き直しの工数（既存機能への影響）を加味して判断する必要があります。
ちなみに新規でページを作る場合には、最初からAMPに対応したものと作成してしまえば、既存ページへの差し替えで悩むことはなくなります。
画面の設計
基本的にはオリジナルページから何を残して何を削るのかを判断する必要があります。 オリジナルページをそのままAMP化しても、CSSの容量超え＋JSのリッチコンテンツで実現可能なものと不可能なものが出ると思います。 なのでAMPページの要件として絶対に必須なものを厳選して残し、CSS容量や工数に余裕があれば別の機能の対応も行うというアプローチが良いでしょう。 実際に開発してみてできること、できないことが分かるという事もあります。
なお、前述の弊社サイト（商品詳細ページ）では、商品情報＋カート購入機能だけを残して、グローバルナビや検索バーといった要素は排除しています。これらの要素はAMPでも代替は可能ではありましたが、CSSの容量制限の関係で断念した要素でした。
実際にAMPページにしてみる
AMP専用の雛形がありますので、ご自身のサイトにあててみましょう。 bodyタグやheadタグやCSSは適宜調整していただければ良いかと思います。
これで、サイトはAMPとして扱われます。
なおAMP用に新規でURLを作る場合には、オリジナルページのHTMLのheadタグ内に下記を記述しましょう。 <link href="AMPページのURL(フルパス)" rel="amphtml"> これでGoogleにもAMPページが認識されます。
ただし、エラーが出る（多分）
Chromeの開発者モードを開きURLの末尾に#development=1とつけましょう。雛形をそのまま使っていない限り、このように大量のエラーとなるはずです。
弊社サイトの対応途中で怒られていた内容としては、主に下記のような内容です。
- img -> amp-imgに変換＋幅・高さ指定してください
- scriptタグの使用してる所を全部削除してください
- a href="javascript:void(0);"など
- cssをインラインで読み込みしてください
- cssのファイルサイズを削減してください
このエラーを解消しないと、GoogleからAMPページとして認識されませんので、すべて対応しなければいけません。 根気よく対応していけば、いずれは下記のように「AMP validation successful.」となりますので、頑張って対応しましょう。
WEBアプリケーションの場合はVIEWにIF文があることも多々あるので、当然ながらその条件分岐は全パターンみておく必要があります。
晴れてエラーがでなくなれば、本番環境にデプロイして、完了となります。 この時本番環境でしか動いてない監視用のJSなどがあると、またエラーになってしまいますので、注意深く観察しましょう。
終わりに
AMPはそれなりに工数もかかる上に、完成する画面としては真新しいものではありません。 むしろ既存の画面より機能が削ぎ落とされたものなので、パッとみた完成品は物足りなさを感じるかもしれません。
なかなか成果のわかりにくい改修ではありますが、実際にAMP対応によって数字の伸びた事例も挙がってきています。 何より低速回線のユーザーにも、快適な挙動のページをお届けするという意味で重要な要因となりますので、ぜひとも導入を検討していただければと思います。
本記事がその際の一助となれば幸いです。
