defer能稳定加快首屏渲染，因其下载与HTML解析并行且执行推迟至DOM构建完毕，确保首屏内容尽早渲染；async则可能因下载完成即执行而中断解析，导致首屏变慢或出错。
defer 和 async 都能显著提升首屏渲染速度，但效果和风险完全不同：defer 几乎总是安全提速，async 在用错时反而可能让首屏更慢甚至出错。
为什么 defer 能稳定加快首屏渲染
defer 让脚本下载与 HTML 解析完全并行，且执行被推迟到 DOM 构建完毕后——这意味着浏览器不会因等待脚本而中断构建可视内容树。首屏元素（比如 <h1>、<img>、文本段落）能尽早完成解析、样式计算和绘制。
- 多个
<script defer src="a.js">和<script defer src="b.js">会按顺序执行，适合有依赖的初始化逻辑（如先加载utils.js，再执行app.js） - 即使某个 defer 脚本下载慢，HTML 解析仍不受影响；只是
DOMContentLoaded事件会被拖住——这对首屏渲染无害，用户已能看到内容 - 内联脚本加
defer无效，只对外链脚本起作用；放在<head>或<body>开头都 OK
async 在什么情况下会让首屏变慢
async 虽然也异步下载，但“下载完立即执行”这一行为可能打断 HTML 解析——尤其当脚本体积小、网络快、又恰好在首屏关键节点前下载完成时，它会强制暂停解析，执行完才能继续。此时，首屏中还没解析到的 DOM 元素（比如轮播图容器）就无法及时渲染。
- 常见错误现象：
document.getElementById("hero-banner")在 async 脚本里返回null，不是因为 DOM 没生成，而是脚本执行时该元素还没被解析到 - 多个 async 脚本执行顺序不可控，若
analytics.js比polyfill.js下得快，前者可能先执行，后者却没来得及补全 API —— 这类问题在线上环境难复现、难调试 - async 不兼容 IE9 及以下；现代项目虽少支持，但若需兼容旧企业内网环境，必须确认
怎么选：看脚本是否操作 DOM 或依赖其他脚本
判断依据非常直接：脚本里有没有 document.querySelector、addEventListener、initSlider() 这类调用？有没有 require('lodash') 或显式依赖前一个脚本导出的变量？
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 有 → 必须用
defer，哪怕只有一个脚本 - 完全没有 DOM 操作、不引用全局变量、也不被其他 JS 调用 → 才考虑
async，典型如gtag.js、taboola.js - 混合场景（比如主逻辑用 defer，统计用 async）：可以共存，但
async脚本不能放在defer脚本之后还指望它“晚执行”——async 的执行时机完全由下载速度决定
容易被忽略的细节：type="module" 默认就是 defer
如果你用 <script type="module" src="main.mjs">，浏览器会自动按 defer 行为处理：异步下载、DOM 解析完再执行、保持顺序。不需要额外加 defer 属性，加了也无效。
- module 脚本天然支持顶层
await，适合做资源预加载或条件加载，比传统 defer 更灵活 - 但 module 不支持 IE，且所有导入路径必须是绝对 URL 或以
/、./、../开头；相对路径如"utils"会报错 - 如果用了 module，就别混用
defer的传统脚本——模块之间依赖清晰，传统脚本加 defer 反而可能打破执行时序
真正影响首屏的从来不是“用了 defer 还是 async”，而是“脚本是否在不该执行的时候执行了”。async 看似激进，实则脆弱；defer 看似保守，实则可靠。多数业务脚本，其实只需要 defer 就够了。
