JavaScriptの実行タイミング制御：DOM、CSSOM、そしてメインスレッドの攻防戦
フロントエンドのパフォーマンスチューニングにおいて、最も根が深く、かつ多くのエンジニアが感覚的なハックで済ませてしまいがちな領域がある。それが「JavaScriptの読み込みと実行タイミングの制御」だ。
BlinkやWebKitといった現代のブラウザエンジンが、HTMLというただのテキストストリームをどのようにパースし、メモリ上にDOMツリーを構築し、レンダリングパイプラインを回しているか。その裏側を覗いたことがあるだろうか？
今回は、`async`、`defer`、そして現代WebのデファクトスタンダードであるES Modules (`type=”module”`) が、ブラウザのメインスレッド上でどのような挙動を示し、メモリ効率やレンダリング負荷にどう影響を与えるのかを、アーキテクチャの深層から紐解いていこう。
—
1. レンダリングパイプラインの基本：なぜ通常の `` は悪なのか？
ブラウザがHTMLを読み込む際、それは上から下へ流れる単なるバイト列のストリームに過ぎない。レンダリングエンジンのパーサー（HTML Parser）は、このストリームをトークン化し、ノードへと変換してDOMツリーを構築していく。
ここで、歴史的な「諸悪の根源」とも言える素の `
パーサーはこのタグに遭遇した瞬間、容赦なく自身の足を止める。HTMLのパースは一時停止（Parser Blocking）し、メインスレッドはネットワーク層へスクリプトのフェッチを要求。さらに、そのスクリプトのダウンロード完了を待ち、JavaScriptエンジン（V8など）に処理を委譲してスクリプトの実行が完全に終わるまで、次のHTMLパースを再開しない。
なぜここまで厳格なのか？理由はシンプルで、JavaScriptはいつでも `document.write()` やDOMの直接的な破壊・改変を行う可能性があるからだ。パーサーは、DOMの整合性を担保するために「安全第一」でシングルスレッドの鍵を固く閉ざす。
しかし、これが数百キロバイトもあるサードパーティ製スクリプトだった場合どうなるか。ユーザーの画面には何も描画されない白画面（Blank Screen）の時間が無慈悲に引き延ばされ、Core Web Vitalsの指標である LCP (Largest Contentful Paint) や TBT (Total Blocking Time) は一巻の終わりを迎える。
---
2. 非同期の世界：`async` と `defer` の決定的なアーキテクチャの違い
このメインスレッドのブロッキング地獄から私たちを救うために用意されたのが、`async` と `defer` 属性だ。だが、この2つの違いを「非同期で読み込むんでしょ？」と曖昧に理解しているなら、今すぐその認識をアップデートしてほしい。両者は「いつ実行されるか」のライフサイクルが全く異なる。
`async`：我先にと動き、協調性を一切持たない暴れ馬
- ダウンロード: HTMLパースと並行して非同期で行われる（ノンブロッキング）。
- 実行: ダウンロードが完了した瞬間、HTMLパースを強制中断（ブロック）して即座に実行される。
`async` は、他のスクリプトとの依存関係が一切ない「完全に独立したスクリプト」（アクセス解析や広告タグなど）のために存在する。
しかし、勘の良いエンジニアならお気づきだろう。この挙動は、どのタイミングでスクリプトが実行されるかがネットワークの速度に依存することを意味する。もしDOM構築の途中でファイルサイズ小さな `async` スクリプトのダウンロードが終われば、容赦なくパースが中断され、まだ生成されていないDOM要素にアクセスしてTypeErrorを吐くリスクすらある。
`defer`：DOMの秩序を守る紳士的な遅延実行
- ダウンロード: HTMLパースと並行して非同期で行われる（ノンブロッキング）。
- 実行: HTMLのパースが完全に完了し、DOMツリーの構築が終わった後、かつ `DOMContentLoaded` イベントが発火する直前に、記述された順番通りに実行される。
実務におけるほとんどのアプリケーションコード（メインのバンドルファイルなど）は、この `defer` を使うべきだ。DOMの構築を一切邪魔せず、かつスクリプトの実行順序（Order of Execution）がソースコードの記述順に保証されるため、依存関係のバグを踏む確率が劇的に下がる。
---
3. 現代の主役：`type="module"` とその暗黙の `defer` 特性
現代のフロントエンド開発において、WebpackやViteなどのバンドラを通すにせよ、ネイティブES Modulesを使うにせよ、避けて通れないのがこの構文だ。
ここで重要なアーキテクチャ上の事実を述べておこう。`
`legacy-lib.js` が通常の同期スクリプト（または `async`）である場合、`type="module"` は暗黙の `defer` として振る舞うため、常にレガシーライブラリの実行後にモジュールが動くという保証は…実は環境や読み込み方によっては危うい瞬間がある。特に、モジュールスクリプトはデフォルトで CORS（Cross-Origin Resource Sharing）の制限を受ける ため、ローカル環境（`file://` プロトコルなど）でそのまま開くとCORSエラーで死ぬという、誰もが一度は通る罠がある。
堅牢なアプリケーション設計のためのプラクティス
上級エンジニアとして、私たちはこれらの非同期競合をコントロール下に置かなければならない。
1. アプリケーションのエントリポイントはすべて `type="module"`（または `defer`）に統一する
混在させないことが最大の防御だ。レガシーなサードパーティライブラリを除き、自社製コードはすべてモジュールとして扱い、実行順序の予測不可能性を排除する。
2. 動的インポート (`import()`) による遅延ロードの活用
初期表示（Critical Path）に関係のない機能（モーダル、重いチャートライブラリ、管理画面のロジックなど）は、最初から読み込ませず、ユーザーのアクションやビューの切り替えに応じて動的にロードする。
// 実務で使える：インタラクション発生時にのみモジュールを非同期ロードする例
const loadDashboardModule = async () => {
try {
// メインスレッドをブロックしないようにユーザーの操作やアイドル時間を狙う
const { initDashboard } = await import('./features/dashboard.js');
initDashboard();
} catch (error) {
console.error('モジュールのロードに失敗しました:', error);
// フォールバック処理やリトライ機構をここに記述
}
};
document.querySelector('#open-dashboard-btn').addEventListener('click', loadDashboardModule);
このアプローチを取ることで、初期HTMLパース時のメモリプレッシャーを最小限に抑え、必要な瞬間までリソースの消費を遅らせることができる。
---
5. まとめ：ブラウザの挙動をハックではなく「科学」として捉える
Webブラウザは、私たちが想像するよりもは遥かに高度な最適化と並行処理の塊だ。
HTMLパース、DOM構築、CSSOM、そしてJavaScriptの実行タイミング。これらは独立して動いているのではなく、ひとつの巨大なメインスレッドの上で絶妙なバランスで調停されている。
- 依存関係のない外部ツール: `async`
- 通常のアプリケーションロジック: `defer`
- モダンな依存関係管理・再利用性: `type="module"`（実質的 `defer` + モジュールグラフ）
- 初期表示の最適化: 動的 `import()` による遅延ロード
それぞれの属性が、ブラウザのレンダリングパイプラインのどの歯車を動かし、どの段階でメインスレッドを占有するのか。その解剖学的な理解を持つことこそが、プロダクトのパフォーマンスを極限まで引き上げ、ユーザーに最高の体験を提供するプロフェッショナルの条件だ。
さあ、明日のコードレビューでは、無造作に置かれた `
コメント