css - 何时使用 rel="preload"？为什么预加载字体/FontAwesome 是个好主意？

我在 Google Pagespeed 中得到了这个建议：

“了解更多”链接指向 404。我试图弄清楚，为什么这应该为我节省 7.08 秒，但找不到。

我会假设在页面上加载 10 个图标将是最后的优先事项？！图像、其他字体和脚本不是更重要吗？

或者以某种方式拖延了一些东西，这些字体没有加载？

我可以在我的网络选项卡中看到，如果我这样加载字体：

<link rel="preload" href="css/fontawesome.css" as="style" onload="this.rel='stylesheet'">

...也就是说（足够真实）成为优先事项并在任何其他事情之前被加载。但我真的想要吗？

更新

我知道这可以解释为 SEO 问题，因为它来自 Google Pagespeed。但事实并非如此。这是一个“如何建立一个好的网站”的问题。在 Google 上排名无关紧要。现场体验很重要。

标签： csspagespeedgoogle-pagespeed

如果您使用@font-face加载字体，您会经常看到此建议。

要了解为什么您会收到此建议，您必须考虑浏览器如何接收和解析信息。

HTML 被下载，浏览器查看所有资产以下载它在 HTML 中找到并开始下载和解析它们。
浏览器发现一个 CSS 文件并下载它。当该 CSS 文件已下载并被解析后，您的浏览器会找到对您的“font-awesome”字体的引用，然后将其添加到要下载的内容列表中。
浏览器下载该字体，但比需要的要晚很多。

通过添加preload项目，您的订单首先会更改为 HTML，然后是 CSS 和 font-awesome 字体，这意味着更早地加载了关键资产。

为什么这很重要？

要了解为什么这很重要，您需要了解“关键请求”——这些是呈现“首屏”内容所需的所有资产。

首屏内容上方是您无需滚动页面即可看到的内容。

现在，如果您在此“首屏”内容中显示任何图标，那么您的字体真棒字体将成为您的“关键请求链”的一部分 - 即对于在首屏上绘制所有内容至关重要的内容。

通过使用preload，您可以更快地交付字体（2 个步骤而不是前面所示的 3 个步骤），因此您的首屏内容可以更快地呈现，因此您的网站似乎加载得更快 - 这是 PSI 评分和现实世界转换的主要因素率改进。

在大多数情况下是的，如果被推荐，你应该这样做，它会减少你的关键请求链深度，通常会导致更快的加载时间。但是，您确实需要检查您的关键请求链以确保它不是误报（PSI 并不完美）。

最简单的检查方法是打开开发人员工具，在网络选项卡上启用 3G 限制，然后查看页面是否显示更快preload。

在这个例子中，没有，但只是因为 font-awesome 通常不是一个好主意。

你真正想做的是完全摆脱 font-awesome。Icon Fonts 是我们 Web 开发人员采用的一种过时且糟糕的做法，并且不会消失。

与其加载一个 50kb+ 的文件（对于您使用的字体的每个“权重”）加上 30kb 的 CSS，为什么不使用内联 SVG。

内联 SVG 有几个优点，但关键是：-

由于它们在 HTML 中内联，因此您至少删除了一个网络请求（通常为 2-3 个）- 非常适合速度。
它们很小——一个典型的图标解压后不到 1kb——你说你使用的 10 个图标在压缩前总共有 10kb。将其与 180kb压缩的 font-awesome 字体、CSS 等进行比较，您可以看到性能提升。
当您在 HTML 中内联图标时，您会减少“关键请求链”的长度，因此您可以获得不到 1 秒的初始页面渲染（显然您还需要内联上述折叠所需的所有关键 CSS。 )
最重要的原因- 人们在您的网站上使用自定义样式表。例如，患有阅读障碍的人可能更喜欢某种字体，因为它更容易阅读，因此他们可能会强制网站使用该字体。你漂亮的“字体图标”变成了可怕的“厄运的失踪字符方块”——这让你很难知道他们在点击什么。可访问性变得越来越重要！

请注意第 2 点 - 图标字体如此之大的原因是它们包含数百个图标。可以将它们减少到比内联 SVG 略小，但这种优化经常被忽视，实际上比简单内联和引用 SVG 更耗时。我只是想为了完整起见我会添加这个。