Image resizing and optimization
Imagine you have an online store where you need regularly update your catalog with items and their images. You ordered professional photography, and after one month (joke), you receive your nice high-resolution pictures that are 10–15 MB in size.
You upload them to your website, and (surprise) you observe an extremely high latency on image delivery. Customers wait too long to see your lovely pictures, give up and go to your competitors.
It’s not performant to deliver images to client browsers in the original size, where you need to show a small thumbnail. That’s a point where you think of making an image resizing. Sounds easy. Let’s resize them in a box of 600x600 pixels for Item preview. But after you need another resolution for a Product page in 800x800, show your item a bit more in detail. And after, probably, in … 4k?
Here I want to discuss with you some options for image resizing and optimization. I considered the following aspects:
- Costs of running
- Implementation costs and flexibility
- Delivery performance
Optimization in background
You can define all resolutions and formats you need and transform images in a batch job. Let say 100x100 for search hint, 800x800 for the Product page, and 1400x1400 for detailed view.
Sounds easy in the initial implementation, and that would work fine until you came up with an idea of having yet another view, where you need to have your assets in another resolution and/or format. And then in another one. And again.
Moreover, you will have multiple duplicates living on the disk. Probably even not being retrieved.
That’d be an option for a case where you’re really-really sure of what you will need in the future. But who knows that?
Buy a service
It’s not a unique use case in the world, where someone needs to have an image resizing.
There’re plenty of companies that offer that as a service. To name a few: Akamai, Cloudinary, imgix, Fastly’s Image Optimizer, Instart Logic’s SmartVision, ImageOptim API, Pixelcrush, Imagekit, Cloudimage, Filestack, Sirv, Netlify, and more.
All of them offer comprehensive solutions for image resizing and optimization. I want to tell you about a few of them.
Fastly
To activate image optimization on Fastly, you’ll need to contact their Sales engineers and explain your use case. After that, they will decide if they want to work with you or not and eventually activate their API for your account. Regarding the price, the subscription will start from 1000Euro per X Mi of image optimization per month. Btw, you can play around with their API in the sandbox.
Imgix
The provider that sells explicitly Image optimization API. Under the neath, they use Fastly infrastructure and provide easy-to-use UI for service configuration. After a few clicks in the admin panel, you’ll have your API ready: you configure your source (Amazon S3, Google Cloud Storage, Web folder, or Web proxy), select if you want your images to be secured with hash or not, and ready.
They have a pay-as-you-go plan. At the moment of writing, it’s 3$ per 1000 image optimizations. Very cheap at the beginning but could be very costly when your website became very popular. Btw, they do have a sandbox as well.
Proxy like services
Several providers offer a resizer as a proxy service. You send a master image URL in the GET parameter or Path, resizing parameters, and receive a resized image back. You can host such a service with Thumbor or buy a hosted solution by Filestack, Pixelcrush, Cloudimage, etc.
Price would be way cheaper than others, but you shouldn’t expect outstanding performance since you’ll need to make at least one more HTTP request in the background.
Build it on your own
If you already run your Cloud infrastructure, specifically AWS, it might be interesting to use Cloudfront CDN with Lambda for image resizing. AWS doesn’t offer this as SaaS, but they publish several examples of how to do that.
Lambda with API Gateway
There is an excellent page on that with documentation and an open-source repository with Cloudformation template and code for Lambda function. It uses Cloudfront -> Api Gateway -> Lambda -> S3 as infrastructure and Node.js application for resizing that is basically a proxy for Sharp library or Thumbor.
AWS estimates costs of running this stack at around 12$ for 1Mi image resizing. Just rough numbers but highlights that it’s cheap.
For a proof-of-concept, you’ll need to check out the repo and execute few commands. And it works. It sounds like an easy start, but in the real world, you’ll need to maintain it on your own. Even if it’s not that hard, you’ll need to have a kind of CI/CD, update dependencies, and fix bugs.
Lambda@Edge
Another option from AWS is to utilize Lambda@Edge. They posted that Solution a bit later, and it aims to be a bit more elegant. You don’t have an unnecessary API Gateway component compared to the previous Solution, and it uses Lambda@Edge instead. The last could be a benefit for latency and a problem in terms of strict limitations. For example, you need to deploy your Lambda in the N.Virginia region, you can only use Node.js as a Runtime, Execution Timeout is limited to 30 Seconds, Payload limit of 1MB (compare to 6Mb in regular Lambda), etc. (valid for the moment of writing, check actual limits). And deployment of such a stack will take a bit longer by its nature.
At the end of the day, you get relatively the exact costs and maintenance tradeoff as the last option. It’s probably slightly better, but just because it’s something newer?
No matter what Lambda you choose for resizing, you’ll need to deal with Lambda payload size limits (6MB or 1MB accordingly). In examples from AWS, they send a base64-encoded image inside the event payload. Users will receive an error when it’s bigger than the limit.
To avoid that, you can store the resized image in your S3 bucket under another name and send 3xx HTTP Status code to redirect that image to your client.
TL;DR
Ok. For this problem, there seem to be many ways to go. Probably too many. But, after all, I tend to agree with the authors of Images Guide eBook saying:
The amount of time you’ll spend reading blog posts and tweaking your configuration is greater than the monthly fee for a service.
I would be glad to hear about your experience.
