Performance and accessibility

Two qualities separate a hobby project from a professional one: it is fast, and everyone can use it. Both are easy to ignore while you build on a fast laptop with a mouse. Your users may be on a budget Android phone, a patchy mobile network, or using a keyboard or a screen reader.

This lesson covers both. The golden rule for performance is: measure first, then fix. Most code does not need optimising, and guessing wastes time.

Google defines three measurements of real user experience, called Core Web Vitals. The exact thresholds are published on web.dev, so check there for current values.

- LCP (Largest Contentful Paint): how long until the biggest thing on screen (usually a hero image or heading) appears. It is about loading. - INP (Interaction to Next Paint): how quickly the page responds visually after a click, tap or key press. It is about responsiveness. It replaced an older measure called FID. - CLS (Cumulative Layout Shift): how much the layout jumps around while loading, such as a button moving just as you tap it. It is about visual stability.

By default, your bundler puts all your code into a few big files that every visitor downloads, even for pages they never open. Code splitting loads a page's code only when it is needed. React gives you lazy and Suspense, and Vite splits the bundle at each dynamic import().

The best place to split is routes: the admin page's code need not load for a visitor to the home page.

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';
import Home from './pages/Home.jsx';

// Loaded only when the user first visits /reports
const Reports = lazy(() => import('./pages/Reports.jsx'));

export default function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/reports" element={<Reports />} />
      </Routes>
    </Suspense>
  );
}

lazy needs a component that is the default export of the imported file. Suspense shows the fallback while the code downloads. After npm run build, Vite prints a separate file for Reports.

Images are usually the heaviest part of a page. A few habits help a lot:

- Resize images to the size they are shown. Do not ship a 4000-pixel photo for a 300-pixel card. - Use modern formats such as WebP or AVIF where you can, and compress them. - Add loading="lazy" to images that are below the fold so they load only when scrolled near. - Always give width and height (or an aspect ratio) so the browser reserves space and the layout does not jump.

<img
  src={recipe.image}
  alt={`Photo of ${recipe.name}`}
  width={300}
  height={200}
  loading="lazy"
/>

Do not lazy-load the main image at the top of the page; that is the one that decides your LCP.

A component re-renders when its state changes, when its parent re-renders, or when a context it reads changes. Re-rendering is normally cheap, and React is fast. It becomes a problem when a render is expensive or happens very often.

Three tools exist for the problem cases:

- React.memo(Component) skips re-rendering a component if its props are the same as last time. - useMemo(() => compute(), [deps]) remembers the result of an expensive calculation. - useCallback(fn, [deps]) remembers a function, so a memoised child receives the same prop each time.

They work together: memo compares props by identity, and a function or object created inline is a new value each render, so useCallback or useMemo keeps it stable.

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

const RecipeRow = memo(function RecipeRow({ recipe, onSelect }) {
  console.log('render', recipe.name);
  return <li onClick={() => onSelect(recipe.id)}>{recipe.name}</li>;
});

export default function RecipeList({ recipes }) {
  const [query, setQuery] = useState('');
  const [selectedId, setSelectedId] = useState(null);

  // Recalculated only when recipes or query change
  const visible = useMemo(
    () => recipes.filter((r) => r.name.toLowerCase().includes(query.toLowerCase())),
    [recipes, query]
  );

  // Same function identity on every render, so memo can skip rows
  const handleSelect = useCallback((id) => setSelectedId(id), []);

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} aria-label="Search recipes" />
      <p>Selected: {selectedId ?? 'none'}</p>
      <ul>
        {visible.map((r) => (
          <RecipeRow key={r.id} recipe={r} onSelect={handleSelect} />
        ))}
      </ul>
    </>
  );
}

Click a row: only the component state of the parent changes, and the console shows no 'render' lines for unchanged rows. Remove memo or useCallback and you will see every row log again.

Rendering 5,000 rows creates 5,000 sets of DOM nodes, and the page becomes slow no matter how clean your code is. Fix this by showing less: pagination (pages of 20), a load more button, or virtualisation, which renders only the rows visible in the window. Libraries such as @tanstack/react-virtual or react-window do virtualisation. Always make sure each item has a stable key (an id, not the array index, if the list can be reordered or filtered).

A search box that calls an API on every key press wastes bandwidth and shows flickering results. Debounce it: wait until the user stops typing for a moment (for example 300 ms) and then search. You can build a small useDebounce hook or use one from a library.

import { useEffect, useState } from 'react';

export function useDebounce(value, delay = 300) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(id); // cancel if value changes again
  }, [value, delay]);

  return debounced;
}

Use it as: const debouncedQuery = useDebounce(query); then fetch using debouncedQuery in your effect or query key.

Accessibility means people with different abilities can use your app: someone blind using a screen reader, someone who cannot use a mouse, someone with low vision or colour blindness, someone with a temporary injury. It also helps everyone, for example keyboard shortcuts and good contrast in bright sunlight. In some countries it is a legal requirement for certain services, and many employers test for it.

The good news: most of it comes from using HTML correctly.

// Bad: a div is not focusable and has no role, so keyboard and screen reader users cannot use it
<div className="btn" onClick={addToCart}>Add</div>

// Good: a button is focusable, works with Enter and Space and is announced as a button
<button type="button" onClick={addToCart}>
  Add Masala Chai to cart
</button>

// Icon-only button needs a name
<button type="button" onClick={closeDialog} aria-label="Close dialog">
  <span aria-hidden="true">x</span>
</button>

ARIA attributes (aria-label, aria-pressed, role) add information when no native element fits. The first rule of ARIA is to use a native HTML element if one exists.

// Tell screen readers when a status message appears
<p role="status">{message}</p>

// Errors that should interrupt
<p role="alert">{error}</p>

// Let keyboard users skip the navigation (first element in the body)
<a href="#main" className="skip-link">Skip to content</a>
<main id="main">...</main>

role="status" is polite and waits for the user to finish; role="alert" is assertive. Use alert sparingly.

Common questions: "How would you find why a React page is slow?" (answer: measure with the Profiler and Lighthouse first), "What is the difference between useMemo and useCallback?", "What does React.memo do and when is it useless?" (it does nothing if you pass a new object or function every time), "How do you split code?", "What are Core Web Vitals?", and "How do you make a custom dropdown accessible?" (start with native elements, then keyboard support, then ARIA).

You are an accessibility specialist who knows WCAG and React. Review this component for accessibility problems that affect keyboard users and screen reader users. For each problem, give the line, why it is a problem, and a corrected version. Prefer native HTML elements over ARIA.

```
[paste your component code]
```

What to expect: Check the advice yourself with the keyboard and a scan tool. AI review misses issues that need real testing, such as focus order and contrast.