Loading everything a page might ever need upfront is the easiest way to build something — and one of the most reliable ways to make it slow. Lazy loading defers work until it's actually needed, trading a bit of complexity for real, measurable performance gains.
Lazy loading is the practice of deferring the loading of resources — images, components, routes, or data — until they're actually needed, rather than loading everything upfront. Applied to images below the fold, JavaScript for routes the user hasn't visited yet, or components behind a modal that isn't open, it reduces initial load time and bandwidth usage without removing any functionality.
Why Lazy Loading Matters (and When to Skip It)
Initial page load performance directly affects both user experience and Core Web Vitals metrics like LCP — loading resources the user won't see or use immediately is wasted work that delays what actually matters for that first render. Lazy loading defers that cost to exactly when it's needed, or skips it entirely if the user never triggers it.
Skip lazy loading for above-the-fold, immediately-needed content — lazy loading your LCP image, for instance, actively hurts performance by delaying the very thing that metric measures. It's a tool for deferring what's not immediately needed, not a blanket default for everything.
Getting Started with Lazy Loading
Native image lazy loading:
<img src="/photo.jpg" loading="lazy" alt="..." />
Component-level lazy loading in React:
import { lazy, Suspense } from "react";
const HeavyChart = lazy(() => import("./HeavyChart"));
function Dashboard() {
return (
<Suspense fallback={<Spinner />}>
<HeavyChart />
</Suspense>
);
}
Route-based code splitting in Next.js (automatic per route by default, but explicit dynamic import for heavy components):
import dynamic from "next/dynamic";
const MapWidget = dynamic(() => import("./MapWidget"), {
loading: () => <Spinner />,
ssr: false,
});
Core Lazy Loading Concepts Every Developer Should Know
Native loading="lazy" on images defers offscreen images with zero JavaScript, using the browser's built-in intersection detection — the simplest and most broadly supported form of lazy loading, worth using as a default for any below-the-fold image.
Component lazy loading via dynamic imports splits your JavaScript bundle, so code for a component isn't downloaded until it's actually rendered — particularly valuable for heavy, infrequently-used components (rich text editors, charting libraries, modals) that not every user will trigger.
Never lazy-load your LCP element. Since LCP measures the largest visible content's render time, lazy loading it directly delays the metric it would otherwise help — the LCP image or hero content should load eagerly, ideally even preloaded.
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />
Data lazy loading (pagination, infinite scroll, deferred fetches) applies the same principle to data, not just assets — fetching only what's visible or immediately needed, loading more as the user scrolls or navigates, rather than fetching an entire dataset upfront.
Common Lazy Loading Mistakes and How to Fix Them
Mistake 1: lazy loading the LCP image or above-the-fold content, actively hurting the metric lazy loading is supposed to help. Fix: load above-the-fold, immediately visible content eagerly (and consider preloading it); reserve lazy loading for genuinely offscreen or conditionally rendered content.
Mistake 2: no loading/fallback state for lazily loaded components, causing a jarring blank gap or layout shift when the component finally loads. Fix: always provide a properly sized loading state (skeleton or spinner matching the eventual content's dimensions) to avoid layout shift.
Mistake 3: over-splitting into too many tiny lazy-loaded chunks, adding network request overhead that outweighs the benefit for small components. Fix: reserve component-level lazy loading for genuinely heavy dependencies, not every small component reflexively.
When Should You Use Lazy Loading Instead of Loading Everything Upfront?
Use lazy loading for below-the-fold images, heavy components not needed on initial render (modals, rich editors, charts), and routes/code paths the user hasn't navigated to yet. Load eagerly for anything above the fold, critical to the initial render, or small enough that the overhead of splitting it out isn't worth the complexity.
Lazy Loading in Production
Audit your bundle and network waterfall periodically (via Lighthouse or your browser's network tab) to identify what's being loaded unnecessarily upfront — lazy loading opportunities tend to accumulate as an application grows and aren't always obvious without measurement. Also verify lazy-loaded content doesn't cause layout shift, since a poorly implemented loading state can trade one performance problem (slow load) for another (CLS).
If your bundle analysis shows large chunks being loaded on every page regardless of whether they're used, that's a concrete lazy-loading opportunity worth acting on first.