Partner Login Customer Login

Content & Commerce

Discover the latest thoughts from the Amplience team and partners about Retail Engagement.

Solve responsive design — give your images 'smarts'

March 17th, 2016

Our Content Delivery Network (CDN) stats from Black Friday clearly show that 53% of digital media is delivered to mobile devices, and over 14% of media is delivered to tablets. With this in mind, it still surprises me how many mobile webpages are weighed down by megabyte upon megabyte of images. Responsive sites are often the worst offenders, leaving businesses totally confused: “It’s responsive, so what’s the problem?”

The problem is that the developers have made the page responsive, but not the images. Responsive design has given web pages the intelligence they need to dynamically adapt to any screen size – now, the same evolution is required for images, which also need to adapt with those responsive environments.

In my previous blog “Responsive images – a ticking time bomb?”, I discussed how new HTML elements ‘SCRSET’ and ‘Picture’ provide better ways of supporting responsive images. I also covered some of the downsides, such as complicated frontend development and the exponential growth in images which leads to escalating costs, complex media production workflows and less business agility.

In this post I’ll discuss how to use the Amplience imaging system my team and I have been developing to alleviate the problems associated with delivering images responsively, and build responsive sites with responsive images (like my demo site, ).

Avoid image management becoming a burden

One way to manage images is to turn your creative team into a factory, churning out image variant after image variant (duplicate images with varying sizes and dimensions required to fit responsive designs), relying on naming conventions and hardcoded image paths, while boring your developers to death with constant URL changes.

An easier method is to simply use fewer images. To do this, we eliminate the necessity to have thousands of variant image files by using a single master image to generate all the responsive image variants you need, whenever you need them.

This Dynamic Media method from Amplience generates all image variants using URL parameters such as its size (width/height/quality/crops/format etc). The result is a creative team remaining creative, your developers being more productive and you keeping some sanity – as well as stopping your image management costs from escalating.

How not to do it – Example using static image variants In this example, a static image on a webserver is required for each variant. This means a designer has to manually create ten images, and save them using a naming convention (which is vulnerable to human error). The developers can then map them into the code as follows:

<**img** src=" **shoe.jpg**" **srcset**=" **shoe-160.jpg** 160w, **shoe-320.jpg** 320w, **shoe-640.jpg** 640w, **shoe-1280.jpg** 1280w">

<**img** src=" **dress.jpg**" **srcset**=" **dress -160.jpg** 160w, **dress -320.jpg** 320w, **dress -640.jpg** 640w, **dress -1280.jpg** 1280w">

This method means manually creating variant images for every single breakpoint – changing breakpoints means you have to start all over again, re-creating and remapping the images.

Example using Dynamic Media

As Dynamic Media uses one master image file to generate all the variants, you can change and add breakpoints as you wish without turning your designers into mindless Photoshop monkeys continually creating and re-creating hundreds of image variants.

<**img** src=" **shoe.jpg**" **srcset**=" **shoe.jpg**?w=160 160w, **shoe.jpg**?w=320 320w, **shoe.jpg**?w=640 640w, **shoe.jpg**?w=1280 1280w">

<**img** src=" **dress.jpg**" **srcset**=" **dress.jpg**?w=160 160w, **dress.jpg**?w=320 320w, **dress.jpg**?w=640 640w, **dress.jpg**?w=1280 1280w">

As you can imagine, in a real life scenario without dynamic imaging, the numbers of actual files you have to manage soon becomes so large that you’re basically pouring images into a bottomless bucket, and unable to keep track of them and their usage. Eventually you even become too afraid to delete images “just in case”, ending up with an unmanageable soup of media.

In contrast, the Anya Finn demo site has 11 images in three carousels that support 6 breakpoints, which results in 66 image variants required – but using dynamic imaging, I only have to manage the 11 master images, and changing breakpoints just requires a simple code change.

When we built Dynamic Media we added more than just image sizing; we support over 20 other parameters that give you full control over the image output and weight. These include ‘sharpening’ to keep resized images crisp, quality for managing JPEG weight, and noise reduction for clearing up artefacts. Play with the image service on our playground.

Art Direction, Not Image Production

Using Amplience Dynamic Media [LINK{, it starts to get really interesting when it comes to enabling Art Direction. When we built the imaging system we added all the features that are perfect for automating the image SRCSET variant lists. However, we soon realised that what you really need for responsive design are additional features that directly address Art Direction.

Aspect Ratio

Art direction relies heavily on image cropping, a feature we built into the imaging system from day one. However, we decided to simplify the work for front-end developers by removing the maths required to calculate the crops for every image, with a straight forward feature to generate images for a given aspect ratio. This is important as images in responsive design need to assume different aspect ratios. For example, you may use images with a 16:9 aspect ratio for desktop, a 4:3 for tablets and a square image on mobile. This is demonstrated in the Anya Finn demo where the carousel slides swap aspect ratio based on the four of the breakpoints (16:10,4:3,5:4,1:1)


Point Of Interest

Using only the aspect ratio is fine, if you’re happy blindly cropping from centre and don’t care about what you crop out of the image – however most designers want more fine grain control over the output of an image. We introduced Point of Interest to fully support Art Direction – this makes sure new image variants always display the most relevant content, no matter how it’s cropped. For example, the image below is typical of an image used in responsive sites, with a broad background that can be cropped to fit varying screens. However, the girl in the spotted dress is the main subject of the image but appears off-centre, which means we can’t just use the aspect ratio and central point to derive a new image. To generate an image with a completely different aspect ratio which makes as much sense as the original, you need the coordinates of the girl.

Original image sized to 500px


Image cropped to a Point of Interest


Obviously passing the point of interest in the URL, although very useful, places an overhead on front-end developers as they would need to know the point of interest for each image – a total pain and impossible to maintain. To simplify development further we can store the point of interest coordinates in the image meta-data and use this to generate images. If that isn’t enough we can take it a stage further and really get developers excited by exposing all these coordinates using a simple REST call.

The Anya Finn demo shows how effective using this method is, as each change in aspect ratio ensures the the Point of Interest is maintained.

Anya-Finn-3 Anya-Finn-4 Anya-Finn-5

The next question I always hear is “how much effort does it take to add all these Points of Interest?”. Well, although adding the metadata using our Micro Services API appeals to me on a deep and emotional level, we realised that most users would prefer a simple user interface. To this end, we created an app (for all those not overly excited by JavaScript and JSON) that makes adding these Points of Interest a walk in the park.


Now for the smarts

Images in Amplience are more than just dumb assets delivered to the browser. Developers can bring them to life by controlling their behaviour with settings, parameter passing, logical operators, metadata and advanced imaging features such as layering. Although passing everything in the URL means that images can be completely controlled by frontend developers, it can make developing frontend code more complex in cases where the sets of parameters are reused across image implementations, and developers want to encapsulate very sophisticated imaging techniques. This is where Transformation Templates (TTs) step in; these templates replace imaging code in the URL with a token ($template name$) that references code snippets to run on the imaging service.

Developers can create and publish the code snippets for image templates in the image service admin console – you can think of these code snippets as a ‘brain’ for your images. Examples of things these brains can be used for include:$bl-roundel$&w=500&offer=summer-sale-banner


This template uses the concepts above to generate a responsive image; this uses four breakpoints based on the parameter ‘VW’ that identifies the screen size.

This template goes further by overriding the original image with the roundel for a screen size below 640px.

The tools I’ve discussed here massively improve development productivity, creative output, and business agility while also preventing the escalating costs associated with responsive design. If you liked this, my next blogs will blow your mind with a deeper look into applying these concepts to content, as well as images. Watch this space!

John Williams, CTO, Amplience. Follow John on Twitter here or on LinkedIn here.

Back to top

Request a Demo


United States

Call toll free 866 623 5705
or +1 917 410 7189


Call +44 (0)207 426 9990

Contact Us

Developer Edition