Next-gen image formats not universally compatible with browsers?

[TomSnow]

Google recommends using "next-gen" image formats to keep page speed down. There's better compression apparently.

The problem is there isn't a next-gen format that's compatible with the major browsers:

JPEG 2000 - Safari but not Chrome
JPEG XR - Internet Explorer and Edge but not Safari or Chrome
WebP - Edge, Firefox, Chrome, Opera, Android Browser, but not Safari.

WebP seems like the best option, but does that mean my images won't be rendered in Safari?

Thanks!

[tangor]

Personally mixed on many of these "improvements" as graphics has been very special for me for many reasons OTHER than the web.

At present there is not clear (other than WebP) winner in the image formats. For me, time will tell what wins in the end. All of the above have something going for them in one way or another... but until the churn settles down, gif jpg and png are what I use on a daily basis ... I KNOW those will render just about everywhere.

[TomSnow]

@tangor

That's the conclusion I'm arriving at as well. I was considering WebP, but much of my traffic is from Safari.

I narrowed down the problem area to a truly large image that Dev didn't compress. Seems like an easy fix.

Google recommended going with next-gen as a fix to my slow page speed. But in reality compression with the standard jpg or gif is the right choice until next-gen is more universal.

Thanks!

[Wilburforce]

Google recommends using "next-gen" image formats to keep page speed down.

WebP is Google's own invention, and they want everybody to use it (and to use Chrome). The more of the web they control, the less choice we have about how our own businesses find customers, and the more "free" things they give away, the more of our oxygent they consume.

WebP's only benefit over other forms of lossy compression is that compressed images using it typically result in smaller file-sizes than with others (which makes more difference the more the image is compressed). How relevant it is for your site depends on the number, size and resolution of images you have, and their purpose: if you run a photography studio, your clients will still want to see uncompressed images. If your images are generally just illustrating a written narrative (or merely decorative), high compression losses only start to make much difference when the quality loss is obvious at a glance. If, in that scenario, your objective is speed, using CSS sprites with existing formats (.jpg and .png are already fairly good) to replace multiple images will probably yield more actual perfomance gain than keeping multiple images and changing them to WebP. Although higher compression rates will give WebP a clearer advantage, they also produce more noticable loss of definition.

On the minus side, it isn't just some browsers that don't support it: other than in their latest versions (and even then not all), existing photo-editing software doesn't support it either, and neither does Windows.

I have ignored Google on this myself (and don't intend changing images in the foreseeable future), so unless you have pressing reasons to move to WebP I wouldn't advise it.

[lucy24]

Google recommends

I would file this in the same place I file at least 2/3 of G’s recommendations. (Hint: It’s the same place as at least 90% of GSC reported “errors” or “problems”.)

For the foreseeable future, I’m sticking with png and jpg, depending on requirements. (I recently came across a 1789-vintage book that prompted the immediate reaction “Ooh, this is crying out for an alpha channel” and I had to reassure myself that yes, even MSIE can deal with those now. Besides, cursory experimentation suggests that I may be able to get it to work in 256 colors, at an obviously enormous savings of bandwidth.)

[skaterpunk]

I agree with everyone else. Stick with .png for vector files or files that need transparent backgrounds, and use .jpg for images.

I would look into a CDN to better handle images for increased page speed.

[tangor]

As a graphics guy (RAW is my fave ... followed by tiff and psd) web graphics are pretty simple ... the only thing that WebP brings is more compression ... at a loss of image ... and the only one that benefits in that "suck the web dry" point of view is g.

I remind g it is they who set out to index the web ... let them index it the way it exists. :)

Seriously ... my images are already presented in the most compact, commonsense, VIEWABLE version possible. Having a third party second guess that is insulting. If my pic is "too large" for their process, just skip it. I don't mind. Meanwhile, not switching to a proprietary format by a single company ... we've already been there with the gig thing back in the day.

</rant off>

[tangor]

Sorry ... "gig" was meant to be "gif" ... (js off , no edit available)...

[Marshall]

I am soooooooo tired of "Google Says..."

[dennisjensen]

Although I agree about being aware of G dictating the web, the question was about next gen image formats :)

We're currently working to implement webp, our guess is, it will become a future standard. It does increase page speed and that is good for the user and our servers. We'll be serving webp as default, that's the plan, with jpeg as fallback. It's not an ootb solution, it does take some dev work, and I appreciate, not everybody can support that with the snap of their fingers! Also, we're contemplating using base64 encoding for various images like icons.