Performance API 能精准定位隐形阻塞者，关键在于识别谁“卡住后续”而非下载慢；同步脚本和样式表会阻塞渲染，async/defer可优化执行时机，FCP、DOMContentLoad时间及资源启动集中度是核心验证指标。
Performance API 能直接暴露资源加载过程中的阻塞关系，关键不是看谁下载慢，而是看谁“卡住后续”。真正影响首屏的，往往是某个小脚本或样式表在关键路径上拦住了整个渲染流程。
识别阻塞渲染的关键资源类型
浏览器对不同资源的处理逻辑差异很大，需结合 initiatorType 和加载行为判断是否构成阻塞：
-
同步脚本（
<script></script>无属性）：暂停 HTML 解析，必须等下载、解析、执行完成才继续；它前面哪怕只多一个空格，也可能拖慢 FCP -
CSS 样式表（
<link rel="stylesheet">）：不阻塞 HTML 解析，但会阻塞后续所有脚本执行，且强制延迟首次内容绘制（FCP） -
带
async的脚本：下载时不阻塞，但执行时机不可控，可能打断 DOM 构建或样式计算 -
带
defer的脚本：最安全，执行推迟到 DOM 解析完成后、DOMContentLoaded前，不会干扰关键路径
用 performance.getEntriesByType('resource') 定位隐形阻塞者
Network 面板只显示网络请求顺序，而 Performance API 可还原真实执行时序。重点关注以下字段组合：
- 过滤出
initiatorType === 'script'或initiatorType === 'link'的条目，按startTime排序，观察谁紧挨在domContentLoadedEventStart之前 - 检查
responseEnd到domContentLoadedEventStart的间隔：若超过 200ms，说明是 JS 执行或 CSSOM 构建耗时，而非网络慢 - 动态插入的资源（如
document.createElement('script').src = '...'）initiatorType为other，需通过 URL 关键词（如analytics、track）人工识别 - 跨域 CSS 若缺失
Timing-Allow-Origin响应头，domainLookupStart会恒为 0，此时不能判断是真快还是数据丢失
结合 Navigation Timing 验证阻塞影响
单看资源不够，要确认它是否真的拖慢了关键节点：
- 调用
performance.getEntriesByType('navigation')[0]，提取domContentLoadedEventStart和responseEnd - 若
domContentLoadedEventStart - responseEnd > 300ms，说明 DOM 解析后仍有大量同步 JS 执行或 CSSOM 构建未完成 - 对比
fetchStart与requestStart：差值大表示重定向或缓存查找耗时，也属于间接阻塞 - 特别关注
type === 'navigate'的导航记录，排除back_forward缓存场景（此时responseStart可能为 0）
捕获运行时阻塞：用 PerformanceObserver 监听长任务
有些阻塞不体现在资源加载时间里，而是主线程被 JS 锁死：
- 注册
PerformanceObserver，监听longtask类型，duration > 50ms即视为风险 - 连续多个 >100ms 的长任务，大概率来自未优化的 React 渲染、复杂计算或未节流的
resize监听器 - Chrome 中启用
--enable-blink-features=InteractiveRenderBlocking可捕获部分渲染阻塞任务（仅开发环境） - 避免轮询
getEntriesByType('longtask')，必须用 Observer，否则会漏掉异步写入的任务条目
