WordPress 字体加载怎么不拖慢首屏

多数人认定字体慢是因为字体文件大。web.dev 的字体最佳实践第一段就把这个前提纠掉了：@font-face 声明本身不会触发下载，只有当页面上真的有元素用到了这个字体，浏览器才会去取文件。也就是说，改样式表和改字库同样重要，甚至更重要。下面按"发现、传输、替换"这三件事拆开讲。

字体拖慢的是哪三件事

那篇字体最佳实践把字体的生命周期分成加载、传输、渲染三段，每一段都有独立的耗时。

• 发现阶段：浏览器先要读到样式表，才知道页面上需要哪个字体。这个阶段慢，通常是样式表来得晚，或者要等好几张样式表都到齐。
• 传输阶段：字体文件本身的下载，以及它来自哪个源——跨站字体要多付一次连接建立的成本。
• 渲染阶段：字体没到位时，文字先用替代字体画，等真字体到了再换一次。换成不成比例的行高和字宽，页面就会跳一下，直接影响 CLS。

三段的关系是串联的：任何一段卡住，后面的都跟着往后推。所以"换更小的字库"只解决中间那一段。

加载：让声明先被看到

既然字体是被样式表触发的，关键就是让用到字体的那段样式尽早出现在首屏 HTML 里。官方给的建议是把字体声明和其他关键样式内联进主文档的 <head>，这样浏览器不必等外部样式表下载完才发现需要字体。

这里有一个容易做过头的地方：即使只内联了一部分 CSS，浏览器仍然要等所有 CSS 都加载完，才能判断到底需不需要字体。所以内联字体声明是治本的一步，剩下那些非关键样式仍要保证不阻塞渲染，两件事一起做才有效。

传输：格式、子集与来源

• 格式：官方明确建议只用 WOFF2，它基于 Brotli，比 WOFF 压缩约三成，浏览器支持也最完整。
• 子集：字体文件里包含大量用不到的字符。拉丁文字体通常在一百到一千个字形量级，而中文字体可能超过一万个字，按语言切分子集是官方点名的做法，配合 unicode-range 让浏览器只下载页面用得到的那一份。
• 来源：跨站加载字体要多付一次连接建立的成本，官方建议对字体所在的第三方源加连接预热提示；而字体文件必须走 CORS 连接，所以这一条预热提示要带 crossorigin 属性。
• 预加载要克制：官方提醒 preload 会占用浏览器资源，绕过一部分内容协商（比如它会忽略 unicode-range 声明），所以只应该用来预加载单一格式的一种字体。

关于自托管：官方没有简单给结论，反而提醒要先确认自己有没有 CDN 和 HTTP/2，否则自托管未必比第三方源更快。这一条正好说明"自己托管就一定快"是句空话。

渲染：三种 font-display 策略怎么选

默认行为是等到字体加载完再显示文字，官方写明 Chrome 与 Firefox 最多阻塞三秒，Safari 则可能一直阻塞。用 font-display 可以改这三种策略，按你最在意什么来选：

用 swap 的前提是字体必须送得足够早，否则你换来的是一次可见的跳动；官方也提醒 block 一样可能引起位移，因为文字先被画成不可见、靠替代字体占位。选 optional 的代价很直白：字体来晚的那次访问，这一页从头到尾都用替代字体。

中文站和不该动字体的几种情况

三类情况建议先别急着改。第一类是需要多语言但只准备了中文字体的站——子集策略在中文上收益不如拉丁文明显，官方直接说中文字体的优化"格外困难"，先把范围缩小比换格式更实际。第二类是页面几乎没有正文文本（纯图表、纯视频页），字体不是首屏内容，改它等于改错对象。第三类是字体本身已经在缓存里命中、加载时间本来就短，改动只会增加改动风险。中文站还有一个现实约束：为了覆盖常用字，往往要同时提供多套字重，文件数量和体积要一起算，不能只看单个文件。

同时要清楚 web.dev 的 Web Vitals 说明里的定位：字体替换引起的位移会计入 CLS，CLS 在 0.1 或更低算好，按第 75 百分位衡量、移动与桌面分开。这是建议性的体验目标，官方没有公布任何与搜索排名对应的换算关系。

怎么验证字体不再拖累首屏

按三段分别验。发现阶段：在网络面板的时间轴上看字体请求是什么时候被发起的，如果它要等某张样式表下载完才出现，说明发现阶段还没解决。传输阶段：看字体文件本身的大小和传输耗时，确认拿到的是 WOFF2 而不是被服务端转成了别的格式。替换阶段：录一次加载过程，观察文字在字体到达前后有没有发生行高变化，有跳动就说明替代字体和真字体的度量差得太多。

改完之后再看整站：按 URL 分组确认 CLS 的状态有没有变化，并确认移动与桌面两端都没有被牺牲。前台还有哪些长期占用资源的组件，站内旧文哪些插件会拖慢速度和缓存、数据库与前端文件的按需优化已经按层拆过，不必在这篇里重讲。