React

Three Kinds of Slow, and the Measurement That Separates Them

Complaints that an interface is slow almost always resolve into one of three unrelated problems, and each has its own measurement. Bundle-bound is the time before anything appears at all: the browser has to download, parse, and execute the JavaScript before the first render happens, so the number that matters is the size of the entry chunk in the production build output. Render-bound is lag during interaction on a page that has already loaded: the React DevTools Profiler records each commit, attributes time to individual components, and reports why each one rendered. Data-bound is a shell that paints immediately and then sits empty: the browser network panel shows whether the requests started together or one after another.

The distinction matters because the fixes do not transfer between categories. Memoization does nothing for a large bundle. Code splitting does nothing for a chain of dependent requests. Caching on the API does nothing for a component that re-renders a thousand rows on every keystroke. Time spent optimizing the wrong category is not just wasted, it usually adds indirection that makes the real problem harder to see.

Measure a production build. Development React runs extra checks, keeps additional bookkeeping for the Profiler, and under Strict Mode deliberately renders components twice and mounts, unmounts, and remounts them so that unsafe effects show themselves. That behavior is useful during development and it makes development timings both slower and different in shape from what users get.

• A context provider whose value is a fresh object on every render re-renders every consumer beneath it, however unrelated that consumer is to what changed.
• An array index used as a key makes React reuse the wrong DOM node when a list reorders, which usually surfaces as state stuck on the wrong row rather than as slowness.
• An effect that fetches, inside a component that renders a child which also fetches, serializes two round trips that could have run as one.
• A date, icon, or charting library imported as a whole module can outweigh the application code itself, and the build's bundle report will say so in a line or two.

What the Browser Stops Doing Once Routing Moves to the Client

A client-side router replaces navigation with a history API call and a re-render. The address bar changes, but no document load happens, and a set of behaviors that came free with real navigation quietly stop. None of them are hard to restore. They are simply invisible until someone reports them, and the report almost never mentions routing.

Scroll is the first. Browsers restore scroll position on back and forward for real navigations, and with a client-side router that restoration fires against the old document before the new view has rendered, which drops the user in the wrong place or at the top. The usual answer is to set history.scrollRestoration to manual and record position per history entry yourself.

Error reporting is the second. Error boundaries catch errors thrown while rendering the subtree below them; they do not catch errors in event handlers, in async callbacks, during server rendering, or thrown by the boundary itself. Without global window error and unhandledrejection listeners reporting to the same place, a whole class of failures never reaches the dashboard and the only symptom is a button that stopped responding.

Forms are the third. Submitting through a real form element with a submit button gives keyboard submission, browser validation messaging, and correct behavior from password managers and autofill; a div with a click handler gives none of it, and calling preventDefault on the submit event keeps the semantics while stopping the navigation. What has to be rebuilt by hand beyond that is a short list, and an easy one to forget:

• Focus moved into the new view on navigation, because the browser no longer moves it and a keyboard user is left where they were.
• The document title, which changed on every real navigation and now changes only if the router updates it.
• An announcement that the view changed, usually a live region naming the new page, since assistive technology has no load event to react to.
• A genuine not-found response, because the server answered 200 for the shell long before the router decided the route matches nothing.

Version Boundaries That Decide What You Can Use

The React major a project is pinned to decides more than syntax. React 19 removed APIs that had carried deprecation warnings for years, so a codebase that ignored those warnings meets all of them at once during the upgrade rather than gradually before it. In application code the removals are mechanical to fix. The difficulty is that a dependency you do not control may still call them, and in JavaScript that surfaces at runtime, in one component, rather than at build time.

React Native sits on its own version line. Each React Native release pairs with a specific React version, so the two upgrades are not independent, and the New Architecture changes how native modules communicate with JavaScript. The binding constraint there is rarely the React code. It is the native dependency set, where a single unmaintained module can hold an entire app on an old release.

Installs make version conflicts visible in a way that is also easy to silence. npm 7 and later install peer dependencies automatically and stop with ERESOLVE when the graph cannot be satisfied; passing --legacy-peer-deps or adding an overrides block makes the install succeed without making the conflict untrue, and the mismatch returns later as a runtime error. TypeScript types ship as separate packages on their own release line, so the types can be a major apart from the React actually installed and the editor will report errors about code that runs correctly. Build tooling has its own floor as well, declared as an engines range. An upgrade inventory therefore covers:

• Which React major each third-party component library declares as a peer dependency, and whether an override is a real answer or a deferral.
• Which versions of @types/react and @types/react-dom match the React that is actually installed.
• Which removed APIs the code still calls, with ReactDOM.render, findDOMNode, string refs, and defaultProps on function components the usual ones.
• Which native dependencies a React Native app carries, and the New Architecture status of each.
• Which Node version the build tooling now requires, which tends to break in CI before anyone notices it locally.

Where the Front End Meets Auth and the API

Most of the integration effort in a React project lands on this boundary, and the first decision is where the session credential lives. Anything in localStorage or sessionStorage is readable by any script running on the origin, which turns a single cross-site scripting bug into token theft, and it persists until something explicitly clears it. A cookie marked httpOnly cannot be read from JavaScript at all, which removes that class of theft, but it puts the cookie's own rules into the path of every request the app makes.

Those rules are worth reading before the architecture is settled. SameSite=Lax means the cookie is not sent on cross-site fetch or XHR calls, only on top-level navigations, so a front end on one domain calling an API on another will not carry it. SameSite=None restores that, but browsers require the Secure attribute alongside it, which makes it HTTPS only. Credentialed cross-origin calls also require the API to answer preflight requests and to name the exact origin in Access-Control-Allow-Origin, because a wildcard is rejected once Access-Control-Allow-Credentials is true. Serving the front end and the API from the same site sidesteps all of it.

Token refresh is the part that usually gets built twice. When an access token expires, several in-flight requests fail at once, and a naive interceptor fires one refresh per failed request; the second refresh presents a token the first one already rotated, and the user is signed out at random intervals that nobody can reproduce. One refresh in flight at a time, with the other requests queued behind it and replayed afterward, is the whole fix, and it is far easier to write before there are twenty call sites.

One more agreement belongs to the same boundary, between the built files and whatever serves them. A client-side router owns paths the server has never heard of, so the host has to rewrite unknown paths to index.html, with an exception for the asset directory. Without that exception a request for a missing or renamed script returns the HTML shell with a 200 status and a text/html content type, and the browser reports a syntax error on an unexpected < character, which sends people hunting for a bug in JavaScript that is not there.