webp/jpg - 仅在 html 文件中预加载所需的类型

Posted 2023-05-07

【中文标题】webp/jpg - 仅在 html 文件中预加载所需的类型

【英文标题】：webp/jpg - Preloading only the needed type in a html file

【发布时间】：2021-06-25 15:43:37

【问题描述】：

我有一个网站，我使用 webp 和 jpg 作为后备。 在标题中，我为移动用户提供了 bis 图像和较小的图像。

所以我有 4 个文件：

header-big.webp
header-small.webp
header-big.jpg
header-small.jpg

因为它在标题中，我想要预加载图像，但只加载我需要的图像。 对于小型和大型的，我可以使用媒体属性预加载它。

<link rel="preload" href="header-small.jpg" as="image" type="image/jpg" media="(max-width: 575px)">
<link rel="preload" href="header-small.webp" as="image" type="image/webp" media="(max-width: 575px)">
<link rel="preload" href="header-big.jpg" as="image" type="image/jpg" media="(min-width: 576px)">
<link rel="preload" href="header-big.webp" as="image" type="image/webp" media="(min-width: 576px)">

在这种情况下，浏览器总是根据文件的宽度预加载两个文件，但仍然只会使用其中一个。

和jeah，这是有道理的，因为jpg和webp都可以实现。所以当然浏览器会预加载两者。

但是我可以说“如果你支持 webp，而不是预加载 webp 而不要预加载 jpg”？

谢谢， 弗洛里安

【问题讨论】：

Something like this?

没有。那是关于已经在工作的实施。我的问题是图像的预加载。我想避免预加载未使用的 iage 格式。

其实是一个非常好的问题！我现在刚刚遇到同样的问题并搜索了“动态预加载”的解决方案，因为某些浏览器仍然不支持 WEBP 我想让他们有机会预加载 JPG (jpeg)，但还没有找到任何地方实现它的方法！你的问题得到了我的 +1

【参考方案1】：

我实现的解决方案涉及一个取自https://avif.io/blog/tutorials/use-avif-in-css/ 的小脚本来检测 AVIF 和 WEBP，因为我之后已经需要它来添加对这两种格式的 CSS 支持，但是对于您的用例可以稍微简化一下。一旦我知道它受支持，我就会在头部添加一个preload 链接。

我把脚本放在头的最后，因为在我的特殊情况下，我不需要更早的图像。

<script type="text/javascript">
  function addPreloadLink(img, type) 
    var fileref = document.createElement('link');
    fileref.setAttribute('rel', 'preload');
    fileref.setAttribute('as', 'image');
    fileref.setAttribute('href', img);
    fileref.setAttribute('type', type);

    document.head.appendChild(fileref);
  

  function AddClass(c) 
    document.documentElement.classList.add(c);
  

  var webp = new Image();
  webp.src =
    'data:image/webp;base64,UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==';
  webp.onload = function() 
    AddClass('webp');
    addPreloadLink('header-small.webp', 'image/webp');
    addPreloadLink('header-big.webp', 'image/webp');
  ;
  webp.onerror = function() 
    //load JPG
    addPreloadLink('header-small.jpg', 'image/jpg');
    addPreloadLink('header-big.jpg', 'image/jpg');
  ;
</script>

【讨论】：

请注意，如果像答案中所说的 in my particular case I don't need to have image earlier 那样，这很好，但如果您预加载的图像是 LCP 元素，这可能会由于添加时间而降低您的 Lighthouse LCP 分数解析/执行脚本并将<link>元素动态注入DOM。

【参考方案2】：

所以，我提出这个问题是因为我正在尝试改进 LCP 以适应最新的谷歌搜索信号更新。我也想在支持时预加载 webp，在不支持时预加载 jpg。

对于不支持webp时预加载jpg的情况，只有当浏览器支持preload且不 webp时才会出现这种情况。当我查看https://caniuse.com/webp 并将其与https://caniuse.com/link-rel-preload 进行比较以确定交叉区域有多大时，我注意到支持预加载而不是webp 的浏览器版本并不多，主要是safari。我在下表中总结了该交叉点。 webp 和 preload 列显示了第一个版本，分别对 webp 和链接元素和 preload 有足够的支持。版本差距列显示了哪些版本属于“支持预加载但不支持 webp”类别和差距中的用户百分比，显示了属于该类别的全球用户的百分比，并将从预加载的 jpeg 中受益。 % 来自 https://caniuse.com/usage-table

Browser	WebP	Preload	Version gap	% users in gap
IE	NA	NA
Edge	18	17	[17-18)	0.03%
FireFox	65	85 (56*, 57-84 disabled by default)	56	0.01%
Chrome	32	50
Safari	14*	11.1	[11.1-14)	0.65%
Opera	19	37
Safari(ios)	14.4	11.3	[11.3-14.4)	1.24%
Opera Mini	all	NA
android Browser	4.2	91
Opera Mobile	62	NA
Chrome for Android	91	91
Firefox for Android	89	89
UC for Android	12.12	NA
Samsung Internet	4	5
QQ Browser	10.4	NA
Baidu Browser	7.12	NA
KaiOS	NA	NA
TOTAL				1.93%

因此，全球大约有 1.93%，我的直觉是，如果您的受众主要是美国，那么假设“发达”世界中使用最新硬件和浏览器的人比其他地方更多的人，它可能会更少。我还预计随着时间的推移，这个数字会逐渐下降到零，并且使用旧版浏览器的用户也更有可能使用较慢的连接。

我从该分析中得出的评估是，如果您有可用的 webp 资产，那么尝试进行任何 jpeg 预加载可能不值得，因为受益的用户是 a) 总数中的一小部分 b) 可能更难总体而言进行优化，随着用户停用这些浏览器版本，收益递减。

如果您像我一样，并且您的目标是将足够多的用户从 Core Web Vitals 上的“差”和“需要改进”的分数提升到“好”的范围内，以达到 75% 的用户门槛，谷歌表示将在搜索结果中为您提供某种“快速站点”的特殊指示，那么您可能不必担心这个群组。