Page MenuHomePhabricator

Allow to render WebP thumbnails in addition to PNG/JPG in MediaWiki core
Open, Needs TriagePublic

Description

Currently, WMF has implemented some WebP thumbnailing support for images on their infrastructure, at the server level, without modifications to MediaWiki: T27611: Serve optimized WebP thumbnails as alternative to JPEG, PNG

This task is to allow MediaWiki to generate WebP thumbnails in addition to the current thumbnails being generated.

Currently, MediaWiki generates thumbnails with ImageMagick, with the same format as the original file (JPG->JPG, PNG->PNG, GIF-GIF) with some exceptions (SVG->PNG). The idea would be to generate also a WEBP thumbnail in addition to the current one.

While WebP format support is now more widespread, there should be a way for browsers to fallback to the JPG/PNG thumbnail. This would require MediaWiki to use the <picture> HTML element instead of the <img> one. The <picture> element allows to specify a list of sources the browser can choose from. It's a sort of content-negotiation feature on the client level instead of on the server level (which is how WMF has done it). The <picture> element can contain a nested <img> tag for compatibility for browsers that don't support HTML5.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture

Possible implementation:

  • A configuration variable to allow WebP thumbnails in addition to the current ones. Maybe with a list of possible file extensions to support (I'm not sure if animated GIF can be transcoded to WEBP or if browsers support that).
  • Use <picture> to render images instead of <img> tag, and add the sources with the WebP variants.

Event Timeline

While WebP format support is now more widespread, there should be a way for browsers to fallback to the JPG/PNG thumbnail.

In terms of nginx config I am using this:
https://www.lazutkin.com/blog/2014/02/23/serve-files-with-nginx-conditionally/

The summary of that link is pretty simple to get the idea:

map $http_accept $webp_suffix {
  default   "";
  "~*webp"  ".webp";
}
location ~* ^/images/.+\.(png|jpg)$ {
  root /home/www-data;
  try_files $uri$webp_suffix $uri =404;
}

The accept: HTTP request header of modern browsers includes image/webp. nginx (and probably other web servers) can recognize that and serve the webp in that case.

It might not be the cleanest solution because if the user downloads let's say a jpeg file it might actually be a webp file but with the jpeg extension. In effect, it's the same as Wikipedia's current implementation.

In any case (no need to nginx or above config) MediaWiki's core could generate a different HTML based on the browsers accept: HTTP request header. Two different HTML document versions in the cache however might be OK for a small wiki but too much for Wikipedia.


https://www.mediawiki.org/wiki/Extension:WebP

In any case (no need to nginx or above config) MediaWiki's core could generate a different HTML based on the browsers accept: HTTP request header. Two different HTML document versions in the cache however might be OK for a small wiki but too much for Wikipedia.

There's no need to store/serve different versions of HTML (with its implications) if MediaWiki outputs <picture> instead of <img> tags. That will let the browser choose the best supported format.