There are several good methods for serving responsive images on the web, and with support in all major browsers for the <picture> and <img> with 'srcset' and 'sizes' there’s no reason not to be using one of those implementations to serve up images. We use a combination of these elements and compressive images.

More About Responsive Images(external link)

Compressive Images

Here‘s a quick summary of the compressive images technique, “…a single high-definition but heavily compressed image is sent to all devices. This image is then scaled down when viewed on normal definition devices, where the compression artifacts tend to disappear in the process. When viewed on high-definition device screens, the device pixels are relatively small, so the compression artifacts are not highly visible.” Weiss, Yoav. “7.” The Smashing Book #5: Real-life Responsive Web Design. Freiburg: Smashing Media GmbH, 2015. N. pag. Print.(external link)

The Compressive Image workflow is not designed to replace the picture spec, but rather to compliment it. Whenever someone says you can get more for less it’s typically met with a bit of skepticism. Compressive images are no different as they promise to look good on both HiDPI and standard displays with a smaller file size—a physically larger file with less weight. To that end, let’s take a look at the workflow that satisfies both of these.

Example

Both images below are displayed at 375px x 211px, but the first image was saved and served at those dimensions with a compression of 78 and weighs 22kb, while the second image was saved at 750px x 422px (@2x) with a compression of 0%, weighs 15kb and is scaled down in the browser. Both images were optimized with ImageOptim(external link) which yieled an additional 11.6% savings. The images appear pretty close in quality, but the second one is 31.82% lighter in file size. The second image has twice the density of the first, so it also looks good on HiDPI screens. Note: If you‘re having trouble telling the difference, make sure you‘re viewing on a HiDPI screen.

It also should be noted that this technique works with the JPEG format. Because the PNG and GIF formats don’t offer the same type of compresison capabilities you would end up with much larger files than intended and they should not be used.

Cycling Standard Size Example
Image saved at 100% size, 22kb
Cycling Compressive Example
Image saved at 200% size and scaled down in browser, 15kb

The Process

1. Design @1x

  • Always design at @1x to easily export assets to any ratio
  • Ensure that any non-vector graphics and images can be scaled up to at least @2x

2. Exporting

  • Export images and non-vector graphics @2x of the size they are in the layout
  • Images should be saved as progressive and in JPEG format without any metadata
  • Compression should typically range between 0–30% on average
  • Use a tool like ImageOptim(external link) for additional compression, or in Sketch use the official Bitmap Compressor extension(external link)

3. Test

  • Test your results by viewing your image @1x scale on a HiDPI screen
  • The goal is the best quality with the smallest file size, to obtain that you may have to test several different compression settings to arrive at the desired result

One more thing…

Here’s a gotcha to keep in mind. Since we’re working with a responsive, mobile-first implementation these layouts likely only represent one instance in time. Often our design comps represent the start of a breakpoint and not the entire range, which means the images will likely scale up until the next breakpoint is reached.

Take a look at the example below. Images at the left breakpoint (XS) will scale until they reach the right breakpoint (SM). This means that they may scale to nearly the size of the larger image to the right before adjusting to new sizes in the next breakpoint. In this case the image you’d save out @2x would be based on the largest size in the layout before the next breakpoint is triggered.

An example of how an image will scale between breakpoints
Image scaling example