professional work

CRM Table Performance Engineering

Tracked down and fixed re-render issues in the CRM's main leads table.

Full-Stack Developer · Undisclosed · Oct 2025 — Present

context

The leads table is the main surface of the app. Changing one cell, selecting a row, or assigning an owner was causing all rows to re-render. With hundreds of leads loaded, this was visibly slow.

the challenge

There were multiple independent causes happening at the same time. Fixing one didn't noticeably improve things because the others were still firing. I had to find all of them.

approach

• 1.I added debug logging first to see which renders were actually firing and why, before touching anything.
• 2.I fixed each source independently instead of trying to do everything at once. For each one, I moved state to the smallest component that needed it and used Zustand selectors to limit what each row subscribed to.
• 3.I split the work across multiple PRs so each fix was independently testable.

technical highlights

• —Row selection, cell editing, color updates, and polling state moved out of component-level state into a Zustand store with per-row selectors.
• —High-churn elements like the column header dropdown, sort button, filter panels, and dialogs were extracted into isolated components so unrelated state changes wouldn't cause them to re-render.
• —TableVirtuoso callbacks and refs were stabilized with useCallback and module-level refs to stop the virtual list from remounting unnecessarily.
• —My first attempt at fixing scroll performance caused a regression and got reverted. The second approach using fine-grained Zustand selectors worked without side effects.

result

Only the affected rows re-render when something changes. The virtual list no longer remounts on unrelated state updates.

technologies