こんにちわ、@t32kです。先日、3/18に大阪で開催されたFRONTEND CONFERENCE 2017に登壇してきました。また弊社メルカリは懇親会スポンサーでした。今回は『スタンドアロンAMPのススメ』というタイトルで講演した内容をシェアしたい思います。
私が所属しているソウゾウ社ではメルカリアッテというクラシファイドサービスを作っています。メルカリは配送システムを介して売買しますが、こちらは直接会って手渡しでモノの売り買いができます。もちろん、手数料や配送料はかかりませんので、よろしかったら使ってみてください。私はそこのWeb担当で、本サイトのAMP実装について話します。
今日のアジェンダです。
- AMPのメリット
- 表現力について
- テンプレート分散について
- 構造化データについて
- まとめ
といった内容でやっていきたいと思います。
AMPとは？
まずはAMPとは何か説明します。AMPとはAccelerated Mobile Pagesの略称で、Search Consoleのヘルプによりますと、
AMPはオープンな仕様に沿って作成されたWebページです。検証された AMPは Google の AMPキャッシュに保存されます。キャッシュに保存することでページをこれまで以上にすばやく表示できるようになります。
と書いてあります。
AMPを構成する要素としては3つが挙げられます。
- AMP HTML（amp-imgとかamp-***とか）
- AMP JS（最適化処理されたJavaScript）
- Google AMP Cache（Google CDNからの配信）
AMPは一見して、普通のWebページのHTMLですが、一部、amp-imgのような独自タグが実装されていたり、既存のHTMLタグが拡張されていたりします。また、そういった独自タグを正常にHTMLとして表示させるためにAMP JSというファイルも読み込まなければなりません。そうして、AMPとしてValidとして認められたら、Google CDNにキャッシュとしてコピーされ、高速に配信されます。
https://www.mercariatte.com/jp/#development=1
AMPエラーかないかどうかは、AMPを実装するページURLに#development=1を足すと、コンソール画面に（もしエラーがあれば）エラーメッセージが表示されます。
百聞は一見に如かずなので、動画で見てみましょう。このように、Googleの検索結果ページにおいて、AMPに対応したページが存在していれば、雷マークが表示されています。この時点で、該当のAMPは<iframe>で先読みされています。AMPの検索結果をタップすると、AMPビューワー（<iframe>）が表示され、閲覧できるわけです。
このとき、表示されているページのリソースはGoogleのCDNから配信されています。また、ATF(above the fold)上のリソースしか読み込まれておらず、それ以外の部分はスクロールすると遅延読み込みされます。つまり、検索結果ページ上で必要以上に通信することがないということです。このようなフローでAMPは最速にWebページを表示しています。
AMPのメリット
- 検索ランキングが上がるわけではない（SEO忘れて！）
- SERP上でキャッシュが効いた状態でアクセスできる
- ユーザー体験向上ヽ(=´▽`=)ﾉ
AMPのメリットをもう一度確認しますが、AMPにしたからといって検索ランキングが上がるファクターとして認められるわけではありません。ただ、SERP(Search Engine Result Page 検索結果ページ)上で、キャッシュが効いた状態で最速でページにアクセスできたり、一部の記事ページはTop Storieというカルーセルで目立って表示できたりするだけです。ページが速く表示されるということはそれだけユーザーの満足度は向上します。
開発者としてAMPを実装するモチベーションとしては、単にAMPをパフォーマンスフレームワークとして考えていて、AMPのルールに従えば誰でも比較的簡単にハイパフォーマンスなWebサイトを実装できるのがメリットだと考えています。
これまでAMPを最速に表示できるのはGoogle検索結果ページ上だけだったのですが、今月New Yorkで開かれたAMP Confでは、導入時期は未定ですが、新たにYahoo Japanも対応することが発表されました。そのほか、中国のBaiduやSogouといった検索プラットフォームも導入するそうです（同僚の@yui_tangが記事を書いています）。
またCloudflareを使用しているサイトでは、新たにAccelerated Mobile Linksという機能を利用することができ、これを使用するとGoogle検索結果ページ以外でもAMPビューワーでAMPを閲覧することができます。
GIF画像は私のブログサイト上でAMPビューワーが立ち上がる様子です。
また気になるAMPキャッシュの更新ですが、基本的にはAMPドキュメントが表示されると更新リクエストされ、次のユーザーは最新のコンテンツを閲覧することができます。ご自身のタイミングでキャッシュを更新したい場合は、https://example-com.cdn.ampproject.org/c/s/amp_document.html のようなAMPキャッシュURLに直接アクセスすることで可能です（適宜、ホストしているドメインや記事のパスに変更してください）。
AMPが望まれる背景
GoogleはかねてからモバイルWebが遅いことを気にしており、そのため1秒未満で表示することを目標にしています。ただこの目標は非常に難しいです。なぜなら、DNSルックアップやTCPコネクション、初回のHTMPリクエスト・レスポンスの往復でどうしても600ms以上はかかるわけで、残り400msの範囲で、サーバーサイドの応答やクライアントサイドのレンダリングをしなければなりません。
Googleのエンジニア Ilya Grigorik氏 著の『High Performance Browser Networking』ではこう言っています。
- バイトを送らないことよりもバイトを速く送る手段はない、つまり送るバイトは最小に
- これ以上バイトを速く送ることはできないが、ユーザーのより近くに置いとくことはできる
リクエストしてからページを用意するのでは遅すぎるので、AMPのように先読みして用意しておく。またGoogle CDNのように、より近くからリクエストできるというのは、理にかなっているといえます。
現実世界においてはお金は神様ですが、ことオンラインの世界においてはキャッシュとは非常に重要だとわかります。ユーザーの満足のためにもAMPを使うことが最善ではないかと考えます。
AMPの表現力について
さて、ここからAMPを実装するにあたって疑問に思ったことなど解説していきます。AMPはThe New York TimesやThe Guardianなどのメディア企業をはじめ、世界各国の企業で採用されています。もちろん、メルカリでもAMP実装をしています。
ただ、どれも見た目がすごく簡素です…
これには理由があります。
- 非同期スクリプトしか認めない(野良JSの使用禁止)
- リソースは予めサイズ指定する
- 拡張コンポーネントに描画をブロックさせない
- Third-Party JavaScript はクリティカルパスにいれない
- CSSは全てインラインに記述し50KBまでに制限する
- フォントの読み込みは適切に
- スタイルの再計算は最小限に
- GPUアニメーションしか認めない
- リソース読み込みの優先づけ
AMPの速さのため、守らなければならないことがいっぱいあります。一番大きいポイントは、AMPでは基本的にはJavaScriptを利用できない点にあります。世間には便利なjQueryプラグインのように簡単にリッチなインタラクションが実装できる手段があるので、これが使えなくなるのはだいぶ厳しいです。
しかし、その点は問題ありません。AMPコンポーネントという、簡単にインタラクティブなコンポーネントが実装できる仕組みがあります。
便利そうなAMPコンポーネントたち
<!-- 簡単な例 --> <amp-carousel height="300" layout="fixed-height" type="carousel"> <amp-img src="/img/image1.jpg" width="400" height="300" alt="a sample image"></amp-img> <amp-img src="/img/image2.jpg" width="400" height="300" alt="another sample image"></amp-img> <amp-img src="/img/image3.jpg" width="400"height="300" alt="and another sample image"></amp-img> </amp-carousel>
たとえば、AMP Carouselというコンポーネントを使いたければ、amp-carousel-0.1.jsという非同期Scriptを読み込み、<amp-carousel>というHTMLタグを使って実装していくだけです。実に簡単です。
ほかにもいろいろ便利なコンポーネントがあります。AMP公式サイトはAMPコンポーネントの実践的な使い方の見本市みたいなものなので、ぜひご覧になってみてください。
これらのコンポーネントは特定の用途で使う想定ですが、もっと汎用的に使えるコンポーネントがAMP Confで発表されました。amp-bindは現時点ではdevelopmentステータスですが、これをつかえばコンテンツを直接書き換えることができます。図のようにテキストを変更したり、class属性を変更してスタイルを変更したり、画像リソースの読み込み先も変更すること出来ます。
このように、AMPを実装するからといってなにかをあきらめなければいけないことはないです。AMP上でもリッチなインタラクションは可能です。
テンプレート分散について
これはThe New York Timesの記事ページのメタ情報です。<link>タグでいろいろ指定してあるのがわかります。
これをわかりやすく言えば、こうゆうことになってます。通常のデスクトップのためのページがあり、スマホ用のページが別途あります。さらに、そのスマホ用のページをAMP対応したページがあります。スマホページとAMPがPairedになっています。よって、同じ記事なのに3つのURL、テンプレートが存在することを意味します。
AMPに対応するのに、さらにテンプレートを追加するのは管理工数的にだいぶ手間です。普通にCSSメディアクエリを使用すれば、一つのHTMLでデスクトップやスマートフォンに対応できるというのは言うまでもありませんね。つまり、レスポンシブレイアウトで実装すればAMPページひとつで事足りるといういみです。このようなAMPをStandaloneと呼びます。Standaloneの場合、<link>タグのrel="amphtml"の記述は必要ありません。
<link rel="canonical" href="https://www.mercariatte.com/jp/">
上記のようにcanonical属性を1つ指定するだけです。
工数的にはAMP実装したHTMLひとつを使い回せれば、願ったり叶ったりです。モバイルWebを早くするために有効な手段がAMPですが、モバイルで速いということは、当然デスクトップで見ても速く表示されることを意味します。それに、AMPはAccelerated Mobile Pagesとは言っていますが、AMPのDeveloper AdvocateであるPaul Bakaus氏はこのように述べています。
モバイル専用というわけではなく、単にモバイルファーストなだけだと述べています。その証拠にAMP公式サイトのデスクトップのHTMLを見ればわかるように、AMPで実装されています。レスポンシブレイアウトで作られているわけです。
<html amp lang="ja"> OR <html ⚡ lang="ja">
※ AMPかそうでないか、手っ取り早く判断するには<html>先頭タグにampもしくは⚡がついてるかどうか見れば分かります。
ただ、最初からAMPのことも考えつつ、レスポンシブレイアウトも考えるのは、いささか大変かもしれません。そんな方にはAMP Startというボイラープレートのようなものがあるので、これをベースにカスタマイズしていけばよいかもしれません。
テンプレートが一つ管理する利点として、モバイルファーストインデックスがあります。デスクトップ・モバイル・AMPで異なったテンプレート（たいていの場合、デスクトップが主でモバイルが副次的な扱いになっているかと思います）に分けていれば、正確にGoogleに情報を伝えることが出来ません。そういう意味では、一つのテンプレートで管理するのは良いことです。
メルカリアッテでもレスポンシブレイアウトでAMPを実装しています。
構造化データについて
最後に、構造化データマークアップについてです。実装したAMPをGoogleの検索結果ページでAMPとして認められるためには、ただAMPの仕様どおりHTMLに実装するだけでは足りません。適切な構造化データも追加しなければなりません。構造化データに関しては構造化データ テストツールでエラーがないかチェックできます。構造化データというのは、そのページが何であるかを伝えるためのものです。
この例で言えば、このページはNewsArticleで、いつパブリッシュされたか、パブリッシャーは誰かと言った情報を持っています。
これはJSON-LDで記述していますが、その他にもMicrodataやRDFaのように直接HTMLのタグとして構造化データを埋め込むことができますが、HTMLの見晴らしが悪くなるので、JSON-LDで別途分けておいたほうが無難でしょう。GoogleもまたJSON-LDでの記述を推奨しています。
AMPに対応している、構造化データの@typeは、今のところ、Article、NewsArticle、BlogPostingといった記事だけです。
しかし、AMPを最も実装したいメルカリアッテの詳細ページは『記事』でしょうか？メルカリアッテはモノの売買ができるのEコマースのようなものです。記事とは言いにくいです。
最近では『レシピ』や『レストラン』にも対応したようですが、私が採用したい『プロダクト』はまだのようです。ですから、もう少し様子を見ようと考えています。
まとめ
Mobile AMP / Tested From: Japan – EC2 – Chrome – Emulated iPhone 5C – 3G
Desktop AMP / Tested From: Japan – EC2 – Chrome – Cable
まとめに入る前に、AMPのパフォーマンスフレームワークとしての評価を見てみましょう。AMPで実装したトップページ（動画：左）、実装前にトップページ（動画：右）で、載せているコンテンツ・レイアウトはほぼ変わりません。純粋にAMPかそうでないかの違いしかありません。
パフォーマンスの指標はどれもAMP側が勝っています。AMP自体の実装コストも、<img>タグを<amp-img>に変えたぐらいで数十分程度で出来ました（構造化データをどのように記述すればいいのか手間取りましたが…）。
最後に、AMPはビジュアル表現を制限するものではありません。必要であれば、UIを作成する際にデザイナーさんと一緒にAMPコンポーネントを眺めたりするなど、協力していくことも良いでしょう。
また、レスポンシブレイアウトの言葉もなかったような時代から運用しているサイトでもない限り、新規で作る際はレスポンシブレイアウトに対応したページで実装し、AMPも考慮にいれるとみんなハッピーになることでしょう。
無理に『記事』の構造化データを埋め込む必要はありませんし、EコマースサイトのようなWebアプリケーションをAMP化するのも、今の段階では心もとない印象なので、簡単な読み物系のサイトであればAMPを導入することはよいでしょう。
ありがとうございました。
