eCommerce Image Optimization: a Beginners' Guide

The problem is that images are large. They’re one of the main culprits of slow load speeds, and slow load speeds cost you conversions. We’ve talked about image optimization before but—with how critical images are in this field—we thought it would be good to go into some more detail.

It’s also a fairly technical topic that can be difficult to get your head around if you’re a business owner without any tech expertise. Our aim here is to break things down in an accessible way—if you’re a developer or a designer, we may be treading over a lot of familiar ground, though I do hope I’ve got a trick or two you didn’t know. If you’re a business owner, you’ve definitely come to the right place.

Image optimization is rarely a case of “one weird trick”—it tends to be a culmination of smaller tricks that each shave off 0.2 of a second’s load, but come together to save you big time. Let’s break it down:

It’s an obvious point (and one we’ve covered before) but for those in the back: don’t rely on HTML to resize your images. Here’s the code for an image in HTML:

<img src=“bumblebee.jpg” alt=“a nice bee!”    
style=“width:100px;height:75px;”>

If you’re using a simple eCommerce interface like Shopify, this is what’s happening under the hood. Here’s the problem: if bumblebee.jpg is 10000×7500, then your site has to load that whole picture every single time. The user sees a tiny picture, but the code sees a huge picture and has to load it all, then shrink it. If you edit the picture to be the right size before uploading, you’re saving yourself a huge amount of bloat while losing almost nothing.

Depending on the image format, there’s going to be a lot of metadata attached that you don’t really need. Photographs in particular are guilty of this: they contain a package of EXIF data that has information like where the picture was taken and the technical specifications of the camera. Free tools like GIMP have options to strip this data away, which can slash file sizes down.

On the other hand, there’s metadata that you do want: well-organised metadata is a great SEO tool. One of the big ones is file names: most users will upload a file using whatever default name it was given, but they’re failing to take advantage of critical keyword space. If you’re selling a tan winter jacket, then saving the product picture as tan-winter-jacket01.jpg is an easy, white hat way to get some extra keywords on your page that also helps you find it if you need it later.

Tying in with this is alt-text. In the bad old days, black hat SEO specialists would overload them with massive keyword strings. Google doesn’t look kindly on this, and it should be avoided. What you’re aiming for is accurate alt-text that still contains your keywords. A good way to think about it is this: folks with impaired vision often use screen-readers that will say out loud the text they read, and when they come to an image, they’ll read out the alt-text. When writing alt-text, imagine you’re vision impaired, and think about what sort of text would be helpful in this space. More often than not, the helpful text contains your keywords.

This sort of metadata management is a quick, easy SEO boost that doesn’t increase file size, and those are worth their weight in gold.

JPG is the most popular image format on the internet, and most guides will point straight to it as your #1 pick for everything. There’s a problem: JPGs are what we call a lossy format—compression works by destroying data, which degrades picture quality over time. Compression often happens without your input—many image viewers, email clients, and chat services will compress images automatically, so sending a JPG through an email chain will quickly degrade its quality and you’re going to see nasty compression artifacts springing up all over the place.

   
compression artifacts in action

Lossless JPG formats like JPG XT have existed for a long time, but still haven’t really been fully adopted, mostly because it’s hard to create digital cameras that natively encode into them, among other reasons. JPG XT supports higher quality images that can be decoded by something that can read a regular JPG, producing a lower quality image.

Accessible lossless formats like PNG won’t degrade when modified. This makes them a lot safer and easier to handle. PNG doesn’t have the same colour space as JPG: the more realistic a picture is, the worse it’s going to look. Photographs saved as PNG won’t degrade, but they can look washed-out and unattractive depending on how you convert them and how the browser handles them (this is mostly fixed in modern browsers). PNG is a better choice for simpler images that you intend to edit, reuse, or move around a lot.

PNG images also offer an advantage that’s rarely utilized: Depending on the type of image, they can be smaller than a JPG. If the image consists of mostly text, simple colors or gradients, or other things that are not photo-like, the stage of JPG compression that introduces loss can actually introduce more data into the image, while producing a lower quality picture, which is much more noticeable with clean lines and text. It’s best to experiment with this to find what you should save as a PNG, or you could batch export everything at your preferred JPG compression level and as a PNG, and keep the smaller files.

When to use a JPG: for photographs, high-quality images, large images     
When to use a PNG: for logos, graphs, line art, text art

Having the right format doesn’t directly lower site speed, but it helps us to have consistently higher-quality images, which gives us more space to change things while keeping them attractive. There are other formats than JPG and PNG of course (we’re rather partial to a good SVG in the right place, ourselves—proper GZip compression keeps the files small but keeps them as vector images) but they’re two very popular formats that are easy for less technical folks to work with.

You want to squeeze a little bit extra out of those big jpegs? Consider saving them as PJPEG—older baseline jpegs load top-to-bottom, while progressive jpgs load in a blurry, low-resolution version of the image first, then increase its quality as they load in fully. Not only does this deliver a cleaner and more modern UX, it loads 2–10% faster. Free tools like Jpeg.io will convert your jpegs to PJPGs, and do some extra optimization on the side.

Top: Progressive JPEG    
Bottom: Regular JPEG    
Note that PJPEGs don’t always load faster

Hey guess what? Fonts are images (specifically, collections of small vector files), and count when you’re trying to create a performance budget. Web fonts—typefaces designed specifically for web viewing, that get rasterized by your browser—are a wonderful optimization tool that are sadly underutilized. There’s a whole article there if you want to dive in, but here’s the short version: whenever you use an operating system typeface (say, Times New Roman), your OS has to handle the rasterization of the vector file for every single character. It tends to do so inconsistently, and can cause issues when working across different operating systems. Web fonts are specifically designed for web display, and are better-optimized for the realities of online content. If you want to go into detail on the technical side of things, the Google developers’ blog has a great writeup.

Shopify doesn’t use web fonts by default—setting them up is fairly simple from a code perspective, though requires some basic HTML. WooCommerce users can install the Easy Google Fonts plugin, though it will require a little bit of wrangling with the API code. Those with a bit more experience can go under the hood and use the CSS @font-face method to call from fonts.com.

Web fonts, when properly installed and deployed (by say, UI UX professionals) will look better, and will shave precious seconds off your load time. If you’re going it alone, here’s the short version:

I’d recommend one main typeface for titles and subtitles, then max 2 typefaces for body text. Roboto is pretty web-standard, and is the official Android typeface. It’s a nice easy san-serif that doesn’t call attention to itself. I’m personally a huge fan of the classic EB Garamond—as screens get better, serif fonts are becoming less of a liability, and Garamond is wonderfully classy

Especially if you’re going international, content delivery networks can give you a wonderful speed boost. A CDN is a network of servers spread around the world, which store your data and then serve it to users from the closest server hub. Say your servers are in Atlanta, but a customer logs in from Sydney. Rather than making your images jump all the way across the Pacific, a CDN can pull from a closer server in (say) Singapore.

There’s a small problem to this: since the images are coming from their servers (not your servers), it won’t be as good for your SEO. That filename keyword trick mentioned earlier? Doesn’t work if you’re using a CDN without making it a subdomain of your url.

This choice is going to depend on where you are, and where your customers are—if they’re spread all over the place and aren’t anywhere near you, a CDN is a great choice. If you’re fairly local, it could be a good idea to give it a skip.

Google’s Guetzli JPEG encoder is a wonderful piece of technology. It analyses an image to see how much can be cut before the human eye perceives any change. It is very good at this: it can cut up to 30% of an image’s size without making any visible changes. It is also:

Not slow to load, mind, slow to encode; if you’ve set up Guetzli to shrink an image down, better go away and make yourself a cup of tea. The process is entirely CPU dependent, and only runs on a single CPU thread. It may be a decent solution for a dedicated export server, running multiple instances over many threads chugging through a ton of files in a much shorter time, but the turnaround time for one file can’t be improved all that much.

Once it’s done its job though, that image will load relatively fast; Guetzli isn’t faster than some compression, but it strikes an excellent balance between size and quality. It has good documentation and should be fairly straightforward to run if you’re a developer but isn’t recommended for most store owners. Some other encoding/compression tools that come highly recommended:

MozJPEG in particular seems to come very close to Google’s solutions in tests, and is a much faster and far more practical solution.

I know what you’re thinking:that was very cool and helpful, I bet the team who wrote it know their stuff, and could help out with the trickier bits. I’d smash the competition with my lightning-fast load speeds. I wonder if I could hire the writers. Well, you’re in luck: here at CodeClouds we have expert creative design services, eCommerce development and much, much more. If you want to hire any of our team, you can get in touch here, or use our contact form for general enquiries.