Web 性能优化一：什么是前端性能？我们到底在优化什么？

“你们前端能不能把页面搞快点？”

每一个前端开发者，都或多或少听过这句话。

于是你开始压缩代码、拆包、上缓存、加骨架屏……但当产品说“感觉还是慢”，你又陷入疑惑：

明明 Lighthouse 评分都 90+ 了，怎么用户还是说卡？

这，就是前端性能的悖论——技术性能 ≠ 用户体验。

本篇文章，我们将建立一个清晰的认知框架：

前端性能究竟是什么、有哪些分类、谁在感知它、我们该从哪儿下手。

一、前端性能，其实是五种不同“速度”的总称

性能类型	描述	用户感知
加载性能	页面打开速度，静态资源加载效率	影响首屏体验
渲染性能	DOM/CSS/UI 的绘制效率	影响“页面抖不抖”
脚本执行性能	JS 运行效率，事件响应快不快	操作是否丝滑
交互响应性能	点击、滚动等动作的响应及时性	感觉“点了没反应？”
稳定性/一致性	不崩溃、不跳动、能容错	“用了不会出事”

简单来说：你页面要开得快、动得稳、点得准、崩得少、看得顺。

二、用户对性能的“感知” vs 技术指标的误区

开发者看的是 Lighthouse 分数、TTFB、LCP、FPS；

但用户看的是：

• 点了按钮页面有没有立刻反应

• 页面是不是白一秒才加载出东西

• 滚动列表是不是顿了、粘了、掉帧了

• 图片是不是慢慢弹出来还抖了一下

• 一提交表单就假死 or 报错

所以我们要优化的不是“跑分”，而是感知流畅度。

三、性能不是“首屏加载”，它贯穿整个使用周期

别把性能等同于“首页打开速度”。

真正的性能优化，是贯穿整个页面生命周期的工程：

1. 首次加载（HTML + CSS + JS）

2. 首屏渲染（骨架屏 / 渐进式渲染）

3. 用户首次交互（响应延迟）

4. 页面切换 / 滚动（滑动卡顿）

5. 数据更新（乐观 UI / 占位反馈）

6. 长时间使用（内存泄漏 / 脚本堆积）

四、性能优化≠“做了很多事”，而是做了对的事

很多同学陷入“优化姿势大全”：

• 图片压缩了！

• Bundle 分割了！

• Tree shaking 开了！

• Lazyload 用了！

• CDN 配了！

最后 Lighthouse 100 分，用户照样说卡。

因为你压缩了图，却没加载优先级；

你 lazy 了资源，却没骨架屏；

你用了缓存，但忽略了交互卡顿。

性能优化要讲策略，不是拼招式。

五、你的页面要优化的“到底是谁的体验”？

从前端视角，我们关注三类对象：

用户类型	关注点	优化思路
首次访问用户	页面加载速度	SSR/预渲染、压缩、骨架屏
活跃用户	页面交互与数据响应	缓存、懒加载、预取数据
长时间停留用户	内存占用、卡顿、闪动等稳定性问题	虚拟滚动、节流防抖、内存释放

不同用户路径，优化重点完全不同。

总结：别让性能优化只剩打分工具

真正有价值的性能优化是：

• 能减少用户等待（加载）

• 能提升用户掌控感（交互）

• 能稳定用户使用节奏（视觉稳定性）

• 能抵抗未来复杂场景（可扩展性）

你不是在跑分，也不是在堆技术方案，

你是在打造“用起来就是顺”的体验系统。

下一篇，我们将深入剖析：

《一文理解 Web 性能核心指标：FCP、LCP、FID、CLS、TTFB》

帮你从指标的视角进一步建立可观测的性能地图。