Performance

Performance in a React application is two separate problems that get discussed as one. The first is how much work happens when something on screen changes. The second is how many bytes the browser downloads before the page responds to anything.

The symptoms differ. Too much rendering work feels like a filter lagging a keystroke behind the keyboard, or a list that stutters as it scrolls. Too much JavaScript feels like a page that looks finished but ignores the first click or two, and it is worst on a mid-range phone on a mobile connection.

The fixes differ as well, so the first job is finding out which problem you have. Guessing is expensive. A large share of the memoisation in React codebases was added to components that were never slow, and it is still there, still being maintained.

import { memo, useCallback, useMemo, useState } from "react";

type Employee = {
  id: string;
  name: string;
  department: string;
};

// Rendered once per employee. memo means this only re-renders when the
// props it receives actually differ from last time.
const EmployeeRow = memo(function EmployeeRow({
  employee,
  onSelect,
}: {
  employee: Employee;
  onSelect: (id: string) => void;
}) {
  return (
    <li>
      <button type="button" onClick={() => onSelect(employee.id)}>
        {employee.name} ({employee.department})
      </button>
    </li>
  );
});

export function EmployeeDirectory({ employees }: { employees: Employee[] }) {
  const [search, setSearch] = useState("");
  const [selectedId, setSelectedId] = useState<string | null>(null);

  // Recomputed when the list or the search term changes. Other state
  // updates in this component hand back the previous array.
  const visible = useMemo(() => {
    const term = search.trim().toLowerCase();
    if (term === "") return employees;
    return employees.filter((employee) =>
      employee.name.toLowerCase().includes(term)
    );
  }, [employees, search]);

  // A new arrow function on every render would defeat the memo above.
  const handleSelect = useCallback((id: string) => setSelectedId(id), []);

  return (
    <>
      <label htmlFor="employee-search">Search employees</label>
      <input
        id="employee-search"
        type="search"
        value={search}
        onChange={(event) => setSearch(event.target.value)}
      />
      <ul>
        {visible.map((employee) => (
          <EmployeeRow
            key={employee.id}
            employee={employee}
            onSelect={handleSelect}
          />
        ))}
      </ul>
      {selectedId ? <EmployeeDetail employeeId={selectedId} /> : null}
    </>
  );
}

• memo wraps a component and tells React to skip the re-render when the new props match the old ones. The comparison is per prop, with ===, so it is reference equality for objects and functions.
• useMemo caches a computed value between renders. The dependency array is the contract: recompute when employees or search changes, otherwise return the previous array. Returning the same array reference is half the point, because anything downstream comparing by reference then sees no change.
• useCallback does the same for a function. This is the part that is easy to get wrong: an inline arrow function is a new value on every render, so a memo-wrapped child receiving one always sees changed props. memo on the row without useCallback on the handler does close to nothing.
• The empty dependency array on handleSelect is safe because setSelectedId is a state setter, and React guarantees setters keep the same identity for the life of the component. If the handler read a value from props, that value would belong in the array.
• The React ESLint rules check these arrays. Take the warnings seriously — a missing dependency means a stale value, and a stale value is much harder to notice than a slow render.
• Delete all three and this component behaves identically, with more work per keystroke. That is the test for whether a change is an optimisation: it changes timings, not outcomes, so it needs a measurement to justify it.

"use client";

import dynamic from "next/dynamic";
import { useState } from "react";

// The charting library is no longer part of the initial download. Its
// chunk is fetched the first time this component renders.
const HeadcountChart = dynamic(() => import("./HeadcountChart"), {
  loading: () => <p>Loading chart</p>,
  ssr: false,
});

export function DirectoryInsights() {
  const [showChart, setShowChart] = useState(false);

  return (
    <section>
      <h2 id="headcount-heading">Headcount by department</h2>
      <button
        type="button"
        aria-expanded={showChart}
        aria-controls="headcount-chart"
        onClick={() => setShowChart(true)}
      >
        Show chart
      </button>
      <div id="headcount-chart">
        {showChart ? <HeadcountChart /> : null}
      </div>
    </section>
  );
}

• next/dynamic puts the imported module in its own chunk. The bytes for the charting library leave the initial download and arrive only if a user opens the chart.
• The loading fallback is a real state, not a courtesy. On a slow connection the gap is visible, and a button that appears to do nothing gets pressed again.
• ssr: false keeps the component out of server rendering, which is necessary for code that touches browser APIs at import time. Leave it off when the component can render on the server, because then its content is in the initial HTML.
• aria-expanded and aria-controls tell a screen reader user that this button reveals something and what it reveals. The container element exists before the chart does, so the relationship is not broken while the chunk loads.
• Measure the effect rather than assuming it. The production build prints the JavaScript size per route, including the shared first load, and a bundle analyser shows which dependency is responsible. The answer is often one large library doing a job that thirty lines could do.
• Dynamic import suits anything behind an interaction: a chart, a rich text editor, an export dialog, a map. It is the wrong tool for something every visitor sees straight away, because you have added a round trip and a loading state without reducing what is needed.