前端性能如何和后端链路追踪打通？

简化版

前端性能和后端链路追踪打通，就是让一次用户访问从浏览器、CDN、网关、后端服务到数据库都有同一个 trace 标识或可关联标识。前端可以在请求头携带 TraceId，采集页面性能、资源耗时、接口耗时和错误；后端继续透传并记录。这样排查慢页面时能判断慢在前端渲染、网络、网关、服务端还是数据库。

详细版

单看前端监控只能知道页面慢，单看后端 APM 只能知道服务慢。端到端追踪把它们连起来。

层级	采集内容	价值
浏览器	LCP、INP、资源耗时、接口耗时	判断用户体验
CDN/网关	命中率、边缘耗时、状态码	判断网络与缓存
后端服务	trace span、接口耗时、错误	判断服务瓶颈
数据库/缓存	查询耗时、命中率	判断数据层问题

const traceId = crypto.randomUUID()
fetch('/api/product/1', {
  headers: { 'x-trace-id': traceId }
})

前端链路追踪不是为了“埋更多点”，而是让慢请求能从用户点击一路查到后端根因。

完整版教学

一、为什么前后端要打通

用户说页面慢时，可能慢在很多地方：DNS 慢、CDN 未命中、接口排队、数据库慢、前端 JS 长任务、图片太大或第三方脚本卡主线程。

如果前端和后端监控割裂，排查就会变成互相猜。端到端 trace 的价值是把同一次访问串起来。

二、TraceId 怎么生成和传递

TraceId 可以由前端生成，也可以由网关生成后返回。关键是请求链路中要持续透传。

前端常见做法：

页面访问生成 pageViewId。
每个接口请求生成 requestId 或复用 traceId。
请求头带上 traceparent 或业务约定 header。
日志、性能指标和错误上报都带同一关联 ID。

三、和 W3C Trace Context 的关系

现代链路追踪常使用 W3C Trace Context，核心请求头是 traceparent。如果后端观测体系支持它，前端可以按标准传递。

const traceId = '4bf92f3577b34da6a3ce929d0e0e4736'
const spanId = '00f067aa0ba902b7'
fetch('/api/list', {
  headers: {
    traceparent: `00-${traceId}-${spanId}-01`
  }
})

真实项目里通常由监控 SDK 或网关统一处理，业务代码不应到处手写。

四、前端要采哪些关联信息

除了指标值，还要采集足够的上下文：

信息	用途
pageViewId	串联一次页面访问
route	判断慢页面
release version	对齐发布版本
resource timing	定位慢资源
API duration	对齐后端 span
device/network	判断环境差异

注意不要采集隐私和敏感业务数据。

五、如何判断慢在哪里

如果 TTFB 高，后端或网络方向优先；如果接口后端耗时很低但浏览器端耗时高，可能是网络、队列或下载；如果接口快但 INP 差，可能是主线程长任务；如果资源耗时高，可能是 CDN、缓存策略或资源体积。

排查要把浏览器时间轴和后端 trace 时间轴对齐。

六、落地风险

前端透传 trace header 可能触发 CORS 预检，因为自定义请求头不属于简单请求。跨域接口要确保服务端允许对应 header。

另外，采样率要控制。全量采集高频资源和交互可能带来上报成本，也会污染性能。

七、常见误区与追问

误区：前端加 TraceId 就等于完成链路追踪。 后端、网关、日志和监控平台都要透传并索引这个 ID。
误区：采集越多越好。 过量埋点会增加带宽、存储和隐私风险，还可能影响性能。
误区：接口耗时就是后端耗时。 浏览器看到的耗时包含排队、网络、TLS、下载和服务端处理。
追问：自定义 trace header 有什么副作用？ 跨域时可能触发 CORS 预检，需要服务端允许请求头。
追问：为什么要带 release version？ 方便把性能回归和具体发布版本对齐。
追问：前端错误和性能如何关联？ 同一 pageViewId 下同时记录错误、指标和请求，可以看慢是否由异常重试或脚本失败导致。

八、加强记忆

端到端性能追踪记成“一个用户动作，一条链路 ID”。前端采体验和资源，后端采服务 span，中间层采缓存和网络；所有数据能按 trace 或 pageView 关联，排查才不会靠猜。

简化版

详细版