ブラウザの深淵を覗く：async/deferがレンダリングパイプラインにもたらす「静かなる革命」
Webブラウザという巨大なブラックボックスの中で、HTMLがパースされ、DOMが構築され、スタイルが計算され、最終的にピクセルが塗りつぶされる。このレンダリングパイプラインを俯瞰したとき、最も厄介な「異物」となるのが `
アーキテクトの視点：メモリとロードパフォーマンス
`defer` はDOM構築の負荷を軽減するが、「スクリプト実行開始のタイミング」がDOM構築の終了後であるという点に注意が必要だ。もし、スクリプトの実行をトリガーにして特定のDOM要素を操作しようとしているなら、`DOMContentLoaded` イベントを待つ必要がなくなるため、コードがスリムになる。
逆に、`async` を使用して「ファーストビューに影響を与えない重要度の低い処理」を裏で回す際は、`preload` リソースヒントを組み合わせることで、ブラウザのキャッシュ層を最適化し、スクリプト実行時のメモリ確保を先回りさせることが可能だ。
4. 最適化のベストプラクティス：現実的な解
現場で堅牢なアプリケーションを構築する際、私なら以下のような戦略を推奨する。
1. コアライブラリは `defer` に統一: 依存関係を静的に解決し、パース完了まで実行を遅延させることで、メインスレッドの競合を最小化する。
2. サードパーティは `async` ＋ `preconnect`: 広告や解析ツールは、レンダリングフローから完全に切り離す。
3. モジュール（ES Modules）は標準で `defer`: `
コメント