Skip to main content
ELYTE
HardFrontendInvestigate

Slow Dashboard — Find and Fix the Bottleneck

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

Start problemBrowse all problems

What you will practice

HTMLCSSJavaScriptPerformanceDOM & EventsDebugging

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

Starter files

index.htmlEditable template
styles.cssEditable starter
main.jsEditable starter

What the judge checks

  • Runs in the browser environment with the browser-eval runner.
  • Uses a 5000ms judge budget.
  • Requires test IDs: app, dashboard-table, filter-input.
  • Checks repeated UI regions: table-row.
  • Behavior rules include: Initial Render Required, Js Logic Required, Html Only Shortcut Disallowed, Filter Responds Quickly.

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)

Example behavior

Input
rowCount = 500, user types "ab" in the filter
Output
Only rows containing "ab" are visible. Typing feels responsive with no visible lag.

Follow-up

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