ブラウザの自動メモリ管理とデタッチDOMリークの検出

なぜデタッチDOMリークを学ぶのか

SPAは画面を破棄せず差し替え続けるため、コンポーネントの生成と破棄が膨大に繰り返されます。このとき「破棄したはずのDOMが解放されない」と、操作のたびにメモリが積み上がり、やがてGC頻度の上昇・カクつき・タブのクラッシュに至ります。やっかいなのは、これがGCのバグではなく到達可能性の論理的帰結である点です。GCの基本動作は ガベージコレクションのブラウザ内動作 で扱った通り、回収されるのは「使わないオブジェクト」ではなくどこからも到達できないオブジェクトだけです。本稿はこの一点を起点に、デタッチDOM・イベントリスナ・タイマーが漏れる成立条件を厳密に整理し、ヒープスナップショットで犯人を特定して直すまでの手順を解説します。DOMの構造は DOM を前提とします。

デタッチDOMの成立条件

「デタッチDOM（Detached DOM）」とは、ドキュメントツリーから切り離されている（documentから到達できない）が、JavaScriptヒープからは到達可能なDOMノードを指します。リークが成立する条件は厳密に次の積です。

1. その要素（またはその祖先）がremoveChild／remove／innerHTML差し替えなどでツリーから外れている。
2. それでもJS側のGCルートから、その要素またはサブツリー内のいずれかのノードへの強参照が1本以上残っている。

const detachedRoots = [];
function render() {
  const panel = document.createElement("div");
  panel.innerHTML = "<ul><li>row</li><li>row</li></ul>";
  document.body.appendChild(panel);
  // li を1つだけ掴んでおく（よくあるDOMキャッシュ）
  detachedRoots.push(panel.querySelector("li"));
  panel.remove();          // ツリーからは外れる
}
// detachedRoots[i] が生きている限り、li→ul→panel の鎖で panel ごと残る

リスナとタイマーが参照を生かす経路

イベントリスナやタイマーそのものがメモリを食うわけではありません。問題はコールバック関数がクロージャとして要素を捕捉する点にあります。クロージャの捕捉規則は クロージャとスコープチェーンの内部 の通りで、ハンドラ関数が生きている限り、その捕捉対象も到達可能なまま保たれます。保持経路を整理します。

決定的な非対称があります。外した要素に付いたリスナは、その要素が他から到達不能なら要素ごとGCされ、リスナも一緒に消えます。問題になるのは、リスナがwindow・document・長命の親など要素より長生きするターゲットに登録されている場合です。このとき要素は「リスナ関数のクロージャ」という鎖でターゲットからずっと到達可能になります。

function mount(el) {
  const onScroll = () => layout(el);   // el を捕捉
  window.addEventListener("scroll", onScroll);  // windowは永続
  // el を消しても window→onScroll→el の鎖で残る
  // → アンマウント時に removeEventListener(onScroll) が必須
}

setIntervalはさらに直接的です。コールバックはタイマーキューにとどまり続け、clearIntervalを呼ぶまで決して解放されません。コールバックがDOMを触っていれば、そのDOMは無条件に生き続けます。

検出手順：3スナップショット法

リークの観測はDevToolsのMemoryパネルが中心です。性能計測の全体観は Webパフォーマンス も参照しつつ、まず増加傾向を確認し、次に犯人を特定します。

3スナップショット法の手順はこうです。(A) 操作前にsnapshotを1枚撮る。(B) 漏れが疑われる操作（パネルの開閉、ページ遷移など）を複数回繰り返す。(C) もう1枚撮る。(D) さらに同じ操作を繰り返し、3枚目を撮る。比較ドロップダウンで2枚目を1枚目基準（Objects allocated between snapshot 1 and 2）に絞ると、操作後も生き残っているオブジェクトだけが見えます。同じ操作で毎回同種オブジェクトが増え続けるなら、それがリークです。

リテイナを辿って真犯人を特定する

増分オブジェクトが分かったら、なぜ生きているかを**保持経路（Retainers）**で確認します。Retainersビューは「このオブジェクトを参照しているのは誰か」を下から上へ、GCルートまで辿るツリーです。これが原因究明の核心です。

デタッチDOMを直接探すなら、snapshotの上部フィルタにDetachedと入力します。Detached <div>のように、ツリーから外れたのにヒープに残るノードが列挙されます。狙ったノードを選び、下段のRetainersを開いて経路を読みます。

Detached HTMLLIElement
  └ in __proto__ / closure ... を無視し、最短の強参照鎖を見る
  └ retained by  closure (onScroll) in EventListener
       └ retained by  window  ← ここがGCルート。windowに登録したリスナが原因

参考に、リークの兆候を測る補助指標としてperformance.memory（Chrome）やmeasureUserAgentSpecificMemory()がありますが、これらは粒度が粗く切り分けには使えません。あくまでsnapshotのRetainersが特定の主役です。

修正パターン：保持経路を切る

原因が「ルートにつながる強参照」である以上、修正はすべてその経路を切ることに帰着します。要素の寿命と、それを参照するもの（リスナ・タイマー・コンテナ）の寿命を一致させるのが原則です。

実務でとくに効くのがAbortControllerです。複数のリスナを1つのsignalにまとめて登録し、破棄時にabort()を1回呼ぶだけで全リスナが外れます。解除漏れを構造的に防げます。

function mount(el) {
  const ac = new AbortController();
  const { signal } = ac;
  window.addEventListener("scroll", () => layout(el), { signal });
  el.addEventListener("click", onClick, { signal });
  return () => ac.abort();   // アンマウント時に1回。全リスナが解除される
}

まとめ