[レベル: 上級]
Signed HTTP Exchanges が有効になったデモ用の検索を Google は公開しました。
ここから検索すると、検索結果に出た AMP ページは AMP キャッシュの URL ではなく、そのページ本来のドメイン名を使った URL を表示します。
オリジントライアルが今月初めから始まっていましたが、すべてのサイトが Signed HTTP Exchanges の仕組みを現在は利用できます。
キャッシュ URL ではなく本当の URL を表示
Signed HTTP Exchanges が有効になったデモ検索には https://g.co/webpackagedemo の短縮 URL からアクセスできます。
ブラウザは Chrome 71 以降が Signed HTTP Exchanges をサポートします（Chrome Beta チャンネル以降、ゆくゆくはすべてのチャンネルでサポート）。
検索すると「ウェブパッケージング」を利用した検索であることを説明するメッセージが表示されます（Signed HTTP Exchanges は “ウェブパッケージング” (Webpakaging) で実現できる機能の一部）。
AMP⚡マークが付いた 1-800 Flowers からのページをタップしてみます。
通常なら、次の AMP キャッシュ URL がブラウザのアドレスバーには表示されます。
https://www.google.com/amp/s/www.1800flowers.com/blog/flower-facts/types-of-christmas-greens/amp/
しかし Signed HTTP Exchanges が有効になっているので次の、本来のURLが表示されます。
https://www.1800flowers.com/blog/flower-facts/types-of-christmas-greens/amp/
自前で構成するか、または CDN を利用する
Signed HTTP Exchanges は、それ専用の証明書を取得し自分が管理するサーバーで構成します。
Signed HTTP Exchanges でパッケージングされたキャッシュを AMP キャッシュサーバーに配信するために AMP Packager というツールを Google は公開しています。
自身での実装が難しい場合は、Signed HTTP Exchanges をサポートしている CDN を利用することもできます。
Cloudflare が Signed HTTP Exchanges のサポートを表明しています。
サンプルで見せた 1-800 Flowers は Cloudflare 経由で Signed HTTP Exchanges を実装しています。
Signed HTTP Exchanges はデジタル証明書の技術を用いて次の2つを実現します。
- 統合性――データが改ざんされていないことを保証する
- 認証――本人であることを保証し、なりすましを防ぐ
AMP キャッシュは実際には、キャッシュサーバーから配信されています。
しかし、Signed HTTP Exchanges によって本来の ウェブサーバーからコンテンツが配信されていて、かつ中身が変わっていないことを保証できます。
よって、キャッシュサーバーの URL ではなく 本来の URL を表示できるのです。
Signed HTTP Exchanges の詳しい仕組みに興味がある方は、AMP プロジェクトのブログ記事を読むといいでしょう。
また、Chrome Dev Summit 2018 では Signed HTTP Exchanges をトピックにしたセッションがありました（Signed HTTP Exchanges 開発の中心メンバーである、日本の Kinuko Yasuda さんがプレゼンしています）。
録画を YouTube で視聴できます。
Signed HTTP Exchanges は誰でも簡単に実装できるというわけではありません。
また、当面は Chrome だけのサポートになりそうです。
それでも、本来の URL でコンテンツを配信できないことによるさまざまな障害を取り去ることができる注目すべき技術です。