Week 14: Profiling & Code-Splitting

1. React DevTools Profiler

Before optimizing anything, measure. The React DevTools browser extension includes a Profiler tab: click record, interact with your app, stop recording, and see exactly which components rendered, how long each took, and — critically — why each one rendered.

// For each component that rendered during the recording:
// - Render duration (ms)
// - "Why did this render?" -- props changed, state changed, parent re-rendered, context changed
// - A flame graph: wider bars = more time spent

The "why did this render" information is the most actionable part — it tells you directly whether a slow component is slow because of expensive work inside it (a candidate for useMemo, Week 3) or because it re-rendered unnecessarily due to a parent re-rendering with a fresh prop reference (a candidate for React.memo + useCallback, also Week 3).

2. React.memo, Revisited

Week 3 introduced useCallback in the context of React.memo without deep-diving memo itself. React.memo wraps a component so React skips re-rendering it when its props are shallowly equal to last time:

const ProductCard = React.memo(function ProductCard({ product }: { product: Product }) {
  console.log('rendering', product.name);
  return <div>{product.name} — ${product.price}</div>;
});

"Shallowly equal" means each individual prop is compared with Object.is — exactly the same comparison Week 2's dependency arrays use. This is precisely why a fresh object or function reference on every render (an inline handler, an inline array literal) defeats memo even when the data inside it is identical — the same lesson Week 3 covered for useCallback, now generalized: memoization only works when the things being compared are actually stable across renders.

A quick heuristic for when React.memo is worth adding: the component renders often relative to how often its actual props change, and rendering it is measurably not free — confirmed by the Profiler, not guessed at.

3. Route-Based Code-Splitting

By default, a bundler ships your entire app as one (or a few) JavaScript files — a user visiting the login page downloads the code for the admin dashboard too, even though they'll likely never see it. Code-splitting breaks the bundle into pieces loaded on demand.

import DashboardPage from './pages/DashboardPage';
import SettingsPage from './pages/SettingsPage';
import AdminPage from './pages/AdminPage'; // large, rarely visited -- shipped to everyone anyway

const router = createBrowserRouter([
  { path: '/dashboard', element: <DashboardPage /> },
  { path: '/settings', element: <SettingsPage /> },
  { path: '/admin', element: <AdminPage /> },
]);

import { lazy, Suspense } from 'react';
import DashboardPage from './pages/DashboardPage';
import SettingsPage from './pages/SettingsPage';

const AdminPage = lazy(() => import('./pages/AdminPage'));

const router = createBrowserRouter([
  { path: '/dashboard', element: <DashboardPage /> },
  { path: '/settings', element: <SettingsPage /> },
  {
    path: '/admin',
    element: (
      <Suspense fallback={<PageSkeleton />}>
        <AdminPage />
      </Suspense>
    ),
  },
]);

React.lazy(() => import('./pages/AdminPage')) tells the bundler to put AdminPage and everything it imports into a separate file, fetched only the first time a user actually navigates to /admin. This is the exact same Suspense component from Week 12 — lazy is a component that suspends while its chunk downloads, using the identical mechanism as a suspending data fetch.

4. Lazy-Loading Non-Route Code

The same pattern applies to anything heavy and conditionally shown, not just whole routes — a modal, a rich text editor, a charting library only used on one rarely-visited screen:

import { lazy, Suspense, useState } from 'react';

const AvatarCropper = lazy(() => import('./AvatarCropper')); // pulls in a large image library

function SettingsPage() {
  const [isCropping, setIsCropping] = useState(false);

  return (
    <div>
      <button onClick={() => setIsCropping(true)}>Change avatar</button>
      {isCropping && (
        <Suspense fallback={<p>Loading editor...</p>}>
          <AvatarCropper />
        </Suspense>
      )}
    </div>
  );
}

Most users who visit SettingsPage never click "Change avatar" at all — lazy-loading AvatarCropper means its (potentially large) image-processing dependencies never download for those users, only for the ones who actually trigger it.

5. Bundle Analysis

To know what's actually worth splitting, you need to see what's in your bundle in the first place. rollup-plugin-visualizer (Vite is built on Rollup) generates an interactive treemap of your final bundle:

npm install -D rollup-plugin-visualizer

import { visualizer } from 'rollup-plugin-visualizer';

export default defineConfig({
  plugins: [
    react(),
    visualizer({ open: true, gzipSize: true }),
  ],
});

Running a production build (npm run build) now opens a treemap where box size represents each dependency's actual size in the final bundle. This routinely surfaces surprises: a date library pulled in wholesale for one formatting call, a charting library imported at the top level when only one rarely-visited page uses it — both are prime code-splitting candidates once you can actually see them.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.