Code splitting breaks a [JavaScript](/courses/javascript) application into smaller bundles so users do not have to download all application code before they can start using the page. Lazy loading means loading some of those code chunks only when they are actually needed. ### Without Code Splitting Imagine an application contains: ```text Home page Dashboard Admin panel Analytics charts Code editor Settings ``` Without appropriate splitting, the initial [JavaScript](/courses/javascript) bundle may contain code for all of these features even when a visitor only opens the home page. Conceptually: ```text User opens Home ↓ downloads Home + Dashboard + Admin + Charts + Editor ``` As an application grows, this can increase initial loading time. ### With Code Splitting The application can be divided into chunks: ```text Initial bundle → common application code Dashboard chunk → loaded when dashboard is needed Admin chunk → loaded when admin is needed Editor chunk → loaded when editor is needed ``` Now the browser can avoid downloading some code until necessary. ### React.lazy [React](/courses/reactjs) provides `lazy()` for deferring the loading of component code. Instead of a normal import: ```jsx import Analytics from "./Analytics"; ``` use: ```jsx import { lazy } from "react"; const Analytics = lazy(() => import("./Analytics") ); ``` The component's code is not loaded until [React](/courses/reactjs) first tries to render it. ### Suspense Provides the Loading UI A lazy component may need time to download. Wrap it with `Suspense`: ```jsx import { lazy, Suspense, useState } from "react"; const Analytics = lazy(() => import("./Analytics") ); function Dashboard() { const [showAnalytics, setShowAnalytics] = useState(false); return ( <> {showAnalytics && ( Loading analytics...

}> )} ); } ``` The flow becomes: ```text User clicks Show Analytics ↓ Analytics component is needed ↓ its code starts loading ↓ Suspense fallback appears ↓ code finishes loading ↓ Analytics renders ``` ### Declare Lazy Components Outside Other Components Prefer: ```jsx const Analytics = lazy(() => import("./Analytics") ); function Dashboard() { // ... } ``` Do not repeatedly declare the lazy component inside another component: ```jsx function Dashboard() { const Analytics = lazy(() => import("./Analytics") ); } ``` Doing so creates a different component type during renders and can cause state-reset problems. ### Route-Level Code Splitting Routes are natural boundaries for code splitting because users often visit only part of an application during a session. Conceptually: ```text / → home code /dashboard → dashboard code /admin → admin code ``` Routing frameworks and build tools may provide their own route-based code-splitting mechanisms, so use framework-specific features when they offer a better integrated solution. ### What Should Be Lazy Loaded? Good candidates can include: ```text Large route sections Rich text editors Code editors Charts Admin tools Heavy modals Features users rarely open ``` ### Do Not Lazy Load Everything Over-splitting can create many additional network requests and loading waterfalls. For a tiny component needed immediately: ```jsx ``` lazy loading may make the experience worse rather than better. ### Code Splitting vs React.memo These solve different performance problems: ```text React.memo / useMemo / useCallback → reduce unnecessary repeated work after code is running Code splitting / lazy loading → reduce how much code needs to load initially ``` ### Interview-Ready Answer Code splitting divides an application into smaller JavaScript bundles, while lazy loading delays downloading some code until it is needed. React's `lazy()` can dynamically load a component, and `Suspense` provides fallback UI while the component code is loading. Lazy loading is especially useful for large routes and heavy features, but excessive splitting can create unnecessary loading waterfalls.