Earlier quoted context omitted.
What’s interesting is that Google’s Lighthouse tool for measuring site speed pushes for “Next Gen” image formats like WebP. But I often find that WebP files are larger than jpg, too. Yet Lighthouse recommends it. And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm.
The irony is that the Lighthouse site itself scores really badly! Can you accept its advice?
Is WebP really better than JPEG?
291–300 of 319 posts
Re: Is WebP really better than JPEG?
#292https://news.ycombinator.com/item?id=22245788
Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL format without loss.
Re: Is WebP really better than JPEG?
#293It's all about Google wanting control. Their own file formats, their own protocols, AMP, not showing URLs in Chrome. The goal is to turn the web into a closed Google ecosystem.
Not that I trust Google, but in this case I don't see the harm.
Re: Is WebP really better than JPEG?
#294You spend all this time improving your stack, reducing your app bundle size, convincing your company on the benefits of server side rendering, improving your devops, getting your manager to see these measurable benefits by running lighthouse audits themselves etc...
Then all of a sudden it turns out that the main tool you used for this has been turned into a.. a fking ad platform.
I apoligise for this emotionally charged rant, but seriously though, is that how you plan on getting developers adopt your dubious new standard, by p*ssing them off?
Re: Is WebP really better than JPEG?
#295Earlier quoted context omitted.
How would you show a photographed image as a svg? Either you would have to "vectorize" the image which would look totally different or you'd create a grid of vectors with different hue values, ultimately representing pixels in an extremely inefficient format. Raster graphics and vector graphics can't be compared because sure, you could create 2 million vector squares with individual positions, sizes and colors and al…
Why would you show a photograph as an svg? You wouldnt. Thats what jpegs are for. We're discussing transparency and the use case for it. I dont think ive ever heard of someone wanting transparency in a photo. The only times i see the need is if theyre doing something that is better off in a vector format. I.e. png, which is being supplanted by svg, which alleviates the size problems raised about pngs. I.e. webp is a…
OK, but they do. It's pretty common for someone to cut out an object in a photo and have a transparent background.
Re: Is WebP really better than JPEG?
#296I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website: BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are: * High compression ratio. Files are much smaller than JPEG for similar quality. * Supported by most Web b…
> I wonder, why nobody mentioned Patrice Bellard's BPG[1]. Isn't it Fabrice Bellard?
@als0: Thanks for pointing that out.
Re: Is WebP really better than JPEG?
#297Summary: - No. It's roughly the same. Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons.
Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. Pithy comment, and reaction, aside, that's enough to give me pause about implementing it.
Re: Is WebP really better than JPEG?
#298Re: Is WebP really better than JPEG?
#299Earlier quoted context omitted.
Is it better? The AVIF examples in the article look even worse than the WebP ones
At 30% reduced size. The true comparison would be at the same file size, which format is able to squeeze more perceivable information into the same bucket?
Re: Is WebP really better than JPEG?
#300Earlier quoted context omitted.
How? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't h…
* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything
* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.
That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.