[英]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.