Slow First Load: Bundles, Code Splitting and LCP

The first load decides your LCP. LCP (Largest Contentful Paint) is a Core Web Vitals metric (Core Web Vitals are Google's three main measures of page experience): the time from the start of the page load until the largest image or block of text in the visible part of the page is drawn. A good LCP is 2.5 seconds or less at the 75th percentile (three out of four visits are at or below it). See Browser Contract, Lesson 09. It also affects SEO (how well search engines rank your page), bounce rate (the share of people who leave at once) and sales. This lesson shows you how to find the problem and make the first load smaller.

Step 1: measure what you are shipping

See the bundle

A bundle is the JavaScript file (or files) that a bundler (a build tool such as webpack, Turbopack or Vite) makes by joining your code and libraries for the browser. First, look inside it.

• Next.js 16: run npx next experimental-analyze. It starts a local page with a treemap (a picture where each module is a box sized by its share of the total). You can filter by route and by client or server, and click a module to see which imports pulled it in. Add --output to save the result and compare it before and after a change. (Next.js 16 no longer prints "First Load JS" sizes in the next build output, because they were not accurate with Server Components.) For Webpack builds you can use the @next/bundle-analyzer plugin instead (build with next build --webpack):

// next.config.tsimport analyzer from "@next/bundle-analyzer";const withAnalyzer = analyzer({ enabled: process.env.ANALYZE === "true" });export default withAnalyzer({ /* your config */ });// ANALYZE=true pnpm next build --webpack

• Vite/Webpack apps: use rollup-plugin-visualizer, webpack-bundle-analyzer, or source-map-explorer on the production source maps.
• Lighthouse is a Google tool (built into Chrome DevTools) that tests a page and gives a score and advice. It shows "Reduce unused JavaScript" and "Reduce JavaScript execution time".
• The DevTools Coverage panel shows how much of each file really ran on load.

Sizes: know which number you are quoting

Say a bundle is "2 MB" but only 600 KB goes over the network. The browser must still unpack it, then parse it (read the code), compile it (turn it into machine instructions) and run all 2 MB. On a mid-range phone this is often worse than the download. Always say which number you mean.

Check the waterfall

The waterfall is a chart of every request, in time order, with a bar for each file. Use the Network tab (set to "Slow 4G" and CPU 4x slower) and a tool like WebPageTest (a free site that tests a page on real devices). Look for these things:

• When the HTML, CSS, JS, LCP image and fonts are requested.
• What blocks rendering (stops the page from drawing).
• How many requests are chained (a script loads a script that loads a font).

Step 2: the levers

A lever is one thing you can change to make the first load faster.

Lever 1: send less JavaScript

Lever 2: code splitting

Code splitting means cutting the bundle into smaller chunks. Each page then loads only what it needs. Heavy features that few people use load only when needed. A dynamic import (import("./Chart")) is the JavaScript call that loads a module later, on demand, and returns a promise.

• Route-level splitting is automatic in Next.js. Each page is its own chunk (a separate file made by the bundler).
• Component-level splitting is for heavy or optional parts of the UI: charts, rich-text editors, maps, PDF viewers, modals, admin panels.

import dynamic from "next/dynamic";const Chart = dynamic(() => import("./Chart"), {  ssr: false,                      // only if it needs `window`/canvas and isn't needed for first paint  loading: () => <div style={{ height: 320 }} aria-busy="true" />,   // reserve space to avoid layout shift});

// Plain React: lazy + Suspense// React.lazy loads a component only when it is first drawn; Suspense shows a fallback while it loadsconst Editor = React.lazy(() => import("./Editor"));<Suspense fallback={<EditorSkeleton />}>{showEditor && <Editor />}</Suspense>

Load code when the user acts (they open the modal, so you import the editor). Or load it when the part becomes visible (use IntersectionObserver, a browser API that tells you when an element enters the screen). Do not load it when the page first opens.

Lever 3: Server Components and streaming

In the Next.js App Router, Server Components are React components that run only on the server. They send no component JavaScript to the browser, only their output. So make components server-side by default. Add "use client" only to small interactive parts (Frontend Depth, Lesson 02).

Streaming means the server sends the page in pieces instead of waiting to finish all of it. You use <Suspense> boundaries for this (a <Suspense> boundary shows a fallback until the content inside is ready). The page shell and the top of the page arrive first. Slower data follows later. Less JS also means less hydration, which is the browser work that attaches React and event handlers to server-made HTML so it becomes interactive. See Lesson 01.

Lever 4: images (the usual LCP element)

• Right format: use AVIF or WebP instead of PNG or JPEG where the browser supports them.
• Right size: use responsive srcset and sizes (HTML attributes that let the browser pick the best file for the screen width). Never show a 4000 px image at 400 px.
• Right priority: the LCP image must be in the HTML. It must not be lazy-loaded (lazy-loading means the browser fetches an image only when it is near the screen, which is too late for the main image). Fetch it with fetchpriority="high", an HTML attribute that tells the browser this file matters most. In Next.js, write <Image fetchPriority="high" loading="eager" />. The older priority prop is deprecated since Next.js 16 (the preload prop replaced it; the docs advise loading="eager" or fetchPriority="high" in most cases). Everything below the fold (the part you must scroll to see) gets loading="lazy".
• Reserve space: set width and height, or CSS aspect-ratio. This stops layout shift (content jumping when something loads).
• Serve from a CDN (content delivery network: many servers around the world that keep copies of your files close to users) with long cache times and correct compression.

import Image from "next/image";<Image src="/hero.jpg" alt="…" width={1200} height={630} fetchPriority="high" loading="eager" sizes="100vw" />

Lever 5: fonts

Web fonts can hide your text for a while (invisible text). They can also move the layout when the real font replaces the first one.

• Self-host the fonts (serve them from your own domain) and subset them (keep only the letters and weights you use). next/font does this. It also removes the extra network trip to a font CDN.
• Use font-display: swap (a CSS rule that shows text at once in a fallback font and swaps in the real font when it loads). optional is similar, but it skips the swap if the font is late.
• Use size-adjusted fallbacks (the CSS descriptors size-adjust and ascent-override). They make the fallback font about the same size as the real one, so less shift happens. next/font does this for you.
• Preload (tell the browser early to fetch) the one or two most important font files. Keep the number of weights and styles low.

Lever 6: CSS and render-blocking resources

A render-blocking resource stops the browser from drawing the page until it has loaded. CSS blocks rendering. Synchronous scripts (a plain <script src> with no defer or async) block parsing (the browser's reading of the HTML). See Browser Contract, Lesson 00.

• Keep CSS small. Remove unused CSS (Tailwind's purging, CSS modules). Put critical CSS (the CSS needed for the first screen) inline, if your framework supports it.
• Use defer (download while the HTML is read, run after it is read), async (run as soon as it downloads) or type="module" (deferred by default) for scripts. Avoid synchronous third-party tags in <head>.
• Load third-party scripts (analytics, chat, A/B tools) with next/script strategies. afterInteractive (the default) loads after some hydration. lazyOnload loads when the browser is idle. Also ask if you need each one at all.

Lever 7: network and delivery

• Compression: use Brotli (or gzip) for text files (HTML, CSS, JS, JSON, SVG) at the CDN or server.
• Caching: give hashed files (files with a content hash in the name, so the name changes when the content changes) a year-long Cache-Control: public, max-age=31536000, immutable header. immutable tells the browser the file will never change. See Browser Contract, Lesson 05.
• CDN to cut RTT (round-trip time: the time for a request to go and come back). Use HTTP/2 or HTTP/3 (newer versions of the web protocol) so many requests can share one connection.
• Fewer origins: each new origin (the scheme, domain and port, such as https://cdn.example.com) adds DNS (finding the server's address), TCP (opening the connection) and TLS (setting up encryption) work. Use preconnect only for the few that are truly critical.
• Avoid redirect chains (one redirect leading to another) such as http to https to www to /en.

Preload vs prefetch vs preconnect

These are hints you give the browser about what to load early.

Difference in one line: preload is for this page and starts now; prefetch is for a later page and waits until the browser is idle.

Too much preload hurts. The files compete with other important files. Preload one or two things that you have checked are found late.

Putting it together

Example numbers (not a measurement):

Typical LCP timeline (bad)                          Optimised─────────────────────────────                       ─────────────────────────────HTML ........ 900 ms (no CDN, no streaming)         HTML (CDN, streamed) ...... 150 msCSS ......... blocks until 1,100 ms                 Critical CSS inline ........ 0 ms extraJS bundle 2 MB executes until 2,400 ms              ~150 KB initial JS, rest lazyLCP image discovered by JS at 2,500 ms              <img fetchpriority=high> in HTML, fetched at 200 msLCP ≈ 3.8 s                                         LCP ≈ 1.4 s

Scenario: the JS bundle is 2 MB. Plan how to halve it.

1. Set a baseline. Write down the parsed and compressed sizes per route (from the analyzer), the Lighthouse unused-JS number, and the real-user LCP and INP. Real-user data (also called field data) comes from the browsers of your actual visitors. INP (Interaction to Next Paint) is a Core Web Vitals metric: how long the page takes to show a visual response after a click, tap or key press. A good INP is 200 ms or less.
2. Analyse. Run the bundle analyzer. List the top 10 contributors. Look for the usual causes:
   • a date or charting library
   • a whole icon pack
   • moment locales
   • two versions of React or lodash
   • an unused UI kit
   • a polyfill bundle
3. Do the quick wins first:
   • Remove unused dependencies and dead code.
   • Fix imports (one icon, one function, lodash-es). Add a package to optimizePackageImports if it exports hundreds of modules and is not already handled.
   • Remove duplicate versions (pnpm dedupe, resolutions).
   • Target modern browsers to drop polyfills.
4. Split what is left. Use dynamic imports for heavy features: below-the-fold parts and features used only after a click (editor, charts, admin, PDF export). Check that each one now loads only when needed.
5. Move work to the server. Turn parts that are not interactive into Server Components. Do formatting, highlighting and markdown on the server.
6. Replace heavy libraries with lighter or native options where it is worth it.
7. Check delivery: Brotli, cache headers, CDN.
8. Lock it in. Set a performance budget (a size or time limit you agree not to pass) in CI (continuous integration: checks that run automatically on every code change). Tools: size-limit or Lighthouse CI. The CI job fails when the JS goes over the limit.
9. Measure again: parsed and compressed sizes, route JS size, LCP, INP and Total Blocking Time (TBT: a lab metric that adds up, for every task longer than 50 ms, the time beyond the first 50 ms, between first paint and the page becoming interactive). The main thread is the one thread that runs your JavaScript and also draws the page. After release, confirm the gain in real-user data.

Diagnosing a poor LCP: a short procedure

1. Find the LCP element. Use Lighthouse, or the "LCP" marker in the DevTools Performance panel (its insights sidebar also explains LCP).
2. Break LCP into four parts (when the LCP element is text, the two "resource" parts are zero): TTFB (Time To First Byte: the time until the first byte of the HTML arrives), resource load delay, resource load duration and element render delay.
3. Fix the biggest part:
   • High TTFB: use a CDN, caching, streaming and faster data (Lesson 02).
   • High load delay: make the LCP resource easy to find in the HTML. Preload it. Remove heroes added by JS or set as CSS backgrounds. Do not lazy-load it.
   • High load duration: use a smaller, modern, correctly sized image. Use a CDN.
   • High render delay: look for render-blocking CSS or JS, client-side rendering that waits for JS, and a busy main thread.

Common mistakes

1. Quoting only the gzipped size and ignoring the cost to parse and run the code.
2. Lazy-loading the hero image.
3. Importing a whole library for one function, or importing through barrel files.
4. Rendering content in the browser when the server could render it.
5. Preloading everything.
6. Loading third-party scripts synchronously or at page load.
7. No performance budget, so the bundle grows back.
8. Tuning on a fast machine with a warm cache (files already stored in the browser).

Interview questions

Key takeaways

• Measure the parsed and compressed bundle size, route by route. Use an analyzer and Lighthouse. Read the waterfall.
• Send less (dead code, lighter libraries, tree-shaking, no needless polyfills). Split the rest (dynamic imports when the user acts or the part is visible). Move work to Server Components.
• Make the LCP resource load early and with high priority. Optimise images and fonts. Keep CSS and scripts from blocking.
• Use preload sparingly, prefetch for next pages, and preconnect for critical origins.
• Enforce a budget and watch real-user data.

What's next

Lesson 07: Rendering 10,000 Rows. After the page has loaded, a very common problem is showing a very large list or table without freezing the browser.