核心思路是用Performance API精准定位阻塞源并优化：通过longtask捕获长任务、LCP资源依赖分析、第三方脚本干扰识别及User Timing打点，实现“该画的先画，该跑的后跑”。
核心思路是：用 Performance API 找出谁在阻塞，再针对性拆解或推迟——不是盲目压缩代码，而是让浏览器“该画的先画，该跑的后跑”。
定位阻塞主线程的长任务
主线程被 JS 长时间占用，是首屏卡顿、FCP/LCP 延迟的主因。Performance API 提供了直接观测手段：
- 启用
performance.getEntriesByType('longtask')，捕获执行超 50ms 的任务（现代浏览器支持） - 配合
PerformanceObserver监听longtask类型，实时上报耗时、起始位置和调用栈（需提前调用performance.setResourceTimingBufferSize(1000)） - 重点排查：初始化阶段的大对象解析、同步 DOM 操作、未拆分的第三方 SDK 初始化（如统计、客服）、复杂计算逻辑
识别拖慢 LCP 的资源依赖
LCP 元素（如主图、标题区块）若被上游资源卡住，整个首屏感知就会变慢。Performance API 可帮你对齐时间线：
- 用
PerformanceObserver监听largest-contentful-paint，拿到entry.element和startTime - 立即调用
performance.getEntriesByType('resource')，筛选出initiatorType === 'img'或'fetch'且 URL 与 LCP 元素匹配的条目 - 检查其
duration和transferSize：图片未压缩、缺少srcset、接口 TTFB > 800ms，都是典型瓶颈
发现隐蔽的第三方脚本干扰
很多阻塞并非来自业务代码，而是你没主动加载、却自动执行的第三方脚本：
- 过滤
performance.getEntriesByType('resource')中initiatorType === 'script'且域名不属于你主站的条目（如google-analytics.com、taboola.com） - 对比其
fetchStart → executeStart时间差：差值大说明排队等主线程；executeStart → executeEnd > 50ms就构成一个长任务 - 若该脚本执行集中在 FCP 前 300ms 内，大概率干扰了首帧渲染，建议延迟加载或改用异步 + defer
用 User Timing 主动标记关键链路
框架或业务逻辑常掩盖真实耗时点。手动打点能穿透封装，看清瓶颈在哪：
- 在路由跳转开始时
performance.mark('route_start')，数据请求发出前performance.mark('api_start')，组件挂载完成时performance.mark('render_end') - 用
performance.measure()连接这些标记，比如performance.measure('api_latency', 'api_start', 'render_end') - 结合
performance.getEntriesByName()提取具体耗时，判断是网络慢、解析慢，还是渲染慢
