Speed is a feature and one thing that can slow down web apps is clients waiting to download images. To speed up image downloads and conserve bandwidth, the good folks of Google have come up with a new image format called WebP (“weppy”). WebP images are around 25% smaller in size than equivalent images encoded with JPEG and PNG (WebP supports both lossy and lossless compression) with no worse perceived quality.
This blog post shows how to dynamically serve WebP-encoded images from ASP.NET to clients that support the new format.
One not-so-great way of doing this is to serve different HTML depending on whether clients supports WebP or not, as described in this blog post. As an example, clients supporting WebP would get HTML with <img src="image.webp"/> while other clients would get <img src="image.jpeg"/>. The reason this sucks is that the same HTML cannot be served to all clients, making caching harder. It will also tend to pollute your view code with concerns about what image formats are supported by browser we’re rendering for right now.
Instead, images in our solution will only ever have one url and the content-type of responses depend on the capabilities of the client sending the request: Browsers that support WebP get image/webp and the rest get image/jpeg.
I’ll first go through creating WebP-encoded images in C#, then tackle the challenge of detecting browser image support and round out the post by discussing implications for CDN use.
Serving WebP with ASP.NET MVC
For the purposes of this article, we’ll assume that we want to serve images from an URI like /images/:id where :id is some unique id of the image requested. The id can be used to fetch a canonical encoding of the image, either from a file system, a database or some other backing store. In the code I wrote to use this, the images are stored in a database. Once fetched from the backing store, the image is re-sized as desired, re-encoded and served to the client.
At this point, some readers are probably in uproar: “Doing on-the-fly image fetching and manipulation is wasteful and slow” they scream. That’s not really the case though, and even if it were, the results can be cached on first request and then served quickly.
Assume we have an Image class and method GetImage(int id) to retrieve images:
private class Image
{
public int Id { get; set; }
public DateTime UpdateAt { get; set; }
public byte[] ImageBytes { get; set; }
}
We’ll now use the managed API from ImageResizer to resize the image to the desired size and then re-encode the result to WebP using Noesis.Drawing.Imaging.WebP.dll (no NuGet package, unfortunately).
public ActionResult Show(int imageId)
{
var image = GetImage(imageId);
var resizedImageStream = new MemoryStream();
ImageBuilder.Current.Build(image.ImageBytes, resizedImageStream, new ResizeSettings
{
Width = 500,
Height = 500,
Mode = FitMode.Crop,
Anchor = System.Drawing.ContentAlignment.MiddleCenter,
Scale = ScaleMode.Both,
});
var resultStream = new MemoryStream();
WebPFormat.SaveToStream(resultStream, new SD.Bitmap(resizedImageStream));
resultStream.Seek(0, SeekOrigin.Begin);
return new FileContentResult(resultStream.ToArray(), "image/webp");
}
System.Drawing is referenced using using SD = System.Drawing;. The controller action above is fully functional and can serve up sparkling new WebP-formatted images.
Browser support
Next up is figuring out whether the browser requesting an image actually supports WebP, and if it doesn’t, respond with JPEG. Luckily, this doesn’t involve going back to the bad old days of user-agent sniffing. Modern browsers that support WebP (such as Chrome and Opera) send image/webp in the accept header to indicate support. Ironically given that Google came up with WebP, the Chrome developers took a lot of convincing to set that header in requests, fearing request size bloat. Even now, Chrome only advertises webp support for requests that it thinks is for images. In fact, this is another reason the “different-HTML” approach mentioned in the intro won’t work: Chrome doesn’t advertise WebP support for requests for HTML.
To determine what content encoding to use, we inspect Request.AcceptTypes. The resizing code is unchanged, while the response is generated like this:
var resultStream = new MemoryStream();
var webPSupported = Request.AcceptTypes.Contains("image/webp");
if (webPSupported)
{
WebPFormat.SaveToStream(resultStream, new SD.Bitmap(resizedImageStream));
}
else
{
new SD.Bitmap(resizedImageStream).Save(resultStream, ImageFormat.Jpeg);
}
resultStream.Seek(0, SeekOrigin.Begin);
return new FileContentResult(resultStream.ToArray(), webPSupported ? "image/webp" : "image/jpeg");
That’s it! We now have a functional controller action that responds correctly depending on request accept headers. You gotta love HTTP. You can read more about content negotiation and WebP on lya Grigorik’s blog.
Client Caching and CDNs
Since it does take a little while to perform the resizing and encoding, I recommend storing the output of the transformation in HttpRuntime.Cache and fetching from there in subsequent requests. The details are trivial and omitted from this post.
There is also a bunch of ASP.NET cache configuration we should do to let clients cache images locally:
Response.Cache.SetExpires(DateTime.Now.AddDays(365));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetMaxAge(TimeSpan.FromDays(365));
Response.Cache.SetSlidingExpiration(true);
Response.Cache.SetOmitVaryStar(true);
Response.Headers.Set("Vary",
string.Join(",", new string[] { "Accept", "Accept-Encoding" } ));
Response.Cache.SetLastModified(image.UpdatedAt.ToLocalTime());
Notice that we set the Vary header value to include “Accept” (as well as “Accept-Encoding”). This tells CDNs and other intermediary caching proxies that if they try to cache this response, they must vary the cached value based on value of the “Accept” header of the request. This works for “Accept-Encoding”, so that different values can cached based on whether the response is compressed with gzip, deflate or not at all, and all major CDNs support it. Unfortunately, the mainstream CDNs I experimented with (CloudFront and Azure CDN) don’t support other Vary values than “Accept-Encoding”. This is really frustrating, but also somewhat understandable from the standpoint of the CDN folks: If all Vary values are honored, the number of artifacts they have to cache would increase at a combinatorial rate as browsers and servers make use of cleverer caching. Unless you find a CDN that specifically support non-Accept-Encoding Vary values, don’t use a CDN when doing this kind of content negotiation.
That’s it! I hope this post will help you build ASP.NET web apps that serve up WebP images really quickly.
