Recommending the use of next gen formats without adequate browser support

[tschallacka]

Welcome! Please use this template for reporting documentation issues on https://developers.google.com/web/.

Page Affected: https://developers.google.com/web/TODO Page Affected https://developers.google.com/speed/pagespeed/insights/

What needs to be done?

caniuse.com shows that jpg 2000 is hardly supported, the webp is hardly supported either, etc... It's nice to recommend newer standards, but without universal dependable browser support, I find it unfair that pagespeed insights punishes for not using next gen formats, when those aren't majorly supported by browsers.

• [ ] Appropriate type-something label has been added.
• [ ] Appropriate section-something label has been added.

[PaintNinja]

I would argue that WebP is well supported. At the time of writing, WebP is supported on over 75% of browsers according to caniuse.com. https://caniuse.com/#feat=webp

[tschallacka]

@PaintNinja safari ios, no support. All iphone/ipad users can't use it. That's a large chunk of users. Safari itself doesn't support either, so mac users fall out also. That's a large user base that need a fallback. Neither IE browser, which will mean that a lot of older users or corporate/government users can't see it either since they are IE locked in for activex support.

I could ignore IE, if safari would support webp. But without safari support, webp is mostly useless in the real world where we make websites, and supporting fallbacks is what we used to do in the heydays of IE versions and Netscape navigator.

I'm all for upgrading to webp when safari is on board. as long as Apple users can't use it, it's a useless feature and one shouldn't be "penalized" for not using it.

[PaintNinja]

You can easily make image fallbacks with the <picture> element, literally 3 lines of code. And in css you can just first define your fallback and then define the webp on the next line and if a browser doesn't support webp it ignores that line.

Have a look at the html and css source code of this page for examples of webp with native fallbacks: https://ozli.ga/firefox-themes

[tschallacka]

Content team finds image on pixabay. team uploads image in cms from pixabay. Image needs to be converted to webp. Image needs to have srcset resizes to webp for responsive image loading Original jpg image needs to have srcset resizes for fallback image. Image needs to be included to host fallback src set and webp srcset.

That's a lot of work, and duplicate image data to host, plus management of files that need to be deleted when someone removes an image from the cms.

That's a lot more implementation cost than "just three lines of code"

[PaintNinja]

<picture>
    <source srcset="photo.webp" type="image/webp">
    <img src="photo.jpg">
</picture>

That's it. You aren't required to define different sizes, you can just define a different format and it'll work.

Sure you may have to convert the image once if it's uploaded by a user in a different format, but it's only a one time conversion. It's already done on some cms implementations where they accept gif uploads and convert to mp4 (e.g. Imgur)

[tschallacka]

@PaintNinja My main gripe is having to host duplicate image content. We currently have 3gb of image data due to all the srcsets. This move would double our image data we need to host and manage. If a push could be made for safari to support it, then I could just host converted files and have a one time change in the cms. currently, it's too large a strain for something that isn't widely supported yet, and for commercial websites, IOS and Apple users are usually the revenue driving force.

It will also increase the size of the generated HTML significantly.

currently:

<img 
        data-sizes="auto" 
        class="marketing-banner-image img-responsive marketing-banner-image-l lazyautosizes lazyloaded"
        alt="something something" 
        title="something something" 
        data-src="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_60_00auto.jpg" 
        data-srcset="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1170x0_100_00auto.jpg 1170w 107h,
        https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_100_00auto.jpg 1200w 109h"
        sizes="1140px">

would become

<picture 
    data-sizes="auto" 
    class="marketing-banner-image img-responsive marketing-banner-image-l lazyautosizes lazyloaded" 
    alt="something something" 
    title="something something" 
    data-src="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_60_00auto.webp" 
    data-srcset="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1170x0_100_00auto.webp 1170w 107h,
                https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_100_00auto.webp 1200w 109h" 
    sizes="1140px">
    <img 
        data-sizes="auto" 
        class="marketing-banner-image img-responsive marketing-banner-image-l lazyautosizes lazyloaded"
        alt="something something" 
        title="something something" 
        data-src="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_60_00auto.jpg" 
        data-srcset="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1170x0_100_00auto.jpg 1170w 107h,
        https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_100_00auto.jpg 1200w 109h"
        sizes="1140px">
</picture>

That's even leaving behind the consideration if the lazyloading library will work properly with nested img elements.

It's a lot more cpu power wasted, a lot more data traffic wasted in useless html, a lot more storage wasted, a lot more management solutions that need to be implemented for the removal of discarded data etc...

A blanked switch to new standard is easier to implement.

I'm fine with webp being a recommendation. The reason I opened this issue, is that it shouldn't count against you when you don't use it in the reporting.

[PaintNinja]

A few of things to note: first off, that's not the correct syntax for the <picture> element. There's a lot less duplicated code in reality than in your example (e.g. you don't need to put the alt, title, etc... twice).

Here's what your theoretical example might actually look like with the correct syntax:

<picture class="marketing-banner-image img-responsive marketing-banner-image-l lazyautosizes lazyloaded">
    <source srcset="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1170x0_100_00auto.webp 1170w 107h,
                https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_100_00auto.webp 1200w 109h" 
    type="image/webp">
    <img srcset="https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1170x0_100_00auto.jpg 1170w 107h,
                 https://www.example.com/app/uploads/public/5ce/3a8/483/77879/something-something--1200x0_100_00auto.jpg 1200w 109h"
    alt="something something" title="something something">
</picture>

Secondly, why are you worried about HTML size? You might increase the filesize of the HTML by a KB or so, sure (probably much less when factoring in gzip/brotli compression), but you'll reduce the bandwidth usage for the majority of clients that support WebP by a much larger margin (potentially hundreds of KB. at least tens of KB).

Also, why those sizes? It doesn't make sense to have two photos that are 33px different in size, the browser can probably do a better job resizing the larger image. Having one image that's half the size for small mobile screens and another image that's the full size would be a more logical use of srcset sizes.

I agree that it would be easier if every vendor just supported a given modern format (be it FLIF, JPEG-XT, WebP, BPG, HEIC/HEIF or whatever), but we're not at that point yet. However, there's a lot of options in terms of native browser fallbacks that can be used in the meantime thus allowing you to optionally implement support for the modern format on your site if you choose to, with browsers that don't support it just falling back to the widely supported legacy format.

If you don't care about bandwidth usage and page load times too much, you probably shouldn't be worrying about different image formats at all.