[レベル: 上級]
Google は、Signed HTTP Exchanges のオリジン トライアル（試験運用）を開始しました。
AMP が抱える問題を解決する Signed HTTP Exchanges
高速化のためにキャッシュを配信する AMP には、たとえば次のような問題が依然として残っています。
- AMP キャッシュを表示した場合はオリジンのドメイン名ではなく AMP CDN キャッシュサーバーのドメイン名を使った URL が表示される
- キャッシュ CDN サーバーからコンテンツが配信されるため Cookie の受け渡しに支障があり、正確なアクセス解析を難しくする
Signed HTTP Exchanges を実装すると、たとえキャッシュであったとしてもオリジンのドメイン名から配信したコンテンツであるかのように扱うことができます。
上で挙げたような問題を根本から解決できます。
URL 問題を解決する手段として Web Packaging という名前の新しい技術のテストを Google は始めていました。
Signed HTTP Exchanges は Web Pakaging のサブセットとして仕様が公開されました。
Signed HTTP Exchanges の詳しい仕組みはこの記事では扱いません（興味がある方はこちらで調べてください）。
簡単に言えば、HTTPS でも用いられているデジタル署名の技術を使って配信元がたしかに本人であることを保証します。
AMP に当てはめると、実際には AMP キャッシュサーバーからコンテンツを配信していたとしても元は、僕たちのサーバーから配信されたコンテンツであることを証明できるので、キャッシュ URL ではなく本来のドメイン名の URL として処理できるのです。
サーバー側での構成が必要、普及には課題が残る
Signed HTTP Exchanges は Chrome 71 で オリジン トライアルとしてスタートし、一定の条件を満たすと終了します。
Signed HTTP Exchanges は自動で有効になるわけではありません。
サーバー側での構成が必要です。
自分で配信するコンテンツに Signed HTTP Exchanges を利用するのか、CDN サービスのように、コンテンツ作成者の代わりに配信するコンテンツに利用するのかによっても構成には違ってきます（オリジントライアルに参加する必要があるのは後者のみ）。
世の中にはレンタルウェブサーバーを利用してサイト運営している人も多くいます。
一般的には、自分ではサーバーを自由に構成することはできないでしょう。
つまりレンタルサーバーがサポートしない限りは、Signed HTTP Exchanges を利用することはできません。
たとえば、CDN サービスを提供している Cloudflare は Signed HTTP Exchanges のオリジントライアルに参加するようです。
こうした CDN サービス経由でコンテンツを配信すれば、一般のサイトでも Signed HTTP Exchanges の恩恵を受けられるかもしれません。
このように、Signed HTTP Exchanges の入手性については課題が残ります（AMP チームの人と話す機会があって、尋ねたところ Google もこの問題は認識しているようでした）。
試験運用がまだ始まったばかりで、かつサポートするブラウザが Chrome だけであることを考慮に入れると Signed HTTP Exchanges が誰にでも幅広く使えるようになるのはしばらく先のように思えます。
それでも、AMP を障害なく使うには Signed HTTP Exchanges は期待したい機能です。
サーバーを構成できる環境にあるなら Signed HTTP Exchanges 試してみてください。
デベロッパーサイトでのアナウンスはこちらから確認できます。