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
