レンダリングブロックとパース阻害（defer/async/moduleの差）

なぜ script の指定で表示が止まったり止まらなかったりするのか

ブラウザのHTMLパーサは、トークンを先頭から順に消費してDOMを直列に組み立てます。問題は <script> に出会ったときの振る舞いで、ここに取得（フェッチ）のタイミングと実行のタイミングという2つの軸があり、async / defer / type=module はこの2軸をそれぞれ別の組み合わせに切り替える属性です。「パースを止めるか」は実行軸の問題で、取得が並列でも実行でパースが止まれば描画は遅れます。基礎の全体像は クリティカルレンダリングパスの最適化原理 を、取得前倒しの仕組みは ブラウザの投機的パース処理とリソース優先度 を参照してください。

なぜ無印 script がパースを止めるのか。理由はスクリプトが document.write で後続のトークン列を書き換えうるためです。書き換えの可能性がある以上、ブラウザはスクリプト実行を終えるまで先のDOMを確定できません。逆に言えば、document.write を使わないと約束できる属性（async / defer / module）ではこの直列化を外せます。

4つの読み込みモードの取得・実行・阻害

外部 script（src あり）の挙動は、属性の組み合わせで次の4モードに整理できます。インライン script（src なし）は別扱いで、async / defer は無効、type=module のみ遅延します。

ここで誤解しやすいのが無印 script の取得です。現代のブラウザはプリロードスキャナで src を先読みし、取得自体は並列に始めます。それでも無印が「ブロックする」と言われるのは、取得が終わるとその場で即実行し、実行が済むまでパースを再開しないからです。取得の並列化とパース阻害は別レイヤーの話です。

defer と async の本質的な違い：順序保証と実行点

async と defer はどちらも「パースを止めない」点で同じに見えますが、実行点と順序保証が正反対です。

• defer：取得は並列で先に進めつつ、実行はHTMLパースが完全に終わるまで待つ。複数の defer script は記述順に、DOMContentLoaded の発火直前にまとめて実行されます。パース非阻害と記述順の両立はこのモードだけの性質です。
• async：取得が終わり次第その場で実行するため、パース途中に割り込みます。順序は取得完了順で順不同、DOMContentLoaded を待たず、場合によってはそれより前にも後にも走ります。

<!-- 並列取得・記述順実行・パース後にまとめて実行。アプリの本体に最適 -->
<script src="framework.js" defer></script>
<script src="app.js" defer></script>   <!-- 必ず framework.js の後に実行される -->

<!-- 並列取得・取得完了順で即実行・他に依存しない計測系に最適 -->
<script src="analytics.js" async></script>

この差から実務の使い分けが決まります。互いに依存する、またはDOM構築の完了を前提とするスクリプトは defer。他のどのスクリプトともDOMとも独立した計測・広告タグは async。DOMContentLoaded を含む発火順序の全体像は イベントループの内部構造 と合わせて押さえると、初期化処理を置く位置が定まります。

type=module の振る舞い：既定が defer 相当である理由

<script type=module> は、属性を何も足さなくても既定で defer 相当です。すなわちパースを止めず、HTMLパース完了後・DOMContentLoaded 前に記述順で実行されます。インライン module（src なし）も同じく遅延する点が、インライン無印 script との大きな違いです。

なぜ defer 相当なのか。module は import で他のモジュールへ依存しうるため、ブラウザは実行前に依存グラフ全体を取得・解析する必要があります。エントリを取得し、import 文を静的解析して依存先を芋づる式に取得し、グラフが揃ってから評価する、という多段の手順を踏むため、そもそも「その場で即実行」が成り立ちません。さらに module には次の固有性質があります。

nomodule と後方互換、そして優先度

type=module を解さない古いブラウザに別ファイルを当てるための属性が nomodule です。module 対応ブラウザは nomodule 付き script を無視し、非対応ブラウザは type=module を不明な type として無視します。この排他で、新旧へ別バンドルを出し分けられます。

<!-- 新しいブラウザはこちらを実行（type=module を理解する） -->
<script type="module" src="app.modern.js"></script>
<!-- 古いブラウザはこちらを実行（nomodule を無視できない＝実行する） -->
<script nomodule src="app.legacy.js" defer></script>

リソース取得の内部優先度も属性で変わります。無印で早い位置の script は High、async / defer の script は描画を妨げないため Low に置かれるのが一般的です（Chromium 基準の概略）。つまり defer は「パースを止めず、かつ帯域を重要リソースに譲る」方向にも働きます。取得前倒しと優先度の関係は ブラウザのレンダリングの仕組み も参照してください。

実務での判断指針

• アプリ本体は defer か module：DOM完成を前提とし、相互依存があるコードは記述順が保証される defer、またはモジュールグラフを解決する module へ。
• 独立タグは async：他に依存しない計測・広告は async で最速取得・即実行に。
• head の無印 script を避ける：どうしても無印を使うなら body 末尾へ。head に置くと取得後の即実行でパースが直列に止まる。
• module の async は限定的に：既定の遅延・記述順を捨ててよい独立 module のみ。

まとめ