Website Slow After Deployment? A Debugging Checklist

The deployment finished. Your uptime check is green. But the page feels slower, and the latest Lighthouse report looks worse than the previous one.

It is tempting to start with the most recent code change. That is a useful suspect, but you still need to establish what changed in the browser. A cold cache, a third-party request or a different test setup can make the comparison misleading.

If your website is slow after deployment, start by reproducing the change under comparable conditions. Then follow the slower metric into the network requests or browser work behind it. This checklist walks through that process using Lighthouse and Chrome DevTools; the last section explains which parts PulseCare can automate.

1. Check that the before and after tests are comparable

Keep the original reports. A pair of screenshots showing different performance scores will not tell you much about the requests, settings or timing behind them.

For a useful comparison, record:

• The page and its state: URL, authentication, consent choices and any feature flags that affect what loads.
• The test setup: mobile or desktop, viewport, network and CPU throttling, browser and Lighthouse version.
• The release: deployment time and commit or version, if available.
• The cache state: whether both runs started with a cold browser cache, and whether a CDN cache may still be warming.

Repeat the test with the same settings and look at the spread of results. One slow run deserves investigation; it does not establish that the release introduced a regression. Chrome’s documentation describes several sources of Lighthouse score variability, including the device and network environment.

If you have no saved report from before the deployment, say so. You can investigate the current page or compare with a previous build in a comparable environment, but you cannot reconstruct a measured baseline from memory.

2. Find the metric that moved

Open the individual measurements before working through the audit list. A lower Lighthouse performance score is a starting point, not a diagnosis.

What changed?	Where to start looking
The HTML takes longer to arrive	Redirects, connection setup, caching and server response time
The main content appears later: higher LCP	The LCP element and the requests or rendering work delaying it
The main thread spends longer blocked: higher TBT	Long tasks and the scripts doing the work
Content moves more while loading: higher CLS	Images without reserved space, inserted content and font changes

Pick the change that best matches the problem you can reproduce. A slow initial page load and a slow response to a button click need different investigations, even when they happen on the same page.

Lighthouse navigation tests report Total Blocking Time (TBT). They do not measure a visitor’s full session of interactions. For a responsiveness problem, use real-user INP data when available and reproduce the affected interaction in DevTools. Google explains how INP testing in the lab differs from field measurement; TBT is useful context, but it is not a replacement for INP.

3. If LCP increased, inspect the element and its timing

First check whether the LCP element is still the same. A layout change can make a different image or text block the largest visible element. Comparing only the totals can hide that change.

For an image-based LCP, follow the HTML request, the image request and the moment the image is painted:

• Time to first byte: how long before the HTML response begins arriving?
• Resource load delay: how long before the browser starts fetching the LCP image?
• Resource load duration: how long does that image take to download?
• Element render delay: after the resource is available, how long before the element is painted?

These intervals help you choose a place to investigate. If a release moved a hero image from the initial HTML into JavaScript, check when the request starts. If the request starts promptly but downloads for longer, inspect its size, delivery and competing requests. If it finishes early but appears late, inspect rendering and main-thread work.

More than one interval can matter. An image optimization may leave the total unchanged if script execution still prevents the element from appearing. Text-based LCP can also have zero resource load delay and duration when no separate resource is needed. Google’s guide to optimizing LCP explains the breakdown and these dependencies.

4. Compare the requests, not just the audit scores

In the Network panel, look for differences that appeared around the release:

• A larger image served to the same viewport.
• A script or stylesheet that now loads before the main content.
• An extra redirect on the document or a critical resource.
• A request that stopped being cached.
• A third-party resource that is slow even though your own deployment did not change it.

For a suspect request, check its initiator and timing. The file that grew largest is not necessarily the one delaying the page. What matters is whether it sits on the path to the content or interaction you are investigating.

Use the Performance panel when the delay is in browser work rather than a download. A network waterfall alone will not explain every long task or delayed paint.

5. Test the suspected cause

A slowdown measured after a deployment is associated with that deployment. It does not, by itself, prove which change caused it.

Try a focused change in a safe environment: restore the previous image, disable the new third-party script or compare the relevant builds with matching settings. Repeat the measurement. If the metric recovers, you have stronger evidence for that explanation.

For an incident affecting users, your recovery procedure may take priority over a complete diagnosis. Preserve the reports so the investigation can continue after recovery. Avoid combining unrelated optimizations in one test; otherwise, you will not know which change helped.

Make the next deployment easier to compare

Save a baseline for the pages that matter and associate later checks with release identifiers. Keep mobile and desktop results separate. Record the test settings alongside the measurements, and leave enough time after deployment for the version you intend to test to be available.

PulseCare’s deploy regression monitoring connects this comparison to a CI hook. After a configurable delay, it runs the selected checks and compares them with the most recent successfully completed scan for the monitor and check type. The first run may establish a baseline rather than produce a comparison.

“Successfully completed” describes the scan, not a guarantee that the page was fast or free of problems. The comparison helps identify what deserves investigation; it does not prove the responsible line of code. PulseCare also provides LCP breakdowns and a request waterfall to help with that investigation.

Deploy regression monitoring is available on Growth. Check the current PulseCare plans for limits, or create a PulseCare account to evaluate it on one project.

Start with one important page and a saved report. When the next release lands, you will have something concrete to compare.