事情是这样的。上个月老板盯着后台数据，脸越来越黑，丢了一句“这首页加载快 4 秒了，用户早跑了”。我看了眼监控，首屏白屏时间确实离谱，3.8 秒，在移动端甚至能到 5 秒。我心想，这还不简单，老套路了：图片压缩、代码分包、懒加载走一波。
结果一周后重新上线，老板又拉数据。首屏时间 4.9 秒。比原来还慢了 1 秒多。
我当时就愣了。明明该做的都做了，图片从 PNG 转成了 WebP，压缩率压到 60%，路由懒加载也拆了，连 lodash 都按需引入了。问题出在哪？
后来花了三天排查，发现罪魁祸首是一个我从来没正眼看过的配置文件。webpack 的 splitChunks 里，我把 minSize 设成了 30000，结果 webpack 把好几个本来该拆开的小模块强行合并成了一个 500KB 的大包。这个包里面混了图表库、日期处理库、还有几个业务组件。首屏根本不需要的代码全塞一起了，导致浏览器必须下载完这个“巨无霸”才能渲染。
踩了这个坑之后，我重新梳理了整套优化思路。不废话，直接说这周我干了什么，以及每个动作的真实效果。
第一件事，删了一堆“优化”代码。
之前为了追求极致，我在项目里加了一堆预加载逻辑。比如在 link 标签里加了 prefetch，把用户可能点的页面资源提前拉下来。还有一个自定义的“智能预加载”脚本，监听鼠标悬停就触发资源下载。这个脚本本身就有 8KB，而且它在移动端会跟主线程抢资源。实际效果是，用户还没点按钮，CPU 已经被预加载耗掉了。我把这些全删了，首屏 JS 执行时间直接从 1.2 秒降到了 0.6 秒。
第二件事，用了一个骚操作：字体文件按字符集拆。
项目用了思源黑体，一个 woff2 文件 3MB。以前的做法是 font-display: swap，让浏览器先用系统字体渲染，等字体下载完再替换。但替换的时候整个页面会闪一下，体验极差。我查了 Fonttools 这个库，把字体文件按 Unicode 范围拆成了三个子集：中文标点、常用 3500 字、生僻字。首屏只用加载中文标点和常用字，文件从 3MB 缩到了 400KB。生僻字只有在用户输入特定文本时才动态加载。这一步让字体渲染延迟从 2 秒降到了 0.3 秒。
第三件事，重构了图片加载策略。
之前用了懒加载，但用的是浏览器的 loading=”lazy” 属性。这玩意儿有个坑：它只在图片即将进入视口时才加载，但首屏的图片如果被 CSS 隐藏了或者被组件延迟渲染了，浏览器根本不知道这张图在首屏，还是会给它打上 lazy 标记。结果就是首屏的几张大图，因为加载时机被推迟，反而拖慢了渲染。我换成了 IntersectionObserver 手动控制，并且给首屏图片加了 fetchpriority=”high”。实测首屏 LCP 从 3.2 秒降到了 1.8 秒。
第四件事，干掉了一个第三方 SDK。
项目里集成了某个客服聊天插件，就一个弹窗按钮，包大小 120KB。这玩意儿在页面初始化时就会加载，哪怕用户根本没点过聊天。我把它改成了动态导入，只有在用户点击“联系客服”按钮时才加载。这一步把首屏 JS 减少了 15%。
第五件事，服务器端加了一个缓存策略。
之前所有静态资源都是 304 协商缓存，每次刷新浏览器都要发请求问服务器“这个文件变没变”。我改成了强缓存，给 JS 和 CSS 文件设置了 max-age=31536000，文件名带哈希。用户第二次访问直接读本地缓存，连请求都不发。配合 Service Worker 做了一层离线缓存，二次加载的时间降到了 0.5 秒以内。
最后说个我差点忽略的细节：字体文件加载顺序。
如果你在 CSS 里同时声明了 @font-face 和 background-image，浏览器的加载优先级是按声明顺序来的。我把字体声明移到了最前面，让字体文件优先下载，而不是被背景图抢了带宽。这个小改动让字体渲染提前了 400ms。
一周下来，首屏时间从 4.9 秒降到了 1.3 秒。老板看了数据，这次没说啥，但嘴角是往上翘的。
总结几个教训。第一，别迷信“优化套路”，每个项目都有自己的瓶颈。第二，工具配置不要想当然，webpack 的 splitChunks 默认值是有道理的，乱改不如不改。第三，第三方库能动态加载就动态加载，哪怕它只有 50KB。第四，字体文件是隐形杀手，很多人只盯着图片和 JS，忘了字体也能吃掉 2-3 秒。第五，监控数据要细到资源级别，只看首屏时间不知道是哪个资源拖的后腿。
这次最大的收获是：优化不是做加法，是做减法。删掉没用的代码、去掉多余的预加载、砍掉非必要的第三方库，效果比加一万行“优化逻辑”都好。
📎 延伸阅读
看完这篇，如果你想：
- 直接拿工具 → 回复”13“，我把跨境获客工具包发给你
- 系统学习 → 点击菜单”AI训练营”，从0开始跑通AI变现