前端性能优化的实用技巧

上线那天，页面“卡”得让人想摔键盘

记得第一次独立负责的项目上线，凌晨两点盯着监控大屏，心跳比咖啡还快。首页加载时间3.8秒，老板在群里问了一句：“怎么比上次慢了？”我当时的第一反应是甩锅给网络。可把手机切到4G、5G、弱网模式反复试，才发现真正的问题是：一个没压缩的大图、一个同步阻塞的JS文件，外加几十个字体图标像排队过独木桥一样等着下载。那一刻我才意识到，性能不是“差不多就行”，而是用户愿不愿意留下的分界线。

用户不关心技术栈，只关心“点下去有没有反应”

有次做活动页，我在本地跑得天衣无缝，上线后却被吐槽“像在泥地里开车”。后来把 DevTools 的 Network 面板打开一看，首屏资源将近3MB，不少图片还是原图上传。最讽刺的是，设计师给的一张背景图，在页面上只显示一角，却让所有人一起等它加载完。那次我把图片转成 WebP，按设备尺寸裁剪，再加个懒加载，首屏时间直接从2.6秒降到1.1秒。数据不会骗人：用户不会因为你用了 React 或 Vue 就多等一秒。

别让“优化”变成“玄学”，从可测量开始

很多团队一提性能优化就列出一堆名词：Tree Shaking、SSR、边缘缓存……听起来很厉害，但最后往往只改了打包配置，忘了真实场景。我见过一个项目，为了追求极致打包体积，把公共库拆得支离破碎，结果线上请求数翻倍，CPU 在合并渲染时反而更忙。后来我们定下一条规矩：每次改之前先录个视频、截个截图、拿一组数字；改完再跑一次 Lighthouse 和真实用户的 RUM 数据。没对比，就别谈改进。

小改动堆起来，才是大提升

性能优化最怕“一次性大手术”。一次把首页重构为 SSR，成本高、风险大，出问题回滚都费劲。不如从能立刻落地的小事做起：把第三方的统计脚本改成异步加载；把首屏不需要的 CSS 拆出来内联；给列表加上分页和虚拟滚动；把不常变的接口设置合理的缓存头。这些改动单独看都不起眼，但叠加在一起，页面的“呼吸感”会明显不同。用户说不出为什么快了，只觉得“这个站越来越顺手”。

别只盯着首页，细节才是口碑

还有一个案例让我印象深刻。一个后台系统，首页加载挺快，但点进表单列表就卡顿。排查后发现，是每次渲染都在重新计算 thousands 行数据的筛选条件，而且没有做防抖。改成按需计算加缓存后，交互立马流畅。后来我们又给表格加上按需渲染和键盘分页，运维同事反馈“终于不用一边喝咖啡一边等表格展开了”。性能优化不只是加载数字，更是让每一次点击、每一次滚动都让人安心。

---

写到这里，我想很多人会问：前端性能优化到底有没有“标准答案”？说实话，没有。每个项目的技术栈、用户场景、网络环境都不一样，盲目套用“最佳实践”，往往会制造新的问题。但有一套思路是通用的：先测量，再假设，然后小步验证，最后沉淀成可复用的规则。

性能不是上线前的冲刺，而是上线后的长跑。真正有效的优化，往往藏在最朴素的常识里：少请求一点，少算一点，少渲染一点，把最重要的事放在最前面做。它不需要炫酷的名字，只需要稳定、可重复、对用户可见的结果。

当页面从“勉强能用”变成“用着不累”，用户也许不会发朋友圈表扬，但留存和转化的曲线会悄悄说话。而我们作为开发者，最踏实的成就感，也正是来自这些看不见却真实存在的改变。