同步脚本会中断html解析，强制暂停dom构建，导致首屏白屏；其下载、解析、执行全程阻塞渲染，即使仅含console.log也会显著延长白屏时间。
同步脚本为什么卡住首屏渲染
同步脚本（即没有 async 或 defer 的 <script src="xxx"></script>）会直接中断 HTML 解析，浏览器必须暂停构建 DOM，等脚本下载、解析、执行完才能继续。哪怕它只有一行 console.log，只要在 里，就可能让白屏时间延长几百毫秒。
常见错误现象包括：DOMContentLoaded 触发早但页面长时间空白、Performance 面板中 Parse HTML 阶段出现长 Gap、Network 面板里某个 script 的 Initiator 显示为 parser。
- 放在
的同步脚本，DOM 构建完全停滞，用户看到白屏 - 放在
前的同步脚本虽不阻塞 DOM 构建，但仍阻塞DOMContentLoaded和后续渲染树生成 - 若脚本内含
document.write()或同步 API（如XMLHttpRequest），会进一步放大延迟
defer 和 async 的实际执行边界在哪
defer 脚本按顺序执行，且只在 HTML 解析完成后、DOMContentLoaded 前运行；async 脚本下载时不阻塞解析，但一旦就绪立即执行，顺序不可控——这两个行为差异直接影响 DOM 可用性与依赖链稳定性。
使用场景决定选哪个：init.js 依赖 DOM 元素，必须用 defer；tracker.js 独立上报，无 DOM 操作，适合 async。
-
defer不保证执行时机早于DOMContentLoaded，但能确保 DOM 已就绪 -
async可能在 DOM 还没解析完时就执行，调用document.getElementById很可能返回null - 多个
async脚本之间无加载顺序保障，不能靠它们之间的依赖关系组织逻辑
type="module" 是不是万能替代方案
type="module" 默认具备 defer 行为，且支持顶层 await、静态导入分析、自动去重，但它不是“开箱即用”的平替：模块脚本仍需完整下载+解析+执行后才触发 DOMContentLoaded，且不兼容 IE 和旧版 Safari。
真正关键的是它改变了资源调度粒度——模块可被浏览器更早识别为“非阻塞”，配合 import 动态拆分，能有效缩短单个任务时长。
- 模块脚本不会被
document.write()中断，但会因import链式加载而产生隐式依赖延迟 - 若主模块里写
import('./heavy.js')，这个动态导入仍会阻塞其所在模块的执行完成 - 服务端需正确设置
Content-Type: text/javascript，否则部分浏览器拒绝执行
如何验证你的脚本是否还在阻塞关键路径
别只看 DOMContentLoaded 时间戳——它只代表 DOM 就绪，不代表页面可交互或已绘制。真正要盯的是 Performance 面板里的 First Paint 和 First Contentful Paint 是否被脚本执行拖慢。
实操建议：打开 Chrome DevTools → Performance → 点击录制 → 刷新页面 → 查看 Parse HTML 后是否紧跟着长时间的 Function Call 或 Evaluate Script；再切到 Network 面板，筛选 Initiator = parser 的请求，这些就是当前仍在阻塞渲染的同步资源。
- 如果某
.js文件在 Network 面板中Initiator列显示为parser，说明它正以同步方式加载 - 即使加了
defer，若脚本内部含大量计算或长循环，仍会阻塞主线程，影响First Input Delay - 第三方 SDK（如广告、统计）常默认提供同步加载方式，务必检查其文档，优先选用
async或动态注入版本
最易被忽略的点是：脚本是否真的“必要”。很多项目把所有 JS 都塞进首屏，却没区分哪些是渲染必需、哪些只是增强体验。优化不是换属性，而是先砍掉不该出现在关键路径上的东西。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
