ウェブページを作るとき、DOMが操作できるようになったあとに処理をしたいという場面は多いものです。その際に「DOMContentLoaded」と「load」のどちらを使うかで動作するタイミングが大きく変化します。これら二つのイベントの違いと発生する順番を理解しておくことで、ページの応答性やユーザビリティの最適化が可能です。この記事では「DOMContentLoaded load 違い 順番」という観点で、その違いを最新情報を交えて詳しく解説します。
目次
DOMContentLoaded load 違い 順番を理解する基礎知識
まずは各イベントが何を意味するのかを抑えておきましょう。DOM（Document Object Model）の構築、リソースの読み込み、HTMLパースなど、それぞれの段階でどのイベントが発火するのかを理解することが後の使い分けに役立ちます。ここでは基本動作と定義、ブラウザの処理過程における位置づけについて説明します。
DOMContentLoadedとは何か
DOMContentLoadedイベントは、HTML文書が完全にパースされ、DOMツリーが構築された時点で発火します。外部のイメージや動画、スタイルシート、iframeなどリソースの読み込みは完了していなくても、このイベントは起こります。同期的スクリプトによってHTMLパースが阻害されている場合は、それが解消されたあとにこのイベントが発火します。HTML構造にアクセスして操作するUIの初期化などには最も適したタイミングです。最新情報では、deferredスクリプトもDOMContentLoadedの発火前に実行される仕様になっています。
loadイベントとは何か
loadイベントは、ページ上にある全てのリソースが読み込まれたあとに発火します。HTMLのパースに加えて、イメージ・スタイルシート・iframe・フォントなど外部リソースがすべて読み込まれて初めて発火するイベントです。ページの総合的な準備完了を検知したいときに使います。例えば画像のサイズを取得したり、アニメーションを開始したりする処理はloadイベント後に設定することが望ましいです。
ブラウザでの処理のステップとそれぞれの位置
ブラウザがページを読み込む過程は大きく次のステップに分けられます。HTMLの取得 → HTMLパースとDOM構築 → CSSの取得とCSSOM構築 → レンダーツリーの構築 → レイアウトおよび描画 → 外部リソースの読み込み完了。DOMContentLoadedはHTMLパース完了とDOM構築の直後の段階で、loadはそのあとで全ての外部リソース読み込みと描画タスクが終わった後に発生します。この順番を意識することが「順番」の理解の鍵です。
DOMContentLoadedとloadの順番の具体例と発火タイミング比較
理論だけでなく具体例で見てみると、違いと順番がさらに明瞭になります。ページにスクリプト・CSS・画像が含まれているケースや、deferやasyncを使っているケースでの発火タイミングの比較を示します。また、複数のイベントリスナーを使った場合の順序付けについても解説します。
スクリプト・CSS・画像がある標準的なページでのタイミング
例えば内にスタイルシートリンクと同期スクリプトがあり、内に画像が配置されている一般的なページでは次の流れになります。HTMLを取得 → HTMLのパース → スタイルシートと同期スクリプトの読み込みと実行（同期スクリプトはパースを一時停止） → DOMツリー構築 → DOMContentLoaded発火 →画像や他リソースの読み込みが完了 →load発火。実際DOMContentLoadedはページ表示が始まる準備ができたことを示し、loadは見た目も機能も完全に準備が整ったことを示します。
defer・asyncスクリプトを使った場合の変化
defer属性をつけたスクリプトはHTMLパース中に並行して読み込まれ、DOM構築後、DOMContentLoaded発火前に実行されます。順序はHTML中の記述順に従います。asyncスクリプトは読み込み完了次第即実行され、順番保証がありません。そのためasyncスクリプトがDOM操作を含むとDOM構築を妨げたり、DOMContentLoadedの発火が予期せぬタイミングになることがあります。最新のブラウザにおいてはdeferが推奨されるモードです。
複数のイベントリスナー・HTML内onloadハンドラなどでの発火順序
DOMContentLoadedにはdocument.addEventListenerで登録されたすべてのハンドラは、DOMの構築完了後に順番に実行されます。一方loadイベントはwindow.addEventListener(‘load’)や属性、各リソース（画像等）の個別onloadハンドラなどがすべて含まれます。たとえばとwindow.loadリスナー、画像のonloadなどは、DOMContentLoaded発火後、各リソース読み込み完了を経てから発火順序が来ます。リスナーの登録タイミングによって順序が異なることもありますが、DOMContentLoadedは必ずloadより先に発生します。
DOMContentLoadedとloadを使い分ける場面とパフォーマンスへの影響
どのような処理をどちらのイベントで行うかによって、ページの動作速度やユーザー体験に大きな違いが出ます。ここでは使い分けの判断基準、パフォーマンス上の注意点、そして実践的なベストプラクティスを紹介します。
DOM操作やUIの初期化はDOMContentLoadedが最適
ユーザがすぐに操作できるメニューやボタン、フォームなどのDOM要素を操作する処理は、DOMContentLoadedで実行すれば十分です。画像やスタイルシートがまだ読み込まれていなくてもDOM構造が整っていればアクセス可能ですので、遅さを感じさせずに初期化処理を開始できます。応答性の高いページ作りにおいては、このタイミングで不要な待ち時間を省くことが重要です。
画像の寸法取得やレイアウト依存処理はloadで行う
画像を使ったスライダーやキャンバス描写、背景画像処理など、リソースの完全な読み込みを待たなければ正確な寸法が取得できない処理はloadイベント後に行う必要があります。loadイベントはすべての依存リソースが揃っている状態を保証するため安全です。DOMContentLoadedではこれらを行うと未ロードの状態で誤った値を扱う可能性があります。
パフォーマンス最適化の観点からの考慮
DOMContentLoadedを待ちすぎる原因として同期スクリプトが影響することがあります。scriptタグをdeferあるいはtype=moduleにする、asyncを使うなどが有効です。CSSの読み込みやフォントがDOM操作に影響する場合はCSSやフォント読み込みのパフォーマンスを改善することも検討します。ページの初期表示を高速化するには、critical CSSをインライン化するなどのテクニックがあります。
DOMContentLoaded load 違い 順番に関するよくある疑問とその答え
実際に開発していると「DOMContentLoadedとloadの間にどれくらい差があるか」「どちらを使えばいいか」「なぜ思った順番で発火しないか」など疑問が湧くことがあります。ここでは代表的な質問に答えます。
DOMContentLoadedとloadの間にどれくらい時間差があるのか
時間差はページの構成によって大きく変化します。リソースの数やサイズ、ネットワーク速度、画像の容量や圧縮率などが影響します。極端な例では軽量なページなら数百ミリ秒で差が出ることがありますが、画像やフォントが多いページでは数秒から十数秒の差が生じることもあります。具体的には遅延読み込みされる画像や大きなスタイルシートなどがload発火を大きく遅らせる要因です。
DOMContentLoadedだけでは不十分なケースはどんなときか
DOM構造のみで完結できない処理を行う場合には不十分です。たとえば画像を読み込んでそのサイズに応じてレイアウトを変更する機能や、外部フォントが適用されるまで文字の幅を計算する処理、iframeや埋め込み広告の読み込み完了を待つ必要がある機能などです。そのような場合はloadイベントを使うことが望ましいです。
DOMContentLoadedとloadが発火しない・遅延する原因は何か
主な原因は次の通りです。大きな外部リソースの読み込み遅延、同期スクリプトの挿入位置、CSSやフォントの読み込み順序、並行読み込みの制限などです。またブラウザキャッシュの影響もあり、リソースがキャッシュされていればload発火が高速になります。加えてasyncスクリプトの順序未保証性や、ネットワーク環境の遅さが影響することがあります。
実践的なサンプルコードで比較する順番
理解を深めるために、実際にコード例を使ってDOMContentLoadedとloadの発火順を確認する方法と、期待される出力を示します。どのようにイベントを登録すればよいか、またその出力がどのようになるかを把握できます。
基本的なサンプルコード
以下のようなHTMLにスクリプトを入れてイベントを登録します。
document.addEventListener(‘DOMContentLoaded’, callbackDOMContentReady)
window.addEventListener(‘load’, callbackLoad)
画像要素に対してonloadハンドラを設定するなど。
この構造でページを実際に読み込むと、最初にDOMContentLoadedのコールバックが呼ばれ、次に画像などの外部リソースが揃ったあとにwindow loadのコールバックが呼ばれます。画像のonloadハンドラはloadの前に発火することがあるが、全体のwindow loadより先です。
scriptの位置を変えたときの影響
scriptタグを内に置くと、HTMLパース中に読み込みと実行が発生するためパースが一時停止しDOMContentLoadedが遅れます。
scriptを末尾に置いたり、deferを使うとHTMLパースがほぼ完了した段階でスクリプトが実行され、DOMContentLoaded発火が早くなります。asyncを使うと読み込み順序や実行タイミングが予測不能になるため注意が必要です。
readystate属性を使った代替アプローチ
document.readyStateプロパティは読み込みの状態を細かく把握できます。readyStateがinteractiveになった時点でDOM構築は完了しており、DOMContentLoadedとほぼ同義です。completeになったときがloadが発火する直前の状態です。これを使ってイベントを待つだけでなく、既にその状態にあるかをチェックして処理を実行することも可能です。
まとめ
DOMContentLoadedとloadの発火順は「まずHTMLパース→DOM構築」「その後リソース読み込み完了」という流れです。DOMContentLoadedはHTMLとDOMが準備できた段階で発火し、loadは画像・スタイル・iframeなど外部リソースがすべて読み込まれてから発火します。順番としては必ずDOMContentLoadedが先で、そのあとにloadが来ます。
ページの初期化やUI操作などDOMだけで完結する処理にはDOMContentLoadedを使うことでユーザへの応答性を高められます。反対に、画像サイズ取得や全リソースの読み込み完了が前提となる処理はloadを使うのが安全です。scriptの配置やdefer/asyncの使い方、CSSやフォントの読み込み順などパフォーマンスにも影響する要因を考慮することが重要です。
狙いどおりの順番でイベントが発火しないと感じた場合は、event リスナーの登録タイミングやスクリプトの属性、外部リソースの読み込み順序を見直してみてください。これらの理解と調整により、最適なユーザー体験とパフォーマンスのバランスを実現できます。
コメント