内联关键JS反而拖慢首屏，因其强制同步执行并阻塞HTML解析；仅内联≤1KB且不操作DOM、不触发layout的极简逻辑（如CSS变量初始化），其余须defer/async或动态导入。
关键JS内联后为何首屏反而更慢
内联 <script> 看似省了网络请求，但实际常导致解析阻塞加剧。浏览器遇到内联脚本会立即暂停 HTML 解析、执行 JS，若该脚本又触发同步 DOM 操作或计算密集逻辑，首屏渲染（FP/FCP）会被拖长。
常见错误现象：DOMContentLoaded 延迟、document.body 为 null、Lighthouse 报 “Reduce JavaScript execution time”。
- 仅内联真正影响首屏渲染的极小逻辑（如主题切换 class 注入、CSS 变量初始化），代码量建议 ≤ 1KB
- 避免在内联脚本中调用
document.querySelector或修改style属性——这些操作需完整 DOM 树就绪 - 若必须操作 DOM，用
document.currentScript?.parentNode定位插入点，或包裹在requestIdleCallback中延后执行
哪些 JS 必须解耦且延迟加载
所有不参与首屏渲染、不决定页面基础状态的逻辑都应解耦。典型包括：埋点 SDK、非首屏组件（如评论区、侧边推荐）、表单校验库、图片懒加载逻辑。
使用场景差异直接决定加载策略：defer 适合依赖 DOM 结构但无需立即执行的模块；async 适合完全独立（如统计脚本）；动态 import() 适合路由级拆分。
立即学习“前端免费学习笔记（深入）”；
-
<script defer src="analytics.js"></script>：确保执行顺序，且不阻塞解析 -
<script async src="chat-widget.js"></script>：加载完立刻执行，不保证顺序，适合无依赖脚本 - 路由组件用
import('./page-about.js')动态导入，配合loading状态提示，避免白屏
内联与外部 JS 的性能边界怎么划
边界不是按文件大小，而是按「执行时机」和「副作用范围」。一个 300B 的内联脚本若调用 fetch 并 await 渲染数据，它就是关键路径外的“伪关键”代码，应移出内联。
判断依据有三：
① 是否在 document.readyState === 'interactive' 前就必须完成？
② 是否修改了影响 CSSOM 构建的 <style> 或 link[rel=stylesheet]？
③ 是否触发了 layout/reflow（如读取 offsetHeight）？
- 满足任一条件 → 保留在内联，但必须精简到只做必要事
- 全不满足 → 一律解耦，哪怕只有 2 行代码
- Chrome DevTools 的
Performance面板里看Parse HTML和Function Call时间占比，超过 50ms 的内联脚本值得重构
HTTP/2 下内联是否还值得
HTTP/2 多路复用降低了多请求开销，但内联并未因此“变安全”。关键问题不在网络，而在执行时序 —— 浏览器仍要同步解析并运行内联代码，无法与 HTML 解析并发。
真实瓶颈常出现在低端设备上：JS 引擎解析内联脚本的 CPU 时间远高于 HTTP/2 下 fetch 一个已缓存的 .js 文件。
- 对比测试方法：用 Chrome 的
Network面板禁用缓存，记录script请求的TTFB + Content Downloadvs 内联脚本的Script Evaluation时间 - 若后者 > 8ms（中端安卓机典型阈值），优先解耦 +
defer - Service Worker 缓存下，外部 JS 几乎零网络耗时，此时内联纯属增加 HTML 主文档体积，不利于 gzip 压缩率
localStorage.getItem 触发同步磁盘读取而卡住解析——这种“关键”其实是假关键。真正该抠的是执行链路中那几个不可跳过的同步节点。 
