Googleが中心となって開発・実装されているAMP（Accelerated Mobile Pages）プロジェクトは2016年の2月に正式公開されました。当初はGoogle謹製のサービスやアプリ、そして当初から開発に協力していたTwitterのサービスでのみ利用されるだけでしたが、Bingがアプリで利用を開始するなどそのメリットに惹かれる第三者も増えつつあります。国内でもはてなブックマーク・アプリを始め、利用しているアプリは散見されます。AMPを利用し始める彼らは、いったいAMPのどこに惹かれ、そしてなぜ開発リソースを割いてまで通常のウェブページよりも優先するのでしょうか。
プロジェクトのウェブサイトでは「Instant. Everywhere.」というキャッチコピーが使われています。AMPの目的はこれに尽き、つまりウェブページが「どこでも。即座に。」表示されるようにすることです。それは時代が求める高速化へのニーズに答えようというものでもあります。
ウェブページが高速であることは多くの意味を持ちます。特にモバイル環境では常に回線品質と転送量、そしてマシンパワーの問題に晒されているため、できうる限り高速化するニーズは大きいでしょう。そのためHTMLのパフォーマンスを上げるために様々な手法が考案されてきました。それらはscript要素のasync属性のように実装だけでなく仕様に取り込まれたため、10年前と比較するとそれなりに環境は整ってきたと言えるでしょう。しかし実装や仕様の進歩速度にもやはり限界はあります。また増え続ける高速化手法を適切に取捨選択することが難しいことも言うまでもないでしょう。
速い（fast）ことと即座（instant）であることは微妙な違いがあります。たとえウェブページの読み込みが速くても、その表示が即座ではないと、ユーザーの体感としては「遅い」ものとなるでしょう。AMPでは即座に表示されるために様々な工夫を行っています。
AMPは以下の3つからなるプロジェクトです。HTMLからパフォーマンスを下げる要因を排除したAMP HTML、そのAMP HTMLに従って書かれた文書を処理するAMP JS、そしてAMP HTML文書を高速に配信するAMP Cacheです。
HTMLでは私たちは自由にコンテンツをマークアップできます。その自由さはともすると非常にウェブページの読み込みや表示を遅くすることになります。AMP HTMLでは、利用できるHTML要素に大きな制限を課すことで、どうやっても遅くならないようにウェブページの代わりになる文書を制作できるように設計されています。
遅くならないように書かれたAMP HTML文書でも、画像の読み込みやスタイルの計算などによって速くないことはありえます。それらHTMLの書き方などではどうにもならない領域に踏み込んで更なる高速化を自動的に行ってくれるのがAMP JSです。
AMP JSがクライアント側での高速化を図るのに対し、ネットワーク側での高速化をもたらすのがAMP Cacheです。AMP JSライブラリーやコンポーネントのためのライブラリー、そしてAMP HTML文書やそれから参照されている画像など、あらゆるものをキャッシュします。それらはHTTP/2を使って同じドメインから配信されるため、非常に高速であることが期待できます。
AMPの導入例を見ているとニュース系のウェブサイトがほとんどです。やはり文章を効率的に読ませることに向いていると言えるのではないでしょうか。またそのひとつがネイティブ広告での成功例であることも注目に値します。
AMP JSやAMP Cacheは用意されたものをそのまま使うだけです。実際に私たちが行うことはAMP HTML文書を制作し、それをどこかで公開することだけです。つまり特別何かを用意するものはほとんどありません。
ここではAMPプロジェクトで公開されている最小構成のAMP HTML文書を例に、守るべき決まりを学びましょう。それら決まりを守っていないAMP HTML文書はそのポテンシャルを存分に発揮することはできません。
- AMP HTML文書の元となるHTML文書を教える（またはその逆の）
linkタグ - 描画領域の状態を指定する
metaタグ - AMP HTML文書の表示を滑らかにする
styleタグ
ブラウザーでAMP HTML文書を開くと開発者ツールで検証を行えます。これを最も利用することになることでしょう。エディターやタスクランナーと連携させたい場合はCLIバージョンを使うべきです。ウェブ・インターフェイスやブラウザー拡張もあります。
先述のようにAMP HTMLはHTMLのサブセットです。HTMLでは必要のないものが必須となっていたり、いくつかの要素へ制限が課されていたりしますが、いわゆるモダンブラウザーであるなら問題なく表示でき、ちゃんと互換性は確保されています。
パフォーマンス、セキュリティー、またはその両方の観点からHTML要素には多くの制限が課されています。
- パフォーマンスのために課される
style要素の制限 - セキュリティーのために課される
base要素の制限 - パフォーマンス及びセキュリティーの両面から課される
script要素の全面的な禁止
HTML要素へ制限が課される一方で、amp-で始まる名前を持つカスタム要素が多く使われます。カスタム要素の多くはプレースホルダー的な意味合いを持ち、関連付けられたJavaScriptファイルを読み込み、実行することでコンポーネントとして機能するようになります。
img要素を置き換えるamp-img要素- ツイートを埋め込む
amp-twitter要素
AMPのメリットは主にパフォーマンスとセキュリティーです。通常のブラウザーだけでなく、アプリ内ブラウザーでウェブページが開かれることが多くなった昨今、両者を追求することはウェブサイト制作において優先すべき課題のひとつでしょう。
パフォーマンスには既に述べたAMP HTMLでの制限が大きく関わっていますが、それだけではありません。AMP Cacheという強力なキャッシュ・サーバーを経由することも大きな意味を持ちます。現在AMP Cacheは、間違いなく世界最高クラスの資金力と運営能力を持つGoogleが運営しています。私たちはそのAMP Cache経由でAMPを配信し、また閲覧することになるので、絶大な効果があるものと期待できます。
AMP HTMLに課されている制限により、配信者は自前で書いたJavaScriptを含めることができません。そしてそのAMP HTMLは、AMP Cacheにキャッシュされる際、その正当性をチェックされます。そのためAMP Cache経由であるならAMP HTMLの制限を無視した怪しい文書であることはほぼなく、セキュリティー上の問題はほぼ起こらないと考えられます。またサードパーティー製のJavaScriptもAMPプロジェクトのCDN経由でしか配信されないため、それらのセキュリティー・リスクは非常に低いものと考えられます。
AMPは、インターネットそのものを抽象化し、置き換えかねない性質を持ちます。それが可能だとは思えませんが、それでもそういった性質を持つものが一企業の完全な支配下にあることには留意するべきでしょう。
ここまで話してきたように、AMPはオープンソース・プロジェクトではありますが、Googleとは切り離して考えることはできません。AMP Cacheを経由せずにAMP HTMLやAMP JSを取得することは可能ですし、それなりの効果を見込めますが、現実的ではないでしょう。特にセキュリティー上の観点からはオススメできません。仮にあらゆるウェブページがそのAMPバージョンを持ったとすると、それを利用することはGoogleが完全に支配した別のインターネットを利用することに他なりません。
すべてがGoogle経由であることは、プライバシー上の懸念もあります。何らかのアプリで内部的にAMPを利用してコンテンツを表示する場合、かなりひそやかな形でトラッキングは行われてしまうことでしょう。そういったトラッキングがGoogleアカウントやそのアプリのユーザー・アカウントと結びつけられることは現実としてはなさそうですが、どのような形で利用されるかは不透明ですし、アプリの利用規約くらいにしかそのことは明示されないことでしょう。
AMPは現実と理想のギャップを埋める手段として注目に値するものです。その仕様もHTMLを始めとしたウェブ標準仕様から逸脱したものではなく、汎用性や学習コストの点からも評価できます。
しかし、普通にHTMLとCSS、そしてJavaScriptを書くと、ブラウザーその他が頑張ってくれるという未来は少しづつ近づいています。高速で安定したウェブサーバーという問題も、安価に運用可能なCDNサービスの選択肢が増えたことにより、なんとかなることでしょう。ですからAMPには勝てないまでも、そん色のないウェブページを制作することは既に可能なはずです。
ただウェブページのパフォーマンスを大きく落とす広告においては、AMPの持つ広告コンポーネントの威力は見過ごせません。ことウェブ経由での収益において、広告は鍵になります。そういった広告が高速かつ安全に表示できることを保証できるAMPはとても魅力的です。