performance.timing是浏览器提供的原生性能监控 API，用于精确测量页面加载各阶段耗时。对前端开发者而言，它是诊断首屏性能瓶颈、优化用户体验的黄金标准。
一、API 结构：performance.timing对象
performance.timing是一个只读对象，包含页面加载过程中15+ 个时间戳（单位：毫秒，自 Unix 纪元）。
核心字段（按时间顺序）：
| 字段 | 含义 | 说明 |
|---|---|---|
navigationStart | 导航开始时间 | 所有时间的基准（用户点击链接/回车） |
domainLookupStart | DNS 查询开始 | |
domainLookupEnd | DNS 查询结束 | DNS 耗时 =domainLookupEnd - domainLookupStart |
connectStart | TCP 连接开始 | |
connectEnd | TCP 连接结束 | TCP 耗时 =connectEnd - connectStart |
requestStart | HTTP 请求开始 | |
responseStart | HTTP 响应首字节 | TTFB（Time To First Byte）=responseStart - navigationStart |
responseEnd | HTTP 响应结束 | |
domLoading | DOM 解析开始 | |
domInteractive | DOM 就绪（可交互） | 关键：用户可操作时间 |
domContentLoadedEventEnd | DOMContentLoaded 事件结束 | JS 执行完毕 |
loadEventEnd | load 事件结束 | 完整页面加载完成 |
📌注意：
performance.timing已废弃（但所有浏览器仍支持）；- 现代替代：
performance.getEntriesByType('navigation')[0]（Navigation Timing API Level 2）。
二、首屏时间（First Screen Time）的计算
“首屏时间”无标准定义，但通常指用户看到主要内容的时间。常用三种指标：
1.FP（First Paint）
- 浏览器首次渲染像素（非白屏）；
- 不包括：默认背景色；
- 计算：需用
PerformancePaintTiming（见下文）。
2.FCP（First Contentful Paint）
- 首次渲染文本、图片、Canvas 等内容；
- 行业标准（Google Core Web Vitals）；
- 计算：
constfcp=performance.getEntriesByName('first-contentful-paint')[0];console.log('FCP:',fcp.startTime);
3.TTI（Time to Interactive）
- 页面可交互（元素可点击、输入）；
- 计算复杂，需第三方库（如
tti-polyfill）。
⚠️
performance.timing无法直接获取 FCP/FP，
只能估算：
- 首屏 ≈
domInteractive（DOM 解析完成，CSSOM 就绪）；- 完全加载 =
loadEventEnd - navigationStart。
三、用performance.timing估算关键指标
constt=performance.timing;// 1. DNS 查询耗时constdns=t.domainLookupEnd-t.domainLookupStart;// 2. TCP 连接耗时consttcp=t.connectEnd-t.connectStart;// 3. TTFB（后端响应速度）constttfb=t.responseStart-t.navigationStart;// 4. 内容传输耗时constcontentTransfer=t.responseEnd-t.responseStart;// 5. DOM 解析耗时constdomParse=t.domInteractive-t.responseEnd;// 6. 首屏时间（估算）constfirstScreen=t.domInteractive-t.navigationStart;// 7. 完全加载时间constfullLoad=t.loadEventEnd-t.navigationStart;console.table({dns,tcp,ttfb,contentTransfer,domParse,firstScreen,fullLoad});典型输出（单位：ms）：
| 指标 | 耗时 | 优化方向 |
|---|---|---|
| DNS | 20 | DNS 预解析（<link rel="dns-prefetch">） |
| TCP | 50 | HTTP/2 + 连接复用 |
| TTFB | 300 | PHP 优化、OPcache、DB 查询 |
| DOM 解析 | 200 | 减少 HTML 体积、JS 异步加载 |
四、实战用法：前端性能监控
1.上报性能数据
window.addEventListener('load',()=>{constt=performance.timing;constfirstScreen=t.domInteractive-t.navigationStart;// 上报到监控系统fetch('/perf-log',{method:'POST',body:JSON.stringify({firstScreen,url:location.href})});});2.诊断慢页面
- 若TTFB > 500ms→ 后端问题（PHP/DB）；
- 若DOM 解析 > 500ms→ 前端问题（大 HTML、同步 JS）；
- 若TCP > 100ms→ 网络问题（跨机房、无 CDN）。
3.与后端联动
- 在 PHP 响应头添加
Server-Timing：header('Server-Timing: db;dur=150, app;dur=50'); - 前端通过
performance.getEntriesByType('navigation')[0].serverTiming读取。
五、现代替代方案：Navigation Timing Level 2
performance.timing已废弃，推荐使用：
// 获取导航性能（等效于 performance.timing）constnav=performance.getEntriesByType('navigation')[0];// 获取 FCP（首屏内容渲染）constfcp=performance.getEntriesByName('first-contentful-paint')[0];// 获取资源加载详情constresources=performance.getEntriesByType('resource');优势：
- 支持FCP、FP、LCP等 Core Web Vitals；
- 支持Resource Timing（单个 JS/CSS 耗时）；
- 支持Server-Timing（后端自定义指标）。
六、PHP 程序员如何利用？
- 监控 TTFB：
- 若
ttfb > 300ms，用xhprof/EXPLAIN优化 PHP/DB；
- 若
- 减少响应体积：
- 开启 Gzip：
ob_start('ob_gzhandler')； - 移除无用 HTML/JS；
- 开启 Gzip：
- 利用 Server-Timing：
// 在 PHP 中标记关键阶段$start=microtime(true);// ... DB 查询 ...$dbTime=(microtime(true)-$start)*1000;header("Server-Timing: db;dur=$dbTime");
七、总结
| 概念 | performance.timing | 现代方案 |
|---|---|---|
| 核心价值 | 测量页面加载各阶段耗时 | 支持 Core Web Vitals |
| 首屏时间 | 估算（domInteractive） | 精确（FCP/LCP） |
| TTFB | ✅ 精确 | ✅ 精确 |
| 前端优化 | 指导 HTML/JS 优化 | 指导用户体验优化 |
| 后端联动 | 通过 TTFB 定位 PHP/DB 问题 | 通过 Server-Timing 暴露内部耗时 |
✅对 PHP 程序员的终极价值：
用performance.timing证明：
“慢”不是前端问题，而是后端 TTFB 高。
掌握此 API，
你就能用数据驱动前后端协作，
而非陷入“甩锅”争论。
