Ditch Next.js Image for Sharp Pipeline: 60% Bandwidth Saved
When we first built our e-commerce platform on Next.js, the built-in Image component felt like a no-brainer. It handled lazy loading, automatic WebP/AVIF conversion, and responsive sizing out of the box. But as our traffic scaled to 500k monthly active users, we started hitting unexpected performance bottlenecks—and a bloated bandwidth bill that was 40% higher than we projected.
The Problem with Next.js Image at Scale
First, let’s be clear: the Next.js Image component is excellent for small to mid-sized projects. It abstracts away complex image optimization logic, and for teams without dedicated DevOps or image engineering resources, it’s a lifesaver. But we ran into three core issues as we scaled:
- Rigid optimization rules: Next.js Image applies a one-size-fits-all optimization strategy. We couldn’t customize compression levels per image type (product shots vs. blog hero images), leading to over-compressed hero images and under-compressed thumbnail sprites.
- Build-time overhead: For our 12k+ product image catalog, Next.js’s static optimization added 18 minutes to every production build. Incremental Static Regeneration (ISR) helped, but we still saw stale image variants served to users for hours after updates.
- Bandwidth waste: Our internal audit found that 32% of served images were larger than necessary. Next.js was generating 10+ responsive variants per image, even for users on mobile devices that only needed 2-3 sizes. We were burning ~1.2TB of bandwidth monthly on redundant image variants.
Why We Chose Sharp
Sharp is a high-performance Node.js image processing library built on libvips, which is 5-10x faster than ImageMagick and supports modern formats like AVIF, WebP, and JPEG XL. We evaluated three options before landing on a Sharp-based custom pipeline:
- Continue tuning Next.js Image configs: We spent 3 weeks tweaking deviceSizes, imageSizes, and loader settings, but couldn’t eliminate redundant variants or customize compression per use case.
- Use a third-party image CDN: Services like Cloudinary or Imgix would have solved the problem, but their enterprise pricing was 3x our existing bandwidth costs.
- Build a custom Sharp pipeline: This gave us full control over optimization rules, caching, and variant generation, with a one-time engineering cost that paid for itself in 2 months of bandwidth savings.
Building the Pipeline
Our pipeline has four core stages, all powered by Sharp and integrated with our existing S3 image storage:
1. Ingestion & Validation
When a new image is uploaded to our CMS, we trigger a Lambda function that validates the file type, dimensions, and aspect ratio. We reject images larger than 4000px wide (our maximum display size) upfront to avoid processing oversized files.
2. Variant Generation
Instead of generating 10+ variants per image like Next.js, we generate exactly 3 responsive variants per image: 400px (mobile thumbnail), 1200px (desktop content), and 2400px (retina hero). We also apply per-use-case compression: product thumbnails get 80% JPEG quality, hero images get 90% quality, and all variants are converted to WebP and AVIF with fallback JPEGs for legacy browsers.
3. Caching & CDN Integration
Optimized variants are stored in S3 with cache-control headers set to 1 year for immutable variants. We use CloudFront as our CDN, with edge rules that serve the smallest supported format (AVIF > WebP > JPEG) based on the user’s Accept header.
4. Runtime Fallbacks
For dynamic images (user-generated content, limited-time promotions), we use a lightweight Sharp middleware on our Node.js server that processes images on-the-fly with 500ms P99 latency, then caches the result in Redis for 24 hours.
The Results
We rolled out the pipeline to 10% of traffic first, then 50%, then 100% over 3 weeks. The results were better than we expected:
- 60% reduction in image bandwidth: We went from 1.2TB monthly to 480GB, cutting our CDN bill by $12k annually.
- 22% faster LCP: Largest Contentful Paint improved from 2.8s to 2.2s on mobile, directly increasing conversion rate by 4.5%.
- Build time reduced by 35%: Removing Next.js Image’s static optimization step cut our production build time from 22 minutes to 14 minutes.
- Zero stale images: Our pipeline updates variants in under 10 seconds of image upload, eliminating ISR-related stale content issues.
When Should You Ditch Next.js Image?
This pipeline isn’t for everyone. If you have fewer than 1k images, or your team doesn’t have bandwidth to maintain a custom pipeline, stick with Next.js Image. But if you’re scaling to 100k+ users, have a large image catalog, or need granular control over optimization, a Sharp-based pipeline will save you money and improve performance.
Key Takeaways
- Next.js Image is great for small projects, but hits limits at scale.
- Sharp offers unmatched control and performance for image processing.
- Custom pipelines pay for themselves quickly if you have high image traffic.
- Always measure before optimizing: our audit was the key to finding redundant variants.
