Signed Exchange対応してるとGoogleがprefetchするってよ
Signed Exchange対応してるとGoogle検索で表示時にプリフェッチするようになったらしい。
Google検索上でプリフェッチされるということは言わずもがな、表示速度が改善するわけで離脱率やCore Web Vitalsにも影響してくるわけです。
とは言っても、「そもそもSigned Exchangeって何？」と思われる方も多いと思うので備忘兼ねて解説しようと思います。
Signed Exchange
Signed Exchange（略称：SXG）はWeb Packagingという現在策定中の仕様に含まれる技術の1つです。
Web PackagingはページとCSS、JSなどのリソースを1つにまとめて配信元が署名することで、配信元のサイトに代わって改竄できないコンテンツを配信する技術です。要は自分のサイトがexmaple.comだったとして、Web Packagingを使うとGoogleのキャッシュサーバーがexmaple.comとして自分のサイトのキャッシュを配信してくれるといったことができたり、オフライン下でも隣の人に自分がダウンロードしたサイトを安全に渡せるなど、これまでできなかった多くの配信が可能になります。
勘の言い方はすでにお気づきだと思いますが、これはまさにAMPが目指している形です。
上記の記事のGifアニメーションでは、AMPにアクセスしたのにURLはfoodnetwork.comになっています（従来だと必ずAMPはGoogleドメインだった）。これがWeb Packaging、特にSXGの力です。
このWeb Packagingは次の3つで構成されます。
コンテンツをサブリソースごとbundleして（Web Bundles）、bundleしたコンテンツに署名して（Signed Exchanges）、ブラウザ側で署名のロードや検証をする（Loading Signed Exchanges）という流れです。
SXGによってブラウザは「このコンテンツはexample.comのもので間違いない」と検証できるわけで、検証して改竄されてないことが確認できればURLバーにexmaple.comと表示しても問題ないわけです。先述のAMPの例はまさにこれですね。
Signed Exchangeとプリフェッチ
去年だったと思うのですがChromeがSXG対応をリリースしたことで少なくともChrome上では、任意のキャッシュサーバーから配信されたSXGを配信元のURLとして表示できるようになっていました。
これによる恩恵は大きく2つです。
- AMPのURLを配信元のURLとして表示することが可能になった
- SXGをGoogleの任意のサーバーにキャッシュして配信することが可能になった
また、Googleは元々検索結果でプリフェッチをやりたかった（というか昔一時期やってたような・・・？）節があるようで、とはいえなんでもかんでもプリフェッチしてたらサイトのオリジンサーバーやCDNに大量のリクエスト負荷をかけることになってしまうのでやってなかったようです。
ですがSXGをGoogleが自分たちでキャッシュ・配信してしまえば、Google検索からいくらプリフェッチしてもだれにも迷惑はかからないので、自分たちでキャッシュ＋プリフェッチを始めたわけです。
JAMStackとSigned Exchange
静的ファイルにしCNDなどで配信するJAMStackもどこかWeb Packagingと目指してるものは近い気がします。
ただJAMStackの場合、例えばNetlifyとかは日本にリージョンがないためリクエストに物理距離分レイテンシが発生するので、静的ファイルなのに200~300msほどかかってしまいます。NetlifyがSXG対応してくれたら最終的にGoogleのキャッシュサーバーに乗るはずなので、Googleのキャッシュサーバーが日本にあれば物理距離による数百msのレイテンシは発生しなくなるはずです。
Web Bundlesが実用化されて、サブリソースごと署名できるようになればどのCDNでも結果的にユーザーからのリクエストは全てGoogleのキャッシュサーバーにしか行かないことになるので、SXG対応してればCDNのキャッシュ機能自体にはベンダーごとの差がなくなるかもしれません。
今後NetlifyやCloudflareがSXG対応の機能を実装してくれたら個人的には嬉しいですが、軽く調べた限りはまだそういった話はなさそうなので、今後も動向に注目したいと思います。
Discussion