压到380KB的字体包，文字还是晚了1.8秒才显形

设计公司把品牌字体打包发过来那天，压缩包解开是五个文件，Light、Regular、Medium、Bold、Heavy 各一个，全是 TTF 格式，加起来 41 兆。前端同事看了一眼文件夹属性，问了一句：这五个都要挂到线上吗。

这个问题当时没人接。视觉稿上确实五个字重都出现过——Heavy 用在首页那句主标语上，Light 用在一处引文里，其余三个散落在标题、正文和按钮上。设计交付的时候按稿件里出现过的字重全给，是行业惯例，没人觉得有问题。三周之后测出来的那些数字，全都能倒推回这个下午。

第一个节点：41 兆里，真正需要的只有 16 兆

一套完整的中文字库，单个字重的 TTF 通常在 8 到 16 兆之间，因为它要覆盖两万多个汉字外加标点、拉丁字符和各类符号。西文字体一个字重只有一两百 KB，中文字体天然重四五十倍，这是起点，不是失误。

失误在字重数量上。把设计稿里所有文本图层导出一份清单，按字重分组统计出现的次数，多数企业官网的结果是很悬殊的：Regular 占七成以上，Bold 或 Medium 占两成多，剩下三个字重加起来不到 5% 的使用面积，往往就是一句标语和一处引文。为了这 5% 扛下 24 兆，账怎么算都不划算。

这一步的处理办法不是砍掉视觉效果，而是替换实现方式。那句主标语用 Heavy，是为了够粗够醒目，可它全站只出现一次，完全可以在设计阶段就切成 SVG 或者一张图片，体积不到 20KB，还顺带解决了不同系统渲染粗细不一致的问题。Light 那处引文改用 Regular 加浅一级的灰度，视觉分量几乎一样。网站设计评审时把这类只出现一两次的特殊字重单独拎出来问一句「它有没有别的实现方式」，比上线后回头优化省力得多。最后留下 Regular 和 Bold 两个字重，16 兆。

第二个节点：格式换掉，16 兆变 5.2 兆，字形一个像素没变

16 兆还是不能直接用。TTF 和 OTF 是给桌面排版软件用的格式，没有为网络传输做过压缩。转成 WOFF2 之后，同一份字形数据通常只剩原体积的三到四成，两个字重从 16 兆降到 5.2 兆左右。

需要说清楚的是，这一步是无损的。WOFF2 用 Brotli 算法压缩字形轮廓，浏览器拿到之后解压还原，渲染出来的笔画和原文件逐点一致，不存在「压过头会糊」这回事。所以它是唯一一个不需要权衡、只要做了就赚的动作。

这个节点上最常见的失误是回退列表写太长。有些模板会在字体声明里同时列出 woff2、woff、ttf、eot 四种格式，本意是照顾老浏览器。实际情况是 WOFF2 的浏览器覆盖率已经在 96% 以上，那三种回退基本用不上，而且格式顺序一旦写反，部分浏览器会先下载排在前面的大文件，等于白白多传几兆。只留 WOFF2 一种，format 标注写对，是现在更干净的做法。

第三个节点：5.2 兆切到 380KB，切法比切不切更要紧

把字库里用不到的字剔掉，这件事本身没有争议，有争议的是按什么标准剔。

第一种是静态子集，扫一遍站内现有文案，把出现过的字打成一个包。企业官网的导航、按钮、首页板块标题、页脚这些固定文案，去重之后常在 700 到 1500 字之间，打包后 90 到 200KB。它的风险很明确：运营明天发一篇新闻稿，里面出现一个包里没有的字，那个字会单独回退成系统字体，一行文字里冒出两种字形，比不用定制字还难看。所以静态子集只能用在文案基本不变的区域，正文区不能碰。

第二种是按码位分片，把字库切成几十个小文件，每片二三十 KB，在样式里用 unicode-range 声明每一片覆盖哪些字符范围。浏览器解析页面时只会下载真正用到的那几片，一个普通产品页通常触发 5 到 15 片，实际下载量落在 150 到 400KB。这种方式对后台新增内容是安全的，代价是首次请求数变多，需要配合 HTTP/2 使用。

还有一个更省事的分层思路：标题和导航用定制字的静态子集，控制在 100KB 以内，正文段落直接交给系统字体栈。长文阅读本来就更适合系统字，屏幕适配也更成熟，访客几乎不会察觉，而首屏字体的下载量能砍掉大半。标题和正文分开对待这件事，在网站设计阶段定下来只是改一句样式，等字体变量已经铺满整张样式表再拆，要动的就是几十个文件。这套项目最后走的是分片方案，首屏实际拉下来 380KB。

第四个节点：包已经够小了，文字还是空了 1.8 秒

上线前压测，体积指标全部达标，但录屏回放时发现一个现象：页面框架和图片都出来了，文字区域一片空白，一秒八之后所有文字才整片浮现。有人第一反应是继续压体积，方向错了——这不是体积的问题，是显示时机的问题。网站设计里这是两条独立的线，包压到极限，配上一个错误的显示策略，访客看到的依然是一片空白。

字体加载有一个默认行为叫隐形文字期。浏览器发现某段文字要用还没下载完的字体时，默认选择先什么都不显示，等字体到了再一次性画出来，最长可以等三秒。380KB 在 4G 下大约要一秒多，那段空白就是这么来的。

控制它的是 font-display 这个属性，四个取值的实际差别值得记住。block 是隐形三秒，任何情况下都不该用。swap 是立刻用系统字显示，字体到了再替换，文字一秒都不会缺席，代价是替换瞬间字形会跳一下。fallback 给 100 毫秒隐形期加三秒替换窗口，超时就永久使用系统字，是企业官网比较稳妥的选择。optional 同样是 100 毫秒隐形期，但网速差时直接放弃本次加载，下次访问再说，对性能最友好，适合字体只是锦上添花的站点。

选了 swap 就要处理字形跳变。同一段文字用系统字和定制字排出来的宽度、行高往往不一样，替换的一瞬间整段会位移，观感很廉价。办法是给回退字体设置 size-adjust 和 ascent-override，把系统字的字宽和基线调到接近定制字，位移幅度能从明显的抖动压到几乎看不出。这类细节在网站设计的验收环节很难被写成条款，但它决定了页面看起来是精致还是毛糙。

另外补一个 preload。首屏一定会用到的那个字体文件，让浏览器提前发起请求，字体出现时间通常能提前 300 到 600 毫秒。但只提前加载一个，最多两个，preload 声明多了会和首屏主图抢带宽，图片慢下来比字体慢更容易被察觉。改完这两处，文字缺席时间从 1.8 秒降到 0.1 秒以内。

第三个月：380KB 回潮到 1.2 兆

上线三个月后例行体检，首屏字体下载量变成 1.2 兆。没有人做错事，是三条路径各自漏了一点。

第一条是活动页。市场部临时上一个专题页，外包的人找不到项目里字体变量写在哪，索性重新引了一份完整字库，多出 5 兆多的资源，只是恰好没在首页触发所以一直没人发现。

第二条是图标字体。为了三个新增图标，前端把整套图标字体又引了一遍，两千多个图标 200 到 400KB，实际用到三个。这三个图标改成内联 SVG，加起来不超过 4KB。图标字体在今天已经很难说还有优势，它整包不可拆、无法只取其中几个，这个特性和瘦身的目标天然冲突。

第三条来自后台。运营习惯先在 Word 里排好版再粘进富文本编辑器，粘贴带进了行内样式，里面指定了本地字体名。访客机器上装了那款字的看到一种字形，没装的回退到另一种，同一个栏目下几篇文章字形各不相同。这条最难防，处理办法是在编辑器里开启粘贴时清除格式，并且在样式表里给正文容器加一条优先级足够高的字体声明覆盖掉行内值。

要让它不再回潮，得给字体单列一条性能预算，不要混在其他资源里统计。阈值给一个能判定的数：首屏字体总下载不超过 300KB，构建时超了就报警。再加一个季度动作，用开发者工具的网络面板按类型筛出字体请求，看一个页面到底下载了几个文件，超过三个基本就是有地方重复引入了。这条规则写进网站设计的交付文档里，比口头提醒有效。

先看你的站现在卡在哪一段

打开浏览器开发者工具的网络面板，刷新首页，按字体类型筛一遍，看三个数：文件格式、文件个数、总字节数。

如果格式栏里还有 ttf 或 otf，这周就把格式转换做掉，用现成的命令行工具跑一遍，不动任何设计稿，也不需要重新评审，体积当场降六成，是投入产出比最高的一步。

如果已经是 WOFF2 但总量仍超过 500KB，问题多半在字重数量上，先回去数一遍到底挂了几个字重，砍到两个，再考虑要不要上分片。

如果体积两项都达标，用户却还在反馈文字要闪一下才出来，那就跟体积无关了，去样式表里找 font-display 有没有声明，再给首屏那一个字体文件补上 preload，改动量是两行。

三段都对得上号的，把首屏字体不超过 300KB 这条数字写进下一版网站设计规范，附上今天量到的实际值。半年后再打开这个面板，至少知道该跟谁对账。