Server-Side Image Resizer
I began with the expectation that I would be writing this service myself, but as I researched conventions and best practices, I came across ImageResizer and realized that anything I tried to do would essentially be a copy of this. We went with the Performance license because we knew that caching is a must for a production environment. We have also found the need for the PrettyGifs plugin that comes with that license. ImageResizer works best as an IIS module, intercepting requests and applying any image adjustments in the query string. I like this approach because it means that if we someday remove the service, we don't have a bunch of dead links to tend to; the original image will get served as expected. The only hiccup we came across was that all .NET applications running under the main need to have the ImageResizer dlls in their bin directories too, but not a huge deal.Srcset + Sizes
While thepicture element seemed to received all of the publicity during the developer driven responsive images campaign, the information pointed to the srcset + sizes variant as the best fit for our needs. Eric Portis has the best explanation I've come across for implementing srcset + sizes. Interestingly, several articles have come out recently talking about how srcset + sizes is most often the best approach.
Our site CMS is Hannon Hill's Cascade Server, which is heavy on XML as a data mechanism and XSLT for HTML output. While working in this framework often feels archaic, it ideally suits implementing img srcset + sizes without needing anything from the content and asset editors. The content goes through a couple of XSL transforms before it's output as HTML, which means that we can easily add the srcset and size attributes to any image elements that we want. We started with the lowest hanging fruit, our gigantic landing page slider images, and by the end we were transforming img elements in all the content, sidebar, and landing page areas.
For the sizes, we looked at our analytics to find the most common resolutions, and then for each content "well" in the layout, we calculated the size needed at each of those resolutions. That went in as the sizes attribute, and the srcset attribute was just a matter of taking each of those sizes and denoting it in the query string for the image. The ImageResizer takes care of generating and caching the requested sizes.
This means that the marketing team can upload one image, the biggest they have, and not worry about resizing it for the many places it may be used. Anyone can use the images, in any place, without any consideration about what size to use. The ImageResizer and the XSLT make sure that the HTML output is good and that the right sized image is being served. And by focusing on our most common screen resolutions, over 80% of our site visitors are getting exactly the right sized image.
Picturefill
At this point we have a server-side image resizer and responsive images markup, but browsers don't natively support srcset + sizes yet. Picturefill covers the gap here. It wasn't until Mat Marquis announced that the picture element and the new srcset + sizes syntax were on the verge of browser implementation at An Event Apart Atlanta that I felt confident in a responsive images solution that wasn't a hack, and when picturefill 2.0 was released, with spec-matching syntax, I knew this would be our implementation. Picturefill 2.0 is a true polyfill, meaning that it only acts to replicate missing native functionality. If the browser supports responsive images, then it does nothing. As browsers start shipping this functionality, we can remove the polyfill and leave those using browsers without support with the fallback. Picturefill recommends not using a src attribute in img elements and letting the alt text be the fallback. The native implementation's fallback is the src attribute; that's the image to serve for browsers that don't support responsive images. Picturefill recommends against it because it means a double download. Browsers will download the image in the src attribute, picturefill will do it's math and src swapping, then the browser will download the new image. We decided on a mobile first approach, using the smallest size image for the src. So, yes, it gets downloaded, but there's no penalty for small screens, and the gains far outweigh the cost as screen sizes increase. Once browsers support this natively, it won't get downloaded, and when support reaches the point where we can remove the polyfill, browsers without support will just get the small image.This implementation has been in production for two months now. I'm very proud of it, from the programmatic server-side image resizing to the absolute absence of any changes to workflows.