キャッシュ戦略とレンダリングの深層：ミリ秒を削り出すブラウザエンジニアリング
ウェブパフォーマンスの最適化を語る時、私たちは往々にして「いかにJavaScriptの実行時間を削るか」「いかにバンドルサイズを小さくするか」というアプリケーションレイヤーの努力に囚われがちだ。しかし、どれほど洗練されたコードを書こうとも、ブラウザがネットワークの向こう側からアセットをフェッチし、それをパースしてピクセルに変換するまでの「物理法則」を無視していれば、真に堅牢なユーザー体験は手に入らない。
特に、HTTPキャッシュ、Memory Cache、そして Disk Cacheという、ブラウザのストレージ階層がレンダリングのクリティカルパスにどう干渉するか。このメカニズムを骨の髄まで理解しているかどうかが、プロのフロントエンド・アーキテクトと、単にフレームワークを使いこなすだけのエンジニアの分水嶺となる。
今回は、ブラウザがネットワークリクエストからDOMツリー構築、そしてレンダリングエンジン（BlinkやWebKitなど）へデータを流し込むまでの裏側の挙動を、メモリ効率とキャッシュ戦略の観点から徹底的に解剖していこう。
—
1. ブラウザキャッシュの階層構造とレンダリングへの影響
リソースが必要になった時、ブラウザは一律にネットワークへ走るわけではない。そこには厳格な優先順位と、速度のトレードオフが存在する。
[Memory Cache] (RAM: 超高速だが揮発性)
↓ (Miss)
[Disk Cache] (SSD/HDD: 永続化されるがI/Oコストあり)
↓ (Miss)
[Network] (TCP/TLS handshake + 転送遅延)
Memory Cache：RAM上の超高速バッファ
ブラウザタブが開いている間、一度読み込んだ画像やスクリプト、スタイルシートはMemory Cacheに保持されることがある。これはOSのメモリ管理やブラウザのプロセスアーキテクチャに強く依存しており、開発者が直接HTTPヘッダーで制御することはできない。
しかし、ここにあるリソースはゼロI/Oコストでレンダリングエンジンへ直結するため、同一セッション内でのページ遷移（SPAのルート変更や、画像ギャラリーの再描画など）において、レンダリングの開始時間を極限までゼロに近づける最大の立役者となる。
Disk Cache：永続化レイヤーとパーサーブロッキング
HTTPキャッシュヘッダー（`Cache-Control`, `ETag`, `Last-Modified` など）に基づいてディスクに保存される。ここからの読み出しは、メモリに比べれば圧倒的に遅い（OSのファイルシステムI/Oとディスクの物理速度に依存する）。
ここで重要なのは、「Disk Cacheからの読み出し待ちが、HTMLパーサーの進行をブロックする可能性がある」という点だ。
例えば、HTML内に非同期属性のない`