“The API Is Fast but the UI Is Slow”: How to Solve It

This is the most common senior-level frontend scenario. It connects directly to the INP metric (Interaction to Next Paint: how long the page takes to react after a click or key press). See Browser Contract, Lesson 09.

Think of the main thread as a single cashier in a shop. If the cashier is busy with one huge order, every other customer waits, even if the warehouse (the server) already delivered the goods.

Confirm the diagnosis

1. Network tab: the request's Waiting (TTFB) is small (for example 80 ms). TTFB means "time to first byte", the time until the server starts answering. Content Download is reasonable too. So the server is not the problem.
2. Performance panel (with 4x CPU throttling, which makes your computer act slower, like a weaker phone): record the interaction. Look for:
   • Long tasks (more than 50 ms, marked in red in the Main thread track).
   • A large Scripting (yellow) block after the response arrives.
   • Recalculate Style / Layout (purple) and Paint / Commit (green) blocks.
3. Break the delay into parts. This is the INP model:
   • Input delay: the main thread was busy before your handler could start.
   • Processing time: your handlers and the work they cause.
   • Presentation delay: the render and paint after the handlers finish.

Now look at the usual causes. They are listed roughly from most common to least common.

Suspect 1: rendering far too many DOM nodes

JSON is a text format for data (for example {"name": "Ana"}). A 5 MB JSON file feeding a table of 20,000 rows can create hundreds of thousands of DOM nodes. The browser must create, style, lay out and paint all of them. This usually takes much more time than parsing the JSON.

How to see it: you get a huge Scripting + Layout + Paint cost after the response. The Elements panel shows a very large DOM. document.querySelectorAll("*").length is in the tens of thousands.

Fixes, from most to least effective:

• Don't send or render what the user cannot see. Use server-side pagination (send one page of results at a time) or cursor paging (the client asks for "the next items after this last one"). Apply filters on the server. See Practical Design Problems, Lesson 03.
• Virtualise long lists. Virtualisation (also called windowing) keeps only the rows visible on screen in the DOM and swaps them as the user scrolls. See Lesson 07.
• Use content-visibility: auto. This CSS property tells the browser to skip layout and painting for sections that are off-screen, until the user scrolls near them. Add contain-intrinsic-size (a guess of the section's size), or the scrollbar will jump.
• Make each row simpler: fewer wrapper elements and fewer nested components.

Suspect 2: parsing and processing a huge payload

Parsing means turning text into JavaScript objects. It is synchronous (it blocks everything else) and uses a lot of CPU. JSON.parse, the built-in function that does this for JSON, usually takes tens of milliseconds for 5 MB on a desktop (sometimes about 100 ms). On a mid-range phone it can be several times slower. The work after parsing (mapping, sorting and cleaning 50,000 objects) often costs more than the parse itself.

Fixes:

• Send less. Return only the fields the screen needs (select in your database query, sparse fieldsets in JSON:API, or the fields you ask for in a GraphQL query). Drop unused data. Compress with Brotli (a compression format that is usually smaller than gzip for text). Paginate.
• Do heavy changes to the data on the server, or in a separate endpoint that prepares the result in advance.
• Move heavy parsing and processing to a Web Worker. A Web Worker is a browser feature that runs a JavaScript file on a separate background thread, so it cannot block the main thread. It has no access to the DOM, and the two threads talk by sending messages. Send only the final result back to the main thread: the data you pass with a message is copied (structured clone), so copying a huge result back can cost almost as much as the work you moved.
• Stream NDJSON (newline-delimited JSON: one JSON object per line) and show the rows step by step. Do not wait for one giant blob.
• Avoid repeated deep copies of large state on every update. A deep copy makes a full new copy of an object and everything inside it. Examples are structuredClone and JSON.parse(JSON.stringify(x)).

// worker.ts — the work happens off the main threadself.onmessage = (e: MessageEvent<{ rows: Row[]; query: string }>) => {  const { rows, query } = e.data;  const result = rows.filter((r) => r.name.toLowerCase().includes(query.toLowerCase())).sort(byDateDesc);  (self as unknown as Worker).postMessage(result.slice(0, 200)); // send back only what will be shown};

Suspect 3: re-render storms

A "re-render storm" is when one state change makes a huge part of the component tree render again, and this happens again and again. For example, typing in a search box re-renders the whole dashboard on every keystroke. Or a context value changes and every component that reads it updates.

How to see it: the React Profiler shows many components rendering on each commit (a commit is one batch of updates that React applies). "Highlight updates when components render" flashes everywhere. The same interaction causes several commits.

The fixes are the topic of Lesson 03. In short:

• Colocate state: keep state in the component that uses it, not high up in the tree.
• Split big components into smaller ones.
• Memoise the expensive children. Memoizing means remembering the result of work so it is not repeated. memo is a React function that makes a component skip rendering when its props are the same as last time. Give the children stable props (props that are the same object in memory between renders).
• Split contexts, or use selectors. A context is React's way to share a value with many components without passing props. A selector is a small function that picks one piece of a store, so a component re-renders only when that piece changes.
• Virtualise long lists.

Suspect 4: expensive work during render

function Table({ rows, query, sortKey }: Props) {  // ❌ Runs on EVERY render, even if rows/query/sortKey did not change (e.g. a parent re-render)  const visible = rows.filter((r) => match(r, query)).sort(compare(sortKey));  return <>{visible.map((r) => <Row key={r.id} row={r} />)}</>;}

Fixes:

• Use useMemo for derived data (data worked out from other data). useMemo is a React hook that memoizes (remembers) a value: it keeps the result of a calculation and only calculates again when its inputs change. Use it only when the calculation is really expensive and its inputs are stable. Measure first.
• Move the work out of render. Calculate it once when the data arrives, or do it on the server.
• Use a better algorithm. For example, prepare a lowercase search field once. Do not lowercase every row on every keystroke. Use a Map for lookups instead of find inside loops (that mistake makes the code slow in a hidden way: for n rows it does about n × n steps, written O(n²)).
• Debounce (wait until the user pauses typing before you start the work) or defer the expensive part. See below.

Suspect 5: layout thrashing and forced reflows

"Layout" is the step where the browser works out the size and position of every element. If you read a layout value (offsetHeight, getBoundingClientRect()) right after changing a style, the browser must redo layout immediately. If this happens inside a loop or an effect, it repeats many times. This is called a forced reflow. See Browser Contract, Lesson 08.

In the Performance panel you see repeated Layout blocks with a "Forced reflow" warning.

Fix: do all the reads first, then all the writes. Measure once. Use ResizeObserver or IntersectionObserver. These are browser APIs that call your function when an element's size changes, or when it enters or leaves the screen, so you do not have to measure it yourself. Do not measure every row.

Suspect 6: hydration cost

Hydration is the step where React, in the browser, takes the HTML that the server already sent and makes it interactive. It runs your components again on the client and attaches the event handlers.

On a Next.js page, the HTML arrives fast and looks ready. But the buttons do nothing for a second or two, because React is still hydrating. The cost grows with the amount of client-side JavaScript and the size of the component tree.

How to see it: a long task right after the JS bundle loads. You may see "Hydrate" or large commitRoot work. Users who click early get no response (bad INP and "rage clicks", where people click again and again).

Fixes:

• Send less client JavaScript. Make components Server Components by default. A Server Component is a React component that runs only on the server and sends no JavaScript for itself to the browser. Mark only the interactive leaves with "use client", a line at the top of a file that makes its components run in the browser. See Frontend Depth, Lesson 02.
• Code-split heavy widgets that are not critical. Code splitting means cutting your JavaScript into several files that load separately. Use a dynamic import (import(), which loads a file on demand), and load them after an interaction or when they become visible.
• Use selective hydration with <Suspense> boundaries. <Suspense> is a React component that shows a fallback (such as a spinner) while part of the page is not ready. Parts of the page then hydrate separately, and React hydrates first the part the user clicked on.
• Do not render huge lists on the client during hydration.

Suspect 7: client-side waterfalls

A waterfall is a chain of requests where each one waits for the one before. The API is fast, but the page makes sequential calls. It renders, then fetches the user, then renders, then fetches their projects, then renders, then fetches project details. Each step waits for the last render. Ten calls of 80 ms become about a second of waiting, plus extra renders.

Fixes:

• Fetch in parallel with Promise.all (a JavaScript function that starts several async calls together and waits for all of them) when the requests do not depend on each other.
• Move the fetching up to the route or the server (Server Components, loaders). The data is then requested before the component tree renders.
• Prefetch requests that will probably come next (on link hover, or route prefetch). Prefetching means loading something before the user asks for it.
• Combine "chatty" endpoints. Make one endpoint for the page, or use a GraphQL query that returns the related data in one call. See Backend, Lesson 09.

Suspect 8: third-party scripts and other main-thread hogs

Third-party scripts are scripts from other companies that you add to your page. Analytics, tag managers, chat widgets, A/B testing and ad scripts all run on the same main thread. How to see it: long tasks that belong to a third-party domain. In the Performance panel, open the Bottom-Up tab and group by Domain, so the cost of each third-party domain is added up.

Fixes:

• Load scripts with async or defer (two attributes that let the browser download a script without stopping the HTML parser; the script still runs on the main thread when it executes), or use the Next.js next/script strategies (afterInteractive, lazyOnload). The experimental worker strategy is not stable and does not yet work with the App Router.
• Remove the scripts you do not need.
• Measure how much INP each tag costs.
• Also check image decoding (very large images), heavy CSS selectors, and animations that cause layout.

startTransition and useDeferredValue

startTransition is a React function that marks a state update as non-urgent. useDeferredValue is a React hook that gives you a copy of a value that is allowed to update a little later. These two React APIs do not make the work cheaper. They make it interruptible and lower priority, so typing and clicking stay responsive.

Everyday comparison: you are cooking, and the doorbell rings. Answering the door is urgent. Stirring the soup can wait a moment. React does the same thing with updates.

function Search({ rows }: { rows: Row[] }) {  const [query, setQuery] = useState("");  const deferredQuery = useDeferredValue(query);          // lags behind during heavy renders  return (    <>      <input value={query} onChange={(e) => setQuery(e.target.value)} />  {/* urgent: updates immediately */}      <ResultList rows={rows} query={deferredQuery} />                    {/* non-urgent: re-renders when React has time */}    </>  );}const ResultList = memo(function ResultList({ rows, query }: { rows: Row[]; query: string }) {  const visible = useMemo(() => rows.filter((r) => r.searchText.includes(query)), [rows, query]);  return <ul>{visible.slice(0, 200).map((r) => <li key={r.id}>{r.name}</li>)}</ul>;});

• useDeferredValue(value) gives you a copy of the value that "catches up" a little later. While the heavy ResultList renders with the old value, the input stays fast. If the user types again, React can interrupt the deferred render.
• startTransition(() => setState(...)) marks a state update as non-urgent. React can render it in the background without blocking urgent updates such as typing or clicking.
• Requirement: wrap the slow child in memo, so it does not re-render for the urgent update. Its render must also be interruptible. These tools do not help in two cases. The first is when the cost is one huge synchronous calculation outside React rendering. The second is when the DOM work in the commit phase is the problem, because the commit cannot be interrupted.
• They improve INP because input is blocked less. But the total CPU work stays the same. Combine them with virtualisation and memoisation to reduce the work itself.

Scenario: a 5 MB JSON feeds a table. Where is the time going?

Here is a ranked analysis that you can say out loud:

The plan:

1. Send less. Paginate or filter on the server, and trim fields.
2. Virtualise the list.
3. Memoise rows. Move heavy sorting and filtering off the main thread, or to the server.
4. Use useDeferredValue so typing stays responsive.
5. After each step, make a new recording and compare INP and total blocking time (TBT, a lab metric: for every long task during page load, the time beyond 50 ms is counted, and the results are added up).

A checklist you can recite

1. Confirm in the Network tab that TTFB is small. Record the Performance panel under CPU throttling.
2. Find the biggest block: Scripting, Layout/Style, Paint, or long tasks.
3. Count the DOM nodes and rendered rows. Reduce them with pagination or virtualisation.
4. Check the payload size and what is parsed. Trim it, compress it, or move it to a worker.
5. Open the React Profiler. What re-renders, why, and how often?
6. Look for work inside render (filter/sort/map) and for forced reflows.
7. Check hydration and client JS size. Move to Server Components and split code.
8. Look for sequential client fetches and third-party scripts.
9. Use transitions or deferred values for non-urgent updates.
10. Measure again. Add a budget (a limit, such as a maximum bundle size) or a RUM alert (an alert based on real-user data).

Common mistakes

1. Blaming the API because the page feels slow, without reading the Timing breakdown.
2. Fixing JSON parsing when the real cost is rendering the rows.
3. Wrapping everything in useMemo/memo without profiling.
4. Expecting startTransition to reduce work. It only changes when the work runs.
5. Profiling on a fast laptop with no CPU throttling.
6. Fetch waterfalls inside nested components.
7. Ignoring hydration cost on server-rendered pages.

Interview questions

Key takeaways

• API fast, UI slow means main-thread work. Find it in the Performance panel and React Profiler under CPU throttling.
• The biggest causes are: too many DOM nodes, re-render storms, expensive work in render, big payload processing, hydration, waterfalls, and third-party scripts.
• First reduce the work: send less, render less, virtualise, memoise with stable props. Then change when the work runs: transitions, deferred values, workers.
• Check the result with INP and total blocking time, and keep a budget.

What's next

Lesson 02: "The UI Is Fast but the API Takes Too Long". This is the opposite case. The browser is idle and the server is slow. We follow a request through every backend layer.