官网首页 4.2MB：我们把它压到 180KB 做了什么

这个项目开始时，客户的官网上线三年，设计已经过时，但真正的痛点不是好看不好看——是移动端打开要等四五秒，投放的落地页跳出率高得离谱。

我们先做了一次完整的资源审计，结果比预想的更糟：首页 4.2MB，其中最大的一张轮播图单独就 2.2MB，还加载了 11 个第三方脚本——统计、客服、字体、图标库、两个轮播插件、一个动画库。

第一步：把「不需要」的删掉，而不是优化

优化的第一步永远是删除。11 个第三方脚本里，有 4 个从未被触发过（一个旧版客服工具的残留、两个统计工具的重复部署、一个已经停用的 A/B 测试 SDK）。删掉它们不需要任何技术工作。

字体是第二刀。原来从 Google Fonts 引了六个字族、十几个字重，实际用到的只有两个字族的三个字重。改成自托管子集之后，字体请求从 4 个跨域请求变成 2 个本地文件。

第二步：图片按实际显示尺寸出

2.2MB 的那张轮播图，实际显示区域在最大屏幕上是 1440×810。原图是 4000×2250 的 PNG。

处理方式很标准：转 WebP、按实际显示尺寸出图、用 srcset 给不同屏幕不同文件。这一项把首屏图片从 2.2MB 降到 120KB 左右。

这里有一个常被忽略的点：width 和 height 属性必须写，否则图片加载过程中页面会跳动，那个跳动本身会让用户觉得「慢」——即使实际加载时间没变。

第三步：动画不阻塞首屏

原站在 <head> 里同步加载了一个动画库，然后所有入场动画都依赖它。这意味着：动画库没下载完，页面内容是隐藏的。

我们改成 CSS 默认可见，JS 只负责「加一个类让元素从隐藏过渡到可见」。这样最坏情况——JS 加载失败——页面依然完整可读。

第四步：把第三方换成自建

原来有一个嵌在页面里的客服组件，加载了大概 300KB。我们和客户讨论后决定去掉它，改成页脚一个邮箱链接加一个表单页。客服量没有下降，因为原来那个组件的实际使用率极低。

图标库、轮播插件同理：实际用到的图标不到 40 个，用 SVG sprite 内联即可；轮播需求只是「手机上能横滑」，CSS scroll-snap 就够了。

结果

首页传输量从 4.2MB 降到约 180KB，请求数从 40 多个降到 12 个，移动端 LCP 从 4.6 秒到 1.5 秒。设计上没有做任何妥协——视觉稿是一致的。

最有说服力的数字不是这些，而是投放落地页的跳出率下降了三分之一。性能不是技术指标，它是转化率的一部分。