字体最佳实践

针对 Core Web Vitals 优化 Web 字体。

本文档讨论了字体的性能最佳实践。Web 字体会以多种方式影响性能:

本文档包含三个部分:字体加载字体交付字体渲染。每个部分都介绍了字体生命周期的特定方面的工作原理,并提供了相应的最佳实践。

字体加载

字体是重要的资源。如果没有字体,用户可能无法查看网页内容。因此,字体加载的最佳实践通常侧重于确保尽可能早地加载字体。应特别注意从第三方网站加载的字体,因为下载这些字体文件需要单独的连接设置。

如果您不确定网页的字体是否及时请求,请查看 Chrome 开发者工具中网络 面板内的时间 标签页,了解详情。

开发者工具中的“时间”标签页。

了解 @font-face

在深入了解字体加载的最佳实践之前,务必了解 如何 @font-face 工作 以及它如何影响字体加载。

@font-face 声明是使用任何 Web 字体的重要组成部分。它至少会声明用于引用字体的名称,并指明相应字体文件的位置。

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}

一个常见的误解是,当遇到 @font-face 声明时,系统会请求字体。这是错误的。就其本身而言,@font-face 声明不会触发字体下载。相反,只有当网页上使用的样式引用了字体时,才会下载字体。例如:

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}

h1 {
  font-family: "Open Sans"
}

在此示例中,Open Sans 只有当网页包含 <h1> 元素时,才会下载。

因此,在考虑字体优化时,务必像考虑字体文件本身一样考虑样式表。更改样式表的内容或交付方式可能会对字体到达时间产生重大影响。 同样,移除未使用的 CSS 和拆分样式表可以减少网页加载的字体数量。

内嵌字体声明

大多数网站都会从在主文档的 <head> 中内嵌字体声明和其他 关键样式中受益,而不是将它们包含在外部样式表中。这样一来,浏览器就能更快地发现字体声明,因为浏览器无需等待外部样式表下载。

<head>
  <style>
    @font-face {
        font-family: "Open Sans";
        src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
    }

    body {
        font-family: "Open Sans";
    }

    ...etc.

  </style>
</head>

内嵌关键 CSS 可能是一种更高级的技术,并非所有网站都能实现。性能优势显而易见,但它需要额外的流程和构建工具,以确保必要的 CSS(最好是仅关键 CSS)正确内嵌,并且任何额外的 CSS 都以非渲染阻塞的方式交付。

预先连接到关键第三方来源

如果您的网站从第三方网站加载字体,强烈建议您使用 preconnect资源提示与第三方来源建立早期连接。资源提示应放置在文档的 <head> 中。以下资源提示用于设置连接以加载字体样式表。

<head>
  <link rel="preconnect" href="https://fonts.com">
</head>

如需预先连接用于下载字体文件的连接,请添加一个单独的 preconnect 资源提示,该提示使用 crossorigin 属性。 与样式表不同,字体文件必须通过 CORS 连接发送。

<head>
  <link rel="preconnect" href="https://fonts.com">
  <link rel="preconnect" href="https://fonts.com" crossorigin>
</head>

使用 preconnect 资源提示时,请注意字体提供商可能会从单独的来源提供样式表和字体。例如,以下是如何将 preconnect 资源提示用于 Google Fonts。

<head>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
</head>

使用 preload 加载字体时要谨慎

虽然 preload 在使字体在网页加载过程的早期可被发现方面非常有效,但这样做会占用浏览器资源,从而影响其他资源的加载。

内嵌字体声明和调整样式表可能是一种更有效的方法。这些调整更接近于解决字体发现延迟的根本原因,而不仅仅是提供一种解决方法。

此外,使用 preload 作为字体加载策略时也应谨慎,因为它会绕过浏览器的一些内置内容协商策略。例如,preload 会忽略 unicode-range 声明,如果谨慎使用,则应仅用于加载单个字体格式。

不过,在使用外部样式表时,预加载最重要的字体可能非常有效,因为浏览器在很晚之前不会发现是否需要该字体。

字体交付

字体交付速度越快,文本渲染速度就越快。此外,如果字体交付得足够早,这有助于消除因字体替换而导致的布局偏移。

使用自托管字体

从理论上讲,使用自托管字体应该可以提供更好的性能,因为它消除了第三方连接设置。但在实践中,这两种选项之间的性能差异不太明显。例如, 《Web Almanac》发现, 使用第三方字体的网站的渲染速度比使用 第一方字体的网站更快。

如果您考虑使用自托管字体,请确认您的网站使用 内容分发网络 (CDN)HTTP/2。如果不使用这些技术,自托管字体不太可能提供更好的性能。

如果您使用自托管字体,建议您还应用一些字体文件优化,第三方字体提供商通常会自动提供这些优化。例如,字体子集化和 WOFF2 压缩。应用这些优化所需的工作量在一定程度上取决于您的网站支持的语言。特别是,请注意针对字体优化 CJK 语言可能特别具有挑战性。

使用 WOFF2

在现代字体中,WOFF2 是最新的, 具有最广泛的浏览器支持,并提供最佳压缩。由于它使用 Brotli,因此 WOFF2 的压缩效果比 WOFF 好 30%,从而减少了要下载的数据,因此性能更快。

鉴于浏览器支持,专家现在建议仅使用 WOFF2:

事实上,我们认为现在也是时候宣布:仅使用 WOFF2,忘记其他一切。

这将大大简化您的 CSS 和工作流程,并防止任何意外的双重或不正确的字体下载。现在,WOFF2 在任何地方都受支持。因此,除非您需要支持非常旧的浏览器,否则只需使用 WOFF2。如果无法使用,请考虑完全不向这些旧版浏览器提供任何 Web 字体。如果您制定了可靠的回退策略,这不会成为问题。旧版浏览器上的访问者将看到您的回退字体。

Bram Stein,来自 2022 Web Almanac

子集字体

字体文件通常包含大量 字形,用于支持各种字符 。但您可能不需要网页上的所有字符,并且可以通过子集化字体来减小字体文件的大小。

unicode-range 声明中的 @font-face 描述符会告知浏览器字体可用于哪些字符 。

@font-face {
    font-family: "Open Sans";
    src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
    unicode-range: U+0025-00FF;
}

如果网页包含一个或多个与 Unicode 范围匹配的字符,则会下载字体文件。unicode-range 通常用于根据网页内容使用的语言提供不同的字体文件。

unicode-range 通常与子集化技术结合使用。 子集字体包含原始字体文件中包含的字形的一小部分。例如,网站可能会为拉丁字符和西里尔字符生成单独的子集字体,而不是向所有用户提供所有字符。

每个字体的字形数量差异很大:

  • 拉丁字体的字形数量通常在 100 到 1000 个之间。
  • CJK 字体的字符数可能超过 10,000 个。

移除未使用的字形可以显著减小字体的文件大小。

某些字体提供商可能会自动提供具有不同子集的字体文件的不同版本。例如,Google Fonts 默认会这样做:

/* devanagari */
@font-face {
  font-family: