ブラウザの「待ち時間」をハックせよ：HTTP 103 Early Hintsの深淵
Webパフォーマンスの最適化において、我々フロントエンドエンジニアが最も恐れるのは「ネットワークの空白」だ。ブラウザがHTMLの最初のバイトを受け取る（TTFB: Time to First Byte）まで、レンダリングエンジンは何もできない。ただ、メインスレッドが空虚に佇むその時間は、近代Webにおいてあまりに贅沢な無駄遣いである。
そこで登場したのが HTTP 103 Early Hints だ。これは単なる「新しいHTTPステータスコード」ではない。ブラウザのプリロード・スキャナをサーバーサイドから直接ハックし、HTMLのパースを待たずにリソースのダウンロードを開始させるという、極めて野心的なバックチャネルである。
—
1. 103 Early Hintsのメカニズム：レンダリングの「先行予約」
通常、ブラウザはHTMLをパースし、`` を発見して初めて「あ、このCSSが必要だったのか」と気づく。ここにはネットワークの往復回数（RTT）分という、取り返しのつかないロスがある。
103 Early Hintsは、サーバーが「これから送るメインコンテンツ（HTML）には、このCSSとJSが必須だ」という情報を、メインレスポンスを生成する前の「前菜」として先に送る仕組みだ。
内部的な挙動のフロー
1. サーバー: リクエストを受け取る。DBクエリやテンプレートエンジンの処理に時間がかかることを察知。
2. サーバー: 処理が終わる前に `103 Early Hints` を送信。ヘッダーに `Link: ; rel=preload; as=style` を付与。
3. ブラウザ: 103を受け取った瞬間、メインのHTMLを待たずに即座に `style.css` のダウンロードを開始する。
4. サーバー: 処理が完了したら `200 OK` をHTMLと共に送信。
5. ブラウザ: HTMLが届く頃には、CSSは既にメモリ上のキャッシュに格納されている（あるいはダウンロード中である）。
これにより、TTFBの発生からDOMツリー構築までのクリティカルパスが劇的に短縮される。
—
2. 上級エンジニアが考慮すべき「非同期の罠」
この技術を導入する際、最も注意すべきは「過剰なプリロード」による帯域の無駄遣いである。
- 優先順位の競合: 103でプリロードさせたリソースが、HTML内に記述された重要度の高いフォントの帯域を奪う可能性がある。
- キャッシュヒットの判断: 既にキャッシュにあるリソースを103で指示してもブラウザは賢く無視してくれるが、サーバー側で「ユーザーが既に持っているか」を判断するロジック（`Cookie` や `Cache-Control` の状態判断）がないと、無駄なヘッダーが帯域を圧迫する。
実装時のコード例（Node.js / Expressの概念的実装）
// サーバー側でのEarly Hints送出のイメージ
app.get(‘/’, (req, res) => {
// 1. サーバー処理が重い場合、先にヒントを送る
res.writeEarlyHints({
link: [
‘; rel=preload; as=style’,
‘; rel=preload; as=script’
]
});
// 2. 実際の重い処理（DB接続など）
const data = heavyDatabaseQuery();
// 3. 本体のHTMLを返す
res.render(‘index’, { data });
});
—
3. ブラウザのメモリ効率とレンダリング負荷
ブラウザ内部において、103で受け取ったリソースは「プリロード・スキャナ」によって管理される。これはメインのHTMLパースとは独立したスレッドで動く。
ここで重要なのは、「103で何を優先して送るか」という選定基準だ。
- CSS: パースブロックを引き起こすため、最優先。
- フォント: `font-display: swap` を考慮しつつ、初回レンダリングに必須なら送るべき。
- JS: パース負荷が高いものは要注意。特にメインスレッドをブロックするようなJSを103でプリロードすると、ダウンロードとパースが早まりすぎて、逆にHTMLのレンダリング開始と競合し、CPU負荷を跳ね上げる恐れがある。
—
4. 現場の教訓：なぜ「バグ」になりやすいのか
103 Early Hintsはブラウザとサーバー間の「契約」だ。もしサーバーが「このCSSは重要だ」と嘘のヒントを送れば、ブラウザは貴重なネットワークリソースを浪費し、レンダリングが遅延する。
特に注意すべき重大な落とし穴:
- HTTP/2以上が必須: HTTP/1.1では103ステータスコードの概念が正しくハンドリングされないことが多く、モダンなストリーム制御が効かない。
- プロキシとCDNの透過性: 間に挟まるCDNやロードバランサーが103を破棄、あるいは誤解釈して `200 OK` に統合してしまうケースがある。これを確認するには `curl -v –http2` でレスポンスのヘッダーを執拗に追いかけるしかない。
—
結論：Webブラウザは「予言」を待っている
HTTP 103 Early Hintsは、サーバーサイドとフロントエンドの境界線を曖昧にする、極めて「ギークな」手法だ。ブラウザがHTMLをパースするまで何もできないという従来の制約を、サーバーからの「予言」によって突破する。
しかし、これは「魔法の杖」ではない。「何がレンダリングに真に必要か」という依存関係を完璧に把握しているエンジニアだけが使いこなせる武器だ。
自身のWebサイトのクリティカルパスを可視化し、何がレンダリングを止めているのかを理解しているなら、今すぐ103の導入を検討すべきだ。ただし、導入後は必ず `Web Vitals` の推移を監視すること。最適化のつもりで入れたプリロードが、メモリ管理を圧迫して `LCP (Largest Contentful Paint)` を悪化させるという皮肉な結末を迎えないために。
ブラウザの内部挙動を深く愛する諸君にとって、この「103という名の先行入力」は、Webをより速く、より堅牢にするための最初の一歩となるだろう。
コメント