何时使用 rel="preload"?为什么预加载字体/FontAwesome 是个好主意? [英] When to use rel="preload"? Why is preloading fonts/FontAwesome a good idea?
问题描述
我在 Google Pagespeed 中得到了这个推荐:
<小时><小时>'了解详情'-链接指向404.我试图弄清楚为什么这应该为我节省 7.08 秒，但找不到.
我认为在页面上加载 10 个图标是最后的优先事项?！图像、其他字体和脚本不是更重要吗?
或者以某种方式拖延了一些东西，这些字体没有加载?
<小时>我可以在我的网络选项卡中看到，如果我这样加载字体:
<link rel="preload" href="css/fontawesome.css" as="style" onload="this.rel='stylesheet'">
...也就是说(足够真实)成为优先事项并在任何其他事情之前加载.但我真的想要那个吗?
<小时>更新
我知道这可以解释为 SEO 问题，因为它起源于 Google Pagespeed.但事实并非如此.这是一个如何建立一个好的网站"的问题.在 Google 上的排名并不重要.网站上的体验很重要.
如果你使用 @font-face 加载字体，你会经常看到这个建议.
要了解为什么会收到此建议，您必须考虑浏览器如何接收和解析信息.
- HTML 已下载，浏览器会查看 HTML 中找到的所有要下载的资源，然后开始下载和解析它们.
- 浏览器发现一个 CSS 文件并下载它.下载并解析该 CSS 文件后，您的浏览器会找到对font-awesome"字体的引用，然后将其添加到要下载的内容列表中.
- 浏览器下载该字体，但比需要的时间晚很多.
通过向项目添加 preload，您的订单将首先更改为 HTML，然后是 CSS 和 font-awesome 字体，这意味着提前加载了关键资产.
为什么这很重要?
要理解为什么这很重要，您需要了解关键请求"——这些是呈现首屏"内容所需的所有资产.
首屏内容是您无需滚动页面即可看到的内容.
现在，如果您在此首屏"内容中显示任何图标，那么您的字体真棒字体将成为您关键请求链"的一部分 - 即对于绘制上面的所有内容必不可少的内容折叠.
通过使用 preload，您可以更快地交付字体(2 个步骤，而不是前面所示的 3 个步骤)，因此您的首屏内容可以更快地呈现，因此您的网站出现 加载速度更快 - 这是 PSI 评分和实际转化率改进的主要因素.
我应该使用 rel="preload" 吗?那么?
在大多数情况下，如果推荐，您应该这样做，它会减少您的关键请求链深度，并且通常会导致更快的加载时间.但是，您确实需要检查您的关键请求链，以确保它不是误报(PSI 并不完美).
最简单的检查方法是打开开发者工具，在网络选项卡上启用 3G 节流，然后查看页面在使用或不使用 预加载 的情况下显示是否更快.
对于问题中给出的场景，这是我的最佳选择吗?
在这个例子中，没有，只是因为字体很棒一般不是一个好主意.
您真正想做的是完全摆脱 font-awesome.图标字体是我们 Web 开发人员采用的一种过时且可怕的做法，而且不会消失.
与其加载 50kb 以上的文件(对于您使用的字体的每个重量")加上 30kb 的 CSS，为什么不使用内联 SVG.
内联 SVG 具有 几个优点，但关键是:-
- 因为它们被内联在 HTML 中，所以您至少会删除一个网络请求(通常为 2-3 个)- 速度非常快.
- 它们很小 - 一个典型的图标解压缩后不到 1kb - 有 10 个你说你使用的图标，在压缩前总共 10kb.将其与 180kb 压缩 的超赞字体、CSS 等文件进行比较，您可以看到性能提升.
- 当您在 HTML 中内联图标时，您减少了关键请求链"的长度，因此您可以将初始页面渲染时间缩短到 1 秒(显然，您需要内联以上折叠所需的所有关键 CSS也一样.)
- 最重要的原因 - 人们在您的网站上使用自定义样式表.例如，有阅读障碍的人可能更喜欢某种字体，因为它更容易阅读，因此他们可能会强制网站使用该字体.你漂亮的字体图标"变成了可怕的厄运的缺失字符方框"——这使得很难知道他们在点击什么.可访问性变得越来越重要！
<块引用><块引用>
注意第 2 点 - 图标字体如此大的原因是它们包含数百个图标.可以将它们减少到比内联 SVG 稍小一些，但这种优化经常被忽视，实际上比简单地内联和引用 SVG 更耗时.我只是想我会添加这个以保持完整性.
I got this recommendation, in Google Pagespeed:
The 'learn more'-link leads to 404. I tried figuring out, why this is supposed to save me 7.08 seconds, but can't find it.
I would assume that loading 10 icons on a page would be the very last priority?! Isn't images, other fonts and scripts more important?
Or is somehow stalling something, that these fonts aren't loaded?
I can see in my Network-tab, that if I load the fonts as such:
<link rel="preload" href="css/fontawesome.css" as="style" onload="this.rel='stylesheet'">
... that is (true enough) becomes a priority and gets loaded before any other thing. But do I really want that?
UPDATE
I know that this can be interpreted as an SEO-question, since it origins from Google Pagespeed. But it's not. It's a 'How to build a good website'-questions. Ranking on Google doesn't matter. The experience on the site matters.
You will often see this recommendation if you use @font-face to load fonts in.
To understand why you get this recommendation you have to consider how the browser receives and parses information.
- HTML is downloaded, browser looks at all the assets to download it found in the HTML and starts downloading them and parsing them.
- The browser discovers a CSS file and downloads it. When that CSS file has downloaded and been parsed your browser finds a reference to your 'font-awesome' font and then adds that to the list of things to download.
- The browser downloads that font, but a lot later than it is needed.
By adding preload to the item your order changes to HTML first, then CSS and the font-awesome font at the same time, meaning a key asset is loaded earlier.
Why is this important?
To understand why this is important you need to understand 'critical requests' - those are all the assets required in order to render the 'above the fold' content.
Above the fold content is content you can see without scrolling the page.
Now if you have any icon showing in this 'above the fold' content then your font-awesome font becomes part of your 'critical request chain' - i.e. content that is essential to paint everything above the fold.
By using preload you get the font delivered sooner (2 steps not 3 as illustrated earlier), so your above the fold content can be rendered sooner and so your site appears to load faster - this is a major factor in PSI scoring and real-world conversion rate improvements.
Should I use rel="preload" then?
In most circumstances yes you should if it is recommended, it reduces your critical request chain depth and normally results in faster loading times. However you do need to check your critical request chain to ensure it isn't a false positive (PSI isn't perfect).
The easiest way to check is to open developer tools, enable 3G throttling on the network tab and then see if the page displays faster with or without preload.
Is it my best option for the scenario given in the question?
In this example, no, but only because font-awesome is not a good idea in general.
What you really want to do is get rid of font-awesome entirely. Icon Fonts are an out-dated and terrible practice us web developers have adopted that just won't go away.
Instead of loading a 50kb+ file (for each 'weight' of font-awesome you use) plus 30kb of CSS why not use inline SVGs instead.
Inline SVGs have several advantages, but the key ones are:-
- As they are inlined in the HTML you remove at least one network request (normally 2-3) - great for speed.
- They are tiny - a typical icon is less than 1kb unzipped - with 10 icons you said you use that is 10kb total before zipping. Compare that to 180kb zipped for font-awesome fonts, CSS etc. and you can see the performance improvement.
- As you have inlined your icons within your HTML you reduce your 'critical request chain' length, so you can get to sub 1 second initial page renders (obviously you need to inline all of your critical CSS required for the above the fold as well.)
- The most important reason - people use custom stylesheets on your websites. For example people with dyslexia may prefer a certain font as it is easier to read, so they may force a site to use that font. Your beautiful 'font icons' become the dreaded 'missing character square box of doom' - which makes it really difficult to know what they are clicking. Accessibility is becoming more and more important!
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.
这篇关于何时使用 rel="preload"?为什么预加载字体/FontAwesome 是个好主意?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
