After switching the SommCellar eCommerce site from Shopify to our own platform, we became responsible for hosting everything. This included a whole stack of product images.
As a quick fix I added all the images to the Git repo for the site and served them as static assets. It wasn't an elegant solution, whenever new products were added I had to manually add the photo to the Git repo and then redeploy, but it worked and at the very least allowed us to keep the site operating while still building.
The issue we ran into was that the images weren't optimised in any way. This had an impact on customer experience as images were taking around 4-5 seconds to download and customers just weren't hanging around to wait for them.
As an eCommerce site, we use the same pictures in multiple views, some as lo-res thumbnails and others as hi-res feature images. If we were to have created the various options manually it would been challenging to keep organised as well as a huge waste of time.
We needed something that would take a single original image and create a set of "production" images that would suit their particular use case.
Incorporating Cloudinary
Cloudinary is a media management tool that does exactly what we needed, accepts a source image and then allows you to apply transformations using URL query parameters.
To get started we uploaded all our original images up to Cloudinary from which we got a set of URLs back. These URLs pointed to the original images with no alterations made. At this stage we were in exactly the same situation as when we had the images in our Git repo - a URL pointing to an unoptimised original image.
But it's at the next stage that things get clever. By editing the URL Cloudinary had given us we can apply transformations to adjust the resolution, shape, and near enough anything else you could imagine doing to an image. The transformations we were particularly interested in were resolution, quality, and format.
Our original images were around 2800x3600 px in size, over 2MB in file size and stored as jpeg. For our thumbnail images we wanted the following spec:
around 300px wide
as small of a file size as possible
delivered in as modern of a format as the requester's browser could handle
These three requirements could be applied by adding the following to our image source URL:
c_scale,f_auto,q_auto,w_300
Making it reusable
The issue we now faced was that we wanted to use the same image in multiple places on the site but our hardcoded source URL was forcing the image to be 300px wide. While this was fine for a thumbnail, for the feature image of a product was too small.
We needed to be able to store the URL for the original image in the database and then apply different transforms depending on the location the image was going to be displayed.
We found the cloudinary-build-url package to help us.
This package takes in the source URL as well as an object of transformations, meaning we were able to swap out the transforms that would be applied depending on the location of the image component.
The impact on the site
We've still got some tweaking to do while chasing the best performance but thanks to Cloudinary we are well on our way.
Images now load much quicker and users don't experience gaps in content while waiting for images to download.
The bandwidth we're using to deliver images has also reduced which translates to reduced Cloudinary credit consumption.
Finally the biggest impact we've found is for the product team. We always wanted images to be optimised and without Cloudinary that would have meant manually adjusting images to suit multiple formats. Being able to upload a single image and leave all the adjustments to a third party is a considerable improvement in workflow and helps take the load off the product team.
Top comments (0)