The system slows down on historical data
Screens that were fast in testing slow down once real history is loaded: ledgers, transactions and logs with hundreds of thousands of rows.
They were designed and tested against a demo dataset.
Profile representative data and separate query time, transfer time and browser rendering. Then choose measures such as appropriate default ranges, paging or server-side aggregation. Keep the selected scope visible; no single layout change resolves every performance cause.
Key facts
- A default range of all time is harmless with demo data.
- Totals calculated in the browser grow with the data.
- Users narrow date ranges by hand before every search.
- Limited defaults keep screens fast and hide older records from users who do not know to widen the range.
- The problem is a design problem and a backend problem at the same time.
Why it happens
Unlimited defaults. A default range of all time is harmless with demo data.
Totals in the browser. Totals calculated in the browser grow with the data.
Default views request all data, and the design has no state for partial or loading results.
How it shows up
- Reports time out
- Users narrow date ranges by hand before every search
- Filtering in the browser freezes the page
- Exports are used in place of screens
Options and trade-offs
What helps:
- Limited defaults, such as the current period
- Totals first, detail on request
- Aggregation on the server for reports
- Design reviews with realistic volumes
The tension: limited defaults keep screens fast, and users who do not know to widen the range miss older records. Unlimited views show everything until the data grows and they stop working.
Common mistakes
- Testing only with demo data
- Calculating report totals in the browser
- Defaulting every list to all time
- No loading or partial state in the design