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.

Requirements

Preserve the existing filterable table behavior and rendered row data.
Filtering must respond quickly for the configured rowCount dataset.
Debounce filter input so rapid typing does not re-render on every keystroke.
Avoid layout reads inside DOM-mutating row render loops.
Batch row DOM updates instead of appending rows one at a time.
Keep rendered rows queryable with data-testid="table-row".

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...