ウェブページやファイルをブラウザに届けるとき、多くのサーバーは中身を圧縮してから送っている。長年その主役はgzipで、近年はより縮むBrotliが加わってきた。ここに三つ目の選択肢として、zstd(Zstandard)という圧縮方式が本格的に使えるようになりつつある。ChromeやFirefoxはすでに対応済みで、遅れていたSafariも直近のアップデートで足並みをそろえた。主要ブラウザが一通り対応したことで、実務でも検討できる段になってきた。
そもそも転送時の圧縮とは何か
HTMLやCSS、JavaScriptといったテキストは、そのまま送るとサイズが大きい。そこでサーバーは送信前にデータを圧縮し、ブラウザが受け取って展開する。この仕組みが転送時の圧縮で、リクエストのAccept-Encodingヘッダーでブラウザが対応方式を伝え、サーバーがContent-Encodingヘッダーで実際に使った方式を返す。読者から見えないところで、日々のページ表示を支えている土台のような機能だ。
gzipは登場からかなり時間が経っているが、いまも事実上すべての環境で通じる共通語として残っている。Brotliはgzipよりよく縮む方式で、Googleがウェブのために設計した。同じファイルでもより小さくなるため、公開サイトの配信では定番になってきた。zstdはMetaが開発した比較的新しい方式で、IANAの圧縮方式一覧にも「zstd」という名前で正式に登録されている。
zstdはどのあたりに位置するのか
三つの方式は、縮む度合いと処理の速さのバランスが少しずつ違う。ざっくり言えば、圧縮率はBrotliがもっとも高く、gzipが控えめ、zstdはその中間あたりに収まる。一方で圧縮にかかる時間はzstdが速く、条件によってはBrotliの最高設定より数倍速く処理できるとされている。縮み具合と速さのどちらを取るかという、昔からある悩みに新しい落としどころを用意した方式だと言える。実測を比べた記事でも、zstdはgzipより一回り小さく縮めつつ、処理そのものは軽いという傾向が繰り返し報告されている。数字の細部は圧縮の強さの設定やファイルの中身で変わるため、自分のサイトで試してみて初めて分かる部分も多い。
この特性から、zstdはその場で圧縮して送る動的なコンテンツと相性がよい。ページを表示するたびに圧縮し直す場面では、少しでも速く処理できるほうが待ち時間の短縮につながるからだ。逆に、あらかじめ圧縮しておける静的なファイルなら、時間をかけてでも最小サイズを狙えるBrotliの最高設定が向く。一度圧縮すれば以後は使い回せるため、処理速度の差はほとんど問題にならない。用途によって使い分けるのが素直な考え方になる。
導入で押さえておきたい前提
実際に使うにはいくつか条件がある。まず、Chromeはzstdを安全な通信、つまりHTTPS接続のときだけ候補として提示する。暗号化されていない通常のHTTPではgzipやBrotliに戻る。常時HTTPS化が当たり前になった今ならほとんどのサイトが該当するが、頭の片隅には置いておきたい。ブラウザごとの対応状況はCan I useのような一覧で確認できる。
サーバーやCDN側の対応も欠かせない。CDN大手のCloudflareは以前からzstdを扱えるようにしており、配信基盤としての土台は整いつつある。自前のサーバーで有効にする場合は、使っているウェブサーバーソフトがzstdに対応しているかを確認することになる。ブラウザが受け取れても、送り出す側が方式を用意していなければ実際には使われない。両側がそろって初めて効いてくる点は、gzipやBrotliと同じ理屈だ。
中小規模のサイトでどう受け止めるか
では今すぐ全サイトがzstdに乗り換えるべきかというと、そこは冷静でよい。多くの中小企業サイトは、gzipやBrotliがすでに効いていれば体感できる速度は十分に出ている。zstdはあくまで選択肢が一つ増えたという話であり、乗り換えないと遅れるという性質のものではない。既存の圧縮が正しく効いているかをまず確かめるほうが、ずっと実益は大きい。
それでも、配信の速さを突き詰めたい場面や、動的に生成する部分が多いサイトでは、zstdが効いてくる余地がある。地方の制作現場でも、圧縮方式の違いと使い分けの勘どころを知っておけば、サーバーやCDNを選ぶときの判断材料が一つ増える。ブラウザ側の対応が一巡した今は、その知識を仕込んでおくのにちょうどよい頃合いだ。
