How to Build the Perfect E-Commerce Image Server

imgix logo
Filippo Conforti — Founder & CEO, Commerce Layer
March 26, 2019
3 minute read
Header image of e-commerce product image displays and VCL script

When shopping online, customers can't touch products, as they do in physical stores. That’s why product images are crucial; they help customers understand what they are buying and inspire them to buy it. In fact, only three percent of U.S. internet users never search for visual content prior to making a purchase. If you think about it, images are your products, so you need to treat them with care.

Unfortunately, serving high-quality images comes at a cost: page load time. Beautiful but heavy images can hurt your SEO, customer experience, and conversion rate. As you can guess, the goal is to find the right balance between image quality and weight. Still, too often image optimization is seen as a low priority and thus forgotten. Or the prospect of managing dozens of image types seems overwhelming. These days, the number of devices we need to address has become quite large. The traditional approach of simply generating "thumb," "normal," and "zoom" versions of your origin images is no longer enough. To get the most out of your images, you need to serve the right format to the right device.

In this article, we will discuss how to build a simple yet powerful, as well as SEO-friendly, e-commerce image server. It's a stack and workflow that we at Commerce Layer have battle-tested in production for many clients. Today, you can easily adapt these guidelines to your own use case in a few steps.


Before diving into the stack details, let's write down a list of goals that we want to achieve from our image server:

  1. We want to manage only one origin image per product view.
  2. We want any required format to be dynamically generated.
  3. We want the image delivery to be fast and secure, with SSL support.
  4. We want our images to be SEO-friendly, for any locale.

For the sake of simplicity, the shooting phase and any approval workflow are intentionally left out of the scope of this tutorial. These phases can be managed through a DAM (Digital Asset Management) and typically include other assets, like documents and videos. Any step of the pipeline can definitely have an impact on the final image that's put in front of the customer. That said, our image server aims to cover only the last mile.

Origin Image Guidelines

When we talk about origin images, we mean the image files that act as the "originals" for all the derivative formats (like crops and resizes). An e-commerce catalog of 100 T-shirts, each coming in 3 colors and 3 sizes, contains 900 SKUs. Differently colored T-shirts look different and need their own images. Sizes generally don't, so there is no need to shoot different sizes of the same T-shirt color. That said, it's still convenient to create one origin image for each SKU, even if some of them will look the same.

Moreover, if you want to display, let's say, 4 views (e.g., front, back, detail, and dressed) on the product page, then you need to manage 900 × 4 = 3600 origin images in total.

The resolution and format of origin images should be chosen wisely, as none of the derivative images will have a higher quality. Think of product zooms on the larger screens. Also, keep in mind that the device screen resolution is always increasing and that the cost of storage is not that high. So don't try to save too much space here.

As a rule of thumb, make sure that your origin images follow the guidelines below:

  • They have a square ratio.
  • They have a resolution of 2400×2400 pixels (at least).
  • They have the background removed.
  • They are trimmed.
  • They support transparency.

TIP: Use a service like Pixelz if you need a very fast and cost-effective service for background removal and retouching.

Name your files in a way that lets you associate them to your SKUs and view type. You can safely ignore any SEO-friendly slug at this stage (more on this later). Something like the following will work great for our purpose:

  • SKUCODE_front.png
  • SKUCODE_back.png
  • SKUCODE_detail.png
  • SKUCODE_dressed.png

Finally, save them on a storage service like Amazon S3, Google Cloud Storage, or any publicly accessible web folder.

Image Processing and Delivery

Using the master images, we want to generate all the derivative images that we need on the fly and serve them cached over a CDN. Thanks to imgix’s real-time processing capabilities, this job becomes a breeze.

The first thing to do is to connect the master image source to your imgix account (learn how). Then visit one of your master image URLs:

If everything is working properly, your image will look nice, but it will be quite heavy. (Although we recommended at least 2400×2400 resolution for your master images, we are actually using 1000×1000 resolution here, so as not to weigh down this very post. Still, the file size is 429 KB, which is quite high.) To prevent it from slowing down your site load time, resize the image by adding parameters to define image width or height:

As you can see, our image has lost some weight (dropping from 429 KB to 172 KB), but it still looks nice. To further optimize the file weight, you need to change the file format and compression. In general, the optimal format and compression level may depend on many factors. Fortunately, imgix ships with a very useful API that lets you automagically adjust them with one parameter, auto=format,compress:,compress

Now the image file size is only 18 KB, but we can do more. Let's change the image background to fit your site color and add some padding with the bg and pad parameters:,compress&bg=FAFAFA&pad=20

(Note that going from transparency to background results in another noticeable drop in weight, from 18 KB to 8 KB.)

This is why we created transparent, trimmed master images. If your site background changes, you can change all of your images with just one parameter. The same goes with the image ratio and padding. Your web developers will love all this flexibility, and it will let you distribute the same images across many sales channels. If you haven't heard of omnichannel commerce, this is definitely a good thing. On the other hand, sometimes you may want to prevent your sources from being used maliciously. For such cases, you can add a security layer as described here, maybe right before the go-live of your site.

Search Engine Optimization

Modern SEO is all about branding and customer experience. Serving high-quality images while keeping the site fast is a great ranking factor. Adding descriptive alt text or creating an image sitemap are all jobs for web developers.

What our image server is missing to be more SEO-friendly is the capability of serving keyword-rich, localized file names. The file name of a black T-shirt should contain the "black T-shirt" keyword in the English site and "maglietta nera" for the Italian one, like this:,compress&bg=FAFAFA&pad=20,compress&bg=FAFAFA&pad=20

Managing more master images only to add this feature is probably not worth the effort. Ideally, our image server should be able to serve all the localized file names, while fetching the same master image for each version.

In other words, we would need some URL rewriting rule to strip out the SEO-friendly slug from the image path before forwarding the request to the image source. A technique that we've used in the past is to put an additional layer on top of imgix with the sole role of rewriting the URL. In particular, we've used Fastly as the additional layer, adding a VCL edge script like the one below:

sub vcl_recv {

 if (req.url ~ "https:\/\/\/[0-9a-zA-Z].+)(\/.*)(\_.*\.png\?.*)") {
   set req.url = "" + +;

#FASTLY recv

 if (req.request != "HEAD" && req.request != "GET" && req.request != "FASTLYPURGE") {


The script regex matches any URL like this:,compress&bg=FAFAFA&pad=20

And rewrites it as:,compress&bg=FAFAFA&pad=20

This is what we need to fetch the master image. As you may have noticed, we also configured our brand domain. According to Google, serving images from your own domain name doesn't bring any benefit in terms of SEO, but it is still a good practice that we like to follow.

So our image server is complete but we still have an issue that we need to address. Adding a third-party CDN like Fastly is not recommended by imgix guidelines, as it could reduce the performances and cause some features not to work properly. In our own experience, we had to work closely with Fastly support to fine-tune our POP locations in order to make it work fine with imgix architecture.

It turns out the imgix CDN is flexible, and the good news is that the (fantastic) support of imgix can assist you in adding a custom solution similar to the one above. Moreover, you can CNAME your own domain right on your imgix account, which also supports SSL out of the box. So in case you want to push your image SEO to the top, there's actually no need to add any additional layer to your stack. Yeah!

Putting It Together

In this post, we've described a practical approach to build a flexible, SEO-friendly image server and workflow with low effort. It's an architecture that comes from our own experience and that we've seen working great in many e-commerce projects. If this sounds like the perfect image server setup for your e-commerce site but you don't have the resources to do it yourself, reach out to us at Commerce Layer. Our API-first commerce platform, paired with a headless CMS and a full-featured image server, lets you easily build enterprise-grade, blazing fast e-commerce websites (learn more).

Being omnichannel and future-friendly is mandatory for staying up-to-date with ever-evolving technology. Whatever the sales channel, customers want to see what they are buying, so images are one of the most important assets for your business. The only exception (to date) is probably represented by voice commerce channels like Amazon Alexa or Google Assistant … at least until imgix adds a vocal format to their API ;-)