4.4MB 砍到 569KB：一次让访客少等四秒的提速手术

我们自己的官网曾经有个尴尬的毛病：首页打开后，版式先出来，字要等一会儿才落位。测下来最慢的一项——最大内容绘制（LCP，就是"访客觉得页面终于出来了"的那一刻）——接近五秒。

五秒是什么概念？一个从搜索结果点进来的访客，通常撑不到第三秒。

先找真凶，别先动手

一看到"慢"，最容易的反应是怀疑服务器不行、CDN 没铺开、要不要加台机器。我们先没动这些，而是把首页加载的每一个文件按体积排了个序。

排在第一位的，是四个字重的中文字体，合计 4.4MB，而且是 preload——浏览器被明确告知"优先下载这个"。

这就说得通了：中文字库天生就大。一套字体要装下两万多个汉字，可我们的官网从头到尾也就用到一千出头。为了显示 1128 个字，下载了两万多个字。

手术方案：只带走用得上的字

解决办法叫字体子集化——扫描全站真正会渲染出来的每一个字符，只把这些字形保留下来，其余全部丢弃。

我们把这一步做成了构建流水线里的一环（scripts/subset-fonts.mjs），每次构建自动重跑。这有个重要的好处：以后改文案，字体子集会跟着一起重算，不会出现"新加了一句话、结果那几个字显示成方框"的事故。

结果：

	之前	之后
字体总体积	4.4 MB	569 KB
省下	—	87%
首页性能评分	69	86
其余页面性能评分	77	94 / 95

八条路由的性能评分全部达标。而且因为用的还是同一套 Noto Sans SC 字形，页面看起来一模一样——我们的像素比对测试跑了 26 张截图，零差异。

我们没有选的那条路

有个更省事的做法：把字体的 preload 关掉。这样首屏指标立刻好看，但代价是访客会先看到一版系统默认字体，过一会儿"啪"地换成正式字体——那个跳动很难看，而且它只是把问题从测试指标里藏起来了，并没有让访客少等。

我们选了攻根因的那条：体积本身降下来，设计一点不改。

这件事说明什么

这次改动从定位到上线，全程由建站工程师·小坚执行：找根因、写子集化脚本、跑三道质量门、本地预演、推生产、验健康。人做的事只有一件——看一眼结果。

这也是我们想说的：数字员工的价值不在于"会写代码"，而在于它会像一个负责任的工程师那样，先找真凶、再挑代价最小的那条路、最后自己把活验干净。

想看你自己的站有没有同样的毛病？把网址告诉我们，小坚跑一遍体检，结果直接发你。