完全なプリレンダリングよりもはるかに効率的
もしそれだけの話であれば、オリジン サーバーから簡単に AMP ページをプリレンダリングできるはずです。しかし、オリジン上では、ページが有効な AMP であることは保証できません。有効な AMP であることは、AMP JS ライブラリが行うカスタム プリレンダリングにとって非常に重要です。
リンクのプリフェッチのような単なるページ全体のプリレンダリングとは異なり、AMP のプリレンダリングではユーザーの帯域幅や CPU、電池の利用も制限されます。
有効な AMP ドキュメントは、プリレンダリングの段階で「協調的」に振る舞います。最初に表示されるビューポートのアセットのみがプリロードされ、サードパーティ製のスクリプトは実行されません。これによって、はるかに低コストで、帯域幅や CPU の負荷も低いプリロードを実現しています。さらに、プラットフォームは最初のページだけでなく、ユーザーがクリックしそうないくつかの AMP ページのプリレンダリングもできるようになります。
安全な埋め込み
AMP Cache はブラウザのプリレンダリングに依存していないため（上記のセクションを参照）、通常のナビゲーションでページからページへの移動を行うことはできません。そのため、AMP キャッシュ モデルでは、プラットフォームのページ上でインラインでページをオープンする必要があります。リクエストされた AMP ページで安全にその処理を実行できることが、AMP Cache によって保証されます。
- 検証ツールによって、メイン ドキュメント内にクロスサイト スクリプティング（XSS）がないことが保証されます。
- さらに、AMP Cache はドキュメントを解析して明確な方法でシリアライズし直します（つまり、HTML5 のエラー訂正には依存しません）。これによって確実に、バグや差異を解析するブラウザで XSS を防ぐことができます。
- キャッシュは、コンテンツ セキュリティ ポリシー（CSP）を適用します。これによって、XSS 攻撃に対する多層防御が提供されます。
プライバシーの強化
さらに、AMP Cache はプリレンダリングの際に重要な問題となり得るものを取り除きます。AMP ページをプリロードしているコンテンツ プラットフォームの結果ページで検索を行った場合、プリロードされた AMP ページは自分がプリロードされていることがわかりません。
次のように考えてみましょう。たとえば、「breakfast burrito」で検索を行うとします。私のことをよく知っている方なら、同じタイトルの
Parry Gripp の曲を検索していることは自明でしょう。しかし、検索結果ページには、実際に朝食のブリトーを売っているファストフード チェーンの AMP 検索結果も表示されます。翌月には、リンクをクリックしていないのに（ひょっとするとクリックするかもしれませんが…）あちこちに表示される実際の朝食のブリトーは見たくないと思うようになるでしょう。広告主も、ブリトーに関する意味のないマーケティングを繰り返して無駄なお金を使いたいとは思いません。AMP のプリロードは AMP ページのサイトオーナーや関連するサードパーティには隠蔽されるため、これはユーザーと広告主の双方にとってメリットになります。
劇的な高速化につながる自動最適化
AMP Cache はまず以上のようなことを行いますが、その後もたくさんの変換を行っています。具体的には、次のような最適化が挙げられます。
- （大規模サイトオーナーだけでなく）すべてのコンテンツに対して、一貫性のある高速なコンテンツ配信ネットワークを無償で提供
- スクリプトの理想的な順番への並び替え、重複するスクリプトタグの削除、不要な引用符や空白文字の削除などによる HTML の最適化
- キャッシュ時間を無限にするための JavaScript URL の書き換え
- イメージの最適化（帯域幅を平均 40% 削減）
イメージ圧縮という側面だけでも、Google はキャッシュを通してロスレス圧縮（EXIF データの削除など、視覚的変化のない圧縮）やロス圧縮（視覚的変化がある圧縮）を行っています。さらに、対応ブラウザに対してはイメージを WebP に変換し、srcset 属性（いわゆるレスポンシブ イメージ）がない場合は自動生成して、各端末で正しいサイズのイメージを生成、表示します。
さらなる改善に向けて
皆さんの言いたいことはわかります。AMP Cache プロバイダは、コンテンツのミラーリングを行っています。これは重要な役割で、大きな責任が伴います。キャッシュ プロバイダがすべての AMP ページに不快な広告を挿入するといったとんでもないことをしでかせば、AMP はサイトオーナーにとって有用なソリューションではなくなり、衰退してゆくことになるでしょう。
AMP は、サイトオーナーやユーザー、プラットフォームにとってモバイルウェブをよりよいものにするために、皆さんとともに作り上げたものです。AMP チームが AMP Cache の
厳格なガイドラインをリリースしたのはそのためです。興味深い点を 2 つ抜粋しましょう。ガイドラインでは、コンテンツは「ソース ドキュメントを視覚的、UX 的に忠実に再現」できる必要があり、キャッシュ プロバイダはたとえキャッシュ自身が使われなくなったとしても、 URL はいつまでも使えるようにしなければならないことが明示されています。これらを始めとするさまざまなルールによって、キャッシュが皆さんのコンテンツを壊さないことが保証されています。
何よりも重要なのは、AMP Cache は 1 つだけではなく、そこには大きな余地があることです。先日、実際に Cloudflare が独自のキャッシュを
発表しています。
AMP Cache ガイドラインがリリースされたので、そのルールに従う限り、他のインフラ会社も新しい AMP Cache を作ることができます。どのキャッシュを選ぶかは、AMP を統合したプラットフォーム次第になります。
キャッシュからウェブ標準へ
以上で、AMP Cache がユーザー フレンドリーなモバイルウェブを即時的に提供するメリットやトレードオフについて理解していただけたと思います。しかし、同じようなさまざまな劇的な最適化をトレードオフなしに、あるいはキャッシュを使わずに行えたらどうでしょう。
個人的には、将来そういったことを実現し、キャッシュ モデルの先を行く（たとえば、アセットが読み込まれる前にページがどのように見えるかがわかる静的レイアウト システムなど）まだ発明されていないウェブ標準ができることを夢見ています。
2016 年、私たちは
CPP でその最初の 1 歩を踏み出しました。現在、CPP は
Feature Policy となっています。これは、「このサイトでは document.write や iframe でのサードパーティ ページの読み込みは許可しない」といったことを指定する方法を提供します。静的レイアウトや安全なプリレンダリングのような高度な概念には、さらなるウェブ プラットフォームの変化が必要です。しかし、未来へのタイムトラベルのように、不可能なことではありません。ただ非常に難しいだけです。
Twitter や
Slack で連絡と取りながら、一緒にこれを探求してみませんか。また、私はいつも皆さんの質問やアイデア、懸念に耳を傾けていることもお忘れなく。前進あるのみ！
Posted by
Yoshifumi Yamaguchi - Developer Relations Team
