优化脚本执行顺序需借助Performance API分析五个归因节点耗时，定位网络、解析或执行瓶颈，并结合FCP/LCP、TTI影响评估阻塞，按场景选用module defer、import()或第三方延迟策略，最终验证性能指标改善。
优化脚本执行顺序不是靠“谁先写谁先跑”，而是通过 Performance API 看清每段脚本在真实加载链路中的位置、耗时归属和阻塞影响，再针对性调整。
定位关键脚本的完整生命周期耗时
动态注入脚本（如 document.createElement("script") 或 import()）的性能瓶颈常藏在“看不见”的阶段。仅看 load 事件远远不够，必须拆解为五个可归因节点：
-
注入前：调用
performance.mark('script-inject-start')，记录 JS 主动发起 DOM 操作的时刻 -
插入后：在
insertBefore或appendChild执行完立即打标'script-inserted' -
加载完成：监听
script.onload或import().then，打标'script-loaded' -
执行开始：若可控，脚本首行加
performance.mark('script-exec-start')；否则用setTimeout(0)或PerformanceObserver捕获首个长任务起点 -
执行结束：脚本末尾或模块导出前打标
'script-exec-end'
之后用 performance.measure() 计算各段，例如：performance.measure('inject-to-insert', 'script-inject-start', 'script-inserted')performance.measure('load-to-exec', 'script-loaded', 'script-exec-start')
这样就能明确是网络慢、解析卡、还是执行拖——不同问题对应不同优化策略。
识别谁在阻塞渲染与交互
脚本执行顺序是否合理，最终要看它对用户感知的影响。重点关注两个维度：
-
是否卡住 FCP/LCP：用
PerformanceObserver监听'paint'和'largest-contentful-paint'，拿到 LCP 时间后，反查performance.getEntriesByType('resource')中对应脚本的startTime和duration。如果脚本responseEnd晚于 LCP 时间点，说明它拖慢了首屏可见性 -
是否拉长 TTI：检查
performance.getEntriesByType('navigation')[0]的domContentLoadedEventEnd和loadEventEnd，再结合主线程长任务（longtask类型条目）。若某段脚本执行耗时 >50ms 且出现在 DOM 构建后、用户可点击前，就是典型的交互阻塞者
按场景选择注入策略并验证效果
同一逻辑，不同注入方式带来的执行时机差异巨大，不能一概而论：
-
首屏强依赖脚本：改用
<script type="module" defer>，天然延迟到 DOM 解析后、DOMContentLoaded前执行，且支持构建期 tree-shaking -
非首屏功能（如客服、分享）：必须改为
import()动态导入，并配合loading="lazy"或路由守卫触发，避免提前下载和执行 -
第三方 SDK：无法修改内部代码时，用
PerformanceObserver监听resource类型，过滤 URL 关键词（如includes('analytics')），统计其duration和是否触发长任务，再决定是否延迟加载或降级
优化后务必验证三个信号：
– FCP/LCP 时间是否提前
– domContentLoadedEventStart 到 domContentLoadedEventEnd 间隙是否缩短
– 主线程中 >50ms 的黄色块（Scripting）是否减少或拆分
