Zhivko Todorov
ALL CASE STUDIES

CASE 124 · MAGNOLIA · 2025

CLOUDFRONTLAMBDA@EDGEIMAGE OPTIMISATIONS3

Images optimised at request, not stored in twelve sizes.

A fashion e-commerce site stored each product image in twelve pre-sized variants (thumbnail, mobile, tablet, desktop, retina × 2-3 use cases). The S3 bill was dominated by image storage. We moved to on-the-fly resizing at the edge using Lambda@Edge plus CloudFront, deleting the pre-sized variants.

INDUSTRY

Fashion e-commerce

DOMAIN

COST

DELIVERED

2025

STACK

CLOUDFRONT·LAMBDA@EDGE·CLOUDFRONT FUNCTIONS·S3·SHARP·WEBP

RESULTS

What changed, by the numbers.

S3 STORAGE BILL

−82%

IMAGES ONLY

CACHE HIT RATE

95%

POST-FIRST-REQUEST

IMAGE WEIGHT (CLIENT)

−61%

WEBP + RESIZING

PAGE LOAD (p75)

−18%

AS A SIDE EFFECT

HOW IT WENT

The twelve-variants-per-image approach had been state of the art when the platform was built. The cost was paid in storage (every variant copied), in deploy time (a regenerate-all-variants job that ran for hours), and in inflexibility (adding a new variant size was a project).

Lambda@Edge with the Sharp library resizes a master image to whatever variant the request specifies. CloudFront caches the result, so subsequent requests for the same variant serve from edge cache at no Lambda cost. WebP conversion happens at the same time for clients that support it.

S3 storage dropped 82% — only master images remain. Cache hit rate stabilised at 95% within a week of launch. As a bonus, the WebP conversion plus better resizing dropped average image weight 61%, which improved page load 18% at p75.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →