Website Slow After Deployment? A Debugging Checklist

Your uptime check is green, but the page feels slower since the last deploy, and the new Lighthouse report agrees. Before you dig through the diff, find out what actually changed in the browser.

The last commit is the obvious suspect, and it may well be guilty. But a cold cache, a slow third-party script or a different test setup can also make a page look slower, and Lighthouse plus Chrome DevTools are enough to tell these apart. If real users are hurting right now, roll back first, keep the reports and come back to this afterward.

1. Make sure the slowdown is real

Lighthouse scores move between runs even when nothing changed. Chrome’s docs list the common reasons, from A/B tests and ads to browser extensions and testing on a different computer.

So make sure the two tests ran the same way. Keep the full reports (a screenshot of the score won’t show which metric moved), and note for both runs:

• the URL and page state: logged in or not, cookie consent, feature flags
• mobile or desktop, viewport, network and CPU throttling
• the Chrome and Lighthouse versions
• the release or commit, and when it went out
• whether the browser cache was cold, and whether the CDN cache might still be warming up

If you didn’t save a report before the deploy, make one now by running the previous build in the same environment with the same settings. The score you remember from last week doesn’t count.

Then run each version a few times and look at the spread. If the new runs overlap with the old ones, you may not have a regression at all.

2. Find the metric that moved

Skip the overall score for now and look at the metrics under it. You need to know which one got worse before you can look for a cause. (If the acronyms are new to you, I explained what each one measures in another post.)

What got worse	Where to look first
The HTML arrives later (higher TTFB)	Redirects, connection setup, caching, server response time
The first text or image appears later (higher FCP)	Stylesheets and scripts in the <head>, web fonts that hide text
The main content shows up later (higher LCP)	The LCP element and whatever delays it
The main thread is blocked longer (higher TBT)	Long tasks and the scripts running them
More content jumps around (higher CLS)	Images without reserved space, inserted content, font swaps
A click or tap responds slowly (higher INP)	Real-user INP data, then the same interaction in the DevTools Performance panel

Pick the row that matches what you can actually reproduce. For the last one, the standard Lighthouse test is only a rough guide: it reports TBT while the page loads, but it doesn’t click anything. Google explains how lab and field INP differ.

3. If LCP went up, find which part got slower

First check that the LCP element is still the same one. A layout change can make a different image or heading the biggest thing on screen, and then you’re comparing two different elements.

For an image, LCP splits into four parts:

• Time to first byte: how long until the HTML starts arriving
• Load delay: how long until the browser starts downloading the image
• Load duration: how long the download takes
• Render delay: how long from the finished download to the image on screen

Each part points somewhere different. Say the release moved the hero image from the HTML into a JavaScript component. The file is the same, but the browser finds it later, so load delay grows. If the download itself takes longer, check the image size and what else is downloading at the same time. If the image arrives on time but appears late, look at rendering and main-thread work.

Several parts can grow at once, so shrinking the image won’t help much if a script is still holding up the paint. A text LCP has no file to download, so its load delay and load duration can be zero. Google’s guide to optimizing LCP goes through each part.

4. Compare the requests

Open the Network panel on the old and new versions and look for what changed:

• a bigger image served to the same screen size
• a script or stylesheet that now loads before the main content
• a new redirect on the page or on an important file
• a file that used to be cached and isn’t anymore
• a slow third-party request, even if your deploy didn’t touch it

For each suspect, check what started the request (the Initiator column) and its timing. The file that grew the most isn’t always the one slowing the page down, so check whether the page actually waits for it. A big script that runs after the LCP image is already on screen won’t change LCP, while a small stylesheet in the <head> can hold back the first paint.

The waterfall only shows downloads. If the delay comes from work in the browser itself, switch to the Performance panel and look for long tasks.

5. Test your suspect

By now you probably have a suspect. Before you call it the cause, test it somewhere safe, one change at a time: put back the old image or turn off the new third-party script, then measure again with the same settings. If the metric recovers, that’s strong evidence you found it. If you change three things at once and the numbers improve, you won’t know which one did it.

Make the next one easier

All of this goes faster with a baseline. For the pages that matter, save a report for each release, with the test settings and the release ID next to the numbers. Keep mobile and desktop results separate, and give a deploy enough time to go live before you test it.

This is the part PulseCare automates. Your CI calls its deploy hook, and after a delay you set, PulseCare runs the checks you picked and compares each one with the last successful scan of the same kind on that monitor. The first run has nothing to compare with, so it just sets the baseline. Keep in mind the baseline is simply the last scan that finished, so it doesn’t mean the page was fast back then. The comparison shows what changed, and finding the exact line of code is still up to you; the LCP breakdowns and request waterfall help with that. Deploy regression monitoring starts on the Growth plan.