Optimizing images for mobile: right format, right size, right place, right device

As we have learned from the previous columns in this series, images are the major contributor to bloated, slow-loading mobile pages.

This column focuses on optimizing images for mobile, including responsive images and other clever methods for stopping images ruining mobile user experience.

By way of illustration, let’s take a look the homepages of three of the world’s largest supermarkets: US giant Walmart, UK giant Tesco and German giant Lidl. The image below shows how the homepages look on an iPhone 7 using the tool Mobilizer.

Image shows: Snapshots of the mobile homepages of Walmart.com, Tesco.com and Lidl.de.

All three sites illustrate how heavily retail sites depend on images to highlight the various departments and promotions. We will consider later the impact this has on page size. But first let’s consider the different approaches the retailers take to reducing the impact that images have on the space.

Tesco.com, like many mobile/mobile friendly sites, uses a single column design. Its images span the entire width of the column (often referred to as a container). This means that only two or three of the departments/businesses are visible above the fold – i.e. what is visible on the device screen without scrolling. And it creates a long webpage (twice as long as pictured, below).

Walmart.com uses two image techniques to use its mobile real estate more efficiently. The first is the slider or carousel which allows the user to scroll horizontally through a number of images. There are three sliders, one at the head of the homepage contains five full-width near-identical (nonsensically) ads for free shipping.

The other two sliders each house an additional dozen images, though smaller than the first, of which two to three are visible on screen at a time.

The second space saving effort on Walmart.com is a series of 18 tappable small images (with text), three per column width to represent the departments. This sensible approach allows customers quickly pick out the required department without needing to use the menu, search or horizontal scroll. Reducing the size of the images reduces the need for vertical scrolling by a factor of four compared with Tesco’s full width images.

Lidl.de‘s homepage has even more sliders than Walmart. Two of the four sliders are above the fold. There are two carousels of full width images and two with smaller images.

As noted in the previous column, sliders may save space, but they may not be an effective way to deliver content.

Which is the right approach? The problem with image optimization is that there are no hard and fast rules. Image optimization is always going to be a careful balancing act between user experience, attractiveness and page performance.

Raluca Budiu, Director of Research at Nielsen Norman Group:

“Because the screen is small on mobile, too small images may offer too little information, and too big images may slow down the page too much. We recommend that you start with a modest size image and allow people to zoom in (or download a larger picture of the image).

Most of the time huge images are not a good idea — their information density is low, and they require people to wait for the page to load and/or to scroll down for more content. This is a common problem with responsive one-column designs: because images are supposed to fill up the whole container width, we often end up with huge images that carry little information compared to their size.”

Of the three featured retailers, Walmart’s departmental images seems to best fit this ‘small, but big enough’ balance; however some images would benefit from greater clarity, and a closer crop on mobile. On the homepage there is no option to zoom in, but elsewhere on the site, product shots will tap through to a larger image, with more product information.

So how do all these images affect page performance?

httpArchive tests the top 1 million sites several times every month. On Feb 15, 2017, these three homepages achieved the following scores for load times, page size, requests (a request is the number of times a browser is required to download an additional piece of content, such as an image) and image size:

  • Lidl.de took 32.7 seconds to load 2409KB of data over 191 requests. Images accounted for 1630KB and 64 requests.
  • Walmart.com took 21.9 seconds to load 1850KB of data over 101 requests. Images accounted for 862KB and 59 requests.
  • Tesco.com took 10.5 seconds to load 597KB of data over 27 requests. Images accounted for none of this (see below for an explanation).
  • The average page size for the top 100 hundred global sites (of which Walmart is one) is 864KB, with 59 requests.
  • Average load time is unfortunately unavailable, but on average images accounted for 468KB and 29 requests.

httpArchive uses WebPageTest to test pages. So should you.

So where did the Tesco.com images go?

Peeking at the source code, it appears that Tesco.com is using a technique called Data URIs (uniform resource identifier). This changes the image into a long string of code (looks meaningless to a human, but is perfectly understandable to modern browsers) which is embedded within the page HTML.

Data URIs reduces the number of requests and downloads a browser needs to make. For an explanation, see this Treehouse tutorial.

Is image size/weight an issue? How do you reduce it?

There is no set-in-stone rule for how small a mobile image should be – it’s a trade-off between quality and page size. But a good guideline is to benchmark against the 100 most popular sites. According to httpArchive, the average JPG is 29KB and the average PNG is 16KB.

Graph shows: The average individual response size for content for the top 100 sites.

The largest images on Walmart.com, according to httpArchive/WebPageTest are the five free-delivery banners in the carousel at the top of the Walmart.com home page weigh in at 124KB to 138KB.

Google’s PageSpeed insights suggests that compressing these images reduce the size of these images by 73% each, which would save Walmart 500KB or 27% of the total page weight. Arguably, it would be far more effective to delete four of the banners and compress the fifth.

The largest images on Lidl.de, according to httpArchive/WebPageTest are those in the carousel of three at the top of the page which weigh in at 134KB to 194KB (the fattest is the fish & chips), but other images are over 100KB, including the Super5 ad.

Google’s PageSpeed insights is less helpful for Lidl.de, it saves a healthy 189KB, but this is only 8% of the homepage total weight.

Compression tools

Reducing the weight of an image is partly about saving the image at the appropriate size and resolution (number of pixels) and partly about compressing the image. Some creative tools, such as Photoshop, will afford some compression, but often not enough, especially with larger image types such as PNG.

There are a number of tools that will very effectively compress images individually or in batches of images. For example the homepages image above was compressed using TinyPNG resulting in a 79% reduction in weight.

For a comparison of the leading compression tools see GitHub.

Should you use different sized images for mobile, tablet and desktop?

When designing separate websites for mobile, tablet and desktop, whether that is via dedicated URLs (site.com and m.site.com) or serving different sites via a single URL (adaptive web design), it is implicit that images ought to be appropriately sized for the largest device in that category.

The position is perhaps less clear with responsive web design (RWD). With RWD, the principle is to serve the same website to different devices, using CSS to format the content according to the device capabilities and screen size.

This doesn’t mean, though, that websites should necessarily adopt a one-size fits all approach to images, explains Alex Painter, Web Performance Consultant at NCC Group:

“Pages are often slow on mobile because of a failure to deliver images appropriately sized for the viewport. The popularity of responsive design may be partly to blame – the idea that the same content can be reflowed so the layout works in any viewport can mask the fact that imagery hasn’t been optimized for mobile.

Plenty of sites deliver the same images on desktop as they do on mobile – with mobile versions just scaled down to fit. This might not be immediately obvious to end users with high-end devices on fast, reliable networks. But it can make websites completely unusable for people with lower spec phones or with poor connectivity.

 There are two reasons why this is a big problem. The first is simple – it just takes longer to deliver an unnecessarily large image over the network. The second is often overlooked: the mobile device has to work hard to a) decode and b) scale down the image. This is expensive in terms of processing power and memory.”

But it doesn’t have to be this way. Helped in part by the advocacy of the Responsive Images Community Group, the HTML specification now makes it easier for developers to create a number of alternate images for different device types – to suit different screen sizes (viewport), resolutions (number of pixels) or device capability.

The webpage HTML tells the browser which of these images to select for screens up to a maximum width and if the image should take up all or just part of the screen width.

Previously, some developers would use JavaScript to specify the use of different images, but using the HTML <picture> element should be more efficient, reducing the extra code and requests that slow down page load times.

Alex Painter:

“Delivering the right image for the viewport is now reasonably straightforward. We’ve had CSS media queries for background images for some time, but until recently images referenced in the HTML was more of a problem.

Now, we have the responsive images specification: the <picture> element, with the srcset[set of alternative image sources] attribute and sizes attribute that make it possible to define which image should be delivered for which viewport width (or to allow the browser to make the most appropriate choice from a selection of images).

The spec is now very well supported by browsers, and developers should ideally be using it rather than using JavaScript to achieve the same end.”

Responsive images in action: a dog cropped closer for smaller devices. Source: Responsive Images Community Group

Who is using responsive images?

A peek at the source code of the three retailers confirms that none are yet using the <picture> element, but then nor is Amazon, Facebook, BBC, or other sites examined.

Would they benefit?

It appears from the source code and examination of the larger images that both Lidl.de and Walmart.com are using the same images on desktop and mobile.

Serving different images to each platform potentially offers several advantages:

  • Allows the website to show a larger, higher resolution image on the desktop.
  • Reduces the picture sizes and total page weight and thus speeding up mobile load time.
  • Enables the mobile site to show a zoomed in image on mobile. (Note the cropped image of the dog above).
  • Retailers can display Mobile-Friendly Hero Images on mobile while sticking to traditional pack shots on larger displays.

Image formats

The most common formats for images used in mobile/mobile-friendly sites are JPEG 46%, PNG 28%, GIF 23% and SVG 1% according to httpArchive.

Graph shows: image requests by format. JPG is most popular with 46%. Source: httpArchive February, 2017

Using an inappropriate image format can increase file size and effect quality when images scale for different screen sizes.

There are two types of web image: raster and vector. The first is made up of dots (like a digital photograph), while the second is made up of lines and shapes. JPEG, PNG and GIF are raster. SVG is a vector. SVG is a newer format not as widely used (yet), but is recommended for responsive design sites by this course on Responsive Images from Google and Udacity.

We’re not going to dwell on this huge subject. There are pro and cons for each, and every web designer has a different opinion and favorite formats. You need to research your own company policy, but in general:

  • JPEG is most commonly used for web photographs
  • GIF is common for animations as well as simple graphs, icons and logos
  • PNG is common for higher quality graphs, logos, icons and other illustrations and photos with graphical effects
  • SVG is good for graphs and logos, page headers – things that are designed by an illustrator.

For more information on format types and sizes, see Google’s guide to optimizing images.

Alternatives to traditional images

Webpages are made up of many small images, such as icons and buttons. If these are made using individual GIF/PNG/JPEG images, it all adds to the page size and each one requires an individual browser request, which can slow down page load time.

Three methods that can help keep page size and image requests down are:

  • CSS sprites – combines a collection of smaller graphics into a single CSS file. N.B. Overloading sprites with too many or too large graphics will be counter-productive.
  • Icon fonts – is a library of icons sent as one single file.
  • CSS shapes – are shapes built using CSS, rather than as a traditional image

Mike D’Agruma Lead Front-End Web Developer, E-volve Creative Group:

“To save on file size, I generally stay away from loading larger, more popular icon libraries, and use Fontastic to create my own custom icon fonts. This method works extremely well on a variety of levels: 1) As I’m only using a small number of custom icons, the font file size is drastically smaller; 2) Icons are created with SVGs, which ensures they’ll be extremely crisp on devices; 3) You can’t beat this option for flexibility, as font icons are extremely customizable with CSS.

Another great way to safe on time, file-size and server requests is to use CSS to create shapes – you can create most shapes and add as many effects and transitions as you’d like with CSS.

 Take Summit County Metro Parks mobile site as an example, in the header section alone, I was able to use a combination of CSS shapes and font icons to create what could’ve been six different images. Activating the mobile menu shows an example of a CSS-shape animation (the hamburger menu morphing into an “X”), and the use of an additional icon on the right side of accordion triggers shows open and closed states.”

Screenshot of Summit County Metro Parks mobile site, there are six small button icons in the header.

Web design techniques for improving perceived load time

When you have trimmed the fat, removed the unnecessary images and optimized the remainder, but the page is still not loading fast enough – what do you do? Cheat.

Make sure the most important stuff loads first, says Raluca Budiu:

“When a page loads, make sure that the text loads first, so that people can start scanning the content. As images load, don’t shuffle the already loaded content around — it will cause readers to lose their place on the page, and sometimes they will even click on the wrong link because the right target unexpectedly moved.”

There is a difference between perceived load time and actual load time. All that matters to the user is that the content on they are looking at, or for, is available. They do not want to be staring at an empty screen while the browser fetches images they may never see.

There are three common techniques for delivering this. Robert Gaines, a Kansas, US-based, web and app developer explains:

 “1. Deferred loading, or delayed loading, uses JavaScript to stop images and other assets loading until after the main content of a webpage has finished loading. Deferred loading reduces the amount of time it takes for a webpage’s primary content to render, but reduces the need to cut images that would otherwise slow down a webpage.

2. Lazy Loading loads assets when and as they are needed. So content is loaded above the fold first, then below the fold as the user scrolls. With image galleries – such as product searches on retail sites – thumbnail images are used, larger images are only loaded when a corresponding thumbnail is clicked.

3. Progressive image loading first loads low quality images while a webpage is being rendered and then replaces them with high quality images after primary content has finished loading. Progressive image loading balances performance with visual appeal. Unlike deferred loading, it doesn’t leave users waiting for secondary images to load after primary content.”

Tools such as Photoshop allow images to be saved as progressive JPEGs, or interlaced PNG, which will load in the way described.

This course on Responsive Images from Google and Udacity is a good introduction to this subject; it is aimed at web developers, but everyone will benefit. You can skip the coding exercises.

This is Part 41 of the ClickZ ‘DNA of mobile-friendly web’ series.

Here are the recent ones:

How to fix your bloated mobile website: fewer, better, smaller images

Average mobile webpage is now 2.2MB, 68% is images: let’s trim the fat

Why brands should care about brand safety in mobile advertising

Andy Favell is ClickZ’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.

Related reading

A QR code which leads to the URL for the ClickZ article about QR codes. Meta.