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,
你就能用数据驱动前后端协作,
而非陷入“甩锅”争论。