ブラウザの「呼吸」を理解する：DOMContentLoadedとloadの深淵
フロントエンドの最適化を突き詰めていくと、必ず「DOMContentLoaded」と「load」という二つの境界線に突き当たる。多くの初学者は「何となく読み込みのタイミング」程度に捉えているが、我々アーキテクトからすれば、これらはブラウザがHTMLという「設計図」を解釈し、最終的に「絵」を描ききるまでのクリティカルパスそのものだ。
今日は、この二つのイベントが単なるライフサイクルの一環ではなく、レンダリングエンジンのメモリ消費や、UIの「チラつき（Layout Shift）」を制御する重要なトリガーであることを解き明かしていこう。
—
1. DOMContentLoaded：パースという名の「建築」
`DOMContentLoaded`は、HTMLドキュメントが完全に読み込まれ、DOMツリーが構築された瞬間に発火する。ここで重要なのは、「DOMツリーの構築完了」と「画像の読み込み完了」は全くの別物だということだ。
ブラウザのパーサー（HTML Parser）は、上から順にバイトストリームをトークン化し、DOMを組み立てる。しかし、ここで最大の障壁となるのが`
---
4. アーキテクトへの提言：重大なバグを回避するために
現場でよく見かける「重大なバグ」は、`DOMContentLoaded`の前にスクリプトが実行され、存在しないDOM要素を操作しようとして落ちるパターンだ。逆に、`load`イベントを待つあまり、インタラクティブになるまでの時間が長すぎるケースも多い。
堅牢なアプリケーションのためのチェックリスト
1. 初期化コードをモジュール化する: `defer`属性を使い、メインロジックはDOM構築完了を待たずに読み込みを開始させる。
2. クリティカルCSSの抽出: CSSOM構築が完了しないとDOMはレンダリングされない。`
3. イベントの使い分け: DOM操作は`DOMContentLoaded`、画像サイズ計測や最終的な描画確認は`load`。この境界線を曖昧にしないこと。
ブラウザは非常に賢い。しかし、エンジニアの無知によってその性能は簡単に殺される。DOMツリーが構築されるまでの数ミリ秒、リソースがダウンロードされるまでの待ち時間。その「隙間」をどう制御するか。そこにこそ、フロントエンド・アーキテクトとしての矜持が宿るのだ。
さあ、次はブラウザの「レイアウト・スラッシング」をどう回避するかについて、深く語り合うとしようか。
コメント