Build a useful investigation brief
Measure server cost as rows increase
Capture query count, query duration, sort and join work, serialization time, response bytes, and total handler time for each representative size. Check whether fields are fetched for every row and whether a filter or sort changes the plan. Preserve shape and ordering so comparisons remain fair.
Follow payload into rendered rows
Compare decoded response data, row objects, DOM nodes, nested controls, image work, and layout duration. Look for repeated transformations or listeners proportional to rows. Record whether offscreen rows are still rendered and whether a later expansion adds hidden work to every item.
Test one scale boundary change
Evaluate one bounded change: server pagination, a narrower initial field set, a focused query, a row rendering limit, or a less expensive sort path. Replay loading and common operations at matched sizes. Check row identity, ordering, selection, keyboard movement, and next-page behavior before accepting speed.
What to carry forward
Deliver a brief with the row-count comparison, first scalable interval, measured query or DOM evidence, and one isolated experiment. State what remains uncertain about larger sizes. Stop when implementation can target one boundary and verification can exercise loading plus the list operation that people actually use.
Keep the decision with the work.
Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.
Create an account See the product workflow