Aglet

How to diagnose slow search across input, query, and results

Slow search can begin before a request leaves the browser or after the server has finished querying. This triage guide follows one search term through input, request, query, response, and rendering, then compares it with a fast term to find the first meaningful divergence.

Establish what is happening

  1. Capture the exact search interaction

    Record whether the search runs on each keystroke, an explicit submit, or both. Preserve the term, filters, account or dataset size, input timestamps, request start, response arrival, first result, and final result. Note empty, short, and common terms separately because they may take different paths.

  2. Split browser and server intervals

    Compare time spent in debounce or event handling, request queueing, server processing, database execution, response transfer, and result rendering. Use request identifiers to align client and server evidence. Mark gaps that cannot be aligned rather than assigning them to the query without proof.

  3. Repeat with a matched fast term

    Run a fast term with the same filters, route, account state, and network profile. Compare result count, query shape, response bytes, cache state, and rendering work. If only specific terms diverge, preserve their characters and selectivity for investigation rather than averaging them away.

What to carry forward

Return a triage brief naming the search mode, slow interval, term or filter conditions, and first observed divergence. Route the next work to input handling, server or query work, transfer, or rendering. Keep empty or partial results separate from latency so correctness and speed do not become one vague issue.

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