AMPの気になること全部、Googleの山口さんに聞いてきました!

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、Googleの山口能迪(やまぐち・よしふみ)さんです。

山口さんのセッションは「AMPで加速するモバイルウェブアプリケーション」でした。

スライド資料はこちらで公開されています。

https://docs.google.com/presentation/d/1ZYyHFRMZnD6bfi6fl9yh9G_TIs3roSxvp-Goa1JZv_c/htmlpresent

AMPとは何か?なぜ必要とされたか?

白石: 今日はよろしくお願いします。まずは簡単に自己紹介をお願いできますか?

山口: Googleでパートナー・デベロッパー・リレーションを担当している山口です。私の役目は特定の技術にとらわれず、最新の技術を広めていき、採用事例を増やすことです。

白石: 最新技術って、Googleさんすごい数出すから大変ですね(笑)。

山口: そうなんですよ(笑)。

白石: では、早速本題に入っていきたいと思います。AMPについてご存じない方のために、軽く説明をお願いできますでしょうか?

山口: AMPとはAccelerated Mobile Pagesの略で、高速にWebページを表示するための技術です(参考: AMPの公式サイト)。

現在のWebは、低速なインターネット上で、モバイルデバイスを用いた利用が非常に多くなっています。特に東南アジア、インドやアフリカ、中国、南米などでその傾向は顕著です。

そういう環境でもWebページをストレスなく閲覧できるよう、Web標準に則った形で、出来る限り高速にWebページを表示できるようにするための技術がAMPです。

白石: なぜAMPは速いのですか?

山口: AMPは速いというよりも、「遅くなる要素を排除している」と言ったほうが正しいと思います。AMPは主に静的で文字中心のコンテンツを配信することを主眼に、HTML5でできることを相当絞り込んだ仕様です。その仕様に則ったHTMLページだけが、妥当なAMP対応ページとして扱われます。

そうした制限のおかげでページサイズも小さくなり、ブラウザによるレンダリングも高速に行われるというわけです。

白石: 具体的には、どのような制限がかけられているのでしょうか?

山口: 例えば、標準のimg要素やvideo要素は使用できず、すべて<amp-img><amp-video>と言ったカスタムタグに置き換える必要があります。こうした要素を使うことで、全ての画像や動画が遅延表示され、また、画面に表示されない間はダウンロードされなくなります。

CSSは外部CSSもstyle属性も使用することができません。全てHTML内に<style>を用いてインラインで記述しなくてはなりませんし、そのサイズも50kbに制限されています。

JavaScriptに至っては、独自のコードを記述することはできません。AMPページでは、動的な振る舞いはすべてカスタムタグを使用して実現することになります。

白石: カスタムタグにはどのようなものがあるんでしょう?

山口: 利用できるタグはすべてドキュメントに記載されていますので、そちらをご覧いただくのが一番です(参考: AMPで利用できるコンポーネント/タグ)。

AMPのタグにはビルトイン(組み込み)とエクステンション(拡張)がありまして、エクステンションのタグを利用するには別途JavaScriptの読み込みが必要です。

ビルトインのタグの代表的なものは、先ほど取り上げた、<img>の代わりとなる<amp-img>です。エクステンションは現時点でもかなりの数が用意されていて、Google Analyticsを使用したり、YouTubeやTwitterの埋め込みを行えるタグもあります。

白石: そうしたエクステンションは、サードパーティの開発者やベンダーでも開発できるんですか?

山口: はい、可能です。ただ、AMPで利用できるタグは、AMP本体のリポジトリに取り込まれているものだけなんです。なので、開発したとしてもそれをリポジトリに取り込んでもらう努力が必要になります(参考: コンポーネントの開発・拡張についてのドキュメント)。

白石: なるほど、そういうプロセスを経なければならないようにすることで、カスタムタグのクオリティを担保しているということですね。そういうレビューはGoogleが行っているんでしょうか?

山口: AMP自体はオープンソースですし、Google一社のものではありません。リリース前からTwitterやPinterestもコミットしていましたし、オープンソースにしたおかげで、プロセスも透過的です。Google以外のコントリビューターも数多くいますし、そこは一般的な企業発のオープンソースプロダクトとあまり変わりはないと思いますね。

AMPページのアクセス解析は?広告は?

白石: AMPはWeb全体に大きな影響を与えている技術だと思いますので、ビジネス面も含めた、もう少し俯瞰的な部分からもお話をお聞きしたいと思います。

まず、AMPに対応すると、Google Analyticsなどの計測を正しく行えなくなるというのを聞いたことがあるのですが、これはどういうことですか?

山口: まず、<amp-analytics>タグを入れているAMPページは、Google Analyticsをはじめとしたツールで、統一的に計測を行うことができます。

ただそれでも、AMPキャッシュの仕組みの都合上、様々な不都合が生じていたのは事実です。

白石: AMPキャッシュというのはなんですか?

山口: GoogleのbotはAMPページを見つけると、専用のキャッシュサーバー(Google AMP Cache)にページをキャッシュします。 Googleは世界中にデータセンターやISP各社に協力していただいているエッジサーバーを持っており、ユーザーにとって物理的に最も近い位置のサーバーからページを読み込みますので、AMPページがより高速に表示されるというわけです。

(筆者注: Google AMP CacheはAPIを用いて明示的なキャッシュを行わせることもできる

白石: Googleの検索結果から辿れるページとかは、AMPキャッシュからの応答ですね。

山口: ただ、AMPキャッシュの問題は、元サイトとは異なるドメインからページが読み込まれるということです。そうなるとCookieが異なるので、Google Analyticsなどで正しく計測が行えないのです。

(筆者注: 例えば 当サイト(https://html5experts.jp)のAMPページは「https://html5experts-jp.cdn.ampproject.org」から読み込まれました)

ただこの問題は、今ではほぼ解決されています。具体的には、Cookieの欠点を補うためのクライアントIDという値を用いることで、AMPキャッシュから配信されたページへのアクセスと、オリジナルサイトへのアクセスを統一して扱えるようになっています。

筆者注: こうした問題とそのソリューションについては、以下のページに詳しい。

白石: なるほど、アクセス解析の問題については、ほぼ解決済みなのですね。知りませんでした。

ほかには、AMPに対応することでパブリッシャーの広告収益に影響が出るのではないかという話を聞きましたが、これについてはいかがでしょうか?特に、AMPページに比べて広告の表示速度が遅いことで、広告が表示される前にユーザーが離脱してしまうのではないかと聞いています。

山口: 実はAMPは、広告の高速化についても「AMP Ads」(筆者注: 「AMP for Ads (A4A)」とも呼ばれる)という取り組みを既に進めているんです。

これは、広告コンテンツについてもAMPフォーマットで記述するというもので、従来よりも素早く表示されるだけでなく、AMPページ以外でも利用できますし、様々な広告ネットワーク上でも利用できる柔軟性があります。

参考: AMP Ads の読み込みがさらに高速化 – Google Developers Japan Blog AMP Ads – GitHub (英語)

白石: そんな取り組みがされてたんですねー、全然知りませんでした。

AMPとPWAを組み合わせる

白石: 最後に、技術者向けに深いトピックをいろいろお聞かせください。

AMPとPWA (Progressive Web Apps)を共存させる、という話を聞きます(※)が、具体的にはどのように組み合わせることができるのでしょうか?

Combine AMP with Progressive Web Apps

山口: AMPは、言ってみればWebプラットフォーム上のフレームワークの1つに過ぎません。なので、例えばWebアプリマニフェストを書いておいて、AMPページからリンクすれば、モバイルアプリにWebアプリをインストールさせることも可能です。AMPだからと言って、特別なことは何もありません。

白石: なるほど。

山口: PWAと言うのはマーケティングワードという側面も強いので、「何を持ってPWAと呼ぶか」も難しいところではありますけどね。

AMPには<amp-serviceworker>というタグもあって、AMPページを起点にしてServiceWorkerをインストールさせることもできます。

これを応用すれば、まずはAMPページを高速に表示させておいて、裏でPWAに必要なアセットをServiceWorkerを利用してキャッシュしておき、リンクをクリックしたらPWAが高速に起動する…というアプローチも取ることができます。

白石: AMPとPWAのいいところ取りができるというわけですね。面白い。

あと、「PWAの中でAMPを使う」というアプローチも聞きました。外部のページをAMPで読み込むと言ったような。

山口: それも可能ですね。AMPをiframeで開くというのが一つのパターンですが、更にもう一歩進んだアプローチとしては、外部のAMPページを読み込んで、Shadow DOMに突っ込んじゃうっていうパターンもあります。

白石: それってどういうメリットがあるんですか?

山口: これも高速化のテクニックの一つですね。iframeだと、AMP JSの読み込みがiframeごとに走るので無駄が多いんです。Shadow DOMに埋め込むのであれば、既に元ページでAMP JSが読み込まれていればいいので、それぞれのページで読み込む必要がありません。

白石: なるほど、面白い!

山口: これはAMPに限った話ではないのですが、従来iframeを使って読み込んでいたコンテンツを、Shadow DOMに埋め込むというテクニックは、広告とかにも応用可能です。広告が元ページに悪影響を及ぼさないようにカプセル化する役割を、Shadow DOMに任せるわけですね。

白石: いやあ、最新のWeb技術てんこ盛りで、Webエンジニアとして大変興味深いお話です。AMPそのものも、そしてAMPを支える技術も、最新技術の塊ですね。本日は大変勉強になりました、ありがとうございました!

(撮影:刑部友康 写真提供:html5j HTML5 Conference 2017事務局)

Powered byNTT Communications

tag list

アクセシビリティ イベント エンタープライズ デザイン ハイブリッド パフォーマンス ブラウザ プログラミング マークアップ モバイル 海外 高速化 Angular2 AngularJS Chrome Cordova CSS de:code ECMAScript Edge Firefox Google Google I/O 2014 HTML5 Conference 2013 html5j IoT JavaScript Microsoft Node.js Polymer Progressive Web Apps React Safari SkyWay TypeScript UI UX W3C W3C仕様 Webアプリ Web Components WebGL WebRTC WebSocket WebVR