ブラウザの「待ち時間」を極限まで削れ：HTTP 103 Early Hintsという劇薬
フロントエンドエンジニア諸君、日々パフォーマンスチューニングに明け暮れていることだろう。「Lighthouseのスコアが上がらない」「FCP（First Contentful Paint）がどうしても削れない」そんな悩みを抱えてはいないか？
多くのエンジニアは、DOMの最適化やバンドルサイズの圧縮に躍起になる。だが、「サーバーがHTMLを生成している間、ブラウザは何をしているのか？」という、もっと根本的な「空白の数ミリ秒」に目を向けたことはあるだろうか。
今日は、その空白を埋めるための最先端の武器、HTTP 103 Early Hintsについて、ブラウザの深淵を覗きながら解説しよう。
—
ブラウザのレンダリングパイプラインを「先読み」する
通常、ブラウザはサーバーにリクエストを投げ、レスポンスとしてHTMLが返ってくるのを待つ。HTMLを受け取って初めて、「お、CSSが必要だな」「お、このJSも読み込まなきゃ」とパースを開始する。
この「サーバーがデータベースを叩いてHTMLを組み立てている時間」、ブラウザはただ虚無を見つめているだけだ。103 Early Hintsは、この「サーバーの処理待ち時間」を有効活用するための仕組みだ。
サーバーはHTML生成の途中で、「このページには、あのCSSとあのJSが必須になるはずだ」と予測できる。その瞬間に、`103 Early Hints`という先行信号をブラウザに投げる。
- 通常の流れ: リクエスト → サーバー処理（数100ms） → HTML受信 → リソース発見 → リソースDL開始
- Early Hintsあり: リクエスト → 103 Early Hints受信（リソースDL開始！） → サーバー処理 → HTML受信 → 既にリソースが準備完了
ブラウザのレンダリングエンジンは、HTMLを受け取った瞬間に「あ、さっき届いたあのファイル、キャッシュにあるよ」と、即座にCSSOMの構築やJSの実行に移れるというわけだ。
—
実務でどう実装するか：魔法のヘッダー
103 Early Hintsを有効にするには、サーバー側でレスポンスのヘッダーに `Link` ヘッダーを付与するだけだ。Node.jsやGo、あるいはNginxなどのリバースプロキシで設定する。
以下は、Node.js（Express風）での概念的な実装例だ。
/
- 実装のポイント:
- HTMLのボディを生成する前に、先行して103ステータスを送信する。
- ブラウザはこれを受け取ると、レンダリングに必要なリソースのDLを先行して開始する。
/
app.get(‘/’, async (req, res) => {
// 1. まずは103 Early Hintsを送信（これに対応しているブラウザは即座にリソース取得を開始）
res.writeEarlyHints({
link: [
‘; rel=preload; as=style’,
‘; rel=preload; as=script’
]
});
// 2. ここで重たいDB処理やテンプレートエンジンでのレンダリングを行う
const html = await renderPageSlowly();
// 3. 最後に200 OKとともに本体を返す
res.send(html);
});
現場でこの技術を扱う際の「注意点」
この技術は強力だが、銀の弾丸ではない。以下の「泥臭い現実」を理解しておかないと痛い目を見る。
1. ブラウザとCDNの対応状況:
103 Early Hintsはブラウザだけでなく、経由するCDN（CloudflareやFastlyなど）がサポートしている必要がある。エッジサーバーがこれに対応していないと、ただのノイズとして無視されるか、最悪の場合パケットがドロップする。
2. Preloadしすぎない:
何でもかんでも `preload` すれば良いわけではない。優先度の低いリソースまで先行取得させると、肝心なメインリソースの帯域を圧迫する。本当にクリティカルなCSSと、レンダリングをブロックするJSだけに絞るのがプロの作法だ。
3. キャッシュの神話:
既にブラウザがリソースをキャッシュしている場合、Early Hintsは余計な往復コストになる。サーバー側でキャッシュ制御をしっかり設計し、本当に必要な時だけ飛ばすという「賢さ」が求められる。
—
まとめ：アーキテクトとしての視座
フロントエンドの最適化とは、単にコードを短くすることではない。ブラウザという名の「実行エンジン」に、どれだけ効率よく、かつ先回りして情報を与えられるかという高度なコミュニケーションなのだ。
103 Early Hintsは、サーバーとブラウザの間の「無駄な沈黙」を会話に変える技術だ。もし君のプロジェクトで、TTFB（Time to First Byte）が大きく、かつ静的リソースの依存関係が明確なら、今すぐ導入を検討すべきだ。
ブラウザの内部構造を理解し、その動きを先回りする。それができるエンジニアこそが、次世代のスペシャリストだと私は信じている。さあ、今すぐDevToolsを開いて、ネットワークの滝（Waterfall）を眺めてみよう。そこに、君が削るべき「空白」が隠れているはずだ。
コメント