前端性能优化实战：从加载到交互的完整体验

只压 bundle 体积，往往把 LCP 做漂亮了，用户点按钮还是卡一秒。这篇按「指标 → 加载 → 渲染 → 交互 → 度量」的顺序，给一条可落地的优化路线。

一、先定指标：三个核心体验指标

「性能优化」四个字，很多团队的第一反应是「压一压 bundle」。但用户感知的性能其实分三段：能不能快点看到（加载）、画面稳不稳（渲染）、点了有没有反应（交互）。

三个指标对应三种体验，优化的第一步是量出哪个最差——它们的最优手段完全不同：LCP 靠减体积与关键路径，INP 靠拆长任务，CLS 靠预留空间。

没有数字，一切优化都是猜——体感由慢设备和弱网决定，所以盯 P75。

二、加载阶段：先减体积，再谈别的

三条落地经验：先看打包分析（用 bundle analyzer 找体积大头，通常是某个「顺手引的大库」——moment 换 dayjs、lodash 改按需引入，常常一次砍掉几百 KB）；图片是第一大头（现代格式加正确尺寸常省一半以上，懒加载记得配合宽高占位）；关键路径优先（首屏需要的 preload，其余全部延后）。

三、渲染阶段：别让主线程堵住

• 长任务拆分：超过 50 毫秒的任务会阻塞交互——大计算切片、能挪进 Web Worker 的挪进去，或放到 requestIdleCallback
• 长列表虚拟化：一万条数据别真渲染一万个节点，只渲染可视区，滚动时回收复用
• 避免布局抖动：别在循环里穿插「读几何属性 + 改样式」——读写分离，批量变更
• 动画只用合成属性：优先 transform 与 opacity，它们不触发布局与重绘

// 读写分离 + 帧内批量：避免反复触发布局
const widths = [...items].map(el => el.offsetWidth);   // 先集中读
requestAnimationFrame(() => {                          // 再统一写
  items.forEach((el, i) => { el.style.width = widths[i] + "px"; });
});

四、交互阶段：INP 优化的具体手段

• 事件处理轻量化：点击后的重活别同步做——先给反馈（按钮进入 loading），把计算放进 Worker 或下一帧
• 防抖与节流分场景：搜索输入用防抖；滚动、拖拽用节流或 rAF 节流（每帧最多一次）
• 乐观更新：先改 UI 再等接口，失败再回滚——把「等待」从感知里去掉
• 让等待可感知：骨架屏、进度提示、按钮禁用态，比「转圈圈」更让人踏实

判断顺序：先看有没有长任务，再看事件处理是否过重，最后才考虑微优化。

五、测量：没有度量就没有优化

• 实验室环境：Lighthouse 做开发期体检；Performance 面板录制交互，看长任务与调用栈
• 线上真实用户：接入 Web Vitals 采集，用 PerformanceObserver 观测三项指标的真实分布
• 看分位数，不看平均：平均 1.2 秒可能藏着 P75 的 4 秒——体感由慢设备和弱网决定
• 性能预算进 CI：给 bundle 体积与关键指标设上限，超了直接让流水线红

{ "budgets": [
  { "resourceType": "script", "budget": 300 },
  { "metric": "LCP", "budget": 2500 },
  { "metric": "INP", "budget": 200 }
]}

六、五个常见坑

• 只优化加载，不看交互：LCP 很漂亮，用户点一下等一秒——INP 才是日常体感
• 只看平均值：P75、P95 才是「慢用户」的真实体验
• 为省几 KB 牺牲可维护性：微观优化要有收益阈值
• 懒加载引发 CLS：图片没写宽高、内容动态插入顶掉布局——预留空间是前提
• 上线即结束：没有持续度量，三个月后性能悄悄退回原样

七、落地路线：三周计划

• 第 1 周 · 建立基线：接入 RUM 与性能预算，记录 LCP、INP、CLS 的 P75
• 第 2 周 · 拿体积开刀：打包分析、路由拆分、图片与字体优化——收益最大、风险最小
• 第 3 周 · 治理交互：找出长任务、虚拟化长列表、重活挪进 Worker、关键操作上乐观更新

速查卡

写在最后

前端性能优化没有「一招鲜」，正确姿势是：先用真实用户的 P75 定位最差的那一段体验，再对症下药——加载慢就减体积与关键路径，交互卡就拆长任务，画面跳就预留空间。最后用性能预算把它锁住，防止优化成果被后续需求悄悄吃掉。