Skip to main content
Problem 14

Slow Dashboard — Find and Fix the Bottleneck

HARDINVESTIGATE
Performance+2

The starter code renders a filterable data table that works correctly but is painfully slow. Investigate and fix the performance bottlenecks without changing the feature behavior. There are at least three anti-patterns to find: layout thrashing (reading layout properties inside a DOM-mutating loop), no input debouncing, and one-at-a-time DOM appends instead of batched updates.

Examples
Example 1
Input
rowCount = 500, user types "ab" in the filter
Output
Only rows containing "ab" are visible. Typing feels responsive with no visible lag.
Constraints
  • Filtering must remain case-insensitive substring match
  • The filter must debounce to avoid re-rendering on every keystroke
  • DOM updates must be batched (use DocumentFragment or innerHTML)
Follow-up

Can you add a visible row count indicator that shows '47 of 500 rows' and updates as the filter changes?

Hints
Console output will appear here...