INP fixes from real sites

Did real teams find the same slow taps?

Ravi has spent the last few lessons on the Leaf and Kettle's tea list. One slow tap at a time, he found the cause and fixed it. A search that worked hard on every key. A click that did four jobs at once. A list that drew 3,000 rows again.

Now he wonders. Were these his own mistakes, or do real teams meet the same ones? And when they fixed them, which fixes paid off most?

Many teams have written down what they found. They measured their real visitors, found the slow taps, fixed them, and measured again. Here is where four of them started, and where they ended:

Each pair of bars is one team's INP, Interaction to Next Paint. Lesson 26.1 showed what it measures. For each click, tap or key press, it times the wait from the press to the next frame: the next picture the browser draws on the screen. A visit's INP is roughly its slowest one. A good INP is 200 ms or less. A millisecond (ms) is a thousandth of a second.

Every team started above the 200 ms line. Two ended under it, and the other two came much closer. Why it matters: slow taps are not bad luck on one small site. Big, busy sites had them too, and fixed them.

Ravi read every write-up. The same three causes came up again and again:

• Heavy work on every key or filter: a search or a filter that does all its work, every time.
• Someone else's code on every click: a cookie banner, a tracker or a widget that works inside your clicks.
• Drawing more than changed: one small change, like one more tea in the cart, that redraws the whole page.

Where the numbers come from

• The teams' numbers come from each team's own write-up, as they measured them. The Sources list at the end links to every one.
• Each team measured in its own way. Some timed their own visitors. Some used Chrome's data from real users. So compare a team with itself, not with another team.
• One test page: Ravi's tea list with all three causes at once, then with the fixes added one by one. The course recorded it in Chrome 157.

Ravi's tea list with all three problems

To see the three causes side by side, Ravi built one page with all of them. It's the tea list from lesson 28.2, with 3,000 teas. Asha does what a shopper does. She clicks Add on Mint tea. Then she clicks the search box and types chai, a key every 120 ms. That's six interactions: two clicks and four key presses.

First, the shop's search. It runs on every key press:

1function search(words) {2  work(35_000_000); // scores every tea against the words3  let found = 0;4  for (const row of teas.children) {5    row.hidden = !row.dataset.name.toLowerCase().includes(words);6    if (!row.hidden) found += 1;7  }8  document.querySelector("#about").textContent = "Teas found: " + found;9}10box.addEventListener("input", () => search(box.value.toLowerCase()));

• Line 2 stands for the slow part: scoring every tea against the words. work() is the course's stand-in loop. It takes the same number of steps on any computer, so a slower phone takes longer.
• Lines 4 to 7 hide each row that doesn't match. Line 8 says how many teas were found.
• Line 10 runs the search on every input event: once per key.

Second, a tracker. It's a third party: code from another company that the page loads, like analytics, ads or a cookie banner. This one notes every click on the page:

1document.addEventListener("click", function track(event) {2  const report = { on: event.target.tagName, at: event.timeStamp };3  work(30_000_000); // reads the page around the click4  navigator.sendBeacon("/collect", JSON.stringify(report));5});

• Line 1 listens for clicks on the whole document. Every click on the page reaches it.
• Line 2 notes what was clicked, and when.
• Line 3 stands for the tracker's work: reading the page around the click.
• Line 4 sends the report with sendBeacon, which doesn't wait for an answer.

Third, Add to cart. It adds the tea, then draws the whole list again from its data:

1function render() {2  document.querySelector("#cart").textContent = "Cart: " + cart.length;3  const words = box.value.toLowerCase();4  teas.innerHTML = all.map((tea) => rowHtml(tea, words)).join("");5}6teas.addEventListener("click", function addToCart(event) {7  if (!event.target.matches(".add")) return;8  cart.push(event.target.closest("li").dataset.tea);9  render(); // the badge and all 3,000 rows, drawn again10});

• Lines 1 to 5 are render(). Line 2 writes the cart badge.
• Line 4 builds the HTML of all 3,000 rows with rowHtml(), and puts it in the page. A tea in the cart says Added.
• Line 8 adds the tea to the cart. Line 9 calls render().

Here is what Asha's six interactions cost, from Chrome's trace:

1// Asha's six interactions on the page as it was, in ms, from Chrome's trace.2const visit = [3  { name: "Add", took: 452.8, waited: 2.1, handlers: 214.7, after: 235.9 },4  { name: "Search box", took: 142.3, waited: 0.3, handlers: 134.0, after: 8.0 },5  { name: "c", took: 347.4, waited: 0.5, handlers: 337.6, after: 9.3 },6  { name: "h", took: 227.5, waited: 63.7, handlers: 154.5, after: 9.3 },7  { name: "a", took: 419.5, waited: 105.3, handlers: 309.1, after: 5.0 },8  { name: "i", took: 297.0, waited: 138.1, handlers: 153.9, after: 5.0 },9];10for (const step of visit) {11  console.log(`${step.name}: took ${step.took.toFixed(1)}, waited ${step.waited.toFixed(1)}, handlers ${step.handlers.toFixed(1)}, after ${step.after.toFixed(1)}`);12}

• Line 1 says where the numbers come from. A trace is Chrome's detailed record of everything it did.
• Lines 3 to 8 hold one interaction each. took is its time as INP counts it, from the press to the next frame.
• The other three are the parts lesson 26.2 named. waited is the input delay, before its handlers started. handlers is the processing. after is the presentation delay: the browser's own work until the frame reached the screen.
• Line 11 prints one line each. The first is Add: took 452.8, waited 2.1, handlers 214.7, after 235.9. The slowest key is a: took 419.5, waited 105.3, handlers 309.1, after 5.0.

Each cause shows. The Add click spent 214.7 ms in handlers, with the tracker inside them, and 235.9 ms on 3,000 new rows. The click in the search box does nothing for the shop, yet took 142.3 ms: the tracker again. And each key waited behind the search for the key before it.

Here is what Asha saw. These are real frames from the recording, the pictures Chrome drew on her screen. The top row is the page as it was. The bottom row has the three fixes this lesson walks through.

On the page as it was, Cart: 1 came 455.0 ms after her click. After her c, nothing changed for 349.5 ms. Then two letters, ch, came at once. With the fixes, Cart: 1 came after 73.8 ms, and the c after 16.4 ms. The results came a little later, at 797.7 ms, because the search now waits for a pause. Why it matters: three ordinary problems made a simple visit feel stuck at every step.

How the course recorded it

• Four versions of the page: as it was, then with fix 1, fixes 1 and 2, and all three. Each keeps the fixes before it.
• Asha's phone: this computer in Chrome 157, with its processor, the CPU, slowed 4 times, as in lessons 28.1 to 28.3. Her window was 412 by 480 pixels.
• Real clicks and keys: sent through Chrome's DevTools protocol, the way programs drive Chrome. Chrome passes mouse clicks and key presses straight to the page.
• Three visits each, taking turns. The lesson quotes the middle visit, by its slowest interaction.

Heavy work on every key or filter

The first cause showed up in search boxes and filters. A filter is a control that narrows a list, like a date or a price. Their handlers do real work: they search, sort and draw the results. On a fast laptop that feels fine. On a slow phone, each key waits for the work of the key before.

Preply, a site for finding tutors, saw it in its search page's subject box. On slow devices, most key presses there took over 300 ms. The team debounced the page's three input boxes. Debouncing means waiting until the keys stop for a moment, then running the update once. Typing in the subject box went from 632 ms to 72 ms.

QuintoAndar, a housing site in Brazil, found parts of its property search where one interaction took 4 seconds at the 75th percentile. That means three visitors in four were faster, and one in four waited that long or longer. Their fix for a filter click had three steps:

1. Show a spinner, so the click has a visible answer.
2. Yield: stop for a moment, so the browser can draw the spinner and handle input. Lesson 27.2 showed how.
3. Then load the filter's data and open its window.

Trendyol, a large online shop in Turkey, found one task of 700 to 900 ms on its product list. It started inside an Intersection Observer callback, code that runs when an element scrolls into view. The callback changed React state, and React drew the list again. They yielded before the state change. INP on that page fell by half, from 963 ms on phones.

Why it matters: none of these teams made the slow work itself faster. They ran it less often, or after the screen had changed. Lesson 28.1 teaches both moves.

Not every browser has scheduler.yield(). Trendyol fell back to setTimeout where it was missing:

On Ravi's page, fix 1 is the debounce from lesson 28.1:

1// debounce() is lesson 28.1's: it runs search once the keys stop for 250 ms.2const searchSoon = debounce(search, 250);3box.addEventListener("input", () => searchSoon(box.value.toLowerCase()));

• Line 1 is a comment. debounce() is the helper from lesson 28.1.
• Line 2 makes searchSoon, which runs search once the keys stop for 250 ms.
• Line 3 calls it on every key, instead of the search itself.

1// How long c, h, a and i took, in ms, and how many searches ran.2const pages = [3  { name: "As it was", keys: [347.4, 227.5, 419.5, 297.0], searches: 4 },4  { name: "+ debounce", keys: [15.8, 11.5, 11.7, 12.7], searches: 1 },5];6for (const page of pages) console.log(`${page.name}: slowest key ${Math.max(...page.keys).toFixed(1)} ms, searches run: ${page.searches}`);

• Lines 3 and 4 hold how long each of Asha's four keys took, and how many searches ran.
• Line 6 prints As it was: slowest key 419.5 ms, searches run: 4 and + debounce: slowest key 15.8 ms, searches run: 1.

Every key now took under 20 ms. Why it matters: when a handler does heavy work on each key, run it once. That helps more than making it a little faster.

Someone else's code on every click

The second cause is harder to see, because it isn't your code. Cookie banners, trackers and chat widgets add listeners of their own. Many listen on the whole page, so every click runs them.

Erwin Hofman, a web performance consultant, timed the Accept button of OneTrust's cookie banner. One click ran several jobs. Closing the banner, the part the visitor sees, took 11.16 ms. Updating the tag manager took 190.35 ms. A tag manager is a script that loads and runs other tracking scripts. In his field data, 31% of clicks on that button were poor. His advice to banner makers: hide the banner first, then yield before the rest.

Disney+ Hotstar's TV app used a third-party library to move between cards with the remote. On every key press, it read the position of every focusable element. That made the browser lay out the page again and again. Lesson 6.3 called this layout thrashing. Hotstar built its own carousel, which reads sizes once per row of cards. Moving along a row went from about 400 ms to about 100 ms.

Some third parties slow clicks they never listen to. Poptin, a pop-up app on thousands of Shopify stores, made synchronous network requests as it started. Synchronous means the main thread stops until the answer comes. That made one task of about 900 ms on every page load, so any tap in it waited. Poptin made the requests asynchronous and started the app in a new task. INP across the stores went from 280 ms to 120 ms, at the 75th percentile.

On Ravi's page, fix 2 is a new version of the tracker that waits for the next frame:

1const afterNextFrame = () => new Promise((resolve) => requestAnimationFrame(() => setTimeout(resolve, 0)));2document.addEventListener("click", async function track(event) {3  const report = { on: event.target.tagName, at: event.timeStamp };4  await afterNextFrame();5  work(30_000_000); // reads the page around the click6  navigator.sendBeacon("/collect", JSON.stringify(report));7});

• Line 1 makes afterNextFrame(), from lesson 28.1. It waits for the next frame, then for a new task.
• Line 3 notes what was clicked, as before.
• Line 4 waits. Lines 5 and 6 then do the same work as before.

1// The tracker's work for the Add click, from Chrome's trace. Times in ms after the click.2const now = { tracker: 130.3, nextFrame: 440.2 };3const waits = { trackerStarted: 316.1, nextFrame: 318.0 };4console.log(`Inside the click: the tracker ran ${now.tracker.toFixed(1)} ms; the frame came at ${now.nextFrame.toFixed(1)}`);5console.log(`After the frame: the frame came at ${waits.nextFrame.toFixed(1)}; the tracker started at ${waits.trackerStarted.toFixed(1)}`);

• Line 2 holds the Add click with fix 1 only. Line 3 holds it with fixes 1 and 2.
• Line 4 prints Inside the click: the tracker ran 130.3 ms; the frame came at 440.2.
• Line 5 prints After the frame: the frame came at 318.0; the tracker started at 316.1.

The tracker started once Chrome had finished the frame's work, and still did all its work: 137.4 ms. The click in the search box went from 143.6 ms to 15.5 ms. Why it matters: you can't always change a third party's code. But you can pick one that waits, ask its makers for a fix, or load it later, as lesson 24.2 showed.

Try it in your own browser. The tracker below keeps the main thread busy for 120 ms on every click:

1const busy = (ms) => { const end = performance.now() + ms; while (performance.now() < end) {} };2const afterNextFrame = () => new Promise((resolve) => requestAnimationFrame(() => setTimeout(resolve, 0)));3lab.addEventListener("click", async function track() {4  if (mode === "after") await afterNextFrame();5  busy(120); // the stand-in tracker's work6});

Lines 4 and 5 of the panel's code are the whole difference. Inside the click, each click should take at least 120 ms. After the frame, the cart should count up at once.

Drawing more than changed

The third cause is drawing more of the page than changed. State is the data a page draws from, like the cart or the search words. When it changes, the code draws the page again. If it draws everything, the browser must style and lay out everything too.

redBus, a bus ticket site in India, saw it in its search page's input fields. Each change called an expensive reducer. A reducer is a function that works out the new shared state. Then the page was drawn again. The team kept each field's text in the field itself. They told the shared store, Redux, only when the field lost focus. After that change, the page's INP was 72% better. Their INP work raised sales by 7%.

Preply found two big parts of its search page drawn again whenever the filters closed. Neither ever changed, so wrapping them in memo was enough. memo skips a component whose inputs haven't changed, as lesson 28.3 showed. A banner's state sat at the top of the page, so closing the banner drew the whole page again. Moving that state into a small component fixed it.

The Economic Times, a news site, had a page with 2,706 elements. A big page makes every style and layout slower. They built the menu's items only when the menu was clicked. The page lost about 1,200 nodes, the elements and text it's made of. With other changes, INP went from over 1,000 ms to 257 ms.

On Ravi's page, fix 3 changes only what changed:

1teas.addEventListener("click", function addToCart(event) {2  if (!event.target.matches(".add")) return;3  cart.push(event.target.closest("li").dataset.tea);4  document.querySelector("#cart").textContent = "Cart: " + cart.length;5  event.target.textContent = "Added";6});

• Lines 1 to 3 are as before.
• Line 4 changes the badge. Line 5 changes the clicked button's text. Nothing else is touched.

1// The Add click, with fixes 1 and 2 in place. Times in ms.2const clicks = [3  { name: "Draws everything", handlers: 75.1, after: 240.9, took: 318.0 },4  { name: "Changes two things", handlers: 3.4, after: 66.6, took: 72.4 },5];6for (const c of clicks) console.log(`${c.name}: handlers ${c.handlers.toFixed(1)}, after them ${c.after.toFixed(1)}, took ${c.took.toFixed(1)}`);

• Line 3 holds the Add click with fixes 1 and 2. Line 4 holds it with all three.
• Line 6 prints Draws everything: handlers 75.1, after them 240.9, took 318.0 and Changes two things: handlers 3.4, after them 66.6, took 72.4.

Drawing every row cost twice. First the handlers built 3,000 rows. Then the browser worked out the style of 12,000 elements and laid out 21,008 boxes before the frame. With fix 3, the browser still laid out the long list: 18.6 ms. Lesson 28.2 showed how to shrink that too. Why it matters: the cheapest work is work that never happens.

What the fixes had in common

Put the teams side by side, and the same steps come up.

1. They found the slow interaction in the field first. Field data comes from real visitors' browsers. redBus, Hotstar and Preply used Google's web-vitals library, which measures INP in visitors' browsers. QuintoAndar split each slow interaction into its three parts.
2. They made it happen again on a slow CPU. Trendyol slowed DevTools' CPU 4 times. Preply went from 6 times to 20 times.
3. They fixed the slowest interaction first. The rest can wait.
4. They measured again. Some changes did nothing. Preply removed 15% of its search page's code, and INP didn't move.
5. They kept watching. QuintoAndar sends each release to a few users first, and rolls it back if it's slower.

Ravi's page shows why the order matters. Here is the visit's INP after each fix:

1// Each version's six interactions, in ms: Add, the search box, c, h, a, i.2const versions = [3  { name: "As it was", took: [452.8, 142.3, 347.4, 227.5, 419.5, 297.0] },4  { name: "+ debounce", took: [440.2, 143.6, 15.8, 11.5, 11.7, 12.7] },5  { name: "+ tracker waits", took: [318.0, 15.5, 14.8, 10.8, 10.9, 11.3] },6  { name: "+ render less", took: [72.4, 17.3, 14.0, 12.7, 12.3, 11.0] },7];8for (const v of versions) console.log(`${v.name}: INP ${Math.max(...v.took).toFixed(1)} ms`);

• Lines 3 to 6 hold each version's six interactions, in the order Asha did them.
• Line 8 takes the slowest of each. It prints As it was: INP 452.8 ms, + debounce: INP 440.2 ms, + tracker waits: INP 318.0 ms and + render less: INP 72.4 ms.

Fix 1 made four key presses fast, yet INP barely moved. The Add click was still the slowest, and INP reports the slowest. Fixes 2 and 3 worked on that click, and INP fell. Why it matters: start with the interaction your field data says is slowest.

So which fixes paid off most? The ones aimed at the slowest interaction. The teams' businesses gained, too. redBus's sales rose 7%. Disney+ Hotstar's weekly card views went from 111 to 226 per user. Trendyol's clicks from its list to a product rose 1%. QuintoAndar's conversions rose 36% in a year, which it links strongly, but not only, to the better experience.

Pick a version to see all six of Asha's interactions and their three parts:

Read this table across. Each row is one team: what was slow, what fixed it, and where this course teaches the fix.

Pick a team to see its own numbers, and where to read more:

Later, less often, or less?

Each change below is one a team made. Sort it by what it does to the slow work.

Common mix-ups

• "Slow taps on a big site come from one big mistake." No. Preply fixed many small things, each worth 5 to 40 ms of INP.
• "Shipping less JavaScript always lowers INP." No. Preply removed 15% of its search page's code, and INP didn't change. INP is about the work that runs during an interaction.
• "A third party only costs time while it loads." No. OneTrust's banner spent 190.35 ms of one click updating the tag manager.
• "Debouncing makes the search faster." No. On Ravi's page, the search took as long as before. It ran once instead of 4 times.
• "Fixing most interactions fixes INP." No. Fix 1 made four key presses fast, but INP only went from 452.8 ms to 440.2 ms.
• "If it's fast on my laptop, it's fast for visitors." No. Trendyol found its 700 to 900 ms task by slowing the CPU 4 times, to act like a phone. Hotstar's TV was slower than a laptop slowed 6 times.

Practice exercises

Answer first, then use the hints.

// Asha types c, h, a, i. The search waits 250 ms after the last key.
const pressedAt = [0, 120, 540, 660]; // she stops for a moment after h
let searches = 0;
pressedAt.forEach((time, i) => {
  const next = pressedAt[i + 1];
  if (next === undefined || next - time >= 250) searches += 1;
});
console.log("Searches: " + searches);

let reducerRuns = 0;
const store = { dispatch: () => (reducerRuns += 1) };
const box = new EventTarget();
box.addEventListener("blur", () => store.dispatch({ search: "chai" }));
for (const letter of "chai") box.dispatchEvent(new Event("input"));
box.dispatchEvent(new Event("blur"));
console.log("Reducer runs: " + reducerRuns);

Check your understanding

For each question, ask which cause it is about, and which interaction sets INP.

Key takeaways

• Real slow interactions came from three causes again and again: heavy work on every key, someone else's code on every click, and drawing more than changed.
• The fixes repeat too: show the change and do the rest later, run it less often, or do less of it.
• Find the slowest interaction in the field first. INP reports the slowest, so fixing others may not move it.
• A third party's work runs inside your clicks. Pick ones that wait, ask for fixes, or load them later.
• Measure again after each change. Some changes, like shipping less code, may not help INP at all.

Sources

The teams' numbers come from their own write-ups. The other facts come from these docs:

• Interaction to Next Paint (INP), web.dev.
• How Preply improved INP on a Next.js application (without React Server Components and App Router), Preply Engineering.
• How QuintoAndar reduced INP by 80%, increasing conversions by 36%, web.dev.
• How Trendyol reduced INP by 50%, resulting in a 1% uplift on click-through rate, web.dev.
• Performance (INP) impact from OneTrust and other CMPs, Erwin Hofman.
• How Disney+ Hotstar increased weekly card views by 100% on living room devices by reducing INP by 61%, web.dev.
• How Poptin improved storefront responsiveness for thousands of Shopify merchants, Shopify Performance.
• How redBus improved their website's Interaction to Next Paint (INP) and increased sales by 7%, web.dev.
• Economic Times quest for fixing INP, web.dev.
• Optimize Interaction to Next Paint, web.dev.
• Scheduler: yield() method, MDN.

Coming next: Memory and speed. Garbage collection pauses and memory pressure, and how they slow a page down.