谈到前端性能优化，很多开发者第一时间想到的是 Lighthouse、WebPageTest、Chrome DevTools 的 Performance 面板。这些工具固然好用，但今天我们要聊一个更底层、更精准的利器——浏览器自带的 Performance API。
它不依赖任何第三方库，原生就能把从输入 URL 到首屏渲染的整个链路拆解成可量化的阶段。不测内存，却能精准定位加载瓶颈，让优化真正落到实处。
看清每一段耗时：用 timing 和 resource timing 定位卡点
页面加载并非黑盒，而是由 DNS、TCP、SSL、TTFB、资源下载、解析、渲染等环节组成。关键不在于总耗时，而在于找到哪一段拖得最久。
先看 DNS 查询阶段，计算 domainLookupEnd - domainLookupStart 的差值。如果超过 100ms，基本可以判断域名解析速度偏慢，或者跨域请求过多，导致解析器过载。
接着是 TCP + TLS 握手阶段，查看 connectEnd - connectStart 的差值。如果超过 300ms，问题可能出在服务端响应慢、未开启 HTTP/2，或者证书链过于冗长。
TTFB 首字节时间，即 responseStart - requestStart。如果持续超过 500ms，那就要重点排查后端逻辑、CDN 缓存策略，甚至是数据库查询响应速度。
首屏内容渲染 FCP，可以通过 performance.getEntriesByType('navigation')[0].firstContentfulPaint 获取。这个指标比 DOMContentLoaded 更能反映用户实际感受到的加载速度。
对订单接口、商品列表 JS 等核心资源，要单独用 performance.getEntriesByType('resource') 拉出来分析。查看它的 duration、transferSize 以及缓存状态，判断到底是体积大、未压缩，还是 no-cache 策略，导致它在整条链路上拖后腿。
提前铺路：预连接 + 预加载 + 合理缓存
浏览器默认是“按需发现”，但核心业务不能等它慢慢查找。要主动告知浏览器哪些资源最关键、来自哪里。
比如对核心 API 域名 api.example.com，在 里添加 ，告诉浏览器提前完成 DNS、TCP、TLS 连接，省得等到页面解析到相关请求时再临时建立连接。
对立即执行的关键脚本，如 checkout.js，使用 ，让浏览器提前下载，避免解析器发现它时已太晚，导致下载滞后。
对非首屏但强相关的资源，比如支付 SDK，采用 ，利用空闲带宽提前拉取，等用户需要时直接从缓存中获取。
所有静态资源（JS、CSS、字体、图片）必须返回 Cache-Control: public, max-age=31536000，配合内容哈希命名，实现长期强缓存。避免浏览器每次加载都重新请求，浪费带宽和时间。
释放主线程：异步化 + 拆分 + 按需加载
很多“白屏久”并非网络慢，而是 JS 在主线程上同步执行太久，阻塞了渲染。优化重点是减少初始化阶段的负担。
把客服浮窗、分享组件、埋点 SDK 等非首屏模块，从 import 改为 dynamic import()，首次交互时再加载。不要让它们一上来就抢占主线程资源。
对体积大的业务逻辑，如复杂表单校验、图表渲染，做代码分割，只在对应路由或操作触发时加载。这样能大幅减少首屏加载的 JS 体积。
避免在 window.onload 或 DOMContentLoaded 里堆砌大量同步逻辑，改用 requestIdleCallback 或微任务调度，把主线程让给渲染。渲染优先，逻辑可以稍后执行。
使用 performance.mark() 和 performance.measure() 标记关键节点，比如“下单按钮点击”到“弹窗显示”，量化业务逻辑执行耗时，这样能更精准地定位问题，而不是只盯着页面级指标。
监控真实体验：不只是实验室数据
Lighthouse 和 Performance 面板适合调试，但真实用户环境千差万别。要把 Performance API 数据上报到监控系统，才能真正反映用户实际体验。
采集 FCP、LCP、CLS 等 Web Vitals 指标，按设备类型、网络条件（4G/WiFi）、地域分维度统计。不同场景下的表现差异很大，需要针对性优化。
对慢资源（duration > 2000ms）自动告警，并附带 transferSize 和 nextHopProtocol（是否使用 HTTP/2），这样能快速定位到底是哪个资源拖了后腿，并找出原因。
结合用户行为，比如点击“立即购买”后 3 秒内未跳转，反向关联 Performance 数据，判断是前端卡顿还是后端超时。这样能更准确地定位问题源头。
避免只看平均值，重点关注 P90/P95 分位耗时，它们更能反映多数用户的实际等待体验。平均值容易被极端值拉低，而 P90 以上的数据才是真实用户的痛点。