Page MenuHomePhabricator

Serve optimized WebP thumbnails as alternative to JPEG, PNG
Closed, ResolvedPublicFeature

Assigned To
Authored By
brooke
Oct 22 2010, 12:51 AM
Referenced Files
F3954059: capture_05012016_163352.png
May 1 2016, 2:38 PM
F3954056: capture_05012016_163337.png
May 1 2016, 2:38 PM
F3954055: capture_05012016_163328.png
May 1 2016, 2:38 PM
F3954062: capture_05012016_163452.png
May 1 2016, 2:38 PM
F3954057: capture_05012016_163335.png
May 1 2016, 2:38 PM
F3954061: capture_05012016_163518.png
May 1 2016, 2:38 PM
F3954058: capture_05012016_163343.png
May 1 2016, 2:38 PM
F3954054: capture_05012016_163323.png
May 1 2016, 2:38 PM
Tokens
"Barnstar" token, awarded by TheDJ.

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

Revisions and Commits

Related Objects

Event Timeline

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

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

capture_05012016_163323.png (381×491 px, 12 KB)

capture_05012016_163328.png (381×491 px, 12 KB)

capture_05012016_163337.png (381×491 px, 9 KB)

capture_05012016_163335.png (381×491 px, 14 KB)

capture_05012016_163343.png (381×491 px, 14 KB)

capture_05012016_163352.png (381×491 px, 16 KB)

capture_05012016_163446.png (381×491 px, 13 KB)

capture_05012016_163518.png (381×491 px, 14 KB)

capture_05012016_163452.png (381×491 px, 14 KB)

Gilles raised the priority of this task from Lowest to Medium.
Gilles added a project: Performance-Team.

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 added a revision: Restricted Differential Revision.Mar 29 2018, 7:08 AM

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

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

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

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.

I feel this task is WMF-only, and not meant to target MediaWiki (or MediaWiki-core). Currently it has been implemented (see related commits) but on the WMF-infrastructure level. No change has been made to MediaWiki core.

If that's the case, I'd suggest removing the MediaWiki-File-management component from this task, and instead create a new task for a true support of WebP thumbnails on MediaWiki core, so people interested in see this support on wikis out of WMF can track its progress or share ideas.

Krinkle subscribed.

@Ciencia_Al_Poder That's fair, yes. I do note that support for thumbnail services exist in core (not WMF-specific), but indeed Thumbor is not trivial to setup.

Krinkle renamed this task from Support optimized WebP thumbnails as alternative to JPEG, PNG to Serve optimized WebP thumbnails as alternative to JPEG, PNG.Oct 8 2021, 5:46 PM
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM
Krinkle assigned this task to Gilles101.

Subtask remains open (unfortunately) but there's nothing left to do within this task. Closing as such.