DOMContentLoadedとloadの違いと順番は？実行タイミングを整理

HTML文書を作成しているとDOMの準備と画像やスタイル・スクリプトなど外部リソースの読み込みが完了するタイミングの差に頭を悩ませることがあります。特に読み込みが遅いページでは、ユーザー体験やスクリプトの実行タイミングに大きな影響を与えます。本記事では「DOMContentLoaded load 違い 順番」をキーワードに、両イベントの実行タイミングの違い・順番・使い分けを最新情報をもとに整理します。

DOMContentLoaded load 違い 順番 何がどう異なるのか

まずはDOMのパース（解析）が完了した時点と外部リソースまですべて読み込まれた時点の違いを理解することが肝要です。DOMContentLoadedとloadはブラウザのページロードライフサイクルの異なる段階で発火します。どちらがいつ発生し、順番はどうなっているのかを明確にすることで、スクリプト初期化やユーザーへの表示操作などを適切なタイミングで行うことができます。

DOMContentLoadedとは何か

DOMContentLoadedイベントはHTML文書のパースが**完全に終了**し、DOMツリーが構築された直後に発火します。スタイルシートや画像、iframeなどの外部リソースはまだ読み込み途中でも発火します。ただし、defer属性付きスクリプトやモジュールタイプのスクリプトはいったんダウンロードおよび実行が完了するまでこのイベントの発火が**保留**されます。これによりDOM操作やUI初期化などを画像や大きなリソースの読み込みを待たずにできる利点があります。最新のブラウザではこうした挙動が標準化されています。

loadとは何か

loadイベントはwindowオブジェクトに対して発火し、ページ内のDOM構築だけでなく、すべての外部リソース（画像、スタイルシート、iframe、スクリプトなど）が完全に読み込み、利用可能になった時点で起きます。文書の表示に必要なすべてが整ってから動かしたい機能（例えば画像サイズ取得やアニメーション開始など）はこのイベントに紐づけるのが安全です。

順番はどうなっているか

順番は非常にシンプルで、まずDOMContentLoadedが発火し、その後loadが続きます。ただし、DOMContentLoadedの発火が遅れる場合があり得ます。例えば、head内で同期スクリプトがあり、それがCSSの読み込みや他のパースをブロックしていると、DOMContentLoadedの発火がそれら終了後まで待たされます。つまり順番は常に「HTMLパース完了 → DOM構築 → DOMContentLoaded → 外部リソース読み込み完了 → load」となります。

DOMContentLoadedとloadが発火する具体的な順番

具体例を挙げて「DOMContentLoadedとloadがどのような順番で発火するか」を理解することで、実際の遅延要因や事前準備のタイミングを見極めやすくなります。タイミングを可視化しながら順序を追うことで、スクリプト配置法や属性（async／defer）の影響も把握できます。

基本の読み込みプロセスの流れ

ページ読み込みの典型的なプロセスの流れは次のようになります。まずHTMLのパースが始まり、DOMツリーが形成されます。同期スクリプトが存在する場合はその間パースが停止します。次にdefer付きやモジュールスクリプトが実行され、その後DOMContentLoadedが発火します。その後、画像やスタイル・フォントなどの外部リソースの読み込みが完了するとloadイベントが発火します。

同期スクリプトと非同期またはdeferスクリプトの影響

同期スクリプトはHTMLのパース中に出現すると、読み込みと実行が終わるまで次のパースがストップします。これによりDOMContentLoadedの発火が大きく遅れることがあります。一方、非同期（async）スクリプトはパースをブロックせず読み込み完了次第実行され、DOMContentLoadedの発火タイミングにはあまり影響しない場合が多いです。deferスクリプトはHTMLのパース完了後に実行され、その完了を待ってDOMContentLoadedが発火します。

画像・スタイルシート・iframeなどの読み込みの影響

loadイベントは画像などのメディアファイルやスタイルシートなど、ページ全体の表示に関わるすべてが読み込まれた後に発火するため、これらのファイル数やサイズが大きいとload発火までに時間がかかります。CSSが多数あるとCSSOMの生成にも時間がかかるためDOMContentLoadedが遅れる要因になる場合もあります。iframeの読み込み完了もloadの発火のタイミングに影響します。

なぜDOMContentLoadedとloadの順番と違いを知る必要があるのか

イベントの順番と違いを理解することは、サイトのパフォーマンス最適化やユーザー体験の改善、バグ回避の観点で非常に重要です。どのイベントに処理を紐づけるかで表示速度や操作可能時間、スクリプトの実行の安全性が変わります。最新のブラウザ挙動を踏まえて正しい使い分けができれば、開発効率も保守性も高まります。

ユーザー体験（UX）への影響

DOMContentLoaded発火後はDOM操作が可能になるため、ナビゲーションメニューの表示、クリックイベントの有効化など、ユーザーがページを操作できる要素を早く機能させたい場合に効果的です。loadを待ってしまうと画像や動画の読み込み遅延で画面が完全に表示されるまでの間にユーザーが操作できない時間が長くなってしまいます。

パフォーマンス最適化との関係

パフォーマンス診断ツール（LighthouseやブラウザのDevTools）ではDOMContentLoadedとloadの時間差が重要な指標になります。この差を把握し、不要な同期スクリプトの削除やスクリプトのdefer属性化、画像の最適化などを行うことでページ表示の初動が速くなることが確認されています。特に初期表示の高速化がSEOや離脱率に与える影響が大きいため、DOMContentLoadedを重視する設計が現代のウェブ開発で主流となっています。

スクリプトのエラーや競合回避

DOMContentLoadedより前にDOM要素を操作しようとしてエラーになるケースや、loadまで待たずにstyleや画像に依存した処理をDOMContentLoaded時に行って想定外のレイアウト崩れを起こすケースがあります。逆に、loadイベントを待たずに画像サイズ取得やstyle適用を行った結果、不正確なサイズやスタイル判定がされることもあります。これらを防ぐために、どの処理をどちらのイベントで実行するかを明確に設計することが重要です。

DOMContentLoadedとloadの使い分けと最新の実践例

最新情報をもとに、どのようなケースでDOMContentLoadedを使い、どのような場合にloadを使うのが最適かを実践的に整理します。最新のブラウザ挙動やリソース種別ごとの読み込み特性を踏まえた設計パターンは、現場の問題解決に直結します。

DOMContentLoadedを使うべきケース

主にHTML構造が整えば処理できるもの、以下のような処理がDOM構築後すぐに動かせるものです。ナビゲーションやメニューの初期化、クリックイベントの登録、フォームバリデーション、動的コンテンツ挿入など。また、スクリプトをdefer属性付きで読み込むことでHTMLパース中のブロッキングを防ぎつつ、このイベントに処理を紐づけることが可能です。軽量で、ユーザーが早くコンテンツとやりとりできる体験を提供できます。

loadを使うべきケース

画像ギャラリーや動画コンテンツ、スライダーやカルーセルなどリソースの寸法や読み込み完了が処理に関わるUI、またページ全体のローディング完了を待ってからアニメーションやフェードインを開始したい場合にはloadイベントを使うのが適切です。さらに、外部フォントの読み込み完了を待ってタイポグラフィを制御するような処理や、ユーザーが見ている画像に関する情報取得などもloadに依存することがあります。

最新ブラウザでの挙動をふまえた工夫

最新のブラウザではdeferやmoduleスクリプトの対応が広く完備されており、CSSOMの生成や同期スクリプトの遅延の影響が軽減される傾向があります。また遅延読み込み（lazy loading）技術やフォント読み込み戦略など外部リソースの読み込みが可制御になってきており、loadイベントの発火を見越した設計がしやすくなっています。これによりDOMContentLoaded～loadの時間差を短縮できるケースが増えています。

よくある誤解とトラブルシューティング

両イベントについて誤解されやすいポイントや、実際に起きやすいトラブルを整理しておきます。初心者だけでなく中級者でも陥りがちな落とし穴を知っておくことで、品質の高いウェブページを作ることができます。

DOMContentLoadedがCSSを完全に待つと思われがち

実際にはCSSスタイルシート自体は読み込みの完了を待たず、パース時に出会うスタイルシートによってパースやレンダーツリー生成が影響を受けることがあります。非deferスクリプトがスタイルシートの後に配置されている場合、CSSの読み込みを待ってからスクリプトを実行するためにDOMのパース進行が一時停止し、DOMContentLoadedの発火が遅れることがあります。ただしスタイルの完全な読み込み（例えば背景画像など）はloadイベントで保証されます。

loadを待ちすぎてインタラクションの低下が起きる

ページ全体の読み込みを待ってから初期操作を有効にする設計だと、ユーザーが利用可能になるまでの待ち時間が長くなり、操作性が落ちたり離脱率が上がったりします。特にスマホ回線や帯域制限がある環境では、load発火までの時間が大きくなるため、DOMContentLoadedを有効活用することがUX改善につながります。

画像やifameのonloadハンドラとの順序問題

bodyのonload属性・imgのonloadハンドラなど、要素ごとの読み込み完了イベントはwindowのloadイベントよりも先または後に発生することがあります。window.onloadはすべての要素のloadが完了してからなので、個別要素のonloadが先になることは多々あります。順番を前提とするロジックを組む時は、その順序が保証されない可能性があることを前提に設計するべきです。

DOM読み込みと完全読み込みを比較する表

DOMContentLoadedとloadの特徴を比較する表を提示します。機能や発火タイミング、実用例が一目でわかるようにしています。

まとめ

DOMContentLoadedとloadの違いは、DOM構築と外部リソース読み込みのどちらまで待つかにあります。順番としては常にDOMContentLoadedが先に発火し、その後loadが発火します。

軽快なページ体験を提供したい場合、可能な限りDOMContentLoadedを活用し、loadは必要なときにだけ使う設計が望ましいです。スクリプトの配置方法（async／defer／同期）、画像やスタイルの最適化などで両イベントの間隔を縮めることができます。

読み込み時の順番・タイミング・用途を正しく理解し使い分けることが、現代のウェブ開発において高品質な体験を提供する鍵です。