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

问题描述

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

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

因为它在标题中，所以我想要预加载图像，但只有我需要的图像。无论大小，我都可以使用 media-attribute 预加载它。

<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”？

谢谢，弗洛里安

解决方法

我实施的解决方案涉及一个取自 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>

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

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

浏览器	WebP	预加载	版本差距	有差距的用户百分比
IE	不适用	不适用
边缘	18	17	[17-18)	0.03%
火狐	65	85（56*，默认禁用 57-84）	56	0.01%
铬	32	50
Safari	14*	11.1	[11.1-14)	0.65%
歌剧	19	37
Safari(iOS)	14.4	11.3	[11.3-14.4)	1.24%
Opera Mini	全部	不适用
安卓浏览器	4.2	91
Opera Mobile	62	不适用
Android 版 Chrome	91	91
安卓版火狐	89	89
安卓统一通信	12.12	不适用
三星互联网	4	5
QQ浏览器	10.4	不适用
百度浏览器	7.12	不适用
KaiOS	不适用	不适用
总计				1.93%

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

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

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

html jpeg preloading webp