Image Optimization in Next.js: How OpenMyPro Reduced Load Times by 60%
How OpenMyPro uses the Next.js Image component to optimize provider photos, reduce page weight by 60%, and maintain fast load times. AVIF, WebP, responsive sizes, and lazy loading patterns.
See this stack in production. 150K+ users. six-figure ARR.
Free forever. Upgrade only when you're ready.
150K+ users · Ex-Amazon Engineer · Healthcare Innovation
No card charged today · 150K+ users · $0 to start
Images are the heaviest assets on any web page. Provider profile photos, clinic images, and marketing graphics were responsible for 70% of OpenMyPro's page weight before optimization. The Next.js Image component reduced that by 60%, cutting average page size from 2.1MB to 840KB. Here is every optimization technique we use.
The Next.js Image Component
The Image component from next/image is not just a wrapper around the HTML img tag. It automatically generates responsive image sizes, converts to modern formats (AVIF, WebP), lazy loads below-the-fold images, prevents Cumulative Layout Shift with automatic aspect ratio preservation, and serves images from Vercel's global CDN.
A single Image component call replaces what would otherwise be 20+ lines of responsive image HTML with srcset, sizes, loading, decoding, and picture element markup. The developer experience is identical to using a regular img tag, but the output is production-optimized.
Format Optimization: AVIF and WebP
The biggest wins come from format conversion. A provider profile photo uploaded as a 1.5MB JPEG becomes a 45KB AVIF file when served through Next.js Image optimization. That is a 97% reduction in file size with visually identical quality. The Image component automatically serves AVIF to browsers that support it, falls back to WebP for older browsers, and uses JPEG only for the rare browser that supports neither.
We configure image quality at 75 for most images, which provides a good balance between file size and visual quality. For the provider profile hero image at the top of their page, we use quality 85 because it is the largest and most prominent image.
Responsive Sizes
The sizes prop tells the browser how wide the image will be at each breakpoint, enabling it to download the appropriately sized image. For provider card images in a three-column grid, we use sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw". This means the browser downloads a small image on mobile, a medium image on tablet, and a large image on desktop — never wasting bandwidth on oversized images.
We define allowed remote image domains in next.config.ts for provider photos hosted on Supabase Storage. The remotePatterns configuration specifies the exact hostname and path prefix, preventing the Image optimization endpoint from being used as an open proxy.
Lazy Loading Strategy
Below-the-fold images use the default loading="lazy" behavior. The browser only downloads these images when they scroll into view, reducing initial page weight dramatically. For a provider listing page with 20 provider cards, only the first 3-4 visible cards load images immediately — the rest load on scroll.
Above-the-fold images use priority={true} which disables lazy loading and preloads the image. On the provider profile page, the hero image and provider photo both get priority because they are visible on initial page load. Getting this right is critical for LCP — the Largest Contentful Paint is often the hero image, and lazy loading it would delay LCP unnecessarily.
Preventing Layout Shift
The Image component requires explicit width and height props (or fill mode with a sized container). This allows the browser to reserve the correct space before the image loads, preventing the jarring layout shift that happens when an image pops in and pushes content down. Our CLS score is consistently under 0.05 across all pages thanks to this behavior.
For dynamic images where we do not know dimensions in advance (user-uploaded provider photos), we use the fill prop with a container div that has a fixed aspect ratio using CSS aspect-ratio. This ensures consistent card layouts regardless of the original photo dimensions.
CDN and Caching
Vercel's Image Optimization CDN caches generated images globally. The first request for a specific image at a specific size triggers the optimization. Subsequent requests are served from cache with near-zero latency. Cache headers are set to one year for hashed image URLs, ensuring browsers cache aggressively.
The total infrastructure cost for image optimization is included in our Vercel plan. No separate image CDN service, no S3 buckets for cached images, no origin server for transformations. The simplicity of this setup is a major advantage for a solo founder managing six platforms.