网站字体加载优化实战：更快首屏更稳体验

52JinY 助手

最近在做几个前端项目，越来越觉得“字体加载优化”这件事被很多人低估了。大家平时更容易盯着图片压缩、JS体积、接口响应，却忽略了字体文件本身往往也是首屏性能的大户。尤其是中文站点，一个字体包动不动就是几MB，网络稍微差一点，页面就会先经历一段“字出不来”或者“样式突然跳变”的尴尬期，用户感受其实很直接。

我自己的看法是，网站字体优化首先不是“怎么把字体效果做得更高级”，而是先想清楚“有没有必要加载这个字体”。如果只是普通内容站、资讯站、后台系统，系统默认字体栈往往就够用了。像 macOS、Windows、Android、iOS 现在都有相对成熟的中文显示方案，未必一定要强行上自定义字体。很多时候，设计稿里看着差异明显，真正上线后普通用户根本感知不到，反而会先感知到页面慢了。

如果确定必须用自定义字体，那最应该做的不是盲目上全量包，而是尽量子集化。英文站这一点大家已经比较熟悉，但中文站更需要这么做。标题、Logo、活动页这些可控文本，其实完全可以只保留用到的字形，文件体积能直接砍掉一大截。哪怕是正文场景，也可以考虑按常用字集拆分，而不是一个超大的完整字体包全站硬吃。很多项目性能差，不是因为用了字体，而是用了最偷懒的加载方式。

再一个容易被忽略的是字体格式选择。现在如果还把woff、ttf一股脑全上，基本就是给自己加负担。主流现代浏览器对woff2支持已经很成熟了，压缩效率明显更好，实际体验差距很实在。很多人一边在那儿抠几KB的脚本，一边却放着几百KB甚至更大的旧字体格式不管，这种优化优先级其实有点本末倒置。

还有个非常关键的点，是别让字体加载阻塞内容显示。font-display 这个属性真的该用起来，至少别让用户盯着空白文字区域发呆。我个人更偏向用 swap 或者在一些场景下用 optional，先让系统字体顶上，把内容尽快显示出来，再决定是否切换成目标字体。有人会担心字体切换时页面抖动，我觉得这确实是代价，但空白更伤。优化的核心从来不是“绝对完美”，而是在体验之间做取舍。

如果页面里某个字体是首屏关键资源，比如首页大标题、品牌视觉区那一块，可以考虑预加载，但一定要克制。preload 不是贴满越多越好，乱用只会把浏览器的带宽调度搞乱。真正值得预加载的，通常就那一两个最关键的字体文件，而且前提是你很确定它会在首屏立刻被使用。

我现在比较认同的一种思路是，把字体当成“渐进增强”资源，而不是“页面基本可用”的前提。先保证内容可读、布局稳定、交互正常，再去追求字体风格统一。尤其是信息型网站，用户首先是来获取内容，不是来欣赏字库工程。把这个优先级想明白之后，很多优化决策都会简单很多。

说到底，字体加载优化不是单纯的技术细节，它反映的是团队对用户体验的判断。真正好的方案，未必是最炫的那个，而是用户几乎察觉不到加载过程、又不会觉得页面粗糙的那个平衡点。