CPP： AMPに替わる標準策定の提案（翻訳版）

Following is a Japanese translation of the article, CPP: A Standardized Alternative to AMP —TimKadlec.com by Tim Kadlec. Translated by Ryo Watanabe .

CPP： AMPに替わる標準策定の提案

現状のGoogleのAMPプロジェクトに疑念を抱いているのは隠せません。とはいえ、明確にしておきたいのは、パーフォーマンスのフレームワークとしてのAMPの技術面に疑念を抱いているのではないということです。AMPに取り組んでいるコミュニティはパーフォーマンスのベースラインを築くために良い働きをしています。どんなフレームワークでもそうですが、同意する決断もあればそうでないものもあります。だからと言って、それが堅実なものではないわけではありません。ただウェブ制作に対するアプローチが違うというだけです。

しかし、それがウェブの美しさでもありますよね？誰でも、どこでもウェブで情報を消費できるというのは素晴らしいことですが、それだけではないですよね。ウェブの素晴らしさは、それに加えて、誰でも、どこでもウェブに貢献できるということです。

開発者登録のようなプロセスを踏まなくてもいいし、特定のアプリケーションを使ってアプリを作る必要もありません。極端な話、テキストエディタとサイトを置くサーバさえあれば良いわけです。

それだけです。あとは自分次第です。jQuery、Sass、React、Angularを使ってもいいし、普通にHTML、CSS、JavaScriptを選ぶこともできます。ビルドプロセスも多数の選択肢の中から、自分に最適なものを選べます。もちろん、なにが最適かは、それぞれ意見があると思います。でも、最終的に選択は自由です。ツールは自分で選べます。

しかし、現状のAMPの場合は違います。より良い[コンテンツ]配信の方法をAMPに結びつけているという疑念は根拠のないものだと多くの人が言っているのを聞いています。しかし、実にそれがGoogleがパブリッシャーの前にぶら下げた人参（見方によってはムチですが）になっています。AMPのコンテンツが検索結果でAMPではないコンテンツよりも優先されるといううわさが多くあります。すぐにはそうならなかったとしても、Googleは検索結果の「サーチ・カルーセル」に表示されるためには、有効なAMPドキュメントである必要があることを強調しています。明らかに、どのパブリッシャーもこの恩恵は受けたいはずです。

これは、サーチ・ランキング・アルゴリズムで何が優先されるか、Googleが過去に発表してきた同じような内容のものとは違っています。例えば、Googleが速いサイトを好むのは周知の事実です。しかし「そのためにはこの特定のツールを使わなくてはならない」と彼らが言ったことは一度もありません。今までは。

ページ作成の際にある特定のツールを使うよう指定することで、Googleは自身の仕事をとても楽にしています。未だにサイトがパフォーマンスを達成できているか検証する簡単な方法はありませんが、AMPがそれを実現します。AMPでは特定の要素や機能のみの使用を許可しているため、Googleは特定の最適化が適用され、やっかいなパターンが避けられていることに確証を持てます。このパフォーマンスの検証が、ユーザ体験をより良くするものとしてGoogleがAMPコンテンツを推奨することを可能にしています。

ゆえに、AMPで提供できることで自分で提供できないことを考えてみると、それはハイパフォーマンスのサイトではないのです – それは、すでに自分たちで実現する能力を持っています。AMPが提供するものは、この「検証」の部分なのです。

コンテンツ・パフォーマンス・ポリシー

私は似たような検証ができる標準化された方法を望みます。それは、開発者に特定のツールの使用を強要しない、そして、それに伴う「ウォールドガーデン（閉じた環境）」を匂わせないものです。

このトピックについては、いろいろな方が幾つかの議論をしています。その中でも、開発者が定義し、ブラウザが遵守するポリシーというアイディアに一番わくわくします。そのポリシーの名前について考えてみましたが「コンテンツ・パフォーマンス・ポリシー（Content-Performance-Policy / CPP）」が一番しっくりきます。

このCPPは、ヘッダーもしくはメタタグに入れる専用の指示（directives）（例えば、スクロールイベントの乗っ取りはしない…とか）を使ってポリシーを定義するアイディアです。ブラウザはこれをサイトが指定のプリシーを遵守しているという「約束」として見ることができます（この場合、スクロールイベントを乗っ取らないという約束として）。

もしサイトがその「約束」を破ろうとした場合、ブラウザは、例えばスクロールイベントを無効にする試みを無視することで、それをできないようにします。そうすれば、検索エンジンやソーシャルネットワークのアプリのようなコンテンツの埋め込み側（embedder）は、開発者が提供した「約束」が遵守されることを確証でき、サイトでのユーザ体験も[スクロールイベントの乗っ取りのような]アンチパターンによる被害を被らないことが保障されます。

CPPの指令（directives）は、第3者[のプログラムやコード]が、ある一つのサイトでできることをコントロールしたり、第3者[のプログラムやコード]が[それが埋め込まれた]サイトで正しく動作するという保障を提供することにも使えます。そすれば、コンテンツ・オーナーはページに多くの任意の第3者のソースコードから読み込まれたスクリプトやコンテンツがあっても、自分のページにユーザ体験を損なうようなアンチパターンが含まれていないことを確信できます。

CPPはすでに存在するコンテンツ・セキュリティ・ポリシー（Content Security Policy / CSP）からコンセプトや方法を取り入れることができます。それは、ポリシーがページにどのような影響を及ぼすのかライブサイトに適用する前に確認できる「伝達オンリー・モード（reporting-only mode）」の存在を意味します。

CPPのやり方は、開発者が自由に使うツールを選べるようにし、AMPが課すウェブ技術のある特定のサブセットに制限されることを避けることができます。ある特定のフレームワークを使う代わりに定義可能なポリシーのセットを使うため、ブラウザやアプリがどのようなコンテンツを強制・促進するか、より自由に選ぶことができます。例えば、あるアプリではその文脈で最適な、ある特定のポリシーのセットを探せる一方、Googleでは検索エンジンでページがどのように優先付けられるべきか考える際、全く違うポリシーのセットを優先することも可能になります。この方が、断然拡張性があります。

速さやユーザ体験を妨げないことが保証されたサードパーティのコンテンツや広告を許可し、それらの保証のないコンテンツをブロックする、よりスマートなコンテンツ・ブロッカーを考えることも可能になります。これにより、Acceptable-Ads program（容認可能な広告プログラム）のような中央集権化されたモデルを避けると同時に、同等の恩恵のある標準的な手法を提供することが可能になります。

では、AMPはどうなる？

AMP開発者には頭の良い人が多いので、その素晴らしい働きを無駄にするようなことはないはずです。配信の恩恵をツールから切り離せば、突然AMPはパフォーマンスのフレームワークになります。それがAMPに、より適した形です。開発者はパフォーマンスのゴールを達成するために、AMPを使うことも、その機能のサブセットを選ぶことも可能です。AMPが選択肢の一つになり、開発者がAMPの使用を強要されないところに違いがあります。

現在、CPPを共有して確立していくために、Yoav Weiss氏と一緒に正式なCPPのポリシー案をまとめています。すでに極めて早期の草案もあって見ることもできます。ブラウザやパブリッシャーの多くの人たちとこのアイディアについて話しましたが、いまのところフィードバックはポジティブです。人々は標準化されたアプローチを好み、とりわけパブリッシャーには、よりオープンで、彼らが強要されないものとして好印象です。

CPPのアイディアはまだできて間もないもので、ほとんどの議論が閉ざされた環境で行われたものです。この機会に公表して、なにが機能し、なにが機能しないのか、また、なにがCPPを改善できるのか、人々に考えてもらえればと思います。

技術的な観点からAMPがしてきたことは気に入っています。そして、ウェブのパフォーマンスを改善するという野心的なゴールにも賛同します。その過程でウェブを素晴らしいものにするオープンさを失わずに、そのゴールを達成できる道を一緒に探しましょう。