Responsive Web Design, Part 2 (2015)
Responsive Images
What Is The Responsive Images Problem?
In short, it’s the problem of efficiently loading appropriately sized content images that fit the page’s design. The emphasis here should be on “efficiently.” More than anything else, the responsive images problem is a performance issue. We want to load high-density images on high-resolution devices, and load images with larger dimensions on devices with wide viewports that need them; but just as importantly, we want to avoid the download of these images on devices that do not need them. We also want to do all that without introducing delays to the image download process, so as to not introduce regressions at page-load time.
The source of the problem is that to make a decision regarding the ideal resource to load, browsers need to take into consideration the screen’s device pixel ratio (DPR), the viewport dimensions, the image’s dimensions, and the final display dimensions of the image – and they need all this info pretty early in the page’s load.
While browsers can easily know the DPR and viewport dimensions at this stage, the image’s dimensions are only available to it after it downloaded the image. Its display dimensions are available only after all the relevant CSS is downloaded, parsed and the page is laid out. The image’s display dimensions can also be affected by the image’s physical dimensions, and by the dimensions of images around it in the page.
All these factors mean that a native solution to the responsive images problem has to provide browsers with the missing info as part of the markup.
Of course, in some cases you can use an SVG resource instead of a raster image and have it scale infinitely as far as needed. That option is thoroughly covered in Sara Soueidan’s chapter. Be sure to check it out.
However, SVG only makes sense for some images (e.g. computer-generated ones), and even then raster images may eventually be smaller than their equivalent vector-based images. In other cases, it may make sense to use a technique dubbed “compressive images5,” where 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. The downsides of that approach are that it only works for images displayed as fixed-width regardless of the responsive breakpoint, and it has a negative memory impact on non-Retina devices.
WHAT IS A PIXEL ANYWAY?
This may sound like a philosophical question, but there are multiple types of pixels that we need to be aware of to fully understand responsive images. A pixel (funnily enough, short for picture element) was originally defined as a single dot that a screen can display in a certain color, and it was originally dictated by the screen’s physical characteristics.
A CSS pixel, on the other hand, is defined in the CSS spec as an equivalent to the way a pixel of a device with 96dpi is seen from an arm’s length6. That’s a rather complex way of saying that CSS pixels may vary in size according to the intended viewing distance, but, on the other hand, should not vary according to the device’s screen characteristics.
Therefore, when high-resolution (AKA Retina screens) were introduced, they brought with them the concept of device pixel ratio (DPR), which was defined as the ratio between a CSS pixel and a device pixel.
On non-Retina screens, CSS pixels are probably the same dimensions as the physical device pixels (which means we have a DPR of 1). On higher-resolution screens, CSS pixels are larger than device pixels, which results in higher DPR values. Typical DPR values for today’s devices can range from 1 for low-end devices and up to 3 and even more for higher-end devices.
It is important to understand that when we’re discussing pixels in browsers, we are almost always referring to CSS pixels and not device pixels.
Now, since we defined DPR as the ratio between CSS pixels and device pixels, it is influenced by desktop browsers’ zoom (which changes layout and so increases the size of CSS pixels). That is the reason it is not rare on a desktop to see all kinds of fractional DPR values. On mobile, where the dominant zoom method is pinch zoom (which doesn’t have an impact on layout, but acts as a magnifying glass), DPR is not affected by zoom and is determined by the device’s characteristics.
Another definition we need to get familiar with is of the image’s intrinsic size. Every raster image has its native dimensions which are defined by the number of pixels it has in its rows (width) and columns (height). It’s important to note that these physical image pixels are displayed in the same dimensions as CSS pixels, unless we tell browsers otherwise.