Page MenuHomePhabricator

Support optimized WebP thumbnails as alternative to JPEG, PNG
Open, Stalled, NormalPublic

Description

With Chrome representing 47% of our traffic nowadays, it's clearly desirable to serve WebP thumbnails to browsers capable of rendering them, given that at equal visual quality they would be smaller than their JPG (and possibly PNG for lossless WebP) counterparts.

Our infrastructure is currently designed to render thumbnails on demand, which is a weakness in a situation like this when introducing a new thumbnail variant. Particularly when rendering thumbnails in WebP is significantly more time-consuming than our current method of generating JPGs. Past a certain point, the time it takes to generate thumbnails on the fly becomes a nuisance to clients.

Also storage cost is non-negligible and we probably don't have the capacity to have our thumbnails storage size nearly double "overnight". Therefore it's unlikely that in an initial stage we would be able to generate WebP variants for all thumbnails.

Given these constraints, the current ideal plan could be the following, assuming a WebP-capable client:

  • If the thumbnail doesn't receive much traffic, serve its JPG version
  • If the thumbnail surpasses a certain edge traffic threshold, check if a WebP version is available
  • If no WebP version is available yet, serve the JPG version to the client, and schedule the WebP version to be generated asynchronously
  • If a WebP version is available thanks to a prior request, serve it

This introduces novel mechanics in our thumbnailing infrastructure:

  • Fallback support
  • Fire-and-forget request to generate a thumbnail variant
  • Inspecting edge traffic information (ideally at the edge itself)

Version: unspecified
Severity: enhancement
URL: http://caniuse.com/#feat=webp

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

mathias.schindler wrote:

(In reply to comment #3)

That'll be the quickest way to get it implemented, but we get the most bang for
our buck if it's automatic.

Chosing this path does not mean we discard any other. Apart from that, I agree.

One downside as a user pref: do *all* your browsers support webp?

Right now, there is no browser supporting WebP. There is a javascript hack out there that modifies webp files in a way to make the browser handle it as a WebM video, therefor displaying it. It works on Firefox, Chrome and Opera.

brion added a comment.Oct 25 2010, 7:14 PM

(In reply to comment #4)

(In reply to comment #3)
> That'll be the quickest way to get it implemented, but we get the most bang for
> our buck if it's automatic.
>

Chosing this path does not mean we discard any other. Apart from that, I agree.

The main reason to implement it at all is to reduce bandwidth usage; as a per-user option it's a geek curiosity, while as a default that can act on all requests it would actually be able to have wide effect.

> One downside as a user pref: do *all* your browsers support webp?

Right now, there is no browser supporting WebP. There is a javascript hack out
there that modifies webp files in a way to make the browser handle it as a WebM
video, therefor displaying it. It works on Firefox, Chrome and Opera.

Well, here's the scenario I was thinking of:

a) user enables WebP thumbnails while logged in via Chrome-next

b) later, user logs into site from another computer running a different browser, and can't see any thumbnails on the site. That browser might be a netbook, tablet, e-reader, smartphone, game console, or a computer that doesn't have any WebP-capable browser.

On the other hand if what the user option is for is to enable an Accept-header check which determines which format gets used, then that's probably not a problem -- that next login would use JPEG thumbnails.

mathias.schindler wrote:

(In reply to comment #5)

Well, here's the scenario I was thinking of:

a) user enables WebP thumbnails while logged in via Chrome-next

b) later, user logs into site from another computer running a different
browser, and can't see any thumbnails on the site. That browser might be a
netbook, tablet, e-reader, smartphone, game console, or a computer that doesn't
have any WebP-capable browser.

I might have come up with another early approach that will prevent this scenario.

  1. A customized user skin .js/.css file to alter any thumbnail linkn(every <img> link to a .jpg that starts with http://upload.wikimedia.org/wikipedia/commons/thumb/) to another url, possibly toolserver.org or webptest.whateverdomain.tld) to ask the browser to get the image from this site.
  1. The js could containt a browser switch. Browser not supporting webp would not get the altered url. If someone installs the user-mod and changes browsers, there would not be the undesirable result you described.

mathias.schindler wrote:

Current Status:

Google Chrome (stable) and the current stable Opera Web Browser now support WebP encoded image files.

In en.wikipedia.org, a test script exists that replaces jpeg thumbnails with a (toolserver generated) WebP image.

Add:
importScript('User:Magnus Manske/webp.js');

into your user specific .js file (such as User:[Name]/vector.js)

[Reopening to get rid of deprecated LATER resolution.]

cesar wrote:

If you implement hosting dual format webp/jpg this will contribute for web advance, because actually this is pre-condition of mozilla to support webp in farifex.

See:

https://bugzilla.mozilla.org/show_bug.cgi?id=600919

Mozilla Firefox Bug 600919 - (WebP) Implement WebP image support

Dave Garrett 2012-12-29 11:54:16 PST
(In reply to patrck from comment #174)
Also Wikipedia/Wikimedia opened a bug and accepted it and I confirmed from
insiders that they are inplementing webp image support (This will be the
"Big Deal" ?).

Adding the ability for WebP files to be used on Wikimedia doesn't
mean they'll be converting everything they already have to it.
If Wikipedia started dual-hosting all of their images in
both WebP and JPEG, that'd be a "Big Deal".

cesar wrote:

this could be done by using Google mod_pagespeed since it does on the fly WebP conversion.
https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize

ModPagespeedEnableFilters convert_jpeg_to_webp

Enabling convert_jpeg_to_webp causes the image optimizer to create webp images whenever it would otherwise create jpegs. The webp images are only served to modern browsers that support the format. Optimized jpeg images will continue to be served to older browsers.

Bryan.TongMinh wrote:

Currently there is no support in MediaWiki for sending different thumbnails depending on the user-agent. I don't think this should be done within MediaWiki itself in any case, as it would fragment the parser cache.

(In reply to comment #10)

this could be done by using Google mod_pagespeed since it does on the fly
WebP
conversion.
https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize

Note that the Wikimedia image servers use nginx, rather than apache.

We could, however, have a look at our 404-handler to provide this functionality. Anybody can remind me where that code resides?

mathias.schindler wrote:

Since the initial opening of this bug Google has significantly added to the webp software and added support for more metadata, transparency and a lossless coding.

webp as of today would fit for shrinking both lossy jpeg and lossless png thumbnails in Wikipedia articles for those browsers supporting it.

Mathias

brion added a comment.Apr 12 2013, 3:01 PM

Updating summary to note webp can serve for PNG needs as well.

Per http://caniuse.com/#feat=webp browsers of 37.24% of people can handle WebP images right now (Chrome and Opera).

(In reply to comment #11)

Currently there is no support in MediaWiki for sending different thumbnails
depending on the user-agent. I don't think this should be done within
MediaWiki
itself in any case, as it would fragment the parser cache.

(In reply to comment #10)
> this could be done by using Google mod_pagespeed since it does on the fly
> WebP
> conversion.
> https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize
>
Note that the Wikimedia image servers use nginx, rather than apache.

Well, there is also ngx_pagespeed, but assuming the conversion happens as a separate step, it's also easy to configure nginx [1] to serve the appropriate asset based on advertised Accept header.

[1] http://www.igvita.com/2013/05/01/deploying-webp-via-accept-content-negotiation/

  • Bug 56832 has been marked as a duplicate of this bug. ***
Rillke added a subscriber: Rillke.Jun 28 2015, 8:40 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJun 28 2015, 8:40 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:14 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptSep 4 2015, 6:14 PM
Subfader added a comment.EditedApr 26 2016, 11:16 AM

It would be great if admin can allow webp copies of jpg thumbs.
PNG tests on http://image.online-convert.com/convert-to-webp returned blurry files for problemtic red etc, so better don't touch png or check lossless webp options if they are still smaller.

Thumb creation (if webp copy global is true):
If a jpg thumb is created, create another webp copy in the same folder with the same filename (for performance reasons schedule it as job).
Maybe also create a webp copy of the original (see T101015 ).

Serving:
Admin sets up server rewrite rule to serve .webp if .jpg is requested in /thumb/ directory if browser supports webp.

Edit: Webp has a lossless flag.

96 KB png


52 KB webp (-q 80 -lossless)

29 KB png (optipng)

Restricted Application added a project: Commons. · View Herald TranscriptApr 26 2016, 11:16 AM
Restricted Application added a subscriber: Poyekhali. · View Herald TranscriptApr 26 2016, 12:59 PM

@Aklapper I added it because webp is smaller and therefor faster. But I don't care much having it removed.

gpaumier removed a subscriber: gpaumier.Apr 26 2016, 4:33 PM
Subfader added a comment.EditedMay 1 2016, 2:38 PM

A look at random thumb folders for 400px on 1x, 1.5x, 2x, 3x, 4x

IM: q80

cwebp : -q 80 -sharpness 0 -m 6 -af -pre 2

Gilles claimed this task.Mar 26 2018, 3:54 PM
Gilles added a project: Performance-Team.
Gilles raised the priority of this task from Lowest to Normal.
Gilles updated the task description. (Show Details)Mar 26 2018, 4:05 PM

In the coming quarter I'm going to attempt implementing some support for WebP. The first step will be to check if the different parts required for the "ideal" implementation currently described in the task description are even possible, by attempting to implement them on Vagrant.

Gilles moved this task from Inbox to Doing on the Performance-Team board.Mar 26 2018, 8:19 PM

Change 422873 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/vagrant@master] Attempt serving WebP for popular thumbnails

https://gerrit.wikimedia.org/r/422873

@fgiunchedi @ema @BBlack

Please take a look at the Vagrant patch mentioned above. This is the approach I was able to put together (can't think of any other way in VCL, really) to make Varnish only attempt to serve WebP variants for popular thumbnails. This would allow us to roll out WebP support for the hottest thumbnails, which would avoid the storage space explosion that would likely happen if we turned on WebP for all thumbnails.

The one downside of the approach is that it has Varnish fetch the JPG thumbnail first, because it's necessary to know its local hit count, before being able to assess whether it's a popular thumbnail or not. Meaning that all WebPs served are a double object fetch at the edge - with the first one being a very hot thumbnail, though.

I think this overhead is worthwhile, considering it lets us avoid breaking the bank in terms of thumbnail storage, and the absolute time this discarded hot JPG object fetch takes should be negligible compared to the transfer time savings, considering that in my initial local tests I saw as much as a 50% reduction in file size for the WebP variant. I expect the impact on WebP-capable clients to be very significant (close to 50% of our traffic at the moment).

Change 422873 merged by jenkins-bot:
[mediawiki/vagrant@master] Attempt serving WebP for popular thumbnails

https://gerrit.wikimedia.org/r/422873

Change 427612 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/debs/python-thumbor-wikimedia@master] Upgrade to 2.0

https://gerrit.wikimedia.org/r/427612

Change 434055 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/puppet@production] Serve WebP variants for the hottest thumbnails

https://gerrit.wikimedia.org/r/434055

Gilles changed the task status from Open to Stalled.Jun 25 2018, 6:44 PM

Stuck in review since April/May

Change 427612 merged by Filippo Giunchedi:
[operations/debs/python-thumbor-wikimedia@master] Upgrade to 2.0

https://gerrit.wikimedia.org/r/427612

Change 442047 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/debs/python-thumbor-wikimedia@master] Add missing CWEBP_PATH definition

https://gerrit.wikimedia.org/r/442047

Change 442047 merged by Filippo Giunchedi:
[operations/debs/python-thumbor-wikimedia@master] Add missing CWEBP_PATH definition

https://gerrit.wikimedia.org/r/442047

Gilles changed the task status from Stalled to Open.Aug 29 2018, 7:01 AM
Gilles moved this task from Doing to Blocked on the Performance-Team board.Sep 3 2018, 8:29 PM

Change 471717 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/vagrant@master] Simplify WebP thumbnail regexes

https://gerrit.wikimedia.org/r/471717

Change 471717 merged by jenkins-bot:
[mediawiki/vagrant@master] Simplify WebP thumbnail regexes

https://gerrit.wikimedia.org/r/471717

Change 471721 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/vagrant@master] Correctly match dot on WebP thumbnail VCL

https://gerrit.wikimedia.org/r/471721

Change 471721 merged by jenkins-bot:
[mediawiki/vagrant@master] Correctly match dot on WebP thumbnail VCL

https://gerrit.wikimedia.org/r/471721

Change 434055 merged by BBlack:
[operations/puppet@production] Serve WebP variants for the hottest thumbnails

https://gerrit.wikimedia.org/r/434055

TheDJ awarded a token.Nov 5 2018, 1:54 PM

Change 472098 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/puppet@production] Lower WebP thumbnail hotness threshold

https://gerrit.wikimedia.org/r/472098

Change 472098 merged by BBlack:
[operations/puppet@production] Lower WebP thumbnail hotness threshold

https://gerrit.wikimedia.org/r/472098

Change 472436 had a related patch set uploaded (by Gilles; owner: Gilles):
[operations/puppet@production] Lower WebP thumbnail hotness threshold further

https://gerrit.wikimedia.org/r/472436

I've checked briefly ~100000 images requests on an esams Varnish server, with the current threshold only 0.035% of image responses are image/webp.

Our efforts to deploy WebP happen to be very timely, as I've just learned that Edge supports it as of last month, and Firefox 65 has just added support as well, with its general release scheduled on January 29.

Change 472436 merged by BBlack:
[operations/puppet@production] Lower WebP thumbnail hotness threshold further

https://gerrit.wikimedia.org/r/472436

Change 474693 had a related patch set uploaded (by Ema; owner: Ema):
[operations/puppet@production] Avoid serving WebP thumbnail variants to Opera

https://gerrit.wikimedia.org/r/474693

Change 474693 merged by Ema:
[operations/puppet@production] Avoid serving WebP thumbnail variants to Opera

https://gerrit.wikimedia.org/r/474693

Gilles moved this task from Blocked to Doing on the Performance-Team board.Dec 5 2018, 4:01 PM
Gilles added a comment.EditedDec 20 2018, 9:50 AM

Expanding the amount of WebP thumbnails we serve is blocked on T211661: Automatically clean up unused thumbnails in Swift

Gilles changed the task status from Open to Stalled.Dec 20 2018, 9:51 AM

I've checked briefly ~100000 images requests on an esams Varnish server, with the current threshold only 0.035% of image responses are image/webp.

Our efforts to deploy WebP happen to be very timely, as I've just learned that Edge supports it as of last month, and Firefox 65 has just added support as well, with its general release scheduled on January 29.

Firefox 65 is released.

Gilles moved this task from Doing to Blocked on the Performance-Team board.Feb 19 2019, 9:43 PM