Performance API 不直接提升加载速度，但能精准定位DNS、TCP、TTFB及资源加载等瓶颈，结合预连接、预加载、强缓存、JS拆分与真实用户监控实现科学优化。
Performance API 本身不直接“提高”加载速度，但它能帮你精准定位拖慢响应的环节，让优化有的放矢——不是靠猜，而是靠数据。
看清加载链路：用 timing 和 Resource Timing 找出真瓶颈
页面白屏久、首屏卡，问题可能藏在 DNS、TCP、TTFB 或某个 JS 文件里。光看总加载时间没用，得拆开看：
-
DNS 查询慢？算一下
domainLookupEnd - domainLookupStart，超过 100ms 就该查是否跨域太多、DNS 未预热或解析服务不稳定； -
TCP/SSL 建连耗时高？看
connectEnd - connectStart，若 > 300ms，可能是后端响应慢、没开 HTTP/2、证书链太长，或 CDN 节点离用户远； -
后端处理拖后腿？
responseStart - requestStart（即 TTFB）持续超 500ms，说明接口逻辑重、数据库慢或缓存未命中； -
关键资源加载慢？用
performance.getEntriesByType('resource')筛出订单页 JS、商品列表 CSS 等核心资源，重点看duration、transferSize和是否命中缓存（nextHopProtocol是 h2/h3 还是 http/1.1）。
加速关键资源：预连接 + 预加载 + 强缓存组合出手
发现瓶颈后，不能只等浏览器“被动发现”，要主动引导：
- 对核心 API 域名（如
api.example.com），在<head>加<link rel="preconnect" href="https://api.example.com">，提前完成 DNS + TCP + TLS 握手； - 对立即执行的 JS 或阻塞渲染的 CSS（如
checkout.js、critical.css），加<link rel="preload" as="script" href="checkout.js">，避免 parser 阻塞导致发现晚、下载迟； - 对非首屏但业务强相关资源（如支付 SDK、地图组件），用
<link rel="prefetch" href="pay-sdk.js">，利用空闲带宽提前获取； - 所有静态资源确保返回
Cache-Control: public, max-age=31536000，配合内容哈希命名（如checkout.a1b2c3.js），实现长期强缓存，避免重复请求。
减少主线程压力：拆分、异步、延迟执行
即使资源加载快，JS 执行卡住主线程也会让用户感觉“点了没反应”。尤其初始化阶段容易堆砌逻辑：
- 把客服浮窗、分享按钮、埋点 SDK 这类非首屏必需模块改成
dynamic import()，按需加载，不拖慢首次交互； - 大体积工具库（如 moment 替代品、加密模块）单独打包，避免和主业务代码耦合；
- 用
setTimeout或requestIdleCallback把非紧急任务（如日志上报、非关键 DOM 操作）延后到空闲时段执行，保障主线程响应优先级。
监控真实体验：从实验室走向用户手机
本地测得快 ≠ 用户觉得快。DevTools 的网络节流模拟不了弱网抖动，更看不到低端机内存压力：
- 用
performance.getEntriesByType('navigation')[0]获取firstContentfulPaint和largestContentfulPaint，这些指标直接反映用户“看到内容”的速度； - 结合
Beacon API或分析平台 SDK，把关键指标（如 FCP、TTFB、JS 执行时长）上报到服务端，按设备型号、网络类型、地域做聚合分析； - 对核心路径（如下单流程）打自定义标记：
performance.mark('checkout_start')→ 执行逻辑 →performance.mark('checkout_submit')→performance.measure('checkout_duration', 'checkout_start', 'checkout_submit')，形成可追踪的业务性能视图。
不复杂但容易忽略：Performance API 不是锦上添花的玩具，它是定位问题的第一手证据。有数据，才能谈优化；有对比，才知道改对没。
