2026 年 7 月我们给一个站查首屏，字体请求花了 1.9 秒，字体包 8 兆。中文字体确实大，但把它变慢的往往不是体积，而是加载时机和切换方式。改完之后同一个包首屏基本感觉不到等待。
中文字体为什么这么大
一个完整的思源黑体，包含两万多个字形，压缩后也有五到八兆。网页上真正用到常用字大概三千五，剩下九成多是浪费。
所以中文字体优化的第一件事不是压缩，是子集化：把你实际用到的字挑出来，生成一个只有几百 KB 的字体文件。
子集化怎么做
第一种，按页面用字生成。统计页面里出现的所有字符，生成对应子集。缺点是页面内容一改就要重新生成，适合内容稳定的官网。
第二种，按 unicode-range 分片。把字体切成多个小文件，浏览器按需加载。首屏常用字在第一个分片里，加载很快。
第三种，用在线字体服务，它们默认做分片。代价是多一个外部依赖，国内访问还要考虑稳定性。
font-display 三种取值
block，字体没加载完文字不显示，最多等三秒。体验最差，用户看到一片空白。
swap，先用系统字体显示，加载完再换。文字马上可见，但切换时会有位移，字号大的时候很明显。
optional，如果字体没在很短的时间内加载好，这次就用系统字体，不切换。最不影响体验，但品牌字体可能经常不显示。
我们的选择是标题用 swap 加尺寸校正，正文直接用系统字体。
预加载和预连接
字体文件藏在 CSS 里，浏览器要等 CSS 解析完才发现它。用 preload 提前告诉浏览器，能省掉一个来回。
preload 要带 crossorigin，否则会因为请求类型不匹配被下载两次。这个坑我们踩过，字体反而更慢了。
字体放在第三方域名上，再加一条 preconnect，把 TLS 握手提前做掉。
什么时候干脆别用
一个官网只用了两种英文字体、没有中文需求，完全可以不加载自定义字体，用系统字体栈。
系统字体在 macOS、Windows、安卓上都不一样，但都好看，且零加载时间。首屏速度能提升几百毫秒。
品牌必须用特定字体，那就只用在标题和 logo 上，正文用系统字体。我们的默认建议就是这条。
一个验证方法
改完别只看 Lighthouse 的分数。把网络降到 3G，清缓存刷新，观察文字什么时候出现、什么时候变形。
再看真实用户数据。CrUX 里没有字体指标，但 LCP 如果卡在文字上，说明字体拖了后腿。
字体优化的收益常常被低估，因为它不像图片那么显眼。但首屏里最大的那块如果是标题文字，字体就是 LCP 的直接原因。
元析智能
为软件公司做 SEO 和 GEO 优化