Site speed and a conversion rate drop: how to find the change that slowed you down

Can a slower website cause a conversion rate drop?

Yes, but a slower site is only the cause when the slowdown started before the drop and hit the pages and devices where conversions fell. Speed problems rarely arrive alone: the release that made pages heavier often also changed the layout, the form or the tracking.

Speed matters because visitors who wait for the main content, or tap a button and see nothing happen, leave before they reach the checkout or the lead form. Google measures those moments with three Core Web Vitals: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability.

This article does not promise a number of lost sales per second of delay. Published figures vary by site and often come from vendor studies. What you can do is show, with your own data, that a dated change made pages slower and that conversions fell on the same pages at the same time. For the general method behind any drop, see how to explain a conversion drop to a client.

Which changes usually make a site slower?

Most speed regressions come from a change someone shipped, not from Google or the hosting provider. The usual suspects are new scripts, heavier media and code releases.

Google's guidance on tags says main-thread time is spent "evaluating and executing JavaScript contained within the tag manager and the tags", and its authors report a correlation between the size of tag managers and poorer INP. Duplicate tags, such as a pixel hardcoded in the HTML and injected again through GTM, add weight without adding data. If you suspect a tag, start with GTM version history.

How do I check whether the site actually got slower?

Compare field data from real users before and after the suspected change, then use lab tests only to find the cause. A single Lighthouse score is not proof: Google notes that lab results vary between runs because of network availability, hardware and resource contention.

Google assesses each metric at the 75th percentile of page views. Three tools cover most cases:

• PageSpeed Insights shows field data from the Chrome UX Report for the previous 28 days, at URL level or, when a URL lacks data, at origin level, plus a Lighthouse lab test.
• The Search Console Core Web Vitals report groups similar URLs and shows how many are good, need improvement or poor over the last 28 days. Groups without enough data are left out.
• Your own real-user monitoring, if you have it, is the only source that shows a daily jump on the day of a release.

The 28-day window matters for dating. Because PageSpeed Insights aggregates the previous 28 days every day, a slowdown that started on a Tuesday appears as a gradual climb over the following weeks, not a step. Read the date where the line starts to bend, then confirm it with lab tests of the old and the new version of the page.

How do I isolate which change caused the slowdown and the drop?

Put every change from the week before the drop on one timeline, rule out tracking first, then test the speed hypothesis on the pages that got slower. A drop in measured conversions can also come from a broken tag, so check that the conversion tag still fires on the new version before you blame speed.

1. Write down the day conversions fell and where it happened: mobile checkout, one landing page or the whole site.
2. List every change in the 7 to 14 days before: site releases, theme or plugin updates, GTM versions, new scripts and consent changes, plus ad edits such as bids, budgets and final URLs.
3. Mark which changes touched the pages that fell. A new script on every page and a drop only on mobile checkout point to mobile responsiveness.
4. Test the old and new versions of the page in the lab and look for the script or asset that adds the most time.

Example: an online furniture shop asks why mobile sales fell on Tuesday while desktop held. Lining up the changes shows a live chat tag added in GTM on Friday, a new hero video on the product pages on Saturday and no ad edits. Lab tests of the product page show the video is now the LCP element and loads far later than the old image. The team swaps the video for a poster image and mobile sales recover the next week. Names and numbers are illustrative.

With every change on one timeline, you would see the hero video went live three days before the drop, on the same template where mobile sales fell. In Changeline you can log each release, tag and consent change with date, owner and reason, and import Google Ads edits automatically, so the list in step 2 already exists when the question comes.

How do I prove the slowdown, not something else, cut conversions?

You prove it by showing that three things line up: the slowdown started with the change, conversions fell on the affected pages and devices only, and they recovered when the change was reverted or fixed.

1. Confirm tracking still fires
2. Date the slowdown in field data
3. Compare affected and other pages
4. Revert or fix the change
5. Watch conversions recover

• Segment by device and page. If desktop conversion rate held, mobile fell and the regression is mostly on mobile, that is evidence. A drop on every device and page points elsewhere.
• Check the traffic mix. A new campaign, audience or budget can bring colder visitors on the same day. Look at conversion rate by source before you credit speed. See why a conversion rate drops for the other causes.
• Use a control. Pages that did not get the new script or asset are your control group. If they held steady, the change is the likelier cause.
• Revert and watch. Removing the script or rolling back the release is the cleanest test. Log the revert as its own change so the recovery is dated too.

Keep the evidence in writing: the change, the date, the before and after lab measurements, and the conversion rate on affected and unaffected pages. That is what a client or a manager will ask for, and it stops the same debate from starting again a month later.

How do I stop speed regressions from coming back?

Make speed part of every release and every new tag, and keep a record of what went live when. Most regressions come back because a script is added again or nobody remembers why it was removed.

Google recommends pausing or removing unused tags rather than blocking them with a trigger exception, because a blocked tag still ships its code in the container. A shared marketing change log gives developers and marketers one record to check, and a website change log covers the site side in more detail.