Troubleshoot a slow website using evidence

What it means

“Slow” needs an observable symptom: a late initial response, content that appears late or a page that remains busy after content arrives. These symptoms can involve different parts of the same page load. A waterfall shows request timing and dependencies; a main-thread trace shows browser work. Together with matching server observations where available, they help turn a broad complaint into a testable explanation.

Try it

Simulation: begin with Time to first byte (ms) at 700 and Post-response rendering (ms) at 250. Change only Post-response rendering (ms) to 900, then inspect the result and explanation. Select Compare with baseline to display the baseline and current outcomes. This is a local teaching example, not a live site check.

The initial result is “Investigate response-path timing first.” The toy timing split is 700 ms response-path versus 250 ms rendering. This comparison does not locate a single root cause. Raising the later interval to 900 ms reverses which interval is larger, so the recommendation switches to investigating browser rendering first.

Keep Time to first byte (ms) at 700 while changing only Post-response rendering (ms). No URL, request, cache state, workload or real system is being observed or changed.

Reset restores Time to first byte (ms) to 700 and Post-response rendering (ms) to 250, clears input errors and removes the baseline comparison. It does not change your independently opened or closed FAQ answers or About this model disclosure.

How it works

A delay affects the next stage only through a dependency. If the browser must wait longer for the initial response, it may also have to wait longer before it can discover resources needed for the page. But an earlier first byte does not guarantee early visible content: a required resource may still be discovered late, take time to load or wait for browser work before it can appear.

Time to first byte describes the interval until the first response byte arrives within the chosen measurement boundaries. That wait can include connection setup, request transit, server work and other waiting; it is not automatically application execution time.

The scene's “Post-response rendering” field is a broad, invented later-stage interval. Real work after the first byte can include further resource loading as well as browser execution. Do not read the label as proof that transfer has finished or that the browser alone caused the delay.

The model discards those details and compares only the two supplied durations. That makes its recommendation useful for practicing where to seek evidence first, but insufficient for choosing a repair. A trace and matching observations must reveal which dependency accounts for the delay.

Worked example

This baseline is synthetic, not a captured production observation.

The comparison establishes that 700 ms is greater than 250 ms, so the result is “Investigate response-path timing first.” The toy timing split is 700 ms response-path versus 250 ms rendering. This comparison does not locate a single root cause.

The useful next question is what accounts for the response-path wait. A slow application response and a delay outside the measured application interval could produce the same two inputs. The scene cannot distinguish them; a browser timing observation correlated with the same request's server timing could help do so. Choosing the longer interval therefore sets an investigation priority, not a diagnosis or a promised saving.

What changes when the condition changes

Change only Post-response rendering (ms) from 250 to 900, keeping Time to first byte (ms) at 700.

The result becomes “Investigate browser rendering first.” The toy timing split is 700 ms response-path versus 900 ms rendering. This comparison does not locate a single root cause.

The recommendation changes because the later interval now exceeds the response-path interval. Nothing in this edit establishes that a script, image or server changed: you changed a teaching input, not a real request.

As a boundary case, entering 500 ms for both fields produces “Both stages deserve evidence.” Equal durations provide no basis for choosing one stage from this comparison alone.

In practice

Start with read-only investigation on a page you own or are authorized to inspect. Use browser developer tools to observe the affected page; access server logs or traces only with the appropriate permission. Do not change configuration as part of this preflight.

1. Define the symptom and scope. Record the exact URL, what appears late, observation time, browser/device, affected audience and cache condition. Investigate that page load, not an unrelated request or a different workload.
2. Locate the interval. Inspect the browser waterfall for the document and relevant resource requests. If content appears late after the response begins, inspect a main-thread trace as well. The expected observation is a timeline showing where the reported wait occurs—not merely a single overall score.
3. Test competing explanations. For a late first byte, correlate the same request with available server timing. For late visible content, examine when its required resource was requested and loaded, and what browser work occurred before display.

STOP before changing DNS, cache policy, application settings or server capacity when the evidence does not support that layer, or when you lack authorization. A long interval is not permission to modify the system.

Verify a hypothesis against the original URL and symptom under comparable conditions. If a later investigation justifies a change, first define its exact scope, preserve the before-state, specify the expected observation and prepare a reversal path. Retest the original symptom afterward; if the expected result does not occur, stop and use the approved rollback rather than stacking speculative changes. This page does not prescribe a platform-specific production fix.

Limits and unknowns

This is a local Simulation of toy request durations and a triage suggestion, not a diagnostic observation of a live site. It makes no network request and accesses no browser trace, server, account or deployment. Its two-number split is not a complete page-load model or an LCP calculation.

Both inputs accept values from 0 to 10000 ms. Empty, nonnumeric or out-of-range input is invalid: the previous calculated outcome is removed, and no outcome applies until you correct the value or use Reset. Valid zero values are teaching inputs, not evidence that a real stage takes no time.

For valid inputs, the model always returns a comparison, including the equal-duration branch. It has no separate computed “unknown” diagnosis: the actual root cause remains unknown because the required observations are absent. The initial result and worked examples remain readable without JavaScript; the interactive controls require JavaScript.

What to carry forward

Choose an observation that can separate competing explanations before choosing a fix. A long browser wait needs evidence about the response path; a late visible element needs evidence about its loading and rendering dependencies. If those observations cannot distinguish the causes, keep the diagnosis unknown rather than changing an unproven layer.