标签频道
Web Vitals
该标签下的文章、提问与讨论帖。
【背景】 5 年前端，去年大促前复盘一次商品详情页事故：用户投诉「打开卡」，前端用 RUM 拉数据，LCP P75 = 2.8s，INP P75 = 410ms；后端拉自家 API 监控，P99 = 820ms，「我们没问题」。两边各看了各
背景 我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个页面），DAU 约 3.5 万，RUM 采样率 10%，核心页日均约 3~5 万会话。去年把 CLS 从 Lighthouse 0.35 治到 0.0
【背景】 我做了 8 年前端，最近半年主抓的是核心链路的稳定性与可观测性。一个让我反复纠结的场景： 我们的下单页走的是「页面渲染 → 表单校验 → 调 3 个接口（库存 / 价格 / 优惠券）→ 提交订单」这条链路。上个月一次灰度，前端做了
背景 热榜上 #1374 那个提问把后端「trace 三段加起来 80ms、网关却看到 2.4s」的缝隙讲得很透。我从前端这边看，类似的「口径对不上」每天都在发生，只是没人系统讨论： - 后端说「这个接口 P99 200ms 达标」； -
背景 React 18 + Vite 5 的 B 端中台 SPA，约 220 个路由，自研 RUM SDK 用 "PerformanceObserver" 采 Core Web Vitals（LCP/CLS/INP）+ "performan
背景 我做了 3 年前端，最近在带一个 B 端 SaaS（React 18.2 + Vite 5 + TypeScript 5.4，约 240 个路由）做 Core Web Vitals 治理。LCP、CLS、TTFB 都有成熟的 Web
背景：我们是一个中台型 B 端产品，前端技术栈 React 18 + Vite，日均 UV 约 12 万，但 LCP 分布长期呈"双峰"——大约 65% 的会话 LCP < 2s（CDN 命中 + 预取生效），其余 35% 的会话 LCP
背景 社区里后端侧的讨论很热（连接池、超时重试、慢 SQL），但前端这边我们常年的痛点其实是：性能指标到底看哪个、看多少分位。我做了 15 年前端，带过的团队里，最常见的做法是「看平均值或 75 分位」，理由是 Web Vitals 官方口
【背景】 我们是一个 React 18 + Webpack 5 的中后台 SPA，约 200 个路由、60+ 个三方 SDK（埋点、IM、风控、客服等）。今年开始把 Web Vitals 纳入稳定性大盘，INP 目标 < 200ms。 【现
文
标题
摘要