直接用浏览器原生performance api即可稳定收集真实用户性能数据：一、navigationtiming获取导航全链路（如dominteractive - navigationstart得首屏可交互时间）；二、resourcetiming追踪资源加载详情并筛选慢资源；三、paint timing和long task补全fcp与卡顿数据；四、上报时需附网络类型、设备信息、页面路径等上下文。
直接用浏览器原生 Performance API 搭配轻量级上报逻辑，就能稳定收集真实用户的页面加载性能数据。关键不是堆工具，而是抓住导航、资源、渲染三个核心环节，把数据采集嵌入页面生命周期里。
一、从 navigationTiming 获取完整加载链路
这是最基础也最关键的一步。通过 performance.getEntriesByType('navigation') 可拿到单页加载全过程的 13 个标准阶段时间戳：
- navigationStart：用户触发跳转（地址栏输入、点击链接等）的起始时间
- domInteractive：HTML 解析完成、DOM 构建就绪，可开始交互
- domComplete：所有资源（含图片、iframe）加载完毕
- loadEventEnd：window.load 事件执行结束
计算常用指标只需相减：
首屏可交互时间 = domInteractive - navigationStart
完全加载耗时 = loadEventEnd - navigationStart
二、用 resourceTiming 追踪每个资源表现
调用 performance.getEntriesByType('resource') 能获取所有 JS/CSS/图片/字体等资源的加载详情，每项包含：
- name：资源 URL，可用于识别慢速第三方脚本或 CDN 故障节点
- initiatorType：触发来源（script/link/img 等），判断是 HTML 内联引入还是动态加载
- duration：总耗时，含 DNS、TCP、SSL、请求响应、接收全部内容
- transferSize：实际传输字节数，结合 encodedBodySize 可评估压缩效率
建议只上报耗时超过 1s 或 transferSize 大于 500KB 的资源，避免日志爆炸。
三、用 Paint Timing 和 Long Task 补全用户体验维度
视觉反馈和操作响应同样重要：
- 监听
'paint'类型条目，提取first-paint（FP）和first-contentful-paint（FCP），反映用户“看到内容”的时间 - 用
PerformanceObserver监控'longtask'，捕获主线程阻塞超 50ms 的任务，定位卡顿根源（如大数组排序、未分片的 DOM 操作）
这两类数据需主动开启监听，且仅在支持的现代浏览器中生效，可配合 if ('paint' in PerformanceObserver.supportedEntryTypes) 做兼容判断。
四、真实用户环境必须补充的上下文
脱离环境看数字意义有限。上报时至少带上：
-
网络类型：用
navigator.connection.effectiveType（如 '4g'/'slow-2g'），注意部分安卓浏览器不支持 - 设备信息：屏幕宽高、devicePixelRatio、UA 中的机型关键词（如 'iPhone'/'Mi'）
- 页面路径与入口：当前 URL、referrer、是否来自 PWA 启动或小程序跳转
- 自定义标记：如活动 ID、AB 实验分组、用户登录态（脱敏后）
这些字段能帮你快速区分：是全量用户都慢，还是仅低端机在弱网下加载异常。
