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

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>

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.