4 ms·

A Very WebP New Year from Cloudflare

53 points by IcyApril 10y ago

pilom 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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-Articles/The-Case-for-VP9-100833.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar... [2] https://infoscience.epfl.ch/record/200925/files/article-vp9-submited-v2.pdf https://infoscience.epfl.ch/record/200925/files/article-vp9-... [3] https://news.ycombinator.com/item?id=13226309 https://news.ycombinator.com/item?id=13226309
      - ensignavenger 10y ago
        In no way better? Isn't VP9 free, whereas H.264 requires patent licenses?
        niftich 10y ago
        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
        ensignavenger 10y ago
        But that is still not "in no way better."
        clouddrover 10y ago
        > 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.
      - clouddrover 10y ago
        > Given that VP9 is in no way superior to H.264 [1][2], YouTube and Netflix disagree with you: https://youtube-eng.googleblog.com/2015/04/vp9-faster-better-buffer-free-youtube.html https://youtube-eng.googleblog.com/2015/04/vp9-faster-better... http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html http://techblog.netflix.com/2016/08/a-large-scale-comparison... http://techblog.netflix.com/2016/12/more-efficient-mobile-encodes-for.html http://techblog.netflix.com/2016/12/more-efficient-mobile-en... The real world experience of YouTube and Netflix across a wide variety of video says VP9 outperforms H.264. It's not ideology, it's practicality. > and is a clear detriment to users. Read the YouTube engineering blog post on VP9. They're optimizing for bandwidth and quality. VP9 allows them to get their users better quality at lower bandwidth.
philo23 10y ago
> 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 10y ago
  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 10y ago
    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-format-users-squawk/ https://www.cnet.com/news/facebook-tries-googles-webp-image-... [2] http://arstechnica.com/information-technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/ http://arstechnica.com/information-technology/2013/04/chicke...
deleted 10y ago
[deleted]
niftich 10y ago
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-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress... [2] https://github.com/dropbox/lepton https://github.com/dropbox/lepton
- Scaevolus 10y ago
  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 10y ago
    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 10y ago
      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.
bberenberg 10y ago
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

53 points by IcyApril 10y ago

pilom 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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-Articles/The-Case-for-VP9-100833.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar... [2] https://infoscience.epfl.ch/record/200925/files/article-vp9-submited-v2.pdf https://infoscience.epfl.ch/record/200925/files/article-vp9-... [3] https://news.ycombinator.com/item?id=13226309 https://news.ycombinator.com/item?id=13226309
    - ensignavenger 10y ago
      In no way better? Isn't VP9 free, whereas H.264 requires patent licenses?
      - niftich 10y ago
        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
        ensignavenger 10y ago
        But that is still not "in no way better."
        clouddrover 10y ago
        > 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.
    - clouddrover 10y ago
      > Given that VP9 is in no way superior to H.264 [1][2], YouTube and Netflix disagree with you: https://youtube-eng.googleblog.com/2015/04/vp9-faster-better-buffer-free-youtube.html https://youtube-eng.googleblog.com/2015/04/vp9-faster-better... http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html http://techblog.netflix.com/2016/08/a-large-scale-comparison... http://techblog.netflix.com/2016/12/more-efficient-mobile-encodes-for.html http://techblog.netflix.com/2016/12/more-efficient-mobile-en... The real world experience of YouTube and Netflix across a wide variety of video says VP9 outperforms H.264. It's not ideology, it's practicality. > and is a clear detriment to users. Read the YouTube engineering blog post on VP9. They're optimizing for bandwidth and quality. VP9 allows them to get their users better quality at lower bandwidth.

philo23 10y ago

> 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 10y ago
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 10y ago
  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-format-users-squawk/ https://www.cnet.com/news/facebook-tries-googles-webp-image-... [2] http://arstechnica.com/information-technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/ http://arstechnica.com/information-technology/2013/04/chicke...

deleted 10y ago

[deleted]

niftich 10y ago

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-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress... [2] https://github.com/dropbox/lepton https://github.com/dropbox/lepton

Scaevolus 10y ago
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 10y ago
  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 10y ago
    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.

bberenberg 10y ago

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