DEV Community: Alex Xiao

The progress bar that made typing lag: debugging a 331 ms INP in a React game

Alex Xiao — Fri, 13 Nov 2026 16:00:42 +0000

TL;DR: A friend told me that typing felt laggy in Museek, my free multiplayer music quiz. I was sure the culprit was my autocomplete filtering. The profiler disagreed. The real problem was a progress bar animating its width once per second, plus a full-screen backdrop-filter: blur(). Switching the bar to transform cut background Rendering time by roughly 7x and took keystrokes out of the slow interactions list.

The bug report

Museek is a browser-based "blind test": up to 12 players each bring a Spotify, Deezer or Apple Music playlist, a song snippet plays, and everyone types the artist and title as fast as they can. It's built with Next.js 16, React 19 and Tailwind 4, with a Node/Socket.io backend.

A friend playing a game sent me this: "There's a delay between what I type and what shows up in the answer field."

In a game where you're racing a 30-second timer, that's not a cosmetic issue.

My first guess (and why it was wrong)

Each answer field has an autocomplete. On every render, my Game component filtered the whole song and artist database, and called a fairly expensive normalizeString() (Unicode NFD normalization plus two regexes) twice per item. Worse, it normalized the user's input again for every single item, inside the loop:

const filteredArtists = (database_artists || [])
  .filter((a) => {
    if (!artistQuery || artistQuery.length < 3) return false;
    const search = normalizeString(artistQuery); // once per item!
    return normalizeString(a.artist).includes(search)
      || normalizeString(a.internationalArtist).includes(search);
  })
  .slice(0, 5);

A quick benchmark gave about 18 ms per render with 2,000 artists and 2,000 tracks on my PC. That's enough to hurt on a phone, so I fixed the cheap part straight away: normalize the input once per render, and skip the loop entirely below 3 characters.

const artistSearch = normalizeString(artistQuery);

const filteredArtists =
  artistQuery.length < 3
    ? []
    : (database_artists || []).filter(/* ...uses artistSearch... */).slice(0, 5);

But one detail didn't fit. With the CPU throttled in DevTools, the lag started from the very first letter, and the filter does nothing below 3 characters. Something else was going on, so I stopped guessing and opened the Performance panel.

Step 1: measure properly (and beware of your extensions)

My setup: Chrome DevTools → Performance, CPU throttling at 4x (roughly a mid-range phone), record, type about ten letters, stop.

First result: INP 510 ms. Terrible. But the call stack under the slow keystroke looked odd: onCommitFiberRoot, handleCommitFiberRoot, then a long chain of updateFiberRecursively. And the "Forced reflow" insight pointed at measureHostInstance @ installHook.js.

installHook.js is injected by the React Developer Tools extension. After every React commit, it walks the component tree and measures elements on screen, which forces a layout. On that keystroke, Museek's own code accounted for 12.8 ms. The extension was responsible for most of the 191 ms of reflow.

Lesson #1: profile in an incognito window, where extensions are disabled by default. Your users don't run React DevTools.

Step 2: the real numbers

Same test, incognito window, 4x CPU, on the live site:

INP: 331 ms
INP breakdown: input delay 3 ms, processing 297 ms, presentation delay 31 ms
Inside that processing time: a single purple Layout of ~290 ms, triggered by Event: textInput
Scripting for the whole interaction: about 30 ms

So JavaScript wasn't the bottleneck. Layout was. And the summary showed the page was busy even when nobody typed: 2,217 ms of Rendering and 954 ms of Painting over an 11.6-second recording. That's more than a quarter of the time spent laying out and painting.

Then the Animations track: a continuous chain of width segments, one per second.

Step 3: find the pattern

Zooming in on the slow keystroke, the timing was suspicious. It landed exactly at the start of a new width segment, right after a tick of the game clock.

The animated element was my timer bar:

<div
  className="h-full rounded-full transition-all duration-1000 ease-linear ..."
  style={{ width: `${((totalPhaseTime - timeLeft) / totalPhaseTime) * 100}%` }}
/>

Every second, timeLeft changes. That one state update does three things at once:

it updates the "Time left" text under the bar,
it updates the same text in the header of the open answer field,
it starts a new 1-second width transition on the bar.

All three invalidate layout. Animating width is especially bad: the browser has to recompute layout on every frame of the transition. If a keystroke arrives right at that moment, the browser has to finish all that layout work before it can paint the new letter. Keystrokes between two ticks stayed fast, which matches what my friend felt: not constant lag, but stutters.

One surprise: only 10 of 83 nodes needed layout, and it still took 262 ms on one capture. The node count wasn't the issue. The keystroke simply had to pay for the layout that the clock tick had just invalidated.

The fix: `transform` instead of `width`

transform and opacity are the two properties browsers can animate on the compositor (the GPU), without running layout. So the bar now always has full width and slides in from the left with translateX, inside a container that has overflow: hidden:

<div className="h-2 w-full overflow-hidden rounded-full bg-(--white)/20">
  <div
    className="h-full w-full rounded-full transition-transform duration-1000 ease-linear will-change-transform ..."
    style={{ transform: `translateX(-${(timeLeft / totalPhaseTime) * 100}%)` }}
  />
</div>

A few details:

Why translateX and not scaleX? scaleX would squash the rounded ends when the bar is short. Translating a full-width bar inside a clipped container looks identical and keeps the corners round.
transition-all → transition-transform. transition-all watches every property, so any change can trigger an expensive transition. Only transition what you actually animate. (Small trade-off: the bar's color now switches instantly between phases instead of fading.)
will-change-transform promotes the bar to its own compositor layer.
tabular-nums on the countdown text. With proportional digits, "10s" and "9s" have different widths, so the text shifts every second. Tabular digits all have the same width, so nothing around them moves.

Result

Same test, production build (run locally this time), incognito, 4x CPU. The Animations track now says transform instead of width.

Over the recording	Before (11.6 s)	After (7.8 s)
Rendering	2,217 ms (19%)	213 ms (2.7%)
Painting	954 ms (8.2%)	71 ms (0.9%)

Relative to recording length, that's about 7x less Rendering and 9x less Painting. Most importantly, keystrokes disappeared from the slow interactions. The INP was still 368 ms, but the worst interaction was now a click, not a keystroke.

Bonus round: the full-screen blur

That slow click was the one that opens the answer field. Its breakdown was very different:

processing: 13 ms
presentation delay: 353 ms

My code reacted instantly. The browser took 353 ms to show the result. When the field opens, a full-screen overlay appears behind it with backdrop-blur-sm. Blurring the whole viewport (including an animated timer bar and an SVG noise background) is expensive GPU work, and it doesn't show up as JavaScript or Layout on the main thread.

I removed the blur and made the background slightly more opaque to keep the dimming effect (/60 → /80). The click's presentation delay dropped to 237 ms, with 1 ms of processing.

One last tweak: the overlay was mounted conditionally ({isActive && <div ... />}), so every opening forced the browser to create and paint a brand new full-screen layer. Now it's always in the DOM, and only its opacity changes:

<div
  aria-hidden="true"
  className={`fixed inset-0 z-40 bg-(--background)/80 transition-opacity duration-250 ease-out ${
    isActive ? "opacity-100" : "pointer-events-none opacity-0"
  }`}
/>

After that, only the very first opening of the field is still slow (about 270 ms at 4x, a one-time cost to create the layer). Later openings no longer show up as long interactions, and you get a fade-out on close for free.

What I'm taking away from this

Profile in incognito. React DevTools alone turned a 331 ms problem into a 510 ms one and pointed me at the wrong function.
Read the INP breakdown before touching code. High processing means your code (or forced layout). High presentation delay means rendering and GPU work. They need completely different fixes.
A timer running while the user types can cost more than your JavaScript. Animate transform and opacity, never width, and avoid transition-all.
Full-screen backdrop-filter isn't free, especially on low-end phones and on top of other animations.
Your first hypothesis is just a hypothesis. My autocomplete fix was still worth keeping, but it wasn't the bug my friend was hitting.

The changes are in two small commits in the Museek repository: dfddfd7 and 02a0f42.

If you want to check that typing is smooth now, start a game on Museek: it's free, there's no account, and you can play with friends using your own playlists. You can also read the full case study on my portfolio.

Building a multiplayer music quiz where everyone brings their own playlist (Next.js + Socket.io)

Alex Xiao — Thu, 22 Oct 2026 15:40:09 +0000

I'm Alex, a web developer in Brussels. This is the story of Museek, a free multiplayer music quiz I built on my own: everyone brings a public Spotify, Deezer or Apple Music playlist, Museek shuffles all the tracks together, and each round you guess the artist or the title. Up to 12 players, no account, desktop, tablet or mobile.

Two things up front, because they shape the design: it is not a race (speed doesn't count, everyone can score on every track), and there is no built-in chat , so the easiest way to play is in a voice call with friends.

Try it: https://museek.xiao-web.com/

The code is on GitHub. Here are the parts that were the most interesting to build.

The stack

Next.js (React, TypeScript) on the front, Node.js + Express + Socket.io on the back, in one monorepo. There is no database: rooms live in memory on the server and disappear when the last player leaves.

1. Importing playlists from three platforms

The idea only works if a player can paste a link from the service they already use. Each platform needed a different approach:

Deezer : the public API (api.deezer.com/playlist/{id}).
Spotify : playlists are read from the public embed page, which exposes the track list in its page data. I used the official API only for albums.
Apple Music : the playlist page is scraped with Cheerio.

An honest caveat: two of the three rely on page structures I don't control, so they can break when the platforms change them. That's the main maintenance risk of the project.

Never trust a pasted link

Players paste arbitrary links, and the server fetches them. Left unchecked, that is a server-side request forgery (SSRF) hole: someone could make the server call an internal address. So links go through a strict allow-list:

const ALLOWED_HOSTS = {
  deezer: /^(?:[\w-]+\.)?deezer\.com$|^deezer\.page\.link$/,
  spotify: /^(?:[\w-]+\.)?spotify\.com$|^spotify\.link$|^spotify\.app\.link$/,
  apple: /^(?:music|itunes)\.apple\.com$/,
};

The check runs on the hostname parsed by new URL, never on the raw text, so https://evil.com/?x=deezer.com and https://deezer.com@evil.com are refused. Only https without a custom port is accepted. Short links (spotify.link, deezer.page.link) are followed redirect by redirect, and every hop must stay on an allowed domain. There is a test file dedicated to this.

2. Typo-tolerant answers

Players type the artist and/or the title. The comparison is forgiving: case and accents are ignored, and everything that isn't a letter or a digit is stripped.

export function normalizeString(str: string): string {
  return str
    .toLowerCase()
    .normalize("NFD")
    .replace(/[̀-ͯ]/g, "")
    .replace(/[^\p{L}\p{M}\p{N}]/gu, "");
}

Artists are split on ,, &, feat., with… and each one is checked. Scoring is simple: 1 point for the artist (0.5 if there are several and you only find some of them) plus 1 point for the title. An autocomplete suggests names from the loaded playlists, which removes most typing errors.

The normalisation of each track is computed once when the game starts, not on every answer.

3. Non-Latin names

Many playlists mix scripts: Japanese, Chinese, Korean, Cyrillic. Players on a Latin keyboard can't type those, so each track also gets an "international" (romanised) name, and both versions are accepted. The pipeline is:

Latin text stays as is.
Anything with kana goes through Kuroshiro (Japanese reading, kanji included).
Other scripts (Chinese, Korean, kanji alone…) go to an LLM through the Groq API, and fall back to local transliteration if the call fails or no key is set.

Only titles and artist names are sent to the API, never usernames or IP addresses. It's documented in the app's privacy page.

4. A server-driven game clock

Every player must see the same countdown, even with a laggy phone or a throttled background tab. Instead of counting down on each client, the server only sends two timestamps:

function getGameTiming(time: number, gameStartTime: number): GameTiming {
  return { gameStartTime, serverNow: Date.now(), time };
}

The client estimates the gap between the two clocks once, then derives the round, the phase and the time left from the current time:

const toGameClock = (timing) => ({
  startTime: timing.gameStartTime,
  offset: timing.serverNow - Date.now(),
  time: timing.time,
});

A round is time seconds of guessing, 5 seconds of reveal and 2 seconds of transition. Because the state is a pure function of the clock, a player who reloads the page or comes back from another app lands on the right screen without any "catch-up" message.

The limit: network latency is ignored, so clocks can differ by a few dozen milliseconds. Since speed doesn't affect the score, that's fine, which is one more reason the game isn't a race.

5. Disconnections and reconnection

On mobile, players switch apps all the time. Each player has a private ID stored in the browser; on reconnect the server swaps the socket and sends back the current state. A 5-minute grace period before a disconnected player is removed, and the host role is transferred if the host doesn't come back. One subtle bug class: a stale socket firing its disconnect event after the player has already reconnected on a new one. The handler ignores it when player.socketId !== socket.id.

6. Privacy by default

No database, no analytics, no ads. Room data is purged when the room empties. Other players never receive your reconnection ID or your playlist link, only a random public ID. The server also rate-limits per IP (room creation, playlist loads, bad room codes, simultaneous connections).

7. Testing with real clients

The backend tests start their own server and play games with real Socket.IO clients: answers and scores, host rights, identity, disconnections and reconnections, reset, mixed-script playlists, the link allow-list, and rate limits. Testing at the socket level caught more real problems than unit tests alone would have.

Try it

museek.xiao-web.com: free, no signup. It's a multiplayer game, so bring a few friends and a voice call. Feedback is very welcome, especially on onboarding and on playlist links that don't load.

Museek is an independent project, not affiliated with Spotify, Deezer or Apple.

I used an AI assistant while building the project and to help draft this post