Separate document waiting from rendering
Begin with the navigation that feels slow, including the address the visitor actually opens. Save the request waterfall and identify the HTML document rather than an image or an API request loaded later. A blank screen alone does not tell you which component is responsible.
Time to First Byte includes more than application processing. Connection setup and redirects can contribute, so a browser timing value is not a direct measurement of database execution. The web.dev guidance also distinguishes a server-response audit from the complete navigation timing. Record the tool and the timing definition before comparing numbers.
Build a reproducible incident record
Write down the route, time, region, device, network profile and whether the visitor was signed in. Note the deployment version and relevant cache response headers when available. Use a test account for personalized flows and exclude credentials and private content from shared evidence.
Repeat the same navigation a small number of times and retain each observation. Compare the affected route with a nearby route that performs a similar task. Treat a faster repeat visit as a clue to investigate, not proof that caching is the sole cause. Avoid adding arbitrary query parameters that change application behavior.
Connect browser evidence to backend evidence
Ask the application owner to correlate the slow request with a request identifier or a narrow timestamp window. Where available, application traces or Server-Timing measurements can separate selected backend operations. Missing instrumentation should be recorded as missing evidence rather than replaced with an assumed database problem.
Make one diagnostic question actionable: does the delay occur before the request reaches the application, inside a measured operation, or after that operation completes? Assign the next measurement to the responsible owner. Do not add overlapping trace durations together as though every operation ran sequentially.
Illustrative example: a slow quote page
In a fictional investigation, the public service page responds consistently while a quote page waits longer. A saved trace links the quote request to a slow external lookup. The team proposes testing a fallback for that lookup in staging before redesigning the page header. These are invented observations illustrating the decision process, not results from a customer site.
The test ticket states the affected route, how to reproduce the delay, the trace to inspect and the expected behavior if the lookup is unavailable. It also requires checking that the quote information remains correct. A quicker response with incomplete business data would fail this acceptance criterion.
Choose a bounded fix and verify the whole task
Match the change to the confirmed bottleneck and keep a rollback path. If a cache change is proposed, have the application owner review which responses are safe to share; a speed target never justifies serving one visitor’s personalized content to another. Retest the original entry route and the relevant signed-in and anonymous states.
Compare response timing under the same recorded conditions, then complete the user task and inspect content rendering. Faster initial bytes do not guarantee a faster usable page. Keep unresolved causes in the issue record. An audit can identify where to investigate, while backend access and measured evidence determine the appropriate repair.