Because nearly 50% of a typical page’s weight is made up of images, optimizing images is extremely important for running a performant site. Every byte you don’t have to transfer to serve your content means a leaner page and faster load times for your users. This tutorial covers the ins and outs of using the
srcset attribute, and how imgix makes the process easier.
Serving correctly-sized images is important because it can minimize bytes transferred and CPU overhead. The
srcset attribute is one of the best ways to do so today.
srcset & Display Densities
srcset provides a simple way to specify different images for different device resolutions. It allows sites to serve 2x, 3x, or higher versions of images to modern devices with high-resolution displays. Using it within an
img tag is easy:
While this delivers the best assets to users, it moves the burden to the service to generate and store each version of every asset. This can cause storage costs to balloon, and you may never serve every asset you generate. When dealing with a large library or with user-generated content, this is untenable.
With imgix, your entire image library is
Using srcset with imgix
Using the imgix
dpr URL parameters, we can simplify the amount of effort it takes to generate the
srcset attributes on our images. For this example, we will use the image located at:
We want to serve this image at 400 pixels wide:
We get an image tag that serves out the best resolution for each device, based on its device-pixel-ratio (DPR). imgix will automatically serve more pixels when given the
Calculating Device-Pixel Ratio
You can see that we’ve applied
dpr=3 to our 1x, 2x, and 3x assets, respectively. The
dpr parameter instructs imgix to treat the
w parameters as device independent pixels (also known as “CSS pixels”). Thus, the 400×300 image at
dpr=2 will actually be a 800×600 pixel image. The
dpr=3 image will be 1200×900 pixels.
This gives you the best of both worlds: full resolution for devices that support it, without delivering more data than necessary to devices that won’t use it. By using imgix, we only have to store the original asset and then manipulate it on the fly as we’ve seen above. This also removes the headache if and when a
4x device comes out. imgix currently supports up to
This practice works best with fixed image layouts. Using
dpr is currently widely supported.
sizes with Media Queries
A different approach to handling responsive images for fluid layouts is to use size definitions with
srcset. This solution gives you the ability to target sizes based off of media query definitions within a
sizes attribute. The browser will request the most appropriate image or—depending on the browser—will load the best image from the cache when available.
The following example demonstrates sizing three images with imgix at 1024, 640, and 480 pixels wide. Using the
sizes attribute, we are targeting two queries for behavior for the images.
At a viewport of
36em or above, the images will display at 1/3 the viewport width. Below that size, the images will display at the full size of the viewport. At those sizes, the browser will determine which image to load in when the page is rendering for the given target size.
Best Practices Using imgix
There is more to think about when delivering the best images possible with
srcset and imgix. imgix affords the ability to add additional operations to give you more control over your output images, and because they are defined in the URL, you can fine-tune your settings and make late-stage edits as decisions change.
One of the challenges of using
srcset is that you want to generate enough sizes so that most of your users are downloading images that are close in size to what they are seeing on the screen, but if you generate too many sizes you can end up impacting cacheability which could have a negative performance impact. Luckily, many of the imgix libraries can automatically generate an optimal
srcset for you.
fit=max parameter on an imgix URL will ensure that an image is never delivered larger than its original size. This way, when requesting a
dpr=3 image, there won’t be any image extrapolation. Read more about
fit in the documentation.
auto=format parameter will deliver lightweight WebP images for browsers that support it (Chrome, Firefox, etc.) and fall back to the original format for other instances. More modern formats like WebP can greatly cut down the amount of image data sent to the client, sometimes by as much as 35%. Read more about Automatic Content Negotiation in the documentation.
Use Variable Quality
dpr with imgix, you may want to consider adjusting the quality of your images. Setting the
q parameter to lower values for higher DPRs allows you to reduce the file size while maintaining a denser pixel set for your image.
This common practice is made easier with the Rendering API. Adjusting the quality works especially well with lossy formats such as WebP and JPEG.
Putting It All Together
Here is an implementation of these examples as applied to our
srcset DPR example:
Summary and Related Tutorials
Responsive imagery is a rapidly-changing area of implementation, and different methods are applicable to different use cases. Here are our other tutorials that touch on aspects of responsive design.