Page speed and conversion rate. What to fix first, and what it is worth.

The short answer. The first few seconds do most of the damage.

Page speed and conversion rate are directly linked, and the relationship is front-loaded: the biggest losses happen in the first few seconds of load time, not spread evenly across a slow page. Portent's analysis of more than 100,000 landing pages found conversion rates fall by an average of 4.42 percent with each additional second of load time between zero and five seconds. A page that loads in one second is converting meaningfully better than the same page loading in four or five, and the gap widens fastest right at the start, which is also where most sites are weakest, on the very first render a visitor sees.

This is a narrower, more technical question than conversion rate optimisation generally. Our wider guide to conversion rate optimisation strategies covers page speed as one factor among several, persuasion copy, social proof, form design and testing discipline. This piece stays entirely on speed: the specific metrics Google measures, what typically causes them to fail on a marketing or landing page, and what to fix first when the budget or the developer time is limited.

Speed is worth treating as its own workstream because, unlike most conversion levers, it does not require a testing programme to prove out. A page either loads inside Google's thresholds or it does not, and the fix, once diagnosed, is usually mechanical rather than a matter of opinion or ongoing experimentation.

How it works in practice. The three metrics, and what actually breaks them.

Google's Core Web Vitals give page speed a specific, testable definition rather than a vague sense that a site "feels slow." Three metrics make up the set, and each one maps to a different kind of visitor frustration.

Largest Contentful Paint is usually the one worth fixing first, because it is the metric a visitor consciously experiences as "is this page loading." On a typical landing page, LCP fails for one of three reasons: an unoptimised hero image served at full resolution rather than resized and compressed for the device requesting it, render-blocking CSS or JavaScript loaded and executed before anything visible appears, or a slow server response time from cheap or oversold hosting. Any one of these three can push LCP well past the four-second poor threshold on its own, and pages frequently have more than one problem stacked together.

Interaction to Next Paint, which replaced First Input Delay as a Core Web Vital in March 2024, measures how long the page takes to visibly respond once a visitor actually tries to use it, clicking a button, opening a menu, typing into a form field. A lagging response on the first genuine interaction reads as broken to someone mid-conversion, and poor INP on a landing page is disproportionately caused by heavy third-party scripts, chat widgets, tracking pixels, embedded video players, that a team added once and never audited again.

Cumulative Layout Shift tracks how much content visibly jumps around as a page finishes loading, an image pushing text down after it appears, or a cookie banner shifting a call-to-action button just as someone was about to tap it. It is the least dramatic of the three metrics and the one most likely to directly cost a click, since a visitor aiming for a button that then moves either mis-taps or gives up.

What good looks like. A worked example.

A UK B2B software client's primary demo-request landing page was scoring a Largest Contentful Paint of 4.8 seconds on mobile, comfortably in Google's poor range, and the page's own analytics showed a bounce rate on mobile traffic that was noticeably higher than desktop, on the same page with the same offer. Diagnosis found two compounding causes: a full-resolution hero photograph, several megabytes as served, being resized down by the browser rather than served at the correct size in the first place, and a third-party live chat widget loading and executing before the page's own content rendered, blocking the browser from painting anything visible until the widget's script had finished.

The fix did not need a rebuild. The hero image was compressed and served at the actual display size with a modern format, and the chat widget was set to load after the page's main content rather than before it, deferred rather than removed, since the client still wanted it available once the page had loaded. LCP on mobile fell from 4.8 seconds to just under 2 seconds, into Google's good range, and mobile bounce rate on the page dropped to within a few points of desktop within the following month, closing a gap that had existed since the page launched.

My rule on page speed with every client: audit the largest single image and every third-party script on a page before touching anything else. Between the two, they account for most of the poor Core Web Vitals scores I see on marketing pages, and both are usually fixable in hours rather than the weeks a full rebuild would take.

Pitfalls to avoid. Where page speed work quietly stalls.

The first pitfall is testing on a fast office connection and desktop, then publishing without checking mobile on a realistic connection speed. Google's own ranking and Core Web Vitals data is weighted toward real-world mobile performance, and a page that scores well on a developer's desktop can fail badly on the mid-range phone and patchy connection a real visitor is actually using.

The second is treating a one-off PageSpeed Insights or GTmetrix score as a fixed fact rather than a snapshot. Adding a new tracking pixel, a chat widget or a marketing script months after a page launches is exactly how a previously fast page quietly drifts back into poor territory, unnoticed until conversion rate has already fallen.

The third is fixing Largest Contentful Paint and stopping there, ignoring Interaction to Next Paint and Cumulative Layout Shift because the page now "looks" fast on first load. A visitor who lands on a fast-rendering page and then taps a button that lags, or a form that jumps as they are about to submit it, still leaves, just later in the journey than a slow LCP would have lost them.

The fourth is chasing a perfect Core Web Vitals score as an end in itself, rather than as a lever on conversion. Once a page is comfortably inside Google's good thresholds, the marginal conversion gain from squeezing out another few hundred milliseconds is usually smaller than the gain available from fixing a genuine persuasion or form problem elsewhere on the same page, covered in the wider conversion rate optimisation strategies guide.

The fifth is assuming a page speed fix is permanent because it was done once properly. Hosting changes, plugin or script updates, and new marketing tags added by other teams all erode Core Web Vitals scores over time without anyone deciding to make the page slower on purpose. A page worth real traffic is worth checking on a quarterly cadence, not a launch-day one.