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

Question

我在 Google Pagespeed 中得到了这个推荐：

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

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

或者以某种方式拖延某些事情，导致这些字体未加载？

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

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

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

更新

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

Answer 1

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

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

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

为什么这很重要？

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

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

现在，如果您在此“首屏”内容中显示任何图标，那么您的超棒字体将成为“关键请求链”的一部分，即绘制首屏所有内容所必需的内容。

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

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

最简单的检查方法是打开开发人员工具，在网络选项卡上启用 3G 限制，然后查看是否使用或不使用preload.

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

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

为什么不使用内联 SVG 来代替加载 50kb 以上的文件（对于您使用的 font-awesome 的每个“重量”）加上 30kb 的 CSS 呢？

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

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

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