CA Reward

Tech Blog

Tech Blogトップに戻る

ウェブエンジニアなら知っておきたいGoogle AMPの技術概説

2016.08.04

  • このエントリーをはてなブックマークに追加
  • Pocket
310k
310kフロントエンドエンジニア

こんにちは。佐藤です。
AMPについてキャッチアップしなければと考えているウェブエンジニアの皆様に向けて、AMP対応の方法ではなく高速化を実現するためAMPが採用している技術面にフォーカスしてご紹介します。
AMPは活発にアップデートが行なわれており、状況も非常に速いスピードで変わっています。GitHubのリリースページもチェックしていくと良いでしょう。

AMPとは?

AMPとは、Googleが主導するモバイル端末でのWebページの表示高速化プロジェクトです。
AMPに準拠したWebページはGoogleのクローラーによってキャッシュされます。Googleの検索結果からこのキャッシュされたページにアクセスすると、モバイル端末では高速に表示されます。
このとき高速表示のポイントは以下の二つです。

  • ページ自体がGoogleによってキャッシュされていて、アクセス時のレスポンスが高速である
  • 検索結果ページが表示された時点で、検索結果上位のAMP準拠ページのデータの読み込みが始まる

AMP準拠ページは検索結果画面が表示された段階で、Googleのキャッシュサーバーからページの読み込みを先に開始して表示する準備をしておき、実際にそのページへのユーザー操作によるリクエストが発生した瞬間に検索結果からAMP準拠ページに表示を切り替えているようなイメージです。

AMPは以下の三つで構成されています。

  • AMP HTML
  • AMP JS
  • Google AMP Cache

AMP HTML

AMP HTMLはHTMLをベースとしてAMP用のカスタムプロパティで拡張したものです。

引用元:AMP spec

上記がAMPのサンプルコードです。
ほとんどHTMLのタグはそのままですが、<img><amp-img> になっているなど、一部のタグがAMPタグに置き換えられています。

AMP JS

AMP JSはAMP HTMLで記述されたコードを解釈し、リソースの負荷を管理しつつAMPの各要素を非同期に高速レンダリングするためのJavaScriptライブラリです。
上記サンプルコード中の <script async src="https://cdn.ampproject.org/v0.js"></script> がそれに当たります。

AMP CDN(Google AMP Cache)

GoogleによってキャッシュされたAMP準拠ページと画像など関連リソースを配信するCDNです。AMP JSもここから配信されブラウザキャッシュが有効になるため、現状40KBほどあるAMP JSのライブラリ本体ファイルも効率よく扱われます。

早く表示するための技術

AMPはHTMLの制限拡張によって高速表示を実現しています。

画像など外部リソースの表示サイズの固定

AMPは<img src='hoge.jpg' width='100%' height='auto'>といったリキッドレイアウトを許容せず、<amp-img src='hoge.jpg' width='320' height='100'>のような固定サイズ指定を求めています。
前者の場合は実際に画像を読み込むまで表示サイズが確定できませんが、後者は画像読み込みを待たずに表示サイズを決めることができ、リフロー(要素の大きさ、位置などの再計算)が発生しません。

AMP JS以外のJavaScriptを制限

ブラウザにおいてJavaScriptは非常に強力に動作し、レンダリングブロックやリフロー、リペイント(再描画)を容易に発生させます。これを排除するためAMP JS以外のJavaScriptの動作を許容しません。

css読み込みの制限

cssを<link rel="stylesheet" href="fuga.css">の形で読み込むと、

  • css読み込み
  • css解釈・スタイル構成作成
  • レンダリング
が発生します。

cssは非同期で動作・スタイリングを行うことはなく、読み込みが完了しスタイル構成作成まで進まないとレンダリングをブロックします。
そのためAMPはcssの読み込みを制限し、インラインスタイルの形での記述を求めています。
また解釈・スタイル構成作成に時間がかかるのを防ぐため、インラインスタイルのサイズは50KB以内としています。

リソース読み込みの順位付けの最適化

縦に長いページでは、下部で表示する画像は早く読み込むより後回しにするのが賢い挙動です。AMPは表示・利用位置などから重要度を検討し、順位付けを行った上でリソースの読み込みを行います。
重要度の低いリソースは極力遅く読み込みますが、読み込んだリソースは可能な限り早くプリフェッチし利用可能な状態にします。

プリコネクト・プリレンダリング

AMPはDNSルックアップ、TCPハンドシェイクの事前接続・開始をを行う新しいreconnect APIを利用してHTTPリクエストを高速化しています。これにより、ユーザーがページを開く前にそのページをレンダリングすることが可能になっています。レンダリングを事前に行えるので、ユーザーがページを開こうとタップした次の瞬間にはそのページを表示することができます。
しかしこのプリコネクト・プリレンダリングには帯域やCPUリソースを多く消費するので、すべてのウェブページに適用することはなく、最適化して動作します。現状はスクロールせずに見えている範囲のリンク先ページに適用されています。

モバイル端末でページを高速表示できる

読み込み・表示に時間がかかるWebページの離脱率は高くなるというのは長く語られていますが、AMPに準拠していれば前述の技術によりその問題は大きく改善されます。

検索結果で有利なる可能性がある

現状GoogleはAMP準拠ページの評価を高くしているわけではないとしていますが、検索結果ページの上部にカルーセル形式の検索結果表示領域を置いており、ここにAMP準拠ページが多く表示される傾向があります。そのためAMPに準拠すると検索経由での露出機会が増えると言えます。

AMPのデメリット

ページの二重管理

現状では一つのページで通常のhtml・css・JavaScriptによるリッチな表現とAMP準拠の両立はできないため、通常のhtmlでできたページとAMPに準拠したページを二重に管理する必要があります。

広告の利用制限

AMPはJavaScriptに制限をかけているため、JavaScriptで動作する広告はAMPに準拠したブログやメディアには掲載できません。
しかし広告自体がAMPに対応していれば掲載は可能になります。
参考:Integrating ad networks into AMP

まとめ

AMPは複雑な仕様があるわけではないので、準拠自体はそれほど難しいものではありません。
今後の流れとして、AMPプロジェクトに参加しているGoogleやTwitter以外にも、AMP対応のページが存在するかを検知し優先して表示するプラットフォームが出てくることが予想されます。
対応にあたり、ウェブページ中のメインとなるコンテンツ、本質は何なのかといった部分に向き合い整理することができるという副次的側面もあります。
そういった面からも、ブログやニュースなど、テキストがメインコンテンツとなるウェブページでは対応を検討してみても良いのではないかと思います。

参考

310k
310kフロントエンドエンジニア