When it comes to e-commerce, study after study has shown that compelling imagery gets more clicks, leads to longer engagement and drives more sales. Pictures sell. It's no longer up for debate.
But despite the importance the e-commerce industry puts on showcasing products with beautiful images, significantly less thought is given to how those images affect web performance. In the rush to optimize how their websites look, many e-commerce professionals ignore small tweaks that could make a big difference to how they load.
This, we think, is a mistake. The simple fact is that page load speed has a huge influence on a host of other behaviors, and image performance is one of the biggest contributors to perceived load speeds. By avoiding a few common errors, e-commerce professionals can get the most out of their imagery.
Here are the most common image mistakes we see the e-commerce industry making.
Not Fitting the Image to the Container
E-commerce retailers have taken the importance of high-quality product photos to heart, and high-definition photography has become the norm. Unfortunately, this has led to the opposite problem: many retailers simply upload the highest-definition photo available for each product, regardless of how large the image will actually be displayed.
This is a problem. Extra megapixels add to the image's file size, contributing significantly to load time. Yet if the photo isn’t being displayed at this size, the browser will simply shrink the photo to fit the container, and all those pixels will be wasted.
You see this problem especially with so-called "hero images," full-width photos that often grace the tops of pages in trendy modern designs. They require larger files, but it is not uncommon for e-commerce sites to disregard the difference between full-width on desktop and full-width on mobile. A hero image might need to be 1920 pixels wide to display on desktop with no pixelation, but only 812 pixels wide display on the latest iPhone. If the same image file is used for both, it mobile load speed will be impacted.
The answer is to have different image files for use at different responsive breakpoints, rather than simply serving the same file and relying on the browser to resize it. Obviously, real-time image processing with a service like imgix makes this very easy to manage at scale, since you can upload a full-size master and specify the proper size for each screen in the image request. But it can be manageable for smaller sites with a limited product library using batch scripts or even manual editing, and can lead to significantly better image performance.
Not Using Progressive JPEG
You’re probably familiar with how a web browser loads a traditional JPEG image—it starts at the top and gradually reveals the full image as it loads. This usually happens fast for most images on modern connections, but becomes more noticeable the larger the image is and the slower the connection. It can be especially visible on mobile, where connectivity is often not ideal and small screen sizes draw more attention to absent visual elements.
E-commerce sites need to capture attention immediately or conversions suffer, and the photos are the first thing that registers in the minds of potential customers. For that reason, even a placeholder usually performs better than a big blank space.
Enter the progressive JPEG, a newer style of encoding that solves this problem. Rather than reveal the image from top to bottom, progressive JPEG immediately displays a pixelated version of the entire image and then refines this into the full-quality image as the file loads completely. For a better idea of what this looks like, check out this interactive demonstration.
Since the entire image displays immediately, progressive JPEGs feel much faster to visitors than traditional JPEGs. Due to a quirk in the way they’re encoded, they’re often 2 to 10 percent smaller than traditional JPEGs many times they don’t just seem faster, they are faster.
For these reasons progressive JPEGs are quickly becoming standard for image-heavy sites—Facebook, Twitter, Pinterest and many others now use this format extensively. Progressive JPEG is also a part of Google’s PageSpeed recommendations, so there are potential SEO benefits for using it as well.
Not Deleting Metadata from Thumbnail Images
EXIF metadata is archival data that is attached to image files. Its purpose is to record information about how an image was captured, such as the camera it was shot on, aperture settings, and copyright data. Online, metadata has no effect on how the image is displayed, and it is usually irrelevant to end viewers, who don't really need to know how a given photo was taken. It’s also relatively tiny—metadata only takes up about 52 kilobytes of an average JPEG.
This doesn’t seem like a problem for normal images, which are so much larger than this that the load impact is basically negligible. Yet it becomes an issue with thumbnails, where the metadata can sometimes be as much as 30 percent of the file size.
Since there are usually many thumbnail images on pages where thumbnails are displayed, and this can add up to a lot of wasted data. It can also have SEO impacts, as removing metadata is one thing that Google recommends as a best practice for image handling.
You can solve this problem by simply removing the metadata from every image you upload. Of course, another nice thing about using a service like imgix is that you can leave the metadata on your master for archival purposes while serving all derivative images without it automatically. imgix even lets you extract this data in JSON format if you need it for your application.
Not Using Multiplexing to Serve Thumbnail Images
While we're on the subject of thumbnails, there's another way major way they can negatively affect page performance: increasing the number of requests to the server.
If you aren’t familiar with networking technology, you might assume loading a webpage is a single step. But the client actually has to make separate requests for all of the art, scripts, videos, CSS and HTML that are assembled to create the finished webpage. Every time the client has to make a separate request and wait for a response, this adds a small amount of latency to that will affect the load time.
For many pages, there aren't enough requests for this to be a significant source of slowdown. Yet on pages where thumbnails are the predominant visual element, such as search result pages, it can become a problem. Depending on how these are set up, each thumbnail might require a separate request, and that can cause a lot of lag.
Fortunately, modern HTTP/2 requests allow for a technique called multiplexing, in which all of the image requests are bundled together into a single request that is sent to the server, which then executes and serves them. This can deliver noticeable performance gains on pages with many images, and should be used wherever possible.
Not Optimizing Image Data for Social and SEO
With all of the focus on the way that images look on a web page, it can be easy to forget that they also have an important role to play off of the page. In an era where search engines are increasingly trying to add visuals to their results pages, images are becoming a more important aspect of SEO. They're also critical for success on social media, where a compelling image is often the the difference between a link being clicked or ignored.
Since visual media isn't easily indexable the way that text is, both search engines and social networks rely on text cues and meta tags to determine what images should be used and how they should be displayed. It's therefore crucial that e-commerce sites not neglect to include this data.
Every image displayed in on an e-commerce site should have a descriptive file name, and a keyword-dense alt text description that search engines can use to index it. Thumbnails and full-size images should have different alt text, to avoid being penalized for duplicate content. If possible, add all images to your xml sitemap.
Social media sites use special metadata tags to determine which image should be displayed with each page when it appears in their feed. Both Facebook and Twitter will look at OpenGraph markup to determine which image to use, but Twitter also has its own Twitter Card Markup that it will reference. This should be set for every page to avoid having the wrong image appear in social feeds. It can also be helpful to generate separate images at the recommended sizes for each site, something that imgix simplifies.
