# next/image Deep Dive — Optimization, Lazy Loading, and the Props That Actually Matter > Source: > Published: 2026-07-14 11:19:01+00:00 `next/image` does a lot automatically — format conversion, lazy loading, preventing layout shift. But several props change behavior significantly, and getting them wrong either hurts performance or breaks things in production. Here's the complete picture of what actually matters, with the approach used in the image-heavy [generation results interface](https://pixova.io/blog/can-ai-generate-images-for-free). When you use `` from `next/image` , you get automatically: `sizes` Prop — The Most Underused Optimization The `sizes` prop tells the browser what size the image will be at different viewport widths. Without it, Next.js can't serve optimally-sized images and defaults to generating several sizes that may be larger than needed. ``` // Without sizes — Next.js doesn't know the display size Hero

// With sizes — Next.js serves the right size for each viewport Hero

``` Read the `sizes` value as: "On mobile (under 768px), this image takes 100% of the viewport width. On tablets (under 1200px), 50%. On desktop, 33%." Next.js uses this to calculate which image size to serve. Correct `sizes` values can reduce image payload by 50-70% on mobile. **Common patterns:** ``` // Full-width hero or banner sizes="100vw" // Half-width on desktop, full on mobile sizes="(max-width: 768px) 100vw, 50vw" // Card grid — 1 col mobile, 2 col tablet, 3 col desktop sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw" // Small thumbnail — always small sizes="150px" ``` `priority` — For Above-the-Fold Images By default, `next/image` lazy loads everything. For images visible immediately on page load (hero images, header images, above-the-fold content), lazy loading is counterproductive — you want these to load as fast as possible. ``` // Hero image — load immediately, don't lazy load Page hero

``` Add `priority` to the first image visible on page load. This tells Next.js to preload it and not apply lazy loading. **The rule:** One or two images maximum per page should have `priority` . If you add it to many images, you've eliminated the performance benefit of lazy loading. `fill` vs Width/Height — When to Use Each **Explicit width/height:** Use when you know the exact dimensions at render time. Generates precise sizes. ```

``` ** fill mode:** Use when the image should fill its container. The container must be `position: relative` (or `absolute` or `fixed` ). ```

``` `className="object-cover"` on the Image determines how it fills the container. `object-cover` maintains aspect ratio and crops. `object-contain` maintains aspect ratio with letterboxing. `quality` — When Default Isn't Right Default quality is 75, which is a good balance. For specific cases you might adjust: ``` // Photographic images — default 75 is fine

// Icons or images with sharp lines — higher quality prevents artifacts

// Background textures where quality difference isn't visible

``` Higher quality = larger file size. The default is right for most cases. `remotePatterns` Config By default, `next/image` only optimizes images from your own domain. For external images, you need to configure allowed patterns: ``` js // next.config.js /** @type {import('next').NextConfig} */ const nextConfig = { images: { remotePatterns: [ { protocol: 'https', hostname: 'cdn.example.com', port: '', pathname: '/images/**', }, { protocol: 'https', hostname: '*.cdn-example.com', // wildcard subdomain }, ], }, }; module.exports = nextConfig; ``` Be specific with `pathname` patterns. Wildcard `/**` allows any path on that host. More restrictive patterns are safer. `placeholder` Prop — Blur-Up Loading For a smooth loading experience, `next/image` supports a blur placeholder that shows while the full image loads: ``` // Static images — Next.js generates blurDataURL automatically at build time import heroImage from '/public/hero.jpg'; Hero

``` For dynamic images (external URLs), you need to provide the blur data yourself: ``` js // Generate a tiny blurred placeholder (many services provide these) const blurDataURL = 'data:image/jpeg;base64,/9j/4AAQ...'; // tiny base64 image

``` The `placeholder="blur"` approach significantly improves perceived loading performance for above-the-fold images. To verify your image optimization is working: `Img` `Type` column — should show `webp` or `avif` instead of `jpeg` /`png` `Size` column vs original file size A well-optimized image should be significantly smaller than the original and in a modern format.**Forgetting sizes on fill images.** Without `sizes` , Next.js can't optimize for viewport — generates full-size images for all viewports.**Adding priority to too many images.** It's for above-the-fold only. One or two per page maximum. **Not configuring remotePatterns.** External images without pattern configuration fall back to unoptimized serving, breaking the performance benefits. **Using instead of .** Native `` tags don't get any next/image optimization — no format conversion, no lazy loading, no layout stability. ESLint rule `next/no-img-element` catches this.| Prop | When to use | |---|---| `sizes` | Always, when using `fill` or when image width changes across viewports | `priority` | First 1-2 visible images on page load only | `fill` | When image should fill a container with unknown dimensions | `quality` | When default 75 is visibly too low (icons) or unnecessarily high | `placeholder="blur"` | Above-the-fold images where loading is visible to users | The three that move the needle most: correct `sizes` (biggest file size impact), `priority` on LCP images (biggest perceived performance impact), and `remotePatterns` configuration (required for external images to optimize at all). If you serve images from a custom CDN with its own optimization parameters, you can configure a custom loader: ``` // next.config.js module.exports = { images: { loader: 'custom', loaderFile: './imageLoader.js', }, }; // imageLoader.js export default function myImageLoader({ src, width, quality }) { return `https://your-cdn.com/image?url=${src}&w=${width}&q=${quality || 75}`; } ``` This gives you full control over how image URLs are constructed for optimization, useful when your CDN uses different query parameter formats than Next.js expects. For most applications using standard hosting, the default loader is correct. Custom loaders are for specific CDN integrations that need URL format control. If you're on an older Next.js version using `domains` config, migrate to `remotePatterns` : ``` // Old (deprecated) images: { domains: ['cdn.example.com'], } // New (use this) images: { remotePatterns: [ { protocol: 'https', hostname: 'cdn.example.com' } ], } ``` `remotePatterns` is more secure — it supports pathname restrictions that `domains` doesn't, preventing a compromised external hostname from serving arbitrary paths through your Next.js image optimizer.