前端性能优化踩过的坑，别只看分数

2026-08-11 前端性能,性能优化,避坑,首屏加载

我那个首款自研小游戏上线后，服务器加域名花了 ¥300 多，微信认证 ¥30，结果当日广告收入不到 ¥6。数据出来我才明白：我优化了半天加载速度，用户根本不打算待第二分钟。前端性能优化踩过的坑，最贵的不是技术坑，是优化错了对象。

分数是手段，不是目的。这篇写三个我真实踩过的坑，和一个止损清单。

一、把跑分当成了目标：前端性能优化最常见的坑

现象：Lighthouse 分数从中间档刷到接近满分，线上指标没什么变化。

为什么踩：跑分工具跑的是它自己设定的网络条件和设备模型。真实用户的网络更差、设备更杂，而且用户不会等你加载完才开始评判页面。

怎么避：先把真实用户的等待感受定成指标，比如首屏什么时候能看见内容、什么时候能点。分数只用来定位问题，不用来当成绩单。跑分高但首屏白屏，就是自欺欺人。

现象：花了很多时间压图片体积，压完发现瓶颈在别处。

为什么踩：因为压图片是看得见成果的动作，改起来也简单，做起来有满足感。而真正的瓶颈往往藏在渲染和请求顺序里，查起来费劲。

怎么避：任何优化之前，先用工具确认时间花在哪一段。没有定位的优化都是赌博，赌赢了是运气，赌输了白干几天。顺序永远是先量、再改、再量。

现象：本地跑得飞快，用户那边依然卡。

为什么踩：本地是无缓存之外的最优环境，而且开发机性能通常比用户设备好很多。我在自己电脑上看到的，是最好情况。

怎么避：把慢速网络和低端设备当成默认测试环境，别当成特殊情况。缓存命中率高不代表用户第一次访问快，第一次访问往往是最慢也是最重要的一次。

优化前先问自己五件事，答不上来就先别动手：

清单的价值不在于全做完，在于逼你承认自己在赌。首屏到底怎么一步步查，我另写过一篇排查顺序，比这份清单更具体。

上面三个坑说到底是一件事：我把注意力放在了能被测量的东西上，而不是用户真正在意的东西上。

跑分能被测量，体积能被测量，加载时间能被测量。但用户在意的是「我能不能马上用上」。这两者大部分时候一致，不一致的时候，被测量的那个会赢，因为它更显眼。

所以我现在多问一句：这个改动，用户能感觉到吗。感觉不到就先放着，把时间留给功能。

这个口径救过我不少时间。首款小游戏那次，人均时长不到 2 分钟，说明问题在留存上，而我在优化加载。当时如果问一句「加载快一点用户会多留一会儿吗」，答案是不会，我就能早点转向。

前端性能优化踩过的坑，多数不是技术不够，是问题问错了。先问用户能不能感觉到，再决定要不要动手。

Q：前端性能优化踩过的坑，最常见的是哪个？

A：把跑分当目标最常见。分数只是定位工具，真实用户的等待感受才是判断标准，两者的差距在小设备上尤其明显。

Q：优化到什么程度可以停？

A：到了「用户没有明显感知」的程度就该停。继续压下去投入产出比会快速下降，把时间放到功能上更划算。

Q：小项目也需要做性能优化吗？

A：需要，但只做低成本的那几件。图片体积、请求数量这类改起来简单收益又直接的事先做，深度改造留到有明确证据时再说。