Aglet

How to diagnose a slow first load before changing code

When the first screen takes too long to become usable, separate server time, transfer time, parsing, and client work before changing code. This triage guide helps you capture one slow navigation, compare it with a fast one, and identify the earliest stage where delay accumulates.

Establish what is happening

  1. Capture a slow and fast navigation trace

    Use a fixed route, account state, and network condition for both captures. Record navigation start, first response byte, document completion, first meaningful paint, and interactive control readiness. Preserve request URLs, response sizes, cache status, and timestamps so the comparison remains reproducible.

  2. Locate the first stage that diverges

    Compare server timing with transfer, stylesheet and script parsing, image decode, and application initialization. Mark the first interval that is materially longer in the slow trace. A later delay may be a consequence, so keep the initial divergence separate from downstream symptoms.

  3. Check whether the delay is broad or route specific

    Repeat the trace on a neighboring route and with a fresh session. Compare document size, request count, response cacheability, and data volume. If only one route is slow, preserve its unique query or rendering evidence; if every route is slow, inspect shared startup work first.

What to carry forward

Output a timing comparison naming the first divergent stage, affected route or session state, and confidence in the boundary. Stop triage when you can assign the next investigation to server work, transfer and assets, or browser initialization without claiming a cause that the trace cannot prove.

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