The Form That Loads Too Much
A case management interface shows a grid of 2,000 open cases with columns for case number, client name, assigned worker, status, and last activity date. The grid is backed by a query that pulls all open cases with no filter. Users report the page takes 9 seconds to render and the browser sometimes freezes when they sort by client name. The interface also has a dropdown of all 4,000 clients for filtering, populated on page load. Users typically work with 20-50 cases at a time and search by client name or case number. The database team says the underlying query is fine when run directly.
1. Identify the two main causes of the slow render and propose the interface changes.
Read the worked answer
Cause 1: unbounded grid query. The grid retrieves 2,000 rows on every load, and sorting by client name forces the client to re-sort a large in-memory set - that is the freeze. The database being fast in isolation confirms the problem is volume and client-side sorting, not the SQL.
Fix: make the grid paged and server-side sorted/filtered, with a default filter (e.g., assigned to current user, or last activity within 30 days) so the initial payload is in the tens of rows, not thousands. Users who need more can search.
Cause 2: eagerly loaded 4,000-item dropdown. Populating a picker with 4,000 clients on page load is pure waste when users search by name anyway.
Fix: replace the dropdown with a search-as-you-type picker that queries on keystroke with a small result cap, or a record-backed picker. Only load options when the user interacts.
Both changes target the same principle: load what the user needs to see, not everything that exists.
2. A user complains that after applying a client filter, sorting by case number returns results in a strange order. What is the likely cause?
Read the worked answer
If the grid is only partially converted to server-side behavior, the filter may be applied server-side while the sort is still applied client-side - or vice versa. Sorting the currently loaded page client-side produces an order that is correct only within that page, so the visible sequence looks arbitrary relative to the full result set.
The fix is to ensure filter, sort, and paging are all executed in the same layer. If sorting is server-side, the query must order before paging; if the grid paginates server-side but sorts client-side, the order is meaningless across pages.
This is a common regression when performance fixes are applied incrementally: each piece works alone, but the combination is inconsistent. The check is to confirm that the query's ORDER BY and the grid's configured sort field refer to the same column and that no client-side re-sort is layered on top.
3. How would you verify the fix actually solved the problem, using measurable criteria?
Read the worked answer
Define targets before measuring:
- Initial render under 2 seconds on a standard machine.
- Grid payload on first load ≤ 50 rows.
- Sort/filter response under 1 second.
- No client-side sort of more than one page of data.
Measure by instrumenting the query (row counts returned) and timing the interface in a browser with a realistic data set - not a developer's small test database. The 2,000-row and 4,000-client volumes must be reproduced, because the original bug only appears at scale.
Also test the specific reported scenario: filter by client, then sort by case number, and confirm the order is globally correct, not just page-local. A fix that improves load time but leaves the sort bug is only half done.