## Why Images Can Destroy Your Page Speed Images are often some of the heaviest assets on a website. A beautiful 4K hero image might look amazing... until somebody opens your site on mobile data and downloads several megabytes just to see a 400px-wide picture. 💀 Using a regular [HTML](/courses/html) image is completely valid: ```html Beautiful mountain landscape

``` But now **you** are responsible for optimizing things such as: - Responsive image sizes - Lazy loading - Modern image formats - Correct dimensions - Layout stability - Loading priority - Image compression [Next.js](/courses/nextjs) gives you a built-in component that handles much of this work: ```jsx ``` from: ```js next/image ``` --- # The Problems with Unoptimized Images Let's understand what we're actually trying to fix. --- ## 1. Downloading Images That Are Too Large Imagine you upload: ```text 3840 × 2160 ``` and display it inside a: ```text 400px ``` card. The user doesn't need the giant original image. But with a basic setup, their browser might still download it. That's basically delivering a billboard when someone asked for a profile picture. 😭 [Next.js](/courses/nextjs) can generate appropriately sized image variants and let the browser choose the suitable one. --- ## 2. Loading Images the User Can't Even See Imagine a page has 20 images. Only the first three are visible. Downloading all 20 immediately wastes: - Bandwidth - Network requests - Mobile data - Browser resources Next.js images use lazy loading by default. That means off-screen images can wait until they're getting close to the viewport. Conceptually: ```text Image visible soon? ↓ Yes ↓ Start loading ``` instead of: ```text Page opened ↓ DOWNLOAD EVERYTHING 🔥 ``` --- ## 3. Cumulative Layout Shift You've probably opened a website where you're about to click something... then an image loads. The page moves. You accidentally click something completely different. Pain. 😭 This is related to: **Cumulative Layout Shift — CLS** --- > **Definition: Cumulative Layout Shift (CLS)** > > CLS is a Core Web Vital that measures unexpected movement of visible content while a page is loading. Suppose the browser doesn't know how large an image will be. Initially: ```text Image height = unknown ``` Then the image downloads and suddenly takes: ```text 400px ``` of vertical space. Everything underneath gets pushed down. Next.js helps avoid image-caused layout shift by knowing the image's intrinsic aspect ratio ahead of time. --- # The Next.js `` Component Import it from: ```js next/image ``` Example: ```jsx import Image from "next/image" export default function Profile() { return (

) } ``` Looks similar to: ```html ``` but Next.js adds image optimization behavior around it. --- # What Next.js Image Optimization Gives You The `` component can help with: - Automatic resizing - Responsive image generation - Lazy loading - Modern formats - Preventing image layout shift - Loading placeholders - Image caching - LCP optimization - Remote image security The important idea is: ```text Original image ↓ Next.js Image Optimizer ↓ Optimized version ↓ Browser ``` Instead of always serving the original giant file. --- # Local Images There are two common ways to use local images. --- ## Option 1: Images from `public/` Suppose you have: ```text public/ └── hero.jpg ``` You can reference it as: ```jsx import Image from "next/image" export default function Hero() { return ( Developer working on a laptop

) } ``` Notice: ```text public/hero.jpg ``` becomes: ```text /hero.jpg ``` You don't write: ```text /public/hero.jpg ``` in the URL. --- # Static Image Imports Next.js can also statically import image files. For example: ```jsx import Image from "next/image" import heroImage from "@/assets/hero.jpg" export default function Hero() { return ( Developer working on a laptop

) } ``` When an image is statically imported, Next.js can determine information such as its intrinsic: ```text width height ``` automatically. So you don't necessarily need to manually write: ```jsx width={1200} height={700} ``` --- ## String Path vs Static Import With a string path: ```jsx Hero

``` you normally provide the dimensions. With a static import: ```jsx import hero from "@/assets/hero.jpg" Hero

``` Next.js knows the source image dimensions. --- # What Do `width` and `height` Actually Mean? This is important. Suppose you write: ```jsx

``` That doesn't necessarily mean: > "Always render this image exactly 800 × 600 pixels." The values primarily describe the image's **intrinsic dimensions and aspect ratio**. Here: ```text 800 / 600 = 4:3 aspect ratio ``` The browser can reserve the correct space before the image finishes loading. That's what helps prevent layout shift. [CSS](/courses/css) can still control the final rendered size. For example: ```jsx

``` The image becomes responsive while preserving its aspect ratio. --- > **Interview Highlight** > > **Q: Why does Next.js require `width` and `height` for many images?** > > They provide the intrinsic image dimensions so the browser can determine the aspect ratio and reserve the correct layout space before the image loads, helping prevent Cumulative Layout Shift. --- # Modern Image Formats Traditional websites commonly use: ```text JPEG PNG ``` Modern formats such as: ```text WebP AVIF ``` can often provide smaller files. Next.js Image Optimization can generate modern formats supported by the browser. In current Next.js, the default configured optimized format is: ```text WebP ``` --- # Enabling AVIF If you want AVIF too, configure: ```js // next.config.mjs const nextConfig = { images: { formats: [ "image/avif", "image/webp" ], }, } export default nextConfig ``` Now supported browsers can receive AVIF, with WebP available as another configured option. AVIF often compresses smaller than WebP, but encoding it can require more server work. So don't automatically assume: ```text AVIF = always better ``` WebP is still a very strong default. --- # Remote Images Images won't always live inside your repository. They might come from: - AWS S3 - Cloudinary - Unsplash - A CMS - Your CDN - User uploads Example: ```text https://images.example.com/users/asif.jpg ``` You can use remote images with ``. But Next.js doesn't blindly optimize every URL on the internet. And that's a very good thing. --- # Why Remote Images Need Configuration Imagine your Image Optimization endpoint accepted literally any URL. Somebody could potentially use your server to repeatedly optimize arbitrary remote images. Congratulations. You've accidentally created a free image optimization service for strangers. 😭 Next.js therefore lets you explicitly define which remote URLs are allowed. --- # Configure `remotePatterns` Inside: ```text next.config.mjs ``` write: ```js const nextConfig = { images: { remotePatterns: [ { protocol: "https", hostname: "images.example.com", pathname: "/users/**", }, ], }, } export default nextConfig ``` Now Next.js can optimize URLs matching: ```text https://images.example.com/users/** ``` while rejecting unrelated URLs. --- ## Unsplash Example ```js const nextConfig = { images: { remotePatterns: [ { protocol: "https", hostname: "images.unsplash.com", }, ], }, } export default nextConfig ``` --- # Be Specific with `remotePatterns` Avoid allowing more URLs than your application actually needs. For example, instead of broadly allowing: ```text everything.example.com/** ``` you might allow: ```text cdn.example.com/products/** ``` Next.js can restrict things such as: - Protocol - Hostname - Port - Pathname - Query string This isn't just configuration. It's also a security feature. --- # Remote Image Example ```jsx import Image from "next/image" export default function Avatar({ user }) { return ( {`${user.name}'s

) } ``` For remote images, Next.js cannot inspect the file during your build like it can with a static import. So you normally provide: ```jsx width ``` and: ```jsx height ``` manually. Unless you're using: ```jsx fill ``` instead. --- # What If You Don't Know the Image Dimensions? Sometimes you genuinely don't know them. For example: ```text CMS image User upload Remote API ``` This is where: ```jsx fill ``` can be useful. --- # The `fill` Prop Instead of: ```jsx width={1200} height={800} ``` you can use: ```jsx fill ``` Example: ```jsx

``` Now the image fills its container. --- # How `fill` Works With: ```jsx fill ``` the image is positioned to fill the available parent container. Conceptually: ```text Parent Container ┌───────────────────────┐ │ │ │ IMAGE │ │ │ └───────────────────────┘ ``` The parent controls the dimensions. The image fills them. --- # Important `fill` Rule The parent must provide a meaningful layout context. A common pattern is: ```css position: relative; ``` For example: ```jsx

``` With [Tailwind](/courses/tailwindcss): ```text relative ``` sets the positioned parent. ```text h-96 ``` gives it height. ```text w-full ``` gives it width. And: ```text object-cover ``` makes the image behave similarly to: ```css background-size: cover; ``` --- # `objectFit: "cover"` vs `"contain"` Use: ```js objectFit: "cover" ``` when the image should completely fill its container, even if some parts are cropped. Think: ```text Hero banners Card thumbnails Cover photos ``` Use: ```js objectFit: "contain" ``` when you want the whole image visible. Think: ```text Product images Logos Diagrams ``` --- # Responsive Images and the `sizes` Prop This is one of the most useful `` props that beginners often ignore. Suppose an image is: ```text 100% width on mobile 50% width on tablet 33% width on desktop ``` You can tell the browser this using: ```jsx sizes ``` Example: ```jsx Product

``` This tells the browser approximately how much screen width the image will occupy. --- # Why `sizes` Matters Next.js generates multiple possible image widths through: ```text srcset ``` The browser then decides which one to download. Imagine Next.js provides: ```text 640px 750px 828px 1080px 1200px ... ``` If your image only occupies: ```text 33% of a desktop screen ``` the browser doesn't need to download a giant full-screen image. `sizes` helps it make the right choice. --- ## Without `sizes` For responsive `fill` images, the browser may assume something closer to: ```text 100vw ``` meaning: > "This image could be the full viewport width." That may cause it to download an unnecessarily large image. So if you're building responsive layouts with: ```jsx fill ``` don't forget: ```jsx sizes ``` Your users' mobile data will appreciate you. 😄 --- # Example: Responsive Product Grid Imagine a [grid](/courses/css): ```text Mobile 1 column Tablet 2 columns Desktop 3 columns ``` You could use: ```jsx {product.name}

``` That's exactly the type of problem `sizes` was designed to solve. --- # Lazy Loading By default, Next.js images use lazy loading. Conceptually: ```text Image above viewport ↓ Load normally Image far below viewport ↓ Wait User scrolls closer ↓ Start loading ``` This prevents a giant page from downloading every image immediately. Example: ```jsx Article illustration

``` You don't need to manually add: ```jsx loading="lazy" ``` because lazy loading is already the default. --- # But Should Every Image Be Lazy Loaded? No. This brings us to: **Largest Contentful Paint — LCP** --- > **Definition: Largest Contentful Paint (LCP)** > > LCP measures how quickly the largest important visible content element appears inside the viewport. A large hero image is often the LCP element. If the hero image is immediately visible, you usually don't want the browser treating it like some random image hiding at the bottom of the page. --- # Next.js 16: `priority` Is Deprecated Older Next.js tutorials commonly show: ```jsx Hero

``` You'll still see this in a lot of existing projects. But starting with **Next.js 16**, the: ```jsx priority ``` prop is deprecated. The clearer API is now: ```jsx preload ``` --- # Using `preload` Example: ```jsx Developer coding

``` When: ```jsx preload={true} ``` Next.js adds a preload link so the browser can discover that image earlier. This can be useful when the image is clearly the page's: ```text LCP image ``` such as a major hero image. --- # Don't Preload Everything This: ```jsx ``` is not optimization. That's panic. 😭 Preloading tells the browser: > "This resource is important. Start fetching it early." If you mark everything important... nothing is really important. Use it carefully. --- # `loading="eager"` Another option for immediately important images is: ```jsx Hero

``` This disables lazy loading for that image. Next.js currently recommends considering: ```jsx loading="eager" ``` or: ```jsx fetchPriority="high" ``` for many high-priority image situations rather than automatically preloading everything. --- # `fetchPriority="high"` Example: ```jsx Hero

``` This tells the browser that the image has a high fetch priority. Think of these tools as different levels of control: ```text Normal image ↓ Lazy load Important visible image ↓ loading="eager" or fetchPriority="high" Clear LCP image that should be discovered very early ↓ preload ``` Don't combine them randomly. Use the one that matches the situation. --- # Blur Placeholders Instead of showing empty space while an image loads, you can show a tiny blurred preview. Example: ```jsx Mountain landscape

``` For supported statically imported image formats, Next.js can provide blur placeholder information automatically. The user first sees something like: ```text ████ blurred image ████ ``` then: ```text Sharp final image ``` This doesn't necessarily make the real image download faster. But it can make the experience **feel** smoother. --- # Remote Blur Placeholders For remote images, Next.js doesn't automatically have a local tiny preview available. You can provide: ```jsx blurDataURL ``` yourself. Example: ```jsx Landscape

``` In production apps, the tiny blur value might come from your: - CMS - Image service - Database - Build process --- # The `alt` Prop Next.js requires: ```jsx alt ``` And no, this isn't just something to write because [React](/courses/reactjs) starts complaining. 😄 Good alt text helps: - Screen readers - Accessibility - Search engines - Users when images fail to load Bad: ```jsx alt="image" ``` Better: ```jsx alt="Developer working on a Next.js project" ``` --- # Decorative Images Sometimes the image adds no meaningful information. For example: ```text Decorative gradient Random background shape Visual divider ``` Then use: ```jsx alt="" ``` This tells screen readers that the image can safely be ignored. Don't write: ```jsx alt="blue decorative circle in top right corner" ``` unless that blue circle somehow contains the secret to understanding the page. 😭 --- # Image Quality You can control optimization quality: ```jsx Hero

``` Higher quality generally means: ```text Better visual fidelity + Larger files ``` Lower quality means: ```text Smaller files + Potentially less detail ``` Don't automatically use: ```jsx quality={100} ``` for everything. That's another excellent way to optimize absolutely nothing. 😄 --- # Next.js 16 Image Quality Allowlist Next.js 16 also tightened image optimization configuration. The default allowed quality configuration is: ```js qualities: [75] ``` You can explicitly allow more values: ```js const nextConfig = { images: { qualities: [ 50, 75, 90 ], }, } export default nextConfig ``` Then your application can use those configured quality levels. This helps prevent arbitrary image optimization requests with unlimited quality values. It's another small security/resource-control improvement in modern Next.js. --- # When Should You Use a Normal ``? `next/image` is great. But that doesn't mean: ```text = forbidden ancient technology ``` A regular image can still make sense in special cases. Examples include: - Images already fully optimized by another service - Special integrations - Generated markup - Cases where Next.js optimization isn't appropriate - Images requiring authentication headers that the default optimizer cannot forward Next.js also provides: ```jsx unoptimized ``` if you want to use the `` component without its image optimization pipeline. Example: ```jsx Logo

``` Use it intentionally, not because: > "Optimization sounded complicated." 😭 --- # A Real-World Hero Image Here's a solid modern example: ```jsx import Image from "next/image" export default function Hero() { return (

Learn Next.js

) } ``` Why: ```jsx fill ``` ? Because the image fills the hero container. Why: ```jsx sizes="100vw" ``` ? Because the hero takes the full viewport width. Why: ```jsx fetchPriority="high" ``` ? Because this could be an important above-the-fold/LCP image. That's optimization based on actual layout behavior. Not random prop collecting. 🔥 --- # A Real-World Product Card ```jsx import Image from "next/image" export default function ProductCard({ product }) { return (

{product.name}

) } ``` Notice that we don't preload it. Why? Because a product [grid](/courses/css) may contain: ```text 10 20 50 ``` images. Most of them should load lazily. --- # Common Mistakes ## ❌ Mistake 1: Using `fill` Without a Proper Container Bad: ```jsx

``` Better: ```jsx

``` --- ## ❌ Mistake 2: Forgetting `sizes` on Responsive Images ```jsx

``` may cause the browser to assume the image needs much more width than it actually does. Better: ```jsx

``` --- ## ❌ Mistake 3: Preloading Every Image Don't do: ```text Image 1 → preload Image 2 → preload Image 3 → preload Image 4 → preload Image 5 → preload ``` Usually only a very small number of critical images deserve special loading treatment. --- ## ❌ Mistake 4: Allowing Overly Broad Remote URLs Don't configure your image optimizer more broadly than necessary. Prefer: ```text images.example.com/products/** ``` over: ```text anything from anywhere ``` Security still matters even when the feature is "just images." --- ## ❌ Mistake 5: Assuming `` Fixes Every CLS Problem `` helps prevent layout shifts caused by unknown image dimensions. But your page can still have CLS from: - Ads - Dynamically inserted banners - Fonts - Animations - DOM changes - Other content So: ```text Next/Image ≠ Automatic perfect CLS score ``` It solves the image part of the problem when used correctly. --- # Quick Reference | Prop | Required? | Purpose | |---|---|---| | `src` | ✅ Yes | Local or remote image source | | `alt` | ✅ Yes | Accessible text alternative | | `width` | Usually | Intrinsic width | | `height` | Usually | Intrinsic height | | `fill` | Optional | Fill the parent instead of using width/height | | `sizes` | Important for responsive images | Tells browser expected rendered width | | `quality` | Optional | Controls optimization quality | | `placeholder` | Optional | Loading placeholder | | `blurDataURL` | Sometimes | Custom blurred placeholder | | `preload` | Optional | Preload an important image | | `loading` | Optional | `lazy` or `eager` loading | | `fetchPriority` | Optional | Browser fetch priority | | `unoptimized` | Optional | Skip Next.js optimization | --- # Old vs Modern Next.js Image Loading Older tutorials: ```jsx ``` Modern Next.js 16: ```jsx ``` when true preloading is actually needed. Or, depending on the use case: ```jsx ``` or: ```jsx ``` So if you see: ```jsx priority ``` in an older project, don't panic. You haven't discovered forbidden code. It's simply the older API. --- # The Mental Model Don't think: ```text = Fancy ``` Think: ```text Source Image ↓ Next.js understands its dimensions ↓ Creates optimized sizes ↓ Uses responsive srcset ↓ Browser chooses suitable version ↓ Lazy loads when appropriate ↓ Preserves layout space ``` And for remote images: ```text Remote URL ↓ remotePatterns security check ↓ Image optimization ↓ Browser ``` That's the bigger picture. --- ## Summary The Next.js `` component helps solve some of the most common image performance problems automatically. The important things to remember are: - Import `Image` from `next/image` - Images are lazy loaded by default - Next.js can generate multiple optimized sizes - WebP is the default optimized format - AVIF can be enabled through configuration - `width` and `height` provide the intrinsic aspect ratio - Static imports can automatically provide image dimensions - Remote images should be restricted using `remotePatterns` - Remote images normally need `width` and `height` unless using `fill` - `fill` is useful for fluid containers - The parent of a `fill` image needs appropriate layout positioning and dimensions - Responsive images should usually provide `sizes` - Blur placeholders can improve perceived loading experience - `alt` is required and matters for accessibility - `priority` is deprecated starting with Next.js 16 - Use `preload`, `loading="eager"`, or `fetchPriority="high"` intentionally for important images - Don't preload every image - `` helps prevent image-related CLS, but it can't fix unrelated layout shifts The biggest rule is simple: ```text Don't make users download more image than they actually need. ``` And that's the approach we'll keep following on **asif.to** — understand what Next.js is optimizing instead of blindly adding props until Lighthouse turns green. Once you understand `sizes`, `fill`, lazy loading, and image priority, `` stops feeling magical and starts feeling like a tool you actually control. 🚀