内存不足とレンダリングの深淵：ブラウザは極限状態でどう振る舞うのか
やあ、フロントエンドの極北へようこそ。
日々、リッチなSPAや複雑なデザインシステムの構築に明け暮れ、「なぜかこのページ、ローエンド端末だとカクつくんだよね」なんて頭を抱えていないだろうか。
JavaScriptのプロファイラを眺め、レイアウトシフト（CLS）のスコアを睨みつけ、果ては`will-change`の乱れ撃ちでDOMを汚染する――。ちょっと待ってほしい。そのパフォーマンスチューニング、もしかして「表層」しか見ていないのではないか？
ブラウザの挙動を真に支配したいのであれば、目を向けるべきは「メモリ」と「レンダリングパイプラインの物理的な衝突」だ。今回は、メモリプレッシャー（メモリ逼迫）という極限状態において、BlinkやWebKitといったモダンブラウザのエンジンが裏で何を考え、どうリソースをかなぐり捨てているのか。その残酷なまでの内部アーキテクチャと、プロフェッショナルが知るべき防衛策を紐解いていこう。
—
1. DOM/CSSOMツリー構築の裏で起きている「メモリの物理的暴食」
ブラウザがサーバーからバイトストリーム（HTML）を受け取った瞬間から、メモリとの静かなる戦いが始まる。
文字の羅列であるHTMLは、字句解析（Tokenization）を経てノードオブジェクトへと変換され、最終的にDOMツリーという巨大なメモリ上のグラフ構造を形作る。
ここでエンジニアがやりがちな致命的な誤解がある。「DOMノードなんて、たかが数千個ならメモリ食わないだろ」と。
甘い。DOMノード一個のサイズを侮ってはいけない。V8（あるいはJavaScriptCore）のヒープ上において、一つの`HTMLElement`インスタンスは、プロパティのハッシュマップ、イベントリスナーの参照、スタイル情報へのポインター、そして何よりC++側（レンダリングエンジン）の対応オブジェクトへのクロス言語参照を抱え込んでいる。
巨大DOMが引き起こす「ガベージコレクションの窒息」
DOMの肥大化が恐ろしいのは、それが単にメモリを圧迫するからだけではない。Garbage Collection（GC）のコストを跳ね上げ、メインスレッドを物理的に停止させるからだ。
[HTMLストリーム] -> [トークナイザー] -> [DOMツリー構築]
│
(メモリ枯渇の予兆)
▼
[V8 Major GC / Blink Memory Purge]
│
メインスレッドが完全に凍結 (Jank発生)
メモリが枯渇しかけると、ブラウザはOSから「おい、メモリ使いすぎだ」とプレッシャー（Memory Pressure Signal）を受ける。この瞬間、V8はヒープを綺麗にしようと全力を上げる。世代別GCのマイナー（Scavenger）ならまだしも、ヒープ全体をスキャンするメジャーGC（Mark-Sweep-Compact）が走った日には、メインスレッドは数ミリ秒から、最悪の場合は数十ミリ秒にわたって完全に凍結する。
アニメーションの最中にこれが起きたらどうなるか？ 1フレーム（16.6ms）の壁をやすやすと超え、ユーザーの目の前で画面が盛大にカクつく。これがメモリ不足がレンダリングを殺す最初のメカニズムだ。
—
2. スタイル計算とCSSOM：カスケードの裏で燃え盛るメモリ
HTMLパースと並行して構築されるCSSOM（CSS Object Model）もまた、メモリ食い虫だ。
セレクタの複雑さ、詳細度（Specificity）、そしてCSS Variables（カスタムプロパティ）の動的な書き換え。これらが絡み合うと、スタイル計算（Recalculate Style）のフェーズでブラウザのメモリ空間は爆発する。
特に厄介なのが、「インラインスタイルの濫用」や「JavaScriptからの動的なスタイル注入」だ。
// 【アンチパターン】これの何がヤバいか、アーキテクチャの視点で説明できるか？
function applyDynamicStyles(elements, dynamicColor) {
elements.forEach(el => {
// スタイルを直接書き換えると、CSSOMの構造が動的に変わり、
// 既存のスタイルルールとのマッチング（Rule Matching）が強制的に再計算される。
el.style.color = dynamicColor;
el.style.backgroundColor = getComplementaryColor(dynamicColor);
});
}
このコードの何が問題か？
JavaScriptから要素の`style`プロパティをいじると、ブラウザは「既存のCSSOMとインラインスタイルのマージ、および詳細度の再評価」を即座に行おうとする。メモリ逼迫状態でこれを大量の要素に対して行うと、スタイルルールを解決するための内部ハッシュテーブルが肥大化し、メモリバスの帯域を圧迫する。
さらに最悪なのは、これがレイアウト（Reflow）やペイント（Repaint）の無効化フラグ（Dirty Bit）を次々と立て、レンダリングパイプラインを無駄に駆動させる点だ。
—
3. ブラウザによる「非情なリソース解放」の内部メカニズム
では、メモリがいよいよ限界を迎えたとき、ブラウザはどう動くのか？
実は、Chromeをはじめとするモダンブラウザは、タブごと、あるいはプロセスごとに厳格なメモリ制限（Quota）を設けている。メモリが枯渇した際、ブラウザの内部スケジューラは「ユーザーに見えていないリソースから容赦なく切り捨てる」という防衛策をとる。
① 画像・フォントのテクスチャ破棄（Decoded Image Cache Purging）
DOMツリーやCSSOMが構築され、レイアウトが終わると、画像などはGPUメモリ（VRAM）やCPU上のデコード済みキャッシュに保持される。
しかし、メモリプレッシャーが高まると、ブラウザは「画面外（オフスクリーン）にある画像のデコード済みキャッシュ」を独断で解放する。
結果どうなるか？ ユーザーが急にページを下へスクロールした瞬間、画像が一時的に白飛びし、数ミリ秒遅れて「ピロッ」と再描画される現象に直面する。あれは、ブラウザがメモリを守るために、一度捨てた画像を慌てて再デコードしている姿なのだ。
② iframeのバックグラウンド凍結とメモリパージ
もしあなたのWebアプリが、大量の`