059. Conditional Request（条件付きリクエスト：「変更があったら教えて」という効率的な対話）

原理：無駄な送受信を極限まで減らす「合言葉」

「まだ変わってない？」と聞く勇気

通信の無駄を省くための最高峰の技術、それが「Conditional Request（条件付きリクエスト）」です。

前回のキャッシュ制御が「とにかく手元のものを使う」という強引な手法だったのに対し、こちらはもっとスマートです。ブラウザがサーバーに対し、「私は今、『バージョン A』のHTMLをすでに持っています。もしサーバー側で『バージョン A』から内容が変わっていたら、新しいHTMLをください。もし変わっていないなら、わざわざ中身を送らなくていいので、一言『変わってないよ』とだけ返してください」という、条件付きの問い合わせを行うのです。

サーバーが「変わってないよ（304 Not Modified）」という短い返事だけを返せば、大量のHTMLデータを送受信する必要がなくなり、通信は一瞬で終わります。

バージョンを見分ける「ETag」と「日付」

この仕組みを支えるのが、主に二つの合言葉です。 - ETag（イータグ）: 「この情報の今のID（指紋）」のような文字列。 - Last-Modified: 「最後に更新された日時」。

実践：サーバーとブラウザの「阿吽の呼吸」

1. 通信の手順（イメージ）

初回: ブラウザが普通にリクエスト。サーバーはHTMLと一緒に ETag: "v1" を返します。
二回目（HTMXクリックなど）: ブラウザは勝手に「もし変わってたら頂戴（If-None-Match: "v1"）」というヘッダーを付けて送ります。
判定:
- 変化あり → サーバーは最新HTMLと新しいETagを返します。
- 変化なし → サーバーは中身なしで「304 Not Modified」とだけ返します。

2. HTMXでの効果

HTMXはこの「304」を受け取ると、画面の書き換えを中止し、手元にある古い表示をそのまま使い続けます。ユーザーには通信が一瞬で終わったように見え、かつデータが最新でない心配もありません。

3. ステップ・バイ・ステップ解説

サーバー側の設定: あなたが使っているフレームワーク（Django, Rails, Spring, Laravelなど）の「ETag自動生成機能」を有効にします。
ブラウザの自動動作: HTMX（およびブラウザ）は、サーバーからETagを受け取ったあとは、自動的に「条件付き」で次のリクエストを送るようになります。あなたは特別なコードを書く必要はありません。
確認: 開発者ツールのNetworkタブで、ステータスコードが 304 になっている通信を探してみてください。それが「究極の節約」が行われた証拠です。

比較：通常のキャッシュ vs 条件付きリクエスト

通常のキャッシュ（Cache-Control）

動作: サーバーにそもそも聞きに行かない。
利点: 最も速い。
不安: 本当に今の情報が最新か、サーバーに確認していない。

条件付きリクエスト（conditional）

動作: とりあえず聞きにいくが、中身は送らせない。
利点: 常に最新であることが保証されつつ、通信量が極小。
不安: 小さな通信（聞きにいく手間）は発生する。

まとめ：初心者のための「知的な通信」

条件付きリクエストを使いこなすと、あなたのWebアプリは「一見普通だけど、なぜかものすごく軽くてサクサク動く」という、魔法のようなユーザー体験を提供できるようになります。

自動化を信じる: 多くのモダンなサーバーソフト（Nginxなど）やフレームワークは、これを自動で行ってくれます。あなたがすべきは、その「恩恵を壊さない（不必要にキャッシュを禁止しない）」ことです。
回線が細い環境での救世主: スマホの電波が悪い場所では、この数KBの節約が「動くか動かないか」の分かれ目になります。
Webの標準を知る: 「304」という数字を愛し、誇りを持って開発者ツールを眺めましょう。

「変わった時だけ、教えて」。そんなわがままを技術で解決する Conditional Request。この仕組みを知ることで、あなたはWebの裏側を支える「賢い仕組み」の住人となりました。次の記事では、自ら定期的に情報を聞きに行くアクティブな技「Polling（定期実行、060. Polling）」をご紹介します。