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

Related Practice

Track

Frontend Fundamentals

Keep moving through related frontend fundamentals problems and build a stronger search-friendly practice loop around this topic.

Console output will appear here...