Next.js Rendering & Bundle Simulator

Every kilobyte of JavaScript you send to the browser has to be downloaded, parsed, compiled, and executed before your page becomes interactive. A single heavy component (a rich text editor, a video player, a charting library) can quietly add hundreds of kilobytes to that bill. The twist: the exact same component can be almost free or brutally expensive depending on how you render it.

So instead of just telling you, let me show you. Pick a component, pick a rendering strategy, and watch the initial payload, LCP, and TBT move. Then read on for why the numbers land where they do.

01The initial bundle is a bill users pay upfront

When someone opens your page, the browser cannot show a fully interactive UI until it has fetched and run the JavaScript that describes it. That first chunk of JS is your initial bundle. Everything in it is on the critical path: it competes for bandwidth on a phone with two bars of signal, then for main-thread time on a mid-range CPU that is four times slower than your MacBook.

This is why two metrics dominate the simulator above. LCP (Largest Contentful Paint) is when the biggest, most meaningful thing finishes painting. TBT (Total Blocking Time) is how long the main thread was frozen parsing and hydrating your JavaScript, unable to respond to taps and clicks. A fat initial bundle pushes both up.

02Four ways to ship the same heavy component

The simulator offers four strategies for the exact same component. Here is what each one actually does to your bundle and your main thread.

03Server Components: ship zero client JS

In the Next.js App Router, every component is a Server Component by default. It runs on the server, produces HTML, and sends no JavaScript to the browser for its own logic. That is why the simulator reports 0 KB initial payload and an 800 ms LCP for this strategy: the browser paints from ready-made HTML.

// No "use client" directive = Server Component.
// This renders on the server. Its code never ships to the browser.

import { getStats } from "@/lib/stats";

export default async function DashboardPage() {
  const stats = await getStats(); // runs on the server

  return (
    <section>
      <h1>Overview</h1>
      {/* Static, data-driven markup. Zero client JS. */}
      {stats.map((s) => (
        <StatRow key={s.id} label={s.label} value={s.value} />
      ))}
    </section>
  );
}

The moment you need useState, useEffect, or an onClick, you cross into Client Component territory and add the "use client" directive. The skill is drawing that boundary as low in the tree as possible, so only the genuinely interactive leaf ships JavaScript, not the whole page.

04next/dynamic: defer the weight you can't delete

Sometimes a component genuinely needs to be interactive, but it is not needed for the first paint. A rich text editor below the fold, a chart in a tab, a modal behind a button. This is where next/dynamic earns its keep: it splits the component into a separate chunk that loads after the initial render. In the simulator, notice how the weight jumps from the Initial Bundle to the striped Deferred Bundle, and LCP and TBT stay low.

"use client";

import dynamic from "next/dynamic";

// The 280 KB editor is NOT in the initial bundle.
// It loads on demand, with a lightweight skeleton in its place.
const RichTextEditor = dynamic(
  () => import("@/components/RichTextEditor"),
  {
    ssr: false, // client-only widget, skip server render
    loading: () => <EditorSkeleton />,
  }
);

export default function EditorPanel() {
  return (
    <div>
      <Toolbar />
      {/* Renders instantly; the heavy chunk streams in behind it */}
      <RichTextEditor />
    </div>
  );
}

05Third-party scripts: the tax you forgot to budget

Your own code is usually not the villain. Analytics, chat widgets, A/B testing snippets, and social embeds are. Loaded eagerly in the document head, a third-party script blocks the main thread before your content ever paints. That is why the Eager 3rd-Party strategy posts the worst LCP and TBT in the simulator: it stacks extra weight and a render-blocking penalty on top of the component.

Next.js gives you a release valve with the next/script component and its strategy prop. Use it to move non-critical scripts off the critical path.

import Script from "next/script";

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}

        {/* afterInteractive: loads after the page is interactive.
            Good default for analytics. */}
        <Script src="https://analytics.example.com/a.js"
                strategy="afterInteractive" />

        {/* lazyOnload: waits for idle time. Great for chat
            widgets and anything the user rarely needs immediately. */}
        <Script src="https://widget.chat.com/w.js"
                strategy="lazyOnload" />
      </body>
    </html>
  );
}

06Reading LCP and TBT like a performance engineer

The two timeline bars in the simulator map to the two questions users actually feel: "when can I see it?" and "when can I use it?"

Go back to the simulator with this lens. Ship the Rich Text Editor as a Server Component and both bars stay green, but you lose interactivity. Ship it eagerly on the client and TBT turns red. Wrap it in next/dynamic and you buy back a green timeline while keeping the interactivity. That trade, made component by component, is most of front-end performance work.