在过去的几周中，由于碰巧在工作中以及在第三方项目中，我学到了很多有关Web字体的知识，尤其是有关Google字体的知识。因此，我可以为过去似乎很简单的问题提供更详细的答案：您应该在服务器上存储Google字体吗？客观地说，我承认字体不是我的强项。我更喜欢一种更实用的方法，并且不专注于设计（请查看此站点并确保它是正确的），在此之前，我不觉得需要使用非标准字体。当然，它们看起来更好一些，并在文本上加上了“商标”。但是对于正文来说，它们几乎没有意义。我从来没有给文章打分（或与文章内容有不同的联系），只是因为使用了漂亮的字体来提交。但是，我完全意识到其他字体对性能和页面加载速度的负面影响，所以也许由于这个原因我有偏见。但是，许多人可能会不同意我的看法，而字体，无论它们对我个人而言是否重要，都会被许多其他开发人员定期使用，并且通常他们别无选择。让我们看看可以做些什么，以免损失网站的速度，并使设计师满意。自托管与外部资源
几年前，它被认为是正常使用CDN连接共享资源（例如，jQuery的用code.jquery.com -和是的，他们仍然使用它非常）。需要说明的是，这里的CDN是指从其他人的域而不是您自己的CDN加载资源。原因是浏览器应该限制每个域的连接数（通常限制为6个连接），因此使用另一个域可以给您另外6个连接。过去（尤其是当限制为<6个域时）以及在HTTPS成为规范之前，这都是正确的，大大增加了连接成本。另外，HTTP / 2实际上使用一个连接（大多数是！）会受益，因此使用其他域通常会降低性能，而不是获得性能。实现此目的的另一种方法是通过使用一个或多个技术子域（例如，assets.example.com）对主域进行分片，在这种情况下，不会在加载网页的主域中显示字体。但是，此方法具有相同的连接问题，因此即使曾经存在，也不能称为性能提升。公共CDN的另一个优点是，访问者在缓存中已经具有此版本的条件jQuery的可能性很高。但是，我再次确信这太多了。有太多的库及其版本，并且浏览器的缓存小于看起来可能的大小，因此这种匹配非常不可能。此外，出于隐私原因，Safari对访问的每个域都使用唯一的HTTP缓存（双键缓存），Chrome也会很快引入此功能。因此，没有什么可争论的了。这个话题顺利地变成了关于第三方CDN对隐私的影响的对话。您不知道他们如何以及为什么他们跟踪用户，而使用自托管解决方案则无法实现。最近的法律创新使许多站点不得不明确列出该站点上使用的所有cookie。使用第三方CDN时，这不是最简单的任务。长期以来，我一直坚信第三方CDN甚至您自己的域的分片与承诺的性能提升都相去甚远。在很多情况下，您会发现主域仅分发index.html的站点，然后浪费大量时间来浪费建立新连接的时间。更不用说从第三方站点下载资源的安全隐患。是的，这里有SRI，但它可能会导致意外的问题，老实说，我看不到这一点。如果它是静态资源（可以在其中使用SRI），则将其存储在本地；如果它不是静态资源（因为内容可能会更改），则不能使用SRI。另外，使用第三方来源的资源还会威胁到它们将成为单点故障（SPOF）并禁用您的站点。这种情况已经发生了不止一次，尽管Google字体似乎不太可能倒下，但它可能会受到公司代理或整个国家/地区的封锁。通常，越来越多的人建议将静态资源放在家里，最好是在您要从中分发网页的域上。字体是静态资源，所以同样适用于它们，对吗？好吧，事实证明，并不是所有事情都那么简单，因为字体具有其自身的特性和优化技术，这会使本地存储变得更加复杂...Google字体及其工作方式
如果您喜欢字体，那么Google字体是很棒的资源。 977种免费字体，任何人都可以免费使用。商业字体通常价格高得离谱，通常被许可而不是出售，也就是说，费用是根据预期的页面浏览量收取的。因此，在一个集合中拥有这么多免费且易于使用的字体非常有用。但这还不是全部。 Google字体与许多网站资源提供程序一样（请参见上面的jQuery示例），提供CDN并存储字体供所有人直接从其服务器使用。这意味着您可以通过简单地在站点上添加一行代码来加载样式表来开始使用字体：<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">
您还可以在一行中添加更多属性和字体，以加载几种字体和每种字体的变体：<link href="https://fonts.googleapis.com/css?family=Lato:400,400i,700,700i,900%7CPoppins:300,400,700,900&display=swap" rel="stylesheet">
缺点是性能下降（优点也在于性能，但这并不是很明显，我们将解决这个问题）。问题是您的网站（例如www.example.com）从fonts.googleapis.com加载了样式表，该样式表返回了一些带有font-facé规则的CSS。这是上面示例中链接的来源：
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjxAwXiWtFCfQ7A.woff2) format('woff2');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wXiWtFCc.woff2) format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
稍后，我们将讨论其中一些设置的含义（以及为什么会有两个字体规则），但是现在这意味着您可以按以下方式使用该字体：body {
font-family: 'Lato', sans-serif;
}
但是，现在您必须连接到fonts.googleapis.com，下载CSS，然后连接到fonts.gstatic.com并下载字体本身（为什么Google不能在同一域上同时托管CSS和字体-我真的不明白！）。浏览器通常在加载页面时会延迟检测到字体（毕竟，您需要加载CSS才能找到指向它们的链接）。但是Google字体是在以后才发现的，因为需要先从另一个域下载CSS ，然后再从第三个域下载字体，正如我提到的，建立HTTPS连接也不是立即的。这可以在下面由WebPageTest生成的级联图中看到（请注意，所有测试都是使用Chrome-3GSlow运行的）：
第1行显示HTML首先被加载。然后，只要下载并在不到2秒钟的时间内读取它，浏览器就会检测到需要加载Google Fonts CSS并将其加载到第4行中。需要一秒钟的时间建立连接，然后下载文件需要3.5秒钟。最终，浏览器发现了我们字体的存在并将其加载到第6行，在与fonts.gstatic.com进行连接的途中又损失了1¼秒。因此，使用Google字体中的这种字体会使我们从HTML可用的那一刻起就花了整整三秒钟的时间，而没有考虑下载字体本身的时间！通过预加载资源来加速Google字体
当从两个不同的域中加载CSS和字体时，可以减轻这种可怕的性能影响。第一个域（用于CSS）应位于靠近index.html文件开头的位置，以便浏览器尽快读取它，但第二个域仍处于隐藏状态。但是，我们知道该域是什么样的（fonts.gstatic.com），因此我们可以提前打开连接，以便以后在第二个连接上节省一些时间：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">
重新测试时，我们看到以下图片：
在这里，我们看到第5行的连接在加载CSS之前已预先打开。因此，我们赢得了超过一秒钟的时间（在4秒内下载字体，而不是5.25秒），因为我们设法避免在连接期间浪费时间，并且在阅读CSS Google字体后立即下载了字体。您可能会认为可以继续加载整个字体，而不是只加入域就满足了，但是Google字体将字体称为唯一哈希。在上面的示例中，下载的字体称为S6uyw4BMUTPHjx4wXg.woff2，而不是lato.woff2，因此无法进行预加载，除非您希望您的网站在Google突然决定更改此哈希值的一天崩溃。无论如何，如果您使用Google字体并且在阅读本说明后不打算做任何其他事情，请至少为该域添加一个初步连接（如果尚未连接）。这只是一行代码，它应该可以大大提高页面的性能。实际上，Google字体在呈现CSS时会在HTTP标头中提供类似的命令：
但是在许多情况下，这并没有多大帮助，因为当您从服务器收到带有CSS的HTTP响应标头时，浏览器已经知道您要连接到该域以下载字体。因此，最好在HTML代码中指定此名称，以使预加载更早地工作（以这种方式进行复制并不重要，第二次尝试将被忽略）。但是，如果在收到Google Fonts CSS服务器的标头时仍在处理您的页面，并且DOM未准备好（也许这是页面上JavaScript过多的迹象？），这最终可以帮助提高性能。要下载哪种字体。字体显示：交换
在上面的字体代码中，您可以看到font-display：swap;行。这是一个相对较新的说明。可以将其添加到字体声明中，并告诉浏览器先使用后备广告，即系统字体（在本示例中为sans-serif），然后在下载后将其替换为真实字体。这样，您可以避免在尚未加载字体时延迟加载内容，并可以很好地提高性能。是的，这会导致显示不稳定文本（FOUT）-在页面加载期间内容出现相同的“跳跃”，但是有些人不喜欢它（我的观点是同意，内容比样式更重要，但是跨页面跳转的文本很烦人可以通过调整备用字体来缓解这种情况。另一种选择是Flash不可见文本（FOIT）。在这种情况下，文本将一直隐藏，直到出现字体为止，这显然会延迟下载，并且如果加载了某些文本，可能会导致其他问题，而有些则不会！无论如何，在引入字体显示：交换之前，不同的浏览器对此进行了不同的处理-某些浏览器（例如IE和Edge）使用FOUT，另一些使用FOIT，并且它们等待字体等待的时间不同。因此，如果未加载字体，您的内容可能会长时间保持不可见。字体显示的介绍：交换使网站开发人员可以自己决定如何进行。大多数浏览器都支持字体显示：交换，除了IE和Edge，但如上所述，它们仍然默认使用该字体。 Google字体还支持各种字体显示选项，并提供字体显示：默认情况下进行交换。因此，如果您使用Google字体，另一个技巧是检查URL中是否具有＆display = swap参数，如果没有（最近才支持），则添加它：例如，替换为：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
在此：
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">
如果愿意，
还可以指定其他字体显示值之一，例如optional。不幸的是，这只能解决一半的问题。该说明位于CSS中，它返回Google字体，因此仅在下载CSS文件后才有用。因此，在加载字体本身时，它有助于解决延迟，但是在等待加载此CSS时，它无济于事。因此，这是一个很好的改进（至少对于那些喜欢FOUT的人来说），但仍然不是整个解决方案的整体。Google Fonts
我帮助创建了Web Almanac（对互联网状况的绝佳观察- 如果您还没有看到它，请亲自看看），并且在我们网站上缓慢下载Google字体使我很烦，我想修复它。特别是带有字体显示的FOUT：交换。我想知道我们是否可以减少这种影响，而本地解决方案似乎是在本地存储文件，可能使用预加载功能。我们已经使用了上述技术（预加载和字体显示：swap;），但是，当然，最好不要从外部连接CSS。我们知道此CSS中的内容。那么，自信地选择自我托管吗？这是有趣的地方。我在GitHub上找到了一个方便的脚本（Google字体下载），这帮助我下载了所有不同的字体选项（因为有很多字体选项，最多取决于页面9个），然后复制了CSS（显示在我们的主样式表中）并将字体上传到服务器。还有其他在线工具也可以这样做。一切似乎都可行，我们摆脱了烦人的CSS加载以及使用两个域的需求。但是，仔细检查后，我发现字体较大：
如您所见，与下载的Google字体（右）和本地放置的字体（左）相比，字体的大小已显着增加（其中某些字体增加了74％！）。最初，我认为这是由于我的本地Web服务器造成的，例如，由于关闭了压缩功能。但是WOFF2字体在没有压缩的情况下可以提供服务，或者至少应如此，因为该格式包括Brotli压缩。另外，上面的屏幕截图显示了下载的字节（顶部为黑色）以及每列的未压缩字节（底部略浅）（两列中的内容都非常相似，因为字体实际上是由Web服务器不经压缩发送的，但是下载的字节包含HTTP标头，因此它们要大一些），并且压缩字节和未压缩字节都有差异，所以这不是重点。使用该工具获得的字体规则与原始规则进行比较，发现有一个区别：与Google字体相比：
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjxAwXiWtFCfQ7A.woff2) format('woff2');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wXiWtFCc.woff2) format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
通过下载工具：@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
src:
local('Lato Regular'),
local('Lato-Regular'),
url('Lato_400.woff2') format('woff2'),
url('Lato_400.woff') format('woff');
}
第一个区别是我们丢失了font-display：交换行，但是可以毫无问题地解决此问题。更有趣的是，Google字体会分发两种字体-并在其中包含不同的Unicode范围。这是由于字体子设置并减少了字体文件。字体子集
字体子集是删除将不用于减小字体文件大小的字符。通常，大多数西方人仅使用拉丁字符，而下载可能不使用的所有字符的字体是不合理的。我以前曾听说过此消息，但我从未想到这可能有多重要！ Google字体会自动呈现带有一组拉丁字符的字体，并且在可能的情况下，还为扩展的拉丁字符（例如Ā）连接第二种字体，只有在必要时才会下载。实际上，您还可以请求特殊字体，该特殊字体仅包含需要使用text参数的那些字符：https : //fonts.googleapis.com/css?family=Lato& text=ABC从进一步的观察来看，我使用的字体加载工具显然支持字体子集，但仅适用于整个“语言”（拉丁语或扩展拉丁语），并且它将字符的两个子集组合到一个文件中。最后，我返回到浏览器使用的版本，并停止使用此工具。这提供了相似的文件大小（由于我的开发环境中的HTTP标头而略有差异），但是我很快发现它不仅仅是字体子集。Google字体可巧妙地分配字体
Google字体并不总是呈现相同的CSS，它取决于使用的用户代理。例如，对于Internet Explorer 11，它将发送以下信息：@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wWA.woff) format('woff');
}
可以看出，由于IE 11 不支持WOFF2，因此它仅提供WOFF格式，并且出于相同的原因，未指定unicode-range。它提供了font-display：swap（如我在CSS URL中指出的那样），尽管浏览器不支持它，但是它没有害处。不仅仅是浏览器的制造商和版本。字体提示在字体文件中包含其他说明，这些说明随后用于提供字体的最佳显示-特别是在低分辨率屏幕上或非常小的尺寸上。字体提示是在Windows上使用的，而不是在MacOS上使用的，因此，根据接收Google字体时使用的操作系统，使用浏览器（即使在每个平台上都使用Chrome），可能会获得带有提示或没有他。如果您下载Windows版本并自己使用，则实际上会使MacOS用户遭受处理未使用提示的大字体文件的困扰，反之，则有可能使Windows用户遭受字体显示不佳的困扰，没有字体提示。当我使用Google字体以及下载字体供本地使用时，我是在Mac上完成的，因此文件较小。使用该工具时，我得到了带有提示的完整字体。因此，这是尺寸差异很大的另一个原因！字体提示是否仍然有用，因为高清屏幕已经变得越来越普遍-这是一个很好的问题，许多字体最初交付时都没有提示，因为创建它需要很多时间。如果存在-它可以显着增加字体大小。如果是Lato，大小会增加一倍。放弃Google字体并在本地定位字体是否值得您承担额外的工作量？这是您需要自己做出的另一个决定。因此，智能字体支持Google字体CDN，该脚本会给出最合适的字体，并对其进行优化以保持最佳性能。切换到字体的本地存储，您将必须自己配置所有这些内容，否则可能会丢失某些浏览器中字体的正确显示。对于Web Almanac，我们查看了访问者浏览器的统计信息，并决定仅支持WOFF2，并且还使用了MacOS版本，而没有暗示，因为它们的重量仅为后者的一半。此简化的CSS（尤其是因为所有支持WOFF2的浏览器都支持unicode-range），并且IE 11和其他旧版浏览器的用户默认情况下会看到sans-serif，虽然看起来不太好，但是我们认为字体是一种渐进的改进，即使没有字体，该网站也仍然无法使用。此外，较旧的浏览器甚至可能会受益于使用系统默认字体，因为它们可能会在较旧的低功耗计算机上使用。如果需要，您还可以对字体进行其他调整（请先检查许可证！），但是如果您只想支持WOFF2浏览器而不提示，那么复制MacOS上的Chrome中使用的默认Google字体对于我们大多数人来说可能就足够了。不过，如果我们选择使用Google字体，那么我们将拥有WOFF（甚至更旧的格式）并在必要时进行提示，而无需根据浏览器进行深入配置来替换正确的字体。因此，将Google字体用于字体仍具有某些优势，选择本地存储会拒绝它们。这也适用于将来对Google字体的所有增强。未来字体增强
由于我研究了字体主题，并警告说，如果转到本地存储，您将来可能会失去Google字体的任何好处，所以我想稍微偏离主要主题，并谈论我发现的其他有趣的事情。字体世界即将发生的重大变化是什么？嗯，目前正在积极讨论两项更改，这些更改可能会影响将来的字体（因此，Google字体可能会支持该更改，如果您选择使用此服务，则可能默认情况下）：可变字体和渐进式字体丰富。可变字体
可变字体使您可以使用不同的字体样式，而不必下载单个文件。我之前提到过，Web年鉴最多使用9种不同的字体文件，但实际上，它只有2种字体。原因很简单-网站也使用其中一种或两种的粗体，斜体，粗体，甚至更薄的版本。这么多相同字体的变体似乎不合适，您可能会认为浏览器本身可以应对更改文本粗细或斜体的任务。是的，有可能。但是每个浏览器的执行方式都略有不同，结果可能会大不相同，因此许多人将其称为“人造字体”。确保相同显示的唯一方法是专门针对所需的每种样式使用“真实字体”。可变字体使各种字体变体的显示标准化，并且不再需要其他文件。从理论上讲，当它们的可变字体版本可用时，我们可以将这9种字体替换为2种。这为在Internet上使用字体开辟了许多可能性。尽管在我看来这两种字体的9个选项太多了，但实际上并不是太多，而可变字体将允许无穷的变化。在移动设备上，可以为“粗体”设置与在台式机和平板电脑上略有不同的厚度。带有一些简单CSS指令的可变字体允许这样做而无需花费资源来下载其他字体。最近在DotCSS上， Jason Pamental讨论了可变字体，并演示了如何使用似乎有很多不同的字体来获得设计精美的页面-全部都使用一个文件！使用可变字体还意味着同时加载所有字体变体，避免了前面提到的问题引起的混乱。这也导致更少的布局重绘：如果没有可变字体，浏览器将在每次加载各个字体变体时一次又一次地重绘页面。可变字体有很好的支持在现代浏览器中，但它们的缺点是尺寸过大，因为存储不同的字体变体需要更多的空间，就像字体提示一样。它取决于字体，但是压缩后通常它们的大小是字体的两倍，因此要证明其合理性，您至少需要两种样式。即使这样，您最好还是选择上传一个较小的文件来显示关键文本，而不是选择一个较大的文件来显示所有文本。再一次，可以使用font-display：swap成为问题较少的解决方案吗？这由每个网站所有者决定！渐进式字体丰富
从本质上讲，“ 渐进式字体丰富”将子集提升到一个新的水平，并允许您根据需要以附加信息流的形式下载附加字符定义，这些附加信息流是对当前加载的字体的补充，但不添加附加字体。对于我们西方人来说，这似乎是一个很小的优势，但是对于其他语言-特别是在远东地区-字体文件可能非常庞大（例如2Mb），因为这些语言中的字符数量很大。因此，网络字体在此类国家/地区不太常用，并且渐进式字体丰富可以对这种情况产生积极影响。据我了解，渐进式字体富集比可变字体要早得多，但是有在线演示。无论如何，这是与字体相关的另一个潜在有趣的变化。Google字体会继续改进吗？
鉴于Google字体的工作原理，不难想象它可以通过新的增强功能（如本文所述（或许多其他功能！）中所述的增强功能）继续发展，只需更改您提供的CSS。而且他可以明智地做到这一点。例如，确定您的浏览器是否支持新技术（现在使用字体格式-WOFF或WOFF2），或通过其他方式。例如，如果您要求使用两种以上的字体，并为可变字体提供较少的资源占用，则可以在多个字体广告中自动执行并链接到同一字体文件；如果您仅请求一种选项，则引用一个更轻量的选项，传统字体。听起来牵强？他们已经用一种字体做到了。（奥斯瓦尔德）！老实说，我不知道渐进式字体丰富技术是否可以做到这一点，因为我还不完全了解它的工作原理，但是很有趣。另外，值得一提的是，使用Google字体，例如在更新字体时（例如，添加新的字符集或纠正字形中的错误），您会自动获得新的字体。对于本地存储，这将不起作用-至少在没有单手干预的情况下是无法实现的。也许您可以考虑通过域代理请求的方向，从而充分利用这两种选择，但这很可能会变慢，并且需要其他配置和管理。另一方面，本地存储可提供稳定性，因为某些更新可能会影响您的设计，例如，如果一行中的标题由于字体更改而开始扩展为两个，则可能会影响设计。有一个人因为这个而感到非常沮丧本地字体存储的好处
因此，我们讨论了很多理论，尽管本地存储有明显的潜在好处，但也有很多困难需要考虑，因此使用Google字体也有一些明显的好处。那么自我托管值得吗？这取决于特定情况下的实际便利设施。如果性能差异不明显，则可能值得继续使用较大的Google字体。对于Web Almanac，我们最近选择了 Google Fonts 本地存储，并且测试显示出巨大的变化：
下部图像包含我们测试服务器上的本地字体，您可以看到下载时间减少了一半-从6到3秒！经过更深入的分析，我发现生产率提高了更多（节省了3秒的时间）！不太明显的内容（但稍后我们会看到）-此时，字体未完全加载到任何图像上-使用Google字体时，本地存储需要7.5秒和10.5秒。但是，所使用的字体与标准字体非常相似，并且布局上没有明显的跳跃。可以在下图中看到：
该图显示带有本地存储（红色）的页面在2.4秒内几乎完全加载，然后在加载图像时又更新了几次，此后还显示了字体。是的，我想使一切变得更加流畅，但是仍然无法优化一些字体下载成本。改进确实是切实可行的，是因为我最初没有考虑的另一件事：CSS块渲染。因此，如果有指向Google Fonts CSS的链接，则浏览器不仅会延迟文本的显示-还会延迟页面整个内容的显示！字体是一种渐进的改进，因此我们可以安全地呈现页面的其余部分，甚至可以显示文本本身（使用标准/后备字体），但浏览器却不行-它只是看到有一些CSS并尝试加载它，因此推迟了下载页面的其余部分。CSS没有异步加载-但也许应该是这种情况？但是，如果在连接到Google字体时出现问题，我们将冒着风险，直到浏览器停止尝试处理链接之前，您整个网站都将无法访问！
在上面的比较表中，垂直的绿色线条“开始渲染”最早出现在6秒内-因为它必须等到Google Fonts CSS加载到第12行时，才花费一半的时间连接到域，而另一半则实际加载。将其与本地版本进行比较：
在这里，我们可以在2.5秒内加载并处理站点的CSS后立即开始渲染。这是因为连接到Google字体域没有延迟。在这两种情况下，我们都看到渲染的开始发生在加载字体之前，并且由于字体显示的神奇作用：交换，文本仍然可见。因此，至少在使用font-display：swap时，最好不要使用CSS阻止渲染来加载Google字体，例如，通过异步JavaScript来加载，该异步JavaScript仅将CSS字体插入页面后如何下载它们。如果以这种方式实现该过程，则不会发生渲染延迟，但是，连接时仍然存在延迟，并且需要长时间等待正确显示文本。UPD：我在GitHub Google Fonts上创建了一个问题，建议添加一种下载Google Fonts而不阻塞渲染的方法-如果您也愿意的话，请投票！Zach Leatherman提倡使用这种方法来减少重绘次数，并表明仅使用JavaScript也是可能的，而无需CSS文件。然后，它显示了使用JavaScript管理字体的其他优点，例如，如果站点从慢速网络打开（使用Network Information API），或者如果用户启用了“ 保存数据”或“ 首选减少运动”设置，则可以完全拒绝下载字体。有趣的功能！预加载字体
离开Google的哈希网址后，您就可以预先加载字体，以进一步提高性能。但是，此选项有一些潜在的缺陷，正如Andy Davies在文章Preloading Fonts and Priority of Priority中讨论的那样。基本上，通过预加载字体并按优先级顺序将它们上移，可以隐式降低其他重要下载文件（例如CSS）的优先级，并且由于Chrome中的错误，字体甚至可以跳到某些字体之上。此外，在不使用字体时进行预加载会导致不必要的过度加载-例如，如果存在本地版本并且可以优先使用，或者浏览器不支持此字体格式（尽管所有支持预加载的浏览器也都支持WOFF2 ）除了建议使用预加载功能外，Google显然会警告您这一点，很高兴看到他们对此有所注意。使用font-display：swap功能时，对预加载的需求可能不那么强烈。尽管在这种情况下，您仍然可以通过下载所需的最少字体数目并避免FOUT和重绘来节省时间。目前，我们没有在Web年鉴中使用预加载功能，在开始之前，我们还需要进行一些测试，但是现在我对这感到满意。结论
在文章标题中回答一个问题：是的，值得，因为它可以显着提高性能。当然，您的结果可能会有所不同，因为这都取决于特定的站点，因此请再次进行测试，测试和测试。但是，我认为，就大多数网站而言，就性能而言，这仍然是最佳选择。但是，Google字体不仅是数百种免费字体的存储库，而且还是一种智能的传递机制，它使用许多最新的优化技术来以最小的网站所有者的精力呈现最合适的字体。切换到自托管，理想情况下，您应该重新实现许多有用的改进，例如字体显示：交换，删除字体提示（至少对于某些浏览器而言），否则，您只能损害笨拙的性能。字体文件。这不是一件容易的事（是的，Google Fonts为您做到了）。但是，由于现在仅使用WOFF2格式是唯一可行的选择，并且浏览器很好地支持大多数优化技术，因此一切都比以前容易得多。不过，在进行所有设置之前，有必要先了解一下网络字体（我希望这篇文章对您有所帮助！），同时请密切关注字体领域的新变化，因为毫无疑问，还会有进一步的改进。好吧，也许我们过于热衷于优化，并且借助本地存储，我们有能力使用完整的字体，而无需子集和提示？在Google字体网站上，您可以下载任何字体，并且它相对简单，尽管存档中不包含WOFF和WOFF2格式很奇怪使用这种加载方法时，这是我完全无法理解的！但是，如果您真的对提高性能感兴趣（并且应该感兴趣！），那么您应该尝试做正确的事情。本文仅显示，它比我一直期望的那样，不仅仅是下载字体并将其放置在您的网站上要复杂得多。哇，有些文字竟然比我预期的要长！但是，我希望您和现在一样对理解该主题感兴趣，并且您现在有了一些新思路可以加快网站上字体的下载。我强烈建议您在Twitter上关注Jason和Zach以了解有关字体的更多信息，而Andy可以了解有关Web应用程序整体速度的更多信息。