Responsive Images - Development AND Design perspective



Hi there,

So for a while now at my company we’ve been working with responsive using Bootstrap

Something that we’ve always struggled with is getting the right image dimensions designed so that they are suitable for all breakpoints/devices (i.e. the images are clear and don’t have a big impact on site performance).

We’ve tried using high-resolution PSDs (300 dpi, obviously more akin to print than web) to get the right image size as a starting point (though this has performance issues - see my point about the third-party application used to resize) and have now dropped down to 72dpi for all designs again but this only suits some of the breakpoints (mobile images are blurry, especially on Retina displays).

We use a third-party application to resize our images - so we start with the highest resolution and then change the width defined within the URL to pull through a suitable image for that size (e.g. /images/1200/myimage.jpg can become /images/768/myimage.jpg). This application is a bit hit and miss when it comes to performance though as all images are generated by effectively “screenshotting” and resizing the image accordingly to create the variation, so starting with a high resolution image and requesting a lower resolution version can sometimes mean the filesize is higher, weirdly. The application will also happily “oversize” images (e.g. if I supplied the original at 1200px, I could request a 1500px version and it would generate it, but it would be low quality).

So, I guess what I’m looking for is some advice on how to develop for responsive images, but also how the design team can design for all breakpoints and supply the images for us to use in a PSD. Note that we will still be continuing to use the third party application for images but don’t necessarily have to use the resizing service.



I don't see there being a "one size fits all" solution. How you handle images will depend on the nature and use case for each image or type of image. Eg, the way you may deal with a full-screen background would be different to a small logo, thumbnail or medium size photo.
Though it does sound as if your system is flawed.

Not sure how/why that is happening, something is wrong. You earlier mention various figures in dpi, this is a largely irrelevant unit on-line/on-screen, you should be more concerned with actual width and height in pixels.

This also sounds flawed. Blowing an image up beyond its native size is rarely a good idea, you will both degrade quality and increase filesize. If you absolutely must blow an image up, keep it the same size and make it display bigger. But really you should inhibit up-sizing images altogether.

For breakpoints, it may be overkill to cater for all. For the most part I will just make images fluid and be done with it.
The only times I have used break points with images is in large backgrounds, so mobiles don't get the hi-res version, and using <picture> to swap out a banner to a mobile version, but those only deal with two versions of an image.

If catering for retina, I will use an image of double resolution, but ramp up the compression to lower file size. This works, as the increased resolution compensates for the compression artefacts.
You can of course use resolution in media queries (also in picture and srcset) but still, stingy compression combined with fluidity can go a long way without those complications.

There is also the image format to consider. For logos, graphics, icons, Etc, I'm SVG all the way and forget the above issues. Then you have only the photos to deal with.

But again, each site, image, image use, may require a suitable tailored approach.


Apologies, I should clarify. Logos are handled via SVG and aren’t resized using the third-party application.
My point concerns only content-related images, such as those featured on the homepage and landing pages which fit a set structure across multiple breakpoints. For standalone pages where the image sizes can differ I agree that there is no “one-size-fits-all” solution though.

The homepage and all of the landing pages all have a set structure in terms of their widths (so banners are a maximum height and width, the same with smaller boxes). Homepage does differ slightly for one element as it is always set to go full-width, but set to go to a maximum width overall.

Agreed - this is part and parcel of the third-party application it seems - it will just blindly resize to whatever we set it at, regardless of the original image’s width. Regarding your point about dpi/actual width - should it be the case that we create a PSD which is the standard 72dpi but each element is double the width of the maximum actual width, thereby we get a “2x” version of the image and can downsize from there?

Agreed, as above it is a very flawed application in that sense, since it doesn’t take into account the original image width, as explained above - it’s very frustrating to work with! haha. We rarely intentionally upsize images since it obviously increases the filesize but also blurs the image as a result.

Great, that all sounds logical from a development point of view, but what about when it comes to the Design Team creating PSDs? Do you recommend that they double the size of the element within their designs, thereby giving us a 2x image?

…or would you say that they need to supply designs for each breakpoint so we can get the images we need for each device size? The only problem with the latter is that there is a script that automatically switches the width parameter depending on the screen size, but still keeps the same filename - since the filename is shared we can’t upload different images for each breakpoint unless they have different names (i.e. on my personal sites I’ve created subfolders for each breakpoint and supply the images that way). Therefore, we’d have to add these as separate inline images which will have a performance impact on the page load speed.



Sorry for the bump but does anyone have any further thoughts as to how this issue could be resolved?

Many thanks!


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.