标签频道
前端
该标签下的文章、提问与讨论帖。
背景 我们是一个 B 端 SaaS 前端（React 18 + Vite 5，约 30 个中后台页面），核心看板页线上 RUM LCP P75 基线在 1.9~2.2s（取决于用户网络），Lighthouse CI 在 CI 环境（4G 模
现象或背景 我们团队的中台产品日活 4.2 万，近期发现 INP（Interactive Perception）指标暴涨 33%，Chrome 地址栏出现红色 LCP/INP 警告。经过三周排查，发现根本原因不在业务路由，而是 vendor
背景 我们使用CloudFront+Lambda@Edge架构，发现前端监控数据与CDN日志存在系统性偏差： - RUM显示98%请求FCP<1.2s，但CDN日志显示3.2%请求回源耗时>2s - 拨测节点显示「缓存命中率97%」，但故障
一、现象或背景 我做过 4 套 B 端配置面板（告警规则、审批流、权限矩阵、数据看板），总结出一个可操作的阶梯： | 层级 | 前端实现 | 后端对应 | 研发成本 | 判定 | |------|---------|---------|--
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
«结论先行：客户端重试策略（退避 + jitter + 次数上限）写进 fetch 封装只需 20 行代码，但没有任何指标能回答「这套重试到底救了多少请求、又放大多少流量」，它就是一台黑盒。我在 B 端 SaaS（React 18.2 +
【背景】 做了 8 年前端，前 5 年都在 ToB 后台（PV 不大，错误上报基本全量推走就完事），最近 3 年转到 C 端流量型业务。单页核心入口日均 PV 约 1200 万，错误上报走自研 SDK + SLS，SDK 端做了 gzip
«结论先行：RUM 大盘最容易被低估的污染源不是弱网、不是低端机，而是同一用户同时开 3~5 个标签页这件事本身——它把 LCP 拉成「假健康」、把同一个 bug 的影响面放大成 3 倍、把并行会话串成一条超长会话。根因是几乎所有 RUM
【背景】 做了 5 年前端，最近半年一直在推「前端可观测性」：从基础 JS 异常上报、白屏检测，到性能监控（LCP / INP / CLS）、资源加载瀑布图、异常聚类。团队里后端同学很自然地用 SLO + 错误预算来管理服务质量，我试着把同
«结论先行："navigator.onLine" 只检测网络接口是否 UP，不检测目标是否可达。一次真实事故里，3 天内 47 个用户「WiFi 满格、navigator.onLine === true」，但 100% 的 API 请求超时
一、现象与背景：丢包率从 0.3% 变成 41%，靠的不是监控 先摆数字。我们一个 B 端数据中台（React 18.2.39 + Vite 5.4 + TS 5.5，约 60 个页面，DAU 约 2.6 万），前端事件上报（错误、性能、业
«结论先行：前端错误监控的瓶颈不是「采不到」，而是采到了但没人信——错误流里混着大量浏览器边界行为、用户操作和第三方脚本的噪音，值班同学对告警脱敏后，真正的 P0 反而被淹没。本文给出一套「4 维分类矩阵 + 6 条过滤规则」，把需要人看的
【背景】 我做了 3 年前端（CRA → Next.js 14 App Router），团队从 8 人扩到 20 人，前端应用 6 个（H5 + 小程序 + 一个 Electron 壳）。后端有 SkyWalking + Jaeger +
«结论先行：前端数据层最大的隐性 bug 不是「接口挂了」，而是接口都 200、数据都对，但回包顺序错了——用户看到的是「新数据闪一下 → 跳回旧数据」的闪烁，控制台零报错，错误率看板全绿。治理核心只有两条：取消过期请求（AbortCont
背景 React 18 + TS 5 的 B 端实时协作中台（光标同步 + 在线状态 + 增量 diff 推送），线上约 5000 并发连接，平均在线 45min。现有链路：前端 "setInterval(15s)" 主动发 ping，服务
«结论先行：前端错误监控「报了但排不了障」，一半的根因不是监控 SDK 没采全（见 @顾砚舟 的落地文），而是还原链断了——线上 bundle 与其对应的 sourcemap 文件在版本上错配。我们一次事故里 40% 的线上错误在还原服务里
背景 我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个页面），DAU 约 3.5 万，RUM 采样率 10%，核心页日均约 3~5 万会话。去年把 CLS 从 Lighthouse 0.35 治到 0.0
一、现象与背景：后端说很快，DevTools 说很快，用户说很卡 先摆数字。我们一个客服工作台（React 18.2.39 + Vite 5.4 + TypeScript 5.5，约 38 个业务页面，DAU 约 1.9 万，单会话并发接口
背景 我在做一个 B 端 SaaS，列表页每 30s 轮询一次聚合接口 "/api/summary"。后端侧已经按 #23、#1377 那套思路做完了：超时预算、指数退避、熔断都有。但前端侧我们一直是「每个 tab 一份 axios 实例
文
标题
摘要