首屏白屏更久的根源是同步脚本在<head>中提前执行，阻塞DOM构建；async仅避免下载阻塞，defer则保序且不卡首屏，但均不解决内联脚本或模块混用导致的执行时机问题。
为什么<script>放<head>里会让首屏白屏更久</script>
不是“位置导致阻塞”，而是同步脚本在 <head> 里让 JS 执行时机提前到了 DOM 构建最开始阶段。浏览器一遇到没加 async 或 defer 的 <script>，立刻暂停 HTML 解析器，把控制权交给 JS 引擎——此时 <body> 里哪怕只写了 <h1>Hello</h1>，它也进不了 DOM 树，更不会参与样式计算或绘制。
常见错误现象：
-
<head>里连写三个无属性外链脚本，首屏白屏时间直接叠加为三者下载 + 执行总和 - 内联初始化代码写在
<head>，却试图document.getElementById("app")，必然返回null - Chrome DevTools → Network 面板中，“HTML” 资源加载时间异常长，且后面跟着多个脚本请求被串行阻塞
async 和 defer 的真实执行时机差异
async 只解决下载不阻塞，执行仍会中断 DOM 解析；defer 则推迟到 DOM 解析完毕后、DOMContentLoaded 前按序执行——这是结构层唯一能“保序且不卡首屏”的方案。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
async脚本必须完全独立：不读写 DOM、不依赖其他 JS（如统计 SDK），否则容易因执行过早或顺序错乱报ReferenceError -
defer是主业务逻辑首选，但注意它仍会阻塞DOMContentLoaded触发——只要脚本没执行完，这个事件就不发 -
async和defer对内联脚本（无src）无效，浏览器直接忽略 - IE9– 完全不支持
defer，降级为同步加载；若需兼容，得用动态插入或条件注释兜底
template.content 克隆如何避开 JS 线程对 DOM 构建的干扰
<template> 的内容不参与 HTML 解析流程，也不触发 JS 执行、资源加载或样式计算。它只是内存中一个惰性的 DocumentFragment。当你用 document.importNode(template.content, true) 克隆插入时，浏览器跳过了从字符串解析 HTML 的全部开销——这部分原本要跑在主线程上，和 JS 执行争时间片。
关键区别：
- 每次动态拼接 HTML 字符串再赋给
innerHTML：都要重新解析、构建节点、触发重排预备，JS 执行期间无法做这事 - 克隆
template.content：只做内存复制，不触发布局/样式计算，JS 执行完立刻可插入 -
template.content是DocumentFragment，不能直接querySelector，得先挂载或用遍历 - 模板里
<script>和<style>会被忽略，事件监听必须手动绑定
type="module" 脚本与 defer 混用的风险
type="module" 脚本默认行为类似 defer（即使没写），但它有更严格的依赖约束：模块图内所有依赖必须解析完成才执行，支持顶层 await，且自动启用严格模式。
容易踩的坑：
- 混用
<script defer src="a.js"></script>和<script type="module" src="b.mjs"></script>：执行顺序不可控，模块可能等不到 defer 脚本里的全局变量 -
document.write()在任何模块脚本里都会直接报错，必须移除 - 服务器返回 404 的模块脚本，会中断整个模块图加载，而普通
defer脚本只会触发error事件且不中断后续
真正决定是否阻塞的，不是“异步”这个词，而是脚本何时执行、是否依赖上下文、以及浏览器是否允许它插队。很多看似“已加 defer”的页面仍卡顿，问题往往出在脚本内部调用了同步 API（比如 getComputedStyle 时 CSS 尚未生效），或没意识到 defer 本身仍会延迟 DOMContentLoaded。
