INP in frameworks

Why do Asha's letters come late?

Ravi has rebuilt the shop's search page in React. A framework like React keeps the page in step with your data. You change the data, and React changes the page to match. The new page starts empty, with a search box and the words "Type to search 3,000 teas."

Asha wants to see the house blends. She types blend, a key every 120 ms, as she did in lesson 28.1. For almost half a second, her screen doesn't change. Then "ble" appears in the box, with a long list under it. Why does she have to wait? React has tools for this, called transitions. Do they help?

Here is what Asha saw. These are real frames Chrome captured. A frame is one picture the browser draws on the screen. The top row is Ravi's first page. The bottom row is the same page with one change, which this lesson explains.

Here are the same moments as code:

1// Asha types "blend", a key every 120 ms. Times are in ms after her first key.2const plain = { firstFrame: 467.4, showed: "ble" };3const deferred = { firstFrame: 21.5, showed: "b" };4 5console.log(`Plain update: the first new frame came at ${plain.firstFrame.toFixed(1)} ms and showed "${plain.showed}"`);6console.log(`useDeferredValue: the first new frame came at ${deferred.firstFrame.toFixed(1)} ms and showed "${deferred.showed}"`);

• Line 1 is a comment. Times are in milliseconds (ms) after Asha's first key. A millisecond is a thousandth of a second.
• Lines 2 and 3 hold the two pages. firstFrame is the first frame that showed anything new. showed is what the box said in it.
• Line 5 prints Plain update: the first new frame came at 467.4 ms and showed "ble".
• Line 6 prints useDeferredValue: the first new frame came at 21.5 ms and showed "b".

On the first page, Asha had pressed four keys before anything new showed. On the second, her first letter showed after 21.5 ms. Why it matters: where React does its work decides when Asha sees her letters.

How the course recorded it

• Seven pages: three search pages and four "All teas" pages. Each is the Leaf and Kettle shop from lesson 26.1, with the 3,000 teas of lesson 28.2. They use React 19.3.1, Preact 11.2.0 with @preact/signals 2.11.4, and TanStack Virtual 3.14.26, built for production.
• Asha's phone: this computer in Chrome 157, with its processor, the CPU, slowed 4 times, as in lessons 28.1 and 28.2. Her window was 412 by 480 pixels.
• Real keys and clicks: they went through Chrome's DevTools protocol, the way programs drive Chrome. Each key went down, then up 60 ms later. Chrome passes key presses and mouse clicks straight to the page.
• Three visits each: every page was loaded three times, taking turns. The lesson quotes the middle visit.
• Two clocks: Event Timing gives how long each key or click took. Chrome's screenshots show what was on screen, a moment after each frame.

Every key renders the whole list

Here is Ravi's search on the first page. It has two parts: the box, and the list of teas that match.

1function Search() {2  const [query, setQuery] = useState("");3  return (4    <>5      <SearchBox value={query} onChange={setQuery} />6      <Results query={query} />7    </>8  );9}

• Line 1 makes a component: a function that returns what part of the page should look like.
• Line 2 makes a piece of state, query. It holds the box's text. setQuery changes it.
• Line 5 draws the box. Each key calls setQuery with the box's new text.
• Line 6 draws the list, and gives it the same text.

When state changes, React calls the component again. This is called a render. React then changes the page to match the result. That second step is the commit. React's docs, in Render and Commit, add that rendering goes down the tree: if a component returns other components, React renders those next.

Here is the list. It's the slow part:

1export const Results = memo(function Results({ query }) {2  const words = query.toLowerCase();3  const found = query ? TEAS.filter((tea) => tea.name.toLowerCase().includes(words)) : [];4  return (5    <>6      <p id="about">{query ? `${found.length} teas match "${query}"` : "Type to search 3,000 teas."}</p>7      <ul id="teas" className="tea-list">8        {found.map((tea) => (9          <TeaRow key={tea.tea} tea={tea} />10        ))}11      </ul>12    </>13  );14});

• Line 1 wraps the list in memo. The next section explains why.
• Line 3 finds the teas whose names include the box's text. With an empty box, it finds none.
• Line 6 says how many teas match.
• Lines 8 to 10 draw one TeaRow for each tea. A row has the tea's name, its price and an Add button, as in lesson 28.2.

Asha's b matched 2,993 teas: Rooibos and the 2,992 house blends. So React ran TeaRow 2,993 times, built the rows, and put them in the page. All of that ran inside the key press. Here is what the main thread did for the b. The main thread is the one thread that runs the page's JavaScript and draws its frames.

1// The main thread's work for the b, on the plain page (ms).2const work = { react: 141.7, style: 33.0, layout: 138.3 };3 4console.log(`React built and placed 2993 rows: ${work.react.toFixed(1)} ms`);5console.log(`The browser worked out their styles: ${work.style.toFixed(1)} ms`);6console.log(`The browser laid them out: ${work.layout.toFixed(1)} ms`);7console.log(`Together: ${(work.react + work.style + work.layout).toFixed(1)} ms`);

• Line 2 holds three times from Chrome's trace, a detailed record of everything Chrome did. react is React's render and commit. style and layout are the browser's work on the new rows.
• Lines 4 and 5 print React built and placed 2993 rows: 141.7 ms and The browser worked out their styles: 33.0 ms.
• Lines 6 and 7 print The browser laid them out: 138.3 ms and Together: 313.0 ms.

Lesson 28.2 met these two steps. Style works out which CSS rules apply to each element. Layout works out each element's size and place. Both ran before the next frame. Why it matters: React's work was only part of the cost. The browser's work on the new rows was bigger.

Meanwhile, Asha kept typing. Here is every key press:

1// Each key press on the plain page, in ms.2const keys = [3  { letter: "b", pressed: 0.0, waited: 0.3, took: 465.6 },4  { letter: "l", pressed: 120.5, waited: 197.7, took: 345.1 },5  { letter: "e", pressed: 240.3, waited: 146.0, took: 225.3 },6  { letter: "n", pressed: 361.9, waited: 96.9, took: 168.6 },7  { letter: "d", pressed: 480.5, waited: 11.5, took: 50.0 },8];9 10for (const key of keys) console.log(`${key.letter}: waited ${key.waited.toFixed(1)} ms, took ${key.took.toFixed(1)} ms`);

• Lines 3 to 7 hold her five key presses. pressed is when the key went down. waited is how long it waited before its handlers could start. That wait is its input delay. took is the key press's time as INP counts it: from the key going down to the next frame.
• Line 10 prints b: waited 0.3 ms, took 465.6 ms, then l: waited 197.7 ms, took 345.1 ms, and so on down to the d.

INP, Interaction to Next Paint, is roughly a visit's slowest click, tap or key press, as lesson 26.1 showed. A good INP is 200 ms or less. This visit's INP was 465.6 ms, the b. The l and the e waited behind the b's work. Why it matters: a key that renders a big list holds back every key after it.

React treats a key press as urgent. It renders the update at once, from start to finish, without stopping. The React lesson Transitions calls this an urgent update. The next two sections let the list wait.

Let the list wait with useDeferredValue

The box must show each letter at once. The list can wait a moment. React has a hook for that: a function, starting with use, that a component calls to get something from React. This one is useDeferredValue. The React lesson Deferred values teaches it. Here it is on the second page:

1function Search() {2  const [query, setQuery] = useState("");3  const deferredQuery = useDeferredValue(query);4  return (5    <>6      <SearchBox value={query} onChange={setQuery} />7      <Results query={deferredQuery} />8    </>9  );10}

• Line 3 asks React for a deferred copy of query: a copy that is allowed to lag behind.
• Line 6 still gives the box the real query, so the box shows each key at once.
• Line 7 gives the list the deferred copy.

React's docs say what happens on each key. First, React renders with the old value. Then it tries another render "in the background with the new value". The first render is quick, because the list is wrapped in memo. memo tells React to skip a component when its props haven't changed. The list's copy hasn't changed yet, so React skips the whole list.

Small pieces of 5 ms

How does React render in the background? In small pieces. Before each step, it asks its scheduler, the part of React that decides when work runs, whether to stop. The scheduler says stop after 5 ms: frameYieldMs in React's source. React then hands the main thread back. The browser can draw a frame or handle a key. Then React picks up where it stopped.

The trace shows it. For the b's list, React worked in 13 pieces, each 5.0 to 5.7 ms long, and then one last piece. The b itself showed at 21.5 ms. Why it matters: React's own work no longer held the box back.

And React did less work in all. Here are the lists it started on each page:

1// The lists React started while Asha typed "blend", on each page.2const plain = ["b", "bl", "ble", "blen", "blend"];3const deferred = ["b", "blen", "blend"];4 5console.log(`Plain update: ${plain.length} lists: ${plain.join(", ")}`);6console.log(`useDeferredValue: ${deferred.length} lists: ${deferred.join(", ")}`);

• Lines 2 and 3 hold the lists React started on each page, in order.
• Lines 5 and 6 print Plain update: 5 lists: b, bl, ble, blen, blend and useDeferredValue: 3 lists: b, blen, blend.

With useDeferredValue, React never started the lists for bl and ble. By the time it came back to the list, the box already said blen. React's docs say it "will always use the latest provided value". Why it matters: lists nobody would see cost nothing.

Why the l still waited

Here are the key presses on this page:

1// Each key press on the useDeferredValue page, in ms.2const keys = [3  { letter: "b", pressed: 0.0, waited: 0.7, took: 19.4 },4  { letter: "l", pressed: 120.2, waited: 235.8, took: 290.4 },5  { letter: "e", pressed: 239.9, waited: 122.7, took: 170.7 },6  { letter: "n", pressed: 358.7, waited: 45.8, took: 60.0 },7  { letter: "d", pressed: 479.7, waited: 12.7, took: 44.1 },8];9 10for (const key of keys) console.log(`${key.letter}: waited ${key.waited.toFixed(1)} ms, took ${key.took.toFixed(1)} ms`);

• Lines 3 to 7 hold the five key presses, as before.
• Line 10 prints b: waited 0.7 ms, took 19.4 ms. Then it prints l: waited 235.8 ms, took 290.4 ms.

The b was quick. But the l waited 235.8 ms, longer than on the plain page. What was the main thread doing? Here is the start of both visits, to scale:

1// What the l waited for on the useDeferredValue page (ms).2const waited = { lastPiece: 60.8, style: 33.2, layout: 141.0 };3 4console.log(`The rest of React's last piece: ${waited.lastPiece.toFixed(1)} ms`);5console.log(`The browser's style and layout: ${(waited.style + waited.layout).toFixed(1)} ms`);6console.log(`The l waited 235.8 ms in all.`);

• Line 2 holds three times from the trace.
• Lines 4 to 6 print The rest of React's last piece: 60.8 ms, The browser's style and layout: 174.2 ms and The l waited 235.8 ms in all.

React's last piece for the b took 90.2 ms, not 5. In it, React finished the list and put all 2,993 rows in the page. React can pause while it works out a list. It doesn't pause while it changes the page. React's post on React 18 says it "waits to perform DOM mutations until the end, once the entire tree has been evaluated".

The l arrived in the middle of that piece. Then the browser styled and laid out the 2,993 new rows, in one task. The l waited for both. Why it matters: a deferred value moves React's work out of the way. It doesn't make the page smaller. The last section of this lesson does that.

Pick a page to see each of Asha's key presses. The third page is the next section's.

startTransition does the same from the handler

The third page uses a transition. A transition is a state update you mark as not urgent. The React lesson Transitions teaches useTransition, the hook that starts one and tells you it's pending. This page uses startTransition, the same function without the hook.

1function Search() {2  const [text, setText] = useState("");3  const [query, setQuery] = useState("");4  function search(value) {5    setText(value);6    startTransition(() => setQuery(value));7  }8  return (9    <>10      <SearchBox value={text} onChange={search} />11      <Results query={query} />12    </>13  );14}

• Lines 2 and 3 keep two pieces of state: text for the box, and query for the list.
• Line 5 sets text at once. That's an urgent update, so the box shows the key.
• Line 6 sets query inside startTransition. React marks that update as a transition.
• Lines 10 and 11 give the box text, and the list query.

Why two pieces of state? React's docs say "Transition updates can't be used to control text inputs." The box needs its own urgent state. Here is the slowest key on each page:

1// The slowest key press on each page: what INP reports for the visit (ms).2const pages = [3  { name: "Plain update", inp: 465.6, key: "b" },4  { name: "useDeferredValue", inp: 290.4, key: "l" },5  { name: "startTransition", inp: 290.5, key: "l" },6];7 8for (const page of pages) console.log(`${page.name}: ${page.inp.toFixed(1)} ms, on the ${page.key}`);

• Lines 3 to 5 hold each page's slowest key press: the visit's INP.
• Line 8 prints Plain update: 465.6 ms, on the b, useDeferredValue: 290.4 ms, on the l and startTransition: 290.5 ms, on the l.

The two React tools gave almost the same result. Both cut INP by more than a third. Both left it over 200 ms, for the reason in the last section. Why it matters: they work the same way, so pick by where your code is.

useDeferredValue or startTransition?

React's docs give the rule. startTransition needs the set function of the state. If you only get the value, from a prop or another hook, use useDeferredValue. Either way, the slow part waits, and React can drop work that is out of date.

Waiting is not debouncing

Lesson 28.1 debounced a search: it waited 250 ms after the last key. React's docs say a deferred value "doesn't require choosing any fixed delay". On a fast phone, the list comes almost at once. On a slow one, it lags further behind. Debouncing still helps work that isn't rendering, like a request to the server.

Now try it in your own browser. This playground runs the same kind of search with the React on this page:

1// Plain update: the list gets the box's text at once.2<Results query={text} />3 4// useDeferredValue: the list gets a copy that can lag behind.5const deferredText = useDeferredValue(text);6<Results query={deferredText} />7 8// startTransition: the list's query is set in a transition.9startTransition(() => setQuery(text));10<Results query={query} />

With Plain update, type blend quickly. Watch the first key's time, and whether the keys after it wait. Then pick useDeferredValue or startTransition and type it again. React may put fewer lists on the page than you pressed keys: it skips lists that are out of date.

Run only what changed: memo and signals

Now Asha is on the All teas page, with all 3,000 rows. She clicks Add on Mint tea. Two things change on her screen: the cart says 1, and the button says Added. Here is the React page's list:

1export function ListApp({ Row }) {2  const [cart, setCart] = useState([]);3  const [byPrice, setByPrice] = useState(false);4  const add = useCallback((name) => setCart((names) => [...names, name]), []);5  const teas = byPrice ? BY_PRICE : TEAS;6  return (7    <Shop cart={cart.length} onSort={() => setByPrice(true)}>8      <ul id="teas" className="tea-list">9        {teas.map((tea) => (10          <Row key={tea.tea} tea={tea} added={cart.includes(tea.tea)} onAdd={add} />11        ))}12      </ul>13    </Shop>14  );15}

• Line 2 keeps the cart: the teas Asha has added. Line 3 keeps whether the list is sorted by price.
• Line 4 makes add, which puts a tea in the cart. useCallback keeps the same function from render to render.
• Line 7 passes the cart's size to the header.
• Lines 9 to 11 draw a Row for each tea. added says whether that tea is in the cart.

On the first page, Row is TeaRow. The click changes cart, so React renders ListApp again, and then every row inside it. Here is the same click on three pages:

1// Asha clicks Add on Mint tea. Rows that ran again, the click's own work, the whole click (ms).2const pages = [3  { name: "React", rows: 3000, work: 43.5, click: 77.4 },4  { name: "React with memo", rows: 1, work: 14.7, click: 48.3 },5  { name: "Preact with signals", rows: 0, work: 2.5, click: 69.6 },6];7 8for (const page of pages) console.log(`${page.name}: ${page.rows} of 3000 rows ran, work ${page.work.toFixed(1)} ms, click ${page.click.toFixed(1)} ms`);

• Lines 3 to 5 hold the three pages. rows is how many TeaRows ran. work is the click's processing: its handlers, with the framework's work. click is the whole click, as INP counts it.
• Line 8 prints one line per page. First, React: 3000 of 3000 rows ran, work 43.5 ms, click 77.4 ms.
• Then React with memo: 1 of 3000 rows ran, work 14.7 ms, click 48.3 ms.
• Last, Preact with signals: 0 of 3000 rows ran, work 2.5 ms, click 69.6 ms.

memo: skip the rows that didn't change

The second page changes one line: const MemoRow = memo(TeaRow);, and passes MemoRow as the row. React then compares each row's props with the last ones. Only Mint tea's added changed, so only Mint tea's row ran. The click's work fell from 43.5 ms to 14.7 ms.

That's also why add uses useCallback: a new function on every render would be a changed prop. The React lesson memo, useMemo and useCallback explains this. React's docs add that the React Compiler applies the same skipping to every component for you.

Signals: tell only the code that read the value

The third page uses Preact, a small library much like React, with signals. A signal is a box for a value that remembers who read it. When the value changes, only the code that read it runs again. This is called fine-grained updating. SolidJS's docs put it plainly: Solid updates the one attribute that changed, while React "would re-execute an entire component".

Here is a signal made small, so you can see how it remembers its readers:

1let running = null;2function signal(value) {3  const readers = new Set();4  return {5    get value() { if (running) readers.add(running); return value; },6    set value(next) { value = next; for (const reader of readers) reader(); },7  };8}9function effect(fn) { running = fn; fn(); running = null; }10 11let runs = 0;12const teas = ["Mint tea", "Green tea", "Earl Grey"].map((name) => ({ name, added: signal(false) }));13for (const tea of teas) effect(() => { runs += 1; tea.label = tea.added.value ? "Added" : "Add"; });14 15runs = 0;16teas[0].added.value = true;17console.log(`${teas[0].name}: ${teas[0].label}. Functions that ran: ${runs}`);

• Lines 2 to 8 make a signal. Line 5 is its getter: whoever reads value while running is added to readers. Line 6 is its setter: it changes the value, then runs each reader.
• Line 9 runs a function once, marked as running, so the signals it reads remember it.
• Lines 12 and 13 make three teas, each with an added signal, and one function per tea that sets its label.
• Line 16 adds Mint tea. Line 17 prints Mint tea: Added. Functions that ran: 1.

This is a model written for the lesson, much smaller than a real library. Press Edit & run and add a fourth tea to line 12. One function still runs.

Here is the real page's state, with Preact's signals:

1const cart = signal(0);2const rows = TEAS.map((tea) => {3  const added = signal(false);4  return { ...tea, added, label: computed(() => (added.value ? "Added" : "Add")) };5});6 7function add(row) {8  batch(() => {9    row.added.value = true;10    cart.value += 1;11  });12}

• Line 1 is the cart count.
• Lines 2 to 5 give each tea its own added signal, and a label worked out from it with computed.
• Lines 7 to 12 are add. batch makes both changes count as one update.

Each row's button shows {row.label}, and the header shows {cart}. Both pass the signal itself, not its value. Preact's docs say that lets Preact "skip all of the expensive rendering work". So no component ran. Preact changed two pieces of text, the same two React changed. Why it matters: the click's work fell from 43.5 ms to 2.5 ms.

Signals may one day be part of JavaScript itself. TC39, the group that designs the language, has a proposal for them at Stage 1, an early step. Its README says frameworks would still handle "scheduling rendering to DOM".

Why the signals click wasn't the quickest

Look at the whole clicks again. Signals did 2.5 ms of work, but the click took 69.6 ms. The memo click took 48.3 ms. Where did the time go? Into the next frame. The page still had 12,022 elements, so the browser's layout took 19.8 ms. And for 32.7 ms, the trace shows no work at all on the main thread.

Lesson 28.2 met a wait like that after its clicks. Here it came after the signals click in all three visits, and after none of the React clicks. Why it matters: signals made the code's share almost nothing. What's left is the browser's work on a big page.

Clicks before the page is ready

So far, every page was drawn in the browser. Lesson 23.3 drew the tea list on the server, then hydrated it: React ran the components again in the browser and attached their click handlers. It's lesson 23.3's shop that opens before the staff arrive. A click in that time goes one of two ways:

• Before React has the button, a click does nothing. Asha's first tap in lesson 23.3 was lost. Event Timing still timed it: 0 ms. To INP, a tap that does nothing is a perfect tap.
• While React is hydrating, a click waits for it. Her second tap took 152 ms: 5.8 ms of input delay, 51.3 ms of processing and 94.9 ms of presentation delay. React hydrated the page inside the tap, then ran her click. On the page drawn in the browser, the same tap took 120 ms.

React 18 added selective hydration. With Suspense boundaries, React hydrates the part you clicked first. The React 18 Working Group's notes say React will "synchronously hydrate" that part "during the capture phase of the click event". The rest waits. In lesson 23.3, the tap on that page took 144 ms. That lesson also showed islands and resumability, which hydrate less, or not at all. Why it matters: a page that looks ready can still lose clicks, or make them wait.

Keep only the rows on screen in the page

Back on the All teas page, Asha clicks Sort by price. On the React page, every row runs again. Here is that click, against a virtual list:

1// Asha clicks Sort by price. Elements in the page, rows that ran, the whole click (ms).2const pages = [3  { name: "Every row in the page", elements: 12022, rows: 3000, click: 84.7 },4  { name: "Virtual list", elements: 50, rows: 7, click: 17.0 },5];6 7for (const page of pages) console.log(`${page.name}: ${page.elements} elements, ${page.rows} rows ran, click ${page.click.toFixed(1)} ms`);

• Lines 3 and 4 hold both pages: the elements in the page, the rows that ran, and the whole click.
• Line 7 prints Every row in the page: 12022 elements, 3000 rows ran, click 84.7 ms and Virtual list: 50 elements, 7 rows ran, click 17.0 ms.

On the first page, React ran 3,000 rows, but it moved only 6 of them in the page. React's docs say a commit applies "the minimal necessary operations". That's lesson 28.2's "move only the rows that change", done for Ravi. Still, the click's processing was 45.6 ms: running 3,000 rows to find the 6.

The second page uses TanStack Virtual, a library for virtual lists. A virtual list keeps only the rows near the screen in the page, like lesson 28.2's windowed list. web.dev calls it "the concept of only rendering what is visible to the user". Here are the two parts that matter:

1const virtualizer = useWindowVirtualizer({2  count: teas.length,3  estimateSize: () => ROW_HEIGHT,4  scrollMargin: top,5  getItemKey: keyOf,6});7 8{virtualizer.getVirtualItems().map((item) => {9  const tea = teas[item.index];10  const style = { transform: `translateY(${item.start - top}px)` };11  return <TeaRow key={item.key} tea={tea} added={cart.includes(tea.tea)} onAdd={add} style={style} />;12})}

• Lines 1 to 6 make the virtualizer. count is how many teas there are. estimateSize gives each row's height: 52.4 px, a row and the gap under it. getItemKey gives each row its tea's own id as its key.
• Line 8 asks for the virtual items: the rows on the screen, and one more below them.
• Lines 9 to 11 draw each one, moved down to its place in the full list.

Sort by price changed the data. Then the virtualizer drew the rows near the screen again: 7 rows. The page had 50 elements in all, and the click took 17.0 ms. Why it matters: with few rows in the page, React and the browser both have little to redo.

What a virtual list costs

• Rows that aren't in the page aren't anywhere for the browser. Lesson 28.2 found that find-in-page can't find them, and the keyboard can't reach them.
• Fast scrolling can show blank space. web.dev warns that "blank space can briefly flash" before new rows are drawn. Extra rows above and below help. Too many slow the list down again.
• The library needs sizes. TanStack's docs say estimateSize should give each row's real size, or an estimate if the rows are measured as they're drawn.

Chrome's guide to DOM size points React apps to windowing libraries like react-window, and to memo. On the search page, a virtual list would give the browser a handful of rows to style and lay out, not 2,993.

Compare all five clicks the course recorded:

Which fix for which slow interaction?

Read this table across. Each row is one fix: what it changes, and what the recording showed.

Now sort these changes. Does each one make the framework's work wait, run less code, or put fewer rows in the page?

Common mix-ups

• "useDeferredValue makes the slow list render faster." No. React's docs say it "does not make re-rendering" faster. It lets the list wait, so the box can show each key.
• "With a transition, no key press can wait." No. React can't pause while it changes the page, and the browser's layout runs in one go. The l still waited 235.8 ms.
• "Deferring is the same as debouncing." No. A deferred value has no fixed delay. React starts the list as soon as the urgent render is done.
• "When React re-renders, it rewrites the page." No. Sort by price ran 3,000 rows, but React moved only 6 of them in the page.
• "Signals make every click fast." No. The signals click did 2.5 ms of work, but the next frame still came 69.6 ms after the click.
• "A virtual list costs nothing." No. Rows that aren't in the page can't be found with find-in-page or reached by the keyboard.

Practice exercises

Answer first, then use the hints.

// How many teas matched each list React rendered on the useDeferredValue page.
const found = { b: 2993, blen: 2992, blend: 2992 };

let rows = 0;
for (const query in found) rows += found[query];
console.log(`TeaRow ran ${rows} times`);

let running = null;
function signal(value) {
  const readers = new Set();
  return {
    get value() { if (running) readers.add(running); return value; },
    set value(next) { value = next; for (const reader of readers) reader(); },
  };
}
function effect(fn) { running = fn; fn(); running = null; }

let runs = 0;
let header = "";
const cart = signal(0);
const teas = ["Mint tea", "Green tea", "Earl Grey"].map((name) => ({ name, added: signal(false) }));
effect(() => { runs += 1; header = `Cart: ${cart.value}`; });
for (const tea of teas) effect(() => { runs += 1; tea.label = tea.added.value ? "Added" : "Add"; });

runs = 0;
teas[2].added.value = true;
cart.value += 1;
console.log(`${teas[2].name}: ${teas[2].label}. Functions that ran: ${runs}`);

Check your understanding

For each question, ask whose work it is: React's, or the browser's, and whether it can wait.

Key takeaways

• A framework's share of a key press or click comes in two parts: its own render and commit, then the browser's style and layout.
• A plain state update renders at once. On the plain search, the b took 465.6 ms, and nothing new showed for 467.4 ms.
• useDeferredValue and startTransition let the list wait. React renders it in pieces of about 5 ms and skips lists that are out of date.
• They can't split React's commit or the browser's layout. The l still waited 235.8 ms, and INP was 290.4 ms.
• memo and signals run only what changed: 1 row with memo, none with signals, instead of 3,000.
• A click during hydration can be lost, or wait for hydration. Selective hydration does the clicked part first.
• A virtual list keeps a few rows in the page. Sort by price took 17.0 ms instead of 84.7 ms.

Sources

The facts on this page come from these docs, posts and source files:

• Interaction to Next Paint (INP), web.dev.
• Render and Commit, React docs.
• useDeferredValue, React docs.
• React v18.0, React blog.
• SchedulerFeatureFlags.js, React 19.3.1, React on GitHub.
• Scheduler.js, React 19.3.1, React on GitHub.
• useTransition, React docs.
• startTransition, React docs.
• memo, React docs.
• JavaScript Signals standard proposal, TC39 on GitHub.
• Signals, Preact docs.
• Fine-grained reactivity, SolidJS docs.
• New Suspense SSR Architecture in React 18, React 18 Working Group.
• Virtualizer, TanStack Virtual docs.
• Virtualize large lists with react-window, web.dev.
• Optimize DOM size, Chrome for Developers.
• Client-side rendering of HTML and interactivity, web.dev.

Coming next: INP fixes from real sites. Real teams' slow interactions, and the fixes they had in common.