[英]webp/jpg - Preloading only the needed type in a html file
我有一个网站,我使用 webp 和 jpg 作为后备。 在 header 中,我为移动用户提供了 bis 图像和较小的图像。
所以我有4个文件:
header-big.webp
header-small.webp
header-big.jpg
header-small.jpg
因为它在 header 中,所以我想要预加载图像,但只需要我需要的图像。 对于小型和大型的,我可以使用媒体属性预加载它。
<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)">
在这种情况下,浏览器总是根据文件的宽度预加载两个文件,但仍然只会使用其中一个。
天哪,这是有道理的,因为 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进行比较以确定该交叉区域有多大时,我注意到没有很多支持 preload 而不是 webp 的浏览器版本,主要是 safari。 我在下表中总结了那个交叉点。 webp 和 preload 列显示了第一个版本,分别对 webp 和链接元素和预加载有足够的支持。 版本差距列显示了哪些版本属于“支持预加载但不支持 webp”类别和差距中的用户百分比,显示了属于该类别的全球用户的百分比,并将从预加载的 jpeg 中受益。 % 来自https://caniuse.com/usage-table
浏览器 | WebP | 预载 | 版本差距 | 差距中的用户百分比 |
---|---|---|---|---|
IE | 不适用 | 不适用 | ||
边缘 | 18 | 17 | [17-18) | 0.03% |
FireFox | 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% |
歌剧迷你 | 全部 | 不适用 | ||
Android浏览器 | 4.2 | 91 | ||
歌剧移动 | 62 | 不适用 | ||
镀铬 Android | 91 | 91 | ||
Firefox 用于 Android | 89 | 89 | ||
UC 用于 Android | 12.12 | 不适用 | ||
三星互联网 | 4 | 5 | ||
QQ浏览器 | 10.4 | 不适用 | ||
百度浏览器 | 7.12 | 不适用 | ||
凯iOS | 不适用 | 不适用 | ||
全部的 | 1.93% |
因此,全球大约有 1.93%,我的直觉是,如果您的受众主要是美国,那么可能会低于这个数字,假设“发达”世界中使用最新硬件和浏览器的人比其他地方多。 我还预计随着时间的推移,这个数字会逐渐下降到零,并且使用这些旧浏览器的用户也更有可能使用较慢的连接。
我对这个分析的评估是,如果你有可用的 webp 资产,尝试做任何 jpeg 预加载可能不值得,因为受益的用户是 a) 总数中的一小部分 b) 可能更难优化一般来说,随着用户停用这些浏览器版本,收益会递减。
如果您像我一样,并且您的目标是将足够多的用户从核心 Web Vitals 上的“差”和“需要改进”分数转移到“好”范围内,以达到 75% 的用户阈值,谷歌表示这将为您带来一些在搜索结果中有一种“快速站点”的特殊指示,那么您可能不必担心这个队列。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.