直接查看 navigation 和 resource 条目可定位80%加载瓶颈；主线程阻塞需用 performanceobserver 监听 longtask 等条目；拆解 navigation 阶段分析 dns、ttfb、dom 解析等耗时；resource 按 duration 排序识别慢资源；标记核心操作并上报 measure 数据。
直接看 performance.getEntriesByType('navigation') 和 performance.getEntriesByType('resource')，就能定位 80% 的加载瓶颈；但主线程阻塞和长任务更隐蔽，必须用 PerformanceObserver 主动监听，否则容易漏掉真实卡顿根源。
拆解 navigation 条目，看清首屏关键路径
页面加载慢，不能只看“白屏时间”，得拆成 DNS、TCP、SSL、TTFB、DOM 解析、样式计算等阶段——这些全在 navigation 条目里。
- 取
performance.getEntriesByType('navigation')[0]，别再用已废弃的performance.timing -
responseStart - navigationStart是 TTFB，超过 800ms 就该查后端或 CDN -
domContentLoadedEventEnd - responseEnd反映 DOM 解析 + 同步 JS 执行耗时，若 > 300ms，检查是否含未拆分的大型 inline 脚本 -
loadEventEnd - domContentLoadedEventEnd高，说明图片、iframe 等异步资源拖慢整体完成，需结合 resource 条目交叉验证
扫 resource 条目，揪出拖慢首屏的“慢资源”
很多性能问题不是代码写得差，而是某个第三方脚本或字体加载卡了 2 秒——它不报错，但会把 FCP 推后整整一拍。
- 按
duration倒序排列，一眼看出谁最慢；重点关注 name 指向 CDN 或第三方域名的条目 - 对比
connectStart和secureConnectionStart：差值 > 150ms，说明 TLS 握手慢，可能需开启 HTTP/2 或预连接 - 字体资源（name 含 .woff2）若
duration > 400ms，考虑加font-display: swap或<link rel="preload">
用 PerformanceObserver 监听长任务与核心指标
用户觉得“卡”，往往不是加载慢，而是主线程被某段 JS 锁死 120ms——这种问题控制台不报错，肉眼也看不出，只能靠监听。
- 必须用
PerformanceObserver，不能轮询getEntriesByType('longtask')，因为条目是异步写入的 - 注册时传
{ entryTypes: ['longtask', 'largest-contentful-paint', 'first-input'] }，一次拿到 LCP、FID、长任务三类数据 - 长任务
duration > 50ms就算风险项；连续多个 > 100ms，大概率是 React 渲染、复杂计算或未节流的 resize 监听器导致
标记关键业务逻辑，量化真实体验
光看全局指标不够，要对搜索、下单、渲染列表等核心操作做精准计时，才能关联业务与性能。
- 用
performance.mark('search-start')和performance.mark('search-end')标记起点终点 - 调
performance.measure('search-duration', 'search-start', 'search-end')生成可上报的测量项 - 在
window.onload后用navigator.sendBeacon()上报，避免影响渲染
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
