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

Question

我在 Google Pagespeed 中收到了这条建议：

---

---

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

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

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

---

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

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

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

---

更新

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

Answer 1

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

要了解您获得此建议的原因，您必须考虑浏览器如何接收和解析信息。

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

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

为什么这很重要？

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

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

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

通过使用preload，您可以更快地获得字体（2 步而不是前面所示的 3 步），因此您的首屏内容可以更快地呈现，因此您的网站似乎加载速度更快 -这是 PSI 评分和实际转化率提高的主要因素。

那我应该使用 rel="preload" 吗？

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

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

对于问题中给出的场景，这是我的最佳选择吗？

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

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

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

内联 SVG 有 several advantages，但关键是：-

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

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