async是唯一安全选项，因像素脚本无需DOM依赖且须尽早发请求而不阻塞HTML解析；必须用外部脚本、置于body开头、配合preconnect，并禁用document.write。
第三方像素追踪脚本（如 analytics.js、umami.js、plausible.js）本身不操作 DOM，但若加载方式错误，会直接卡住首屏渲染——不是“慢”，是解析停摆。必须用 async，且仅限外部脚本；加了也白加的内联写法、放错位置、缺预连接，都会让优化失效。
为什么async是唯一安全选项
像素类脚本只上报数据，不依赖 document.body，也不需要等其他 JS 执行完毕。这类脚本的核心诉求是：越早发请求越好，但绝不能打断 HTML 解析。
-
defer会排队等到 DOM 构建完才执行，对纯埋点毫无意义，反而延迟上报时机 -
async下载不阻塞，执行不保序，但像素脚本本来就不依赖顺序 -
async对内联脚本无效——所以<script>fetch('/pixel.gif')</script>加了async也没用，必须拆成带src的外部引用 - 如果脚本返回 404 或超时，浏览器仍会等待默认 timeout（通常 10–30s），页面持续白屏；必须配合
onerrorfallback 或降级逻辑
<script async> 必须放在 <body> 开头，而非 <head>
很多人把 async 脚本塞进 <head> 就以为万事大吉，其实位置错了照样拖慢首屏。浏览器虽不阻塞解析，但主线程仍要处理下载完成后的立即执行——若此时正忙于 Layout/Paint，就会挤占帧时间。
- 把
<script async src="https://cdn.umami.dev/script.js"></script>移到<body>第一行，紧贴<div id="app">或首屏容器之后 - 避免和关键 CSS、字体、首屏 JS 同一时刻竞争主线程资源
- 不要用
setTimeout(() => load(), 0)动态插入——它只是推到下一个宏任务，仍可能卡在 paint 前
必须搭配 preconnect，否则网络握手耗时抵消所有优化
光加 async 不够。像素脚本域名（如 https://analytics.example.com）若未预连，首次 DNS 查询 + TCP 握手 + TLS 协商动辄 300–800ms，期间主线程空转——你写的优化全白做。
立即学习“前端免费学习笔记（深入）”；
- 在
<head>顶部加：<link rel="preconnect" href="https://analytics.example.com"> - 如果脚本带 query 参数（如
?id=abc123），预连目标必须是 origin（不含 path 和 query） - 不要对同一域名重复
preconnect，浏览器会去重，但冗余标签增加 HTML 体积 - 慎用
preload：像素脚本不需要提前 fetch 内容，preconnect已足够
真正安全的底线：禁用 document.write 并隔离执行上下文
部分老版追踪脚本仍含 document.write，一旦在 DOM 构建中途执行，会清空当前文档并重开 parser，导致整个页面重建——这是比阻塞更严重的灾难。
- 检查脚本源码或 Network 面板响应体，确认无
document.write调用；如有，必须联系服务商升级或换 SDK - 若无法规避，可用
iframe sandbox="allow-scripts"包裹整个像素加载逻辑，将其执行环境完全隔离 - CSP 中明确限制：
script-src 'self' https://cdn.umami.dev;，禁止'unsafe-inline'和'unsafe-eval' - 绝对不要用
innerHTML = '<script src="..."></script>'注入——这会绕过async属性，退化为同步加载
最易被忽略的点：像素脚本不是“不重要”就可以随便放。它的加载路径一旦进入主线程争抢队列，哪怕只多占 20ms，就可能让一个 60fps 的渲染帧掉成 30fps——用户感知到的就是卡顿，而不是“某个统计没报上”。
