performance api 是定位资源加载卡点的手术刀，能识别阻塞渲染的脚本或css、发现动态插入资源、指导预加载干预，并通过fcp、domcontentloaded差值等验证优化效果。
Performance API 不是“看时间的工具”，而是定位资源加载卡点的手术刀。它能告诉你哪个资源在关键路径上悄悄拖慢了首屏，而不是只显示“这个 JS 加载用了 800ms”。优化加载顺序，核心在于识别阻塞、干预时机、验证效果。
看清谁在真正阻塞渲染
别只盯着 Network 面板的瀑布图——它反映的是网络请求顺序，不是浏览器实际执行顺序。真正卡住页面的，常是一个小脚本或一段内联 CSS。
- 用
performance.getEntriesByType('resource')筛出所有资源，按startTime排序，重点关注initiatorType === 'script'或'link'的条目 - 检查
responseEnd到domContentLoadedEventStart之间的空档：如果超过 100ms，说明是 JS 执行或 CSSOM 构建耗时，不是网络慢 - 特别留意
<script></script>标签没加async或defer的情况——它会同步阻塞 HTML 解析，哪怕只有几 KB
识别隐形阻塞者
很多拖慢首屏的资源根本不在 HTML 源码里，它们动态插入、跨域加载，或藏在内联样式中。
- 动态创建的脚本（如
document.createElement('script').src = '...'）在 Performance API 中initiatorType是'other'，需结合 URL 关键词（如includes('analytics')）手动识别 - 跨域 CSS（如 CDN 上的
<link rel="stylesheet">）若未配置Timing-Allow-Origin响应头，DNS 和连接字段会缺失（domainLookupStart === 0），此时数据不可信，不能判断真快还是假快 - 过大的内联
<style></style>会拉长 HTML 解析时间，尤其含大量@import或复杂选择器时，它不发请求，但一样卡主线程
用预加载和预连接主动干预
等浏览器自己发现资源太晚。要提前告诉它：这些资源马上要用，现在就去拿。
- 对核心业务域名（如
api.example.com）加<link rel="preconnect" href="https://api.example.com">，提前完成 DNS、TCP、TLS 连接 - 对立即执行的关键 JS 或 CSS，用
<link rel="preload" as="script" href="checkout.js">，确保下载优先级高、不被延迟 - 对非首屏但强相关的资源（如支付 SDK），用
<link rel="prefetch">，利用空闲带宽提前获取，不抢首屏资源带宽
验证优化是否真的起效
改完代码后，别只看“总加载时间降了”，要盯住三个具体信号：
-
FCP（首次内容绘制）是否提前：用
performance.getEntriesByType('navigation')[0].firstContentfulPaint对比优化前后 -
DOMContentLoad 是否不再被某段 JS 拖累：检查
domContentLoadedEventStart - responseEnd的差值是否显著缩小 -
关键资源是否出现在更靠前的时间窗口：比如 checkout.js 的
startTime是否从 DOM 解析中途，提前到了 HTML 解析刚启动阶段
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
