webp/jpg - Preloading only the needed type in a html file

Question

i have a website and i am using webp and jpg as a fallback. in the header, i have a bis image and smaller image for mobile users.

So i have 4 files:

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

Because it is in the header, i want wo preload the image, but only the image i need. for the small and big ones i can preload it with the 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)">

In this case, the browser always preloads two files, depending on its width, but still just one of them will be used.

and jeah, it makes sense, because the jpg and webp can be both implemented. so of course the browser preload both.

but can i say "if you support webp, than preload the webp and do not preload the jpg"?

Thanks, Florian

Neilla

Something like this? – Vostok

No. Thats about the implementing which is already working. My issue is the preloading of the images. I want to avoid the iage format being preloaded which is not used. – Neilla

Actually a very good question! I just encountered the same problem right now and searched for a solution of "dynamically preloading" as some browsers still do not support WEBP I want to give them the chance to preload JPG (jpeg) but have not found a way to achive that anywhere! Your question got my +1 – Meli

Answer 1

The solution I implemented involves a small script taken from https://avif.io/blog/tutorials/use-avif-in-css/ to detect AVIF and WEBP, because I already needed it afterwards to add CSS support for both formats, but for your use case can be a bit simplified. Once I know it is supported I add a preload link in the head.

I placed the script at the very end of the head, coz in my particular case I don't need to have image earlier.

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

Wellturned

Just a note that this is fine if, like the answer says in my particular case I don't need to have image earlier, but if the image you're preloading is the LCP element, this could decrease your Lighthouse LCP score due to addition time taken to parse/execute the script and dynamically inject the <link> element into the DOM. – Periderm

Answer 2

So, I came to this question because I'm trying to improve LCP for the latest google search signal update. I too wanted to preload webp when supported and preload jpg when not.

For the case of preloading jpg when webp is not supported, this could only occur when the browser supports preload and not webp. When I looked at https://caniuse.com/webp and compared it to https://caniuse.com/link-rel-preload to determine how big that area of intersection is, I noticed there aren't a whole lot of browser versions that support preload and not webp, mostly safari. I've summarized that intersection in the table below. The webp and preload columns show the first version with sufficient support for webp and for the link element and preload respectively. The version gap column shows which versions fall into that 'supports preload but not webp' category and the % users in gap, shows what percentage of global users fall into that category and would benefit from preloaded jpegs. The % were aggregated from 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%

So, approximately 1.93% globally and my hunch is that if your audience is mostly US based, it's probably less than that, under the assumption that more people in the 'developed' world are on the latest hardware and browsers than elsewhere. I also expect that number to be declining asymptotically towards zero as time marches forward and that users who are on those older browsers are more likely to be on slower connections as well.

My assessment from this analysis is that it's probably not worth it to try and do any preload of jpegs if you have webp assets available, because the users who would benefit are a) a teeeny sliver of the total and b) probably harder to optimize for in general, with diminishing returns as the users sunset those browser versions.

If you're like me and your goal is to move enough users from 'bad' and 'needs improving' scores on Core Web Vitals into the 'good' range to meet the 75% of users threshold that google has indicated will get you some kind of special indication of 'fast site' in the search results, then you can probably not worry about this cohort.

Goldfilled