什么时候使用 rel="preload"？为什么预加载 fonts/FontAwesome 是个好主意？
When to use rel="preload"? Why is preloading fonts/FontAwesome a good idea?
我得到了这个推荐，Google Pagespeed：
'learn more'-link 导致 404。
我试着弄清楚，为什么这应该能帮我节省 7.08 秒，但找不到。
我假设在页面上加载 10 个图标是最后的优先事项？！图像、其他字体和脚本不是更重要吗？
或者以某种方式拖延了一些事情，这些字体没有加载？
我可以在网络选项卡中看到，如果我这样加载字体：
<link rel="preload" href="css/fontawesome.css" as="style" onload="this.rel='stylesheet'">
...也就是说（足够真实）成为优先事项并在任何其他事情之前加载。但我真的想要那样吗？
更新
我知道这可以解释为 SEO 问题，因为它源自 Google Pagespeed。但事实并非如此。这是一道 'How to build a good website' 题。在 Google 上的排名无关紧要。现场体验很重要。
如果你使用@font-face加载字体，你会经常看到这个推荐。
要了解为什么会收到此建议，您必须考虑浏览器如何接收和解析信息。
- HTML 已下载，浏览器会查看在 HTML 中找到的所有要下载的资产，然后开始下载并解析它们。
- 浏览器发现 CSS 文件并下载。下载并解析 CSS 文件后，您的浏览器会找到对 'font-awesome' 字体的引用，然后将其添加到要下载的内容列表中。
- 浏览器下载该字体，但比需要的晚很多。
通过将 preload 添加到项目中，您的订单首先更改为 HTML，然后是 CSS 和 font-awesome 字体，这意味着更早加载关键资产.
为什么这很重要？
要了解为什么这很重要，您需要了解 'critical requests' - 这些是呈现 'above the fold' 内容所需的所有资产。
首屏内容是您无需滚动页面即可看到的内容。
现在，如果您在此 'above the fold' 内容中显示 任何 图标，那么您的超棒字体将成为您 'critical request chain' 的一部分 - 即内容必须在首屏上绘制所有内容。
通过使用 preload，您可以更快地获得字体（2 步而不是之前所示的 3 步），因此您的首屏内容可以更快地呈现，因此您的网站 出现 加载速度更快 - 这是 PSI 评分和实际转化率提高的主要因素。
那我应该使用 rel="preload" 吗？
在大多数情况下，是的，如果推荐的话，您应该这样做，它会减少您的关键请求链深度，并且通常会导致更快的加载时间。但是，您确实需要检查您的关键请求链以确保它不是误报（PSI 并不完美）。
最简单的检查方法是打开开发人员工具，在网络选项卡上启用 3G 限制，然后查看页面 显示 是否更快 preload。
对于问题中给出的场景，这是我的最佳选择吗？
在这个例子中，没有，但这只是因为 font-awesome 通常不是一个好主意。
您真正想要做的是完全摆脱 font-awesome。图标字体是我们 Web 开发人员采用的一种过时且糟糕的做法，它不会消失。
为什么不加载 50kb 以上的文件（对于您使用的每个 'weight' 超赞字体）加上 30kb CSS 为什么不使用内联 SVG。
内联 SVG 有 several advantages，但关键的是：-
- 因为它们内嵌在 HTML 中，所以您至少要删除 一个网络请求（通常为 2-3）- 非常适合速度。
- 它们很小 - 一个典型的图标解压后不到 1kb - 你说你使用的 10 个图标在压缩前总共 10kb。将其与 180kb zipped font-awesome 字体、CSS 等进行比较，您可以看到性能改进。
- 由于您在 HTML 中内嵌了图标，因此减少了 'critical request chain' 长度，因此您可以在不到 1 秒的时间内完成初始页面呈现（显然，您需要内嵌所有关键 CSS 上面的折叠也是必需的。）
- 最重要的原因 - 人们在您的网站上使用自定义样式表。例如，有阅读障碍的人可能更喜欢某种字体，因为它更容易阅读，因此他们可能会强制网站使用该字体。你美丽的 'font icons' 变成了可怕的 'missing character square box of doom' - 这使得很难知道他们点击了什么。辅助功能变得越来越重要！
Note on point 2 - the reason icon fonts are so large is they contain hundreds of icons. It is possible to reduce them to be slightly smaller that inline SVGs but that kind of optimisation often gets over-looked and is actually more time consuming than simply inlining and referencing SVGs. I just thought I would add this for completeness.
我得到了这个推荐，Google Pagespeed：
'learn more'-link 导致 404。 我试着弄清楚，为什么这应该能帮我节省 7.08 秒，但找不到。
我假设在页面上加载 10 个图标是最后的优先事项？！图像、其他字体和脚本不是更重要吗？
或者以某种方式拖延了一些事情，这些字体没有加载？
我可以在网络选项卡中看到，如果我这样加载字体：
<link rel="preload" href="css/fontawesome.css" as="style" onload="this.rel='stylesheet'">
...也就是说（足够真实）成为优先事项并在任何其他事情之前加载。但我真的想要那样吗？
更新
我知道这可以解释为 SEO 问题，因为它源自 Google Pagespeed。但事实并非如此。这是一道 'How to build a good website' 题。在 Google 上的排名无关紧要。现场体验很重要。
如果你使用@font-face加载字体，你会经常看到这个推荐。
要了解为什么会收到此建议，您必须考虑浏览器如何接收和解析信息。
- HTML 已下载，浏览器会查看在 HTML 中找到的所有要下载的资产，然后开始下载并解析它们。
- 浏览器发现 CSS 文件并下载。下载并解析 CSS 文件后，您的浏览器会找到对 'font-awesome' 字体的引用，然后将其添加到要下载的内容列表中。
- 浏览器下载该字体，但比需要的晚很多。
通过将 preload 添加到项目中，您的订单首先更改为 HTML，然后是 CSS 和 font-awesome 字体，这意味着更早加载关键资产.
为什么这很重要？
要了解为什么这很重要，您需要了解 'critical requests' - 这些是呈现 'above the fold' 内容所需的所有资产。
首屏内容是您无需滚动页面即可看到的内容。
现在，如果您在此 'above the fold' 内容中显示 任何 图标，那么您的超棒字体将成为您 'critical request chain' 的一部分 - 即内容必须在首屏上绘制所有内容。
通过使用 preload，您可以更快地获得字体（2 步而不是之前所示的 3 步），因此您的首屏内容可以更快地呈现，因此您的网站 出现 加载速度更快 - 这是 PSI 评分和实际转化率提高的主要因素。
那我应该使用 rel="preload" 吗？
在大多数情况下，是的，如果推荐的话，您应该这样做，它会减少您的关键请求链深度，并且通常会导致更快的加载时间。但是，您确实需要检查您的关键请求链以确保它不是误报（PSI 并不完美）。
最简单的检查方法是打开开发人员工具，在网络选项卡上启用 3G 限制，然后查看页面 显示 是否更快 preload。
对于问题中给出的场景，这是我的最佳选择吗？
在这个例子中，没有，但这只是因为 font-awesome 通常不是一个好主意。
您真正想要做的是完全摆脱 font-awesome。图标字体是我们 Web 开发人员采用的一种过时且糟糕的做法，它不会消失。
为什么不加载 50kb 以上的文件（对于您使用的每个 'weight' 超赞字体）加上 30kb CSS 为什么不使用内联 SVG。
内联 SVG 有 several advantages，但关键的是：-
- 因为它们内嵌在 HTML 中，所以您至少要删除 一个网络请求（通常为 2-3）- 非常适合速度。
- 它们很小 - 一个典型的图标解压后不到 1kb - 你说你使用的 10 个图标在压缩前总共 10kb。将其与 180kb zipped font-awesome 字体、CSS 等进行比较，您可以看到性能改进。
- 由于您在 HTML 中内嵌了图标，因此减少了 'critical request chain' 长度，因此您可以在不到 1 秒的时间内完成初始页面呈现（显然，您需要内嵌所有关键 CSS 上面的折叠也是必需的。）
- 最重要的原因 - 人们在您的网站上使用自定义样式表。例如，有阅读障碍的人可能更喜欢某种字体，因为它更容易阅读，因此他们可能会强制网站使用该字体。你美丽的 'font icons' 变成了可怕的 'missing character square box of doom' - 这使得很难知道他们点击了什么。辅助功能变得越来越重要！
Note on point 2 - the reason icon fonts are so large is they contain hundreds of icons. It is possible to reduce them to be slightly smaller that inline SVGs but that kind of optimisation often gets over-looked and is actually more time consuming than simply inlining and referencing SVGs. I just thought I would add this for completeness.