前端性能优化：为了让用户少等那几秒，项目可以怎么优化？

做前端久了有个体会：功能再牛，打开页面转半天圈，用户照样跑。尤其现在大家耐心都薄，首屏慢个一两秒，跳出率肉眼可见地涨。所以性能优化这事儿，真不是闲得慌才搞，是实打实影响留存的。

一、先搞清楚时间都花哪了

很多人一上来就"压缩图片"“加缓存”，一顿操作也不知道管不管用。我习惯先把那条时间线摊开看——用户从敲回车到看见内容，中间其实是一串环节：

你看，网络往返、下载资源、JS 解析执行、等接口数据……每一段都在吃掉用户的时间。优化不是瞎做，是看哪段最肥，先砍哪段。

二、网络那一段：CDN 和连接复用

最前面那截"DNS + 建连"最容易被忽略，但它每次访问都要付。我做的几件事：

• 静态资源全上 CDN。JS、CSS、图片推到离用户近的节点，用户不用跨半个地球连你源站。
• 开 HTTP/2。多路复用，原来一个连接一次只能传一个文件，现在能并行，建连次数直接降下来。
• 域名别分太散。有人喜欢把图片、JS、字体扔三个域名，结果每个都要重新建连，反而慢了。

三、资源体积：能小就别大

这块是最容易出效果的。

# 构建时压缩，nginx 再开 gzip / brotli
# 现代打包工具基本都带 tree-shaking，把没用到的代码摇掉
# 图片能用 webp 就别 PNG，体积能小一大截

还有缓存策略：带 hash 的文件名（比如 app.a1b2c3.js）设长缓存，内容没变就一直用本地，不重复下载。这一招对回头客特别明显，二次打开快得飞起。

四、JS 执行：别让一坨脚本卡住渲染

以前我把所有代码打成一个大 bundle，首屏得等这一大个文件下完、执行完才能动，体验很差。后来改成代码分割（code splitting），首屏只加载眼前要用的那点，剩下的用到再懒加载：

// 路由级懒加载，点进去才加载对应模块
const OrderPage = () => import('./pages/OrderPage.vue')

再配合骨架屏——数据没回来之前先画个灰色的占位骨架，用户至少知道"页面在加载"，不像白屏那样以为卡死了。心理感受上快很多。

五、等接口那一段：并发和预请求

最后那段是等后端数据。我一般俩思路：

• 能并发的别串行。多个不相关的接口一起发，而不是 A 完了才发 B。
• 预请求。列表页点进去详情，其实可以在列表项 hover/点击的瞬间就提前发详情请求，等页面跳过去数据可能都回来了。

说句大实话：前端优化很大程度是在"抢"那点感知速度。真要接口本身就慢，前端再怎么折腾也有限，这时候得回头找后端/DB 的麻烦（这块以后单写）。

六、关键点

• 过度优化。小项目首屏本来就不大，上全套优化性价比低，够用就行。
• 只测自己电脑。你公司千兆网当然快，用户可能在地铁里用 4G，务必用节流（throttling）模拟弱网测。
• 忽略长列表。列表几千条不虚拟化，手机直接卡死，这个比首屏更要命。

简单总结一下

性能优化没有"做完"那天，它是个持续的事。但我现在的态度是：先量再改，改完再量，别凭感觉瞎优化。Lighthouse、WebPageTest 这些工具跑一下，能够发现更深的问题。