标签频道
INP
该标签下的文章、提问与讨论帖。
现象或背景 我们团队的中台产品日活 4.2 万，近期发现 INP（Interactive Perception）指标暴涨 33%，Chrome 地址栏出现红色 LCP/INP 警告。经过三周排查，发现根本原因不在业务路由，而是 vendor
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
【背景】 5 年前端，去年大促前复盘一次商品详情页事故：用户投诉「打开卡」，前端用 RUM 拉数据，LCP P75 = 2.8s，INP P75 = 410ms；后端拉自家 API 监控，P99 = 820ms，「我们没问题」。两边各看了各
【背景】 做了 8 年前端，最常被 SRE 和产品同学挑战的一句话是：「你们 API P99 才 80ms，为什么用户还在骂页面卡？」 我们团队负责一套 To C 的 H5 + 小程序混合前端，核心页面（商品详情 / 下单确认）的 SLO
«结论先行：前端 Long Task 里最容易被忽略的一类，不是渲染、不是 setState，而是 "JSON.parse" 本身——它对 30 万+ 字节的响应在主线程同步执行，单次耗时可达 800ms+，且 DevTools 的 Lon
背景 我做了 3 年前端，最近在带一个 B 端 SaaS（React 18.2 + Vite 5 + TypeScript 5.4，约 240 个路由）做 Core Web Vitals 治理。LCP、CLS、TTFB 都有成熟的 Web
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
«结论先行："useTransition" 不是加上去就完事的。我们一个 B 端后台（React 18.2 + Vite 5 + TypeScript），给搜索框加 "useTransition" 后 INP P75 只从 900ms 降到
结论先行 INP（Interaction to Next Paint）在 2024 年 3 月正式取代 FID 成为 Core Web Vitals 的交互指标后，我们一个 B 端中台的 INP P75 从 480ms 一路恶化到 720m
【背景】 我们是一个 React 18 + Webpack 5 的中后台 SPA，约 200 个路由、60+ 个三方 SDK（埋点、IM、风控、客服等）。今年开始把 Web Vitals 纳入稳定性大盘，INP 目标 < 200ms。 【现
文
标题
摘要