先日、Googleからモバイルファーストインデックス(モバイル版コンテンツを優先して検索結果の評価対象とすること)のアナウンスがありました。また、アメリカでの数字ではありますが、Techrunchの記事では、モバイルデバイスからのインターネットの利用がデスクトップからの利用を追い越したという内容が掲載されています。モバイルの重要性は数年前から話題には上がっておりましたが、いよいよ現実味を帯びてきたという気がします。

本記事で紹介するAMP(Accelerated Mobile Pages Project / “アンププロジェクト”と発音するようです)は、2015年10月に発表されたモバイルWEBの表示パフォーマンス向上を目指すオープンソースプロジェクトです。

Accelerated Mobile Pages Project

 

 

AMPに対応しているアプリやプラットフォームから、AMPの仕様に沿ったページを表示すると、高速にページが表示されます。2016年2月24日にはGoogleモバイル検索でも対応が開始されました。

もし手元にスマートフォンがあり、インターネットに繋がっているのであれば、Googleモバイル検索ですぐにAMPを確認することができます。AMP仕様に沿って作成された記事型のページは、上部にカルーセルの形で表示され、キャプションには“⚡AMP”と表示されますので、非対応ページと比べてみてください。

ニュース・キュレーション「Nuzzelアプリ」、「はてなブックマークアプリ」は、すでにAMPに対応しています。また、Googleのアナウンスによると、今後AmebaやLINEもAMP対応予定となっているようです。コンテンツパブリッシャーとしては、「New York Times」、「朝日新聞DIGITAL」や「毎日新聞」などのニュースサイトが続々対応を開始しています。

 

なぜAMPが推進されているのか

近年、Googleを中心に、WEBコンテンツのパフォーマンス最適化の重要性がトピックの一つとなっていました。

古くは技術書を多く発刊するオライリー社から出版されている『ハイパフォーマンスWEBサイト』を読んでパフォーマンスの勉強をしたエンジニアも多いはずです。そして「RAIL」というパフォーマンスモデルが発表され、フロントエンド界隈のエンジニアたちはそれを目指して試行錯誤をするような状況でした。

パフォーマンスを考えるときには、読み込み(ネットワーク)と描画(レンダリング)と大きく二つの指標が考えられますが、AMPの仕様を見ていると、それら両方のベストプラクティスを集めた結果だと感じさせられます。

例えば、WEBページに画像を表示するときに、読み込み済み(プリロード)のものを表示するときと、読み込み前のものを表示するときでは、描画のスムーズさに違いがあります。技術的な詳細は割愛しますが、画像やCSSなどの外部リソースを多く読み込むと、読み込みと画面描画のパフォーマンスを損なうことが多くあります。それらの解の一つとしてCSSをインラインCSSとして読み込み、かつ読み込み量の制限をしている点や、外部リソース読み込みをコンポーネント化している点があげられるかと思います。

またAMP対応されたドキュメントはGoogle AMP Cacheにて配信されます。Google AMP Cacheは、次世代ウェブの重要なキーワードのひとつ、HTTP/2を利用して効率的なドキュメント配信を行っているようです。もちろん、それらはほんの一部で、さらに多くの最適化のための施策が行なわれていることが想像できます。

AMPにマッチしたコンテンツと制限

ページが高速に表示され、ユーザーエクスペリエンスが向上できるのであれば、すべてのページをAMP化すればいい……というのが理想ですが、当然のことながら、いくつかの制限や相性などもあるようです。

1. 動的なコンテンツには不向き

Googleによると、動的なコンテンツよりも静的なコンテンツが特に効果を発揮するようです。その理由として考えられるのは、ページをキャッシュ配信するという性質や、動的なページで提供されるような多様な機能すべてを高速化するのが困難、またページ独自のJavaScriptが制限されているといった事が考えられます。

動的に生成されるページというのは、例えば検索結果ページや、最新の記事一覧など、毎回表示結果が異なっていたり、頻繁に変更されるページだったり、SNSやメンバーページなど個人の情報に依存するようなページです。

一方、個々の記事ページやブログ投稿、商品や製品の詳細ページなど、静的(不変)コンテンツにしやすいものはAMP化に向いていると考えられます。そういう理由もあってか、ニュースメディアやブログメディアの記事コンテンツを中心に先行実装されてきました。

2. サポートブラウザー

Webブラウザーでのサポートは、デスクトップ、モバイル、タブレットで利用できる最新2バージョンのメジャーブラウザー(Google Chrome、FirefoxやEdgeなど)と、そのWeb viewバージョンが対応しているようです。

3. HTMLをAMP HTML仕様に合わせる必要がある

AMP HTMLにはいくつかの独自の仕様があるのですが、制限に関していくつかピックアップすると:

・AMPのHTMLの仕様では一部使用できない要素がある

・独自のJavaScriptの使用ができない

・CSSはインライン(HTML内に埋め込み)で50kB内におさめる必要がある

・クローラにコンテンツを見つけてもらう必要があるため、robots.txt、コンテンツへのリンク設定、メタデータの設定を適切に行う必要がある

などといったものがあります。HTMLの一部の要素やJavaScriptが使えない、CSSの容量制限が厳しいとなると、コンテンツ作成ができないのではないかと思われます。

しかし実際は、使えないHTMLタグの代わりにAMP仕様のタグが用意されていてそれを利用できるJavaScriptで実装したいような機能はAMPにあるコンポーネントという形で最適化されたものが使える(仮に使用したい機能がコンポーネントになかったとしても、GitHubに機能リクエストを送ることができる)、CSSの容量が重くなりそうな複雑なレイアウトは、ショートハンドでの記述を利用するとか、クラス名を設定してなるべくスタイリングの対象の要素を短く記述するなど、容量に気をつけて作成する必要はありますが、CSS最適化ツールを利用したプログラムの利用で自動化する等で対応できると思います。

すべてのタグやコンポーネント、メタタグの詳細については割愛しますが、AMPプロジェクトのページで確認することができます。

AMPページ作成は負担になるのか?

スマートフォンが登場したときに、スマートフォン専用ページとデスクトップ専用ページをそれぞれ手作業で用意した時のように、もしくは iOSとAndroid用それぞれに同じ内容のアプリをリリースする必要があった時のように、それぞれAMP対応ページと通常ページを用意するのを負担に感じるかもしれません。

スマートフォン用とデスクトップ用ページが必要な場合はレスポンシブデザインを利用し、一つのファイルで複数のデバイスに対応するように、またiOSとAndroid用アプリが必要な場合にはWeb技術を利用した Apache Cordovaなどでソースを一元化するように、AMP対応にも何かしらのアプローチが必要になってくると考えられます。

実際のところ、レスポンシブデザインのようなスタイル、つまりAMP対応ページと通常コンテンツを一つのファイルにしてしまう(Googleではスタンドアローンと表現されています)ことも可能なようです。ただし、今現在、制限の多いAMP仕様に全てを合わせるというのはコンテンツ表現として難しい場合も多いかと思います。

考えられる方法としては、AMPに対応したCMSやプログラムを利用して、ひとつのソースから複数のフォーマットへ出力するという方法です。もし対象のコンテンツが「WordPress」を利用しているのであれば、既にAMP用のプラグインが開発されているようです。

CMSを利用していないのであれば、タグの抽象化、CSSファイルの埋め込み、メタの設定などを、近年のフロントエンド界隈におけるオープンソースのモジュールを元に、独自でプログラムを組んでいくという方法も考えられるかと思います。

 

まとめ :AMP導入は必要なのか?

モバイル中心の時代において、ユーザーにストレスなくコンテンツを届けるという意味ではAMPプロジェクトの取り組みは非常に大きなものであると思います。

繰り返しになってしまいますが、今現在においてAMPはコンテンツの内容によって向き不向きがあるため、必ず導入しなくてはならないというわけではないと思います。しかし、もしもコンテンツがマッチするようであれば、AMPの導入を検討するだけの価値は十分にある仕組みだと考えています。また、AMPが行っている高速表示をするためのアプローチや考え方は、AMPを導入しないサイトでも改善に役立つ考え方だと思います。

 最後に、今回残念ながら調査しきれなかったのが、「BACKYARD」のAMP対応状況です。

今回は大人の事情で調べることができませんでしたが、機会があればその辺りも探っていけたらと思っております。

参考サイト / 記事