
A Very WebP New Year from Cloudflare - IcyApril
https://blog.cloudflare.com/a-very-webp-new-year-from-cloudflare
======
philo23
> For example, a JPEG image at
> [https://example.com/picture.jpg](https://example.com/picture.jpg) that has
> been converted to WebP will still have that same URL. The “Content-Type”
> HTTP header tells the browser the true format of an image.

So if a visitor tries to download one of those images, are they going to end
up saving the image with an incorrect file extension, or is it up to browsers
to fix the file extension based off of the Content-Type header?

~~~
jblok
It will have the wrong file extension, but the bigger problem is that when the
user tries to open the file in Preview on OSX or whatever their native picture
viewing application is, chances are it will fail to open a WebP image.

I recall Facebook experimenting with WebP, but abandoned it because when users
saved images from the web to their hard drives, they couldn't work out how to
open the files.

~~~
niftich
Indeed Facebook tried this in 2013, and the user misery was immediate and loud
[1][2].

[1] [https://www.cnet.com/news/facebook-tries-googles-webp-
image-...](https://www.cnet.com/news/facebook-tries-googles-webp-image-format-
users-squawk/) [2] [http://arstechnica.com/information-
technology/2013/04/chicke...](http://arstechnica.com/information-
technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/)

------
pilom
I wish cloudflare had better tooling for a/b tests. I'd love to enable this
option on our site, but without a/b test evidence that it won't affect
conversions I'll never get buy in from management for a feature that likely
won't affect our infrastructure. It might improve conversions through faster
load times but I can't prove that.

~~~
uniclaude
That's a very fair point. IIRC WebP uses more cpu than JPEG, so, faster
transfers but will it actually enhance my customers experience with their
various Android phones?

~~~
bastawhiz
The transfer time saved is almost certainly more expensive than the CPU
resources used, especially on modern devices. Depending on your browser, this
may even happen off the main thread.

~~~
niftich
A more glaring problem is video, where the widespread lack of hardware
acceleration for VP8, VP9, or whatever variant Youtube happens to serve by
default today will burn software decoding cycles [3] (and battery life) while
H.264 would decode in hardware buttery smooth.

Given that VP9 is in no way superior to H.264 [1][2], this is purely an
ideological push to favor their own format over a more widely supported
another, and is a clear detriment to users.

[1] [http://www.streamingmedia.com/Articles/Editorial/Featured-
Ar...](http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-
Case-for-VP9-100833.aspx) [2]
[https://infoscience.epfl.ch/record/200925/files/article-
vp9-...](https://infoscience.epfl.ch/record/200925/files/article-
vp9-submited-v2.pdf) [3]
[https://news.ycombinator.com/item?id=13226309](https://news.ycombinator.com/item?id=13226309)

~~~
ensignavenger
In no way better? Isn't VP9 free, whereas H.264 requires patent licenses?

~~~
niftich
Not for H.264 made available at no cost on the public Internet [1]:

 _" Internet Broadcast AVC Video (not title-by-title, not subscription) - no
royalty for life of the AVC Patent Portfolio License"_

For any other uses (like Netflix, Youtube RED, and other subscription, pay-
per-view and similarly commercial uses), once a company exceeds the yearly cap
in license payments, they need not pay more. In 2016 the cap is $8.125
million, from 2017 to 2020 the cap is $9.75 million.

[1]
[http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf](http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf)

~~~
clouddrover
> _Not for H.264 made available at no cost on the public Internet [1]:_

That's only the content license. You still have to pay for the encoder and the
decoder.

> _from 2017 to 2020 the cap is $9.75 million._

So using VP9 saves them $9.75 million per year in licensing fees alone, never
mind the bandwidth cost savings from better compression. That's a strong
financial incentive to switch to VP9 today and AV1 later when it's ready.

------
bberenberg
If I understand this correctly "...removes unnecessary data...", their
optimization algorithm strips metadata on the image. This would include
copyright information. For every single image that they do this to it would be
a crime.[1] And they face a minimum liability of $2500, up to $25,000 + lawyer
fees.[2]

[1][https://www.law.cornell.edu/uscode/text/17/1202](https://www.law.cornell.edu/uscode/text/17/1202)
[2][https://www.law.cornell.edu/uscode/text/17/1203](https://www.law.cornell.edu/uscode/text/17/1203)

------
niftich
Dropbox's Lepton [1][2], an additional _lossless_ compression layer that
operates on top of JPEG, would make for a smoother transition.

If a browser natively supported Lepton, you could serve the compressed version
over the wire, and still get the bit-exact original .jpg out at the end, if
the user wanted to save the file.

Of course, browser support doesn't exist yet. But browser implementors,
consider the gains. This isn't promoting an incompatible format, it's getting
bandwidth savings while being fully backwards compatible.

[1] [https://blogs.dropbox.com/tech/2016/07/lepton-image-
compress...](https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-
saving-22-losslessly-from-images-at-15mbs/) [2]
[https://github.com/dropbox/lepton](https://github.com/dropbox/lepton)

~~~
Scaevolus
There's not really much point to supporting Lepton directly instead of WebP.
It's (approximately) a JPEG converted losslessly into a WebP variant-- it uses
a predictor very similar to the VP8 inter-block predictor and the VP8
arithmetic coder. WebP is based on VP8, so it uses the same technologies.

~~~
niftich
I'd argue the exact opposite: the two use nearly equivalent methods, but one
of them is completely backwards compatible with JPEG, while the other one...
isn't.

~~~
Scaevolus
The ability to losslessly convert it between another format doesn't seem that
relevant for a browser-- you still need to deploy new software to support it,
at which point you might as well just use something more efficient than JPEG.

Remember, the compression is lossy to begin with.

