How Improving WordPress Speed Increases Your Revenue

Website speed is one of the few things you can change on a WordPress site that has a measurable, published effect on money. Not a plausible one, a measured one. The trouble is that most advice on the subject is a list of plugins, and most of the statistics quoted alongside it are more than a decade old.

This article does two things. It sets out what the evidence actually says about speed and revenue, with sources you can check. And it explains which numbers matter in 2026, because the metrics changed and a great deal of published advice, including the earlier version of this article, has not kept up.

First, The Metric Most Guides Still Get Wrong

If you have read anything about WordPress speed in the last few years, you have probably been told to optimise First Input Delay. Do not. FID stopped being a Core Web Vital on 12 March 2024, when Google replaced it with Interaction to Next Paint, and it was removed from Google's tooling altogether on 9 September 2024.

This matters more than a change of name. FID only measured the delay before the browser began responding to the first interaction, which made it easy to pass: around 95% of sites did. INP measures the full time from interaction to the next visual update, across every interaction on the page. Sites that comfortably passed FID routinely fail INP, and the fixes are different. FID was largely about not blocking the main thread early; INP is about how much JavaScript runs every time somebody clicks anything.

The same applies to Time to Interactive, which Lighthouse dropped in version 10. If a guide is still built around FID and TTI, it predates the current standard regardless of what date is printed on it.

What "Fast" Means In 2026

Three metrics are Core Web Vitals. The rest are diagnostics that help you work out why a Core Web Vital is failing.

One detail that trips people up: these are assessed at the 75th percentile of real visits, not the average. Three quarters of your traffic has to clear the bar. An average of 2.4 seconds can still be a failing LCP if the slow quarter of your visitors is slow enough, which is why a perfect score in a lab test does not guarantee a pass.

How Website Speed Changes Visitor Behaviour

Before revenue, behaviour. People do not consciously decide a site is slow; they simply leave, and they rarely attribute it to speed afterwards.

• Around 53% of mobile visits are abandoned when a page takes longer than three seconds to load.
• Portent found sites loading in 1 second convert roughly three times better than sites loading in 5 seconds, with conversion rates falling about 4.42% for each additional second across the first five.
• Slow pages compound: a visitor who waits once is less likely to click through to a second page, so the damage is not limited to the landing page.

The important nuance is that the biggest gains are at the fast end. Going from 5 seconds to 4 saves a little. Going from 2 seconds to 1 is where the conversion curve is steepest, which is the opposite of most people's intuition that a site is "fast enough" once it stops feeling broken.

What The Revenue Evidence Actually Shows

Two studies are worth more than the dozens of recycled statistics in circulation, because both are large and both are published.

Deloitte and Google, "Milliseconds Make Millions." Across 37 brands and 30 million user sessions, a 0.1 second improvement in mobile site speed produced:

• +8.4% retail conversions, with average order value up 9.2%
• +10.1% travel conversions, with average order value up 1.9%
• +8.6% page views per session for luxury brands

One tenth of a second. That is the part people find hard to believe, and it is why speed work is worth doing even when a site does not feel slow.

Vodafone. A single controlled improvement of 31% in LCP produced 8% more sales, an 11% better cart-to-visit rate and a 15% better lead-to-visit rate. This one matters because it is a straight before-and-after on one large commercial site rather than a correlation across many.

Work Out What A Second Is Worth To You

Borrowed statistics justify the project. Your own numbers decide whether it is worth doing. The calculation is simple enough to do on paper:

1. Take your monthly revenue from the site.
2. Apply a deliberately conservative uplift for the improvement you expect. If you are cutting a full second, the published data supports far more than 1%, so use 1% and you are almost certainly understating it.
3. Multiply by twelve.

A store turning over £40,000 a month at a conservative 1% uplift is £4,800 a year, recurring, from work that is mostly done once. Against that, weigh the cost of better hosting and a day of an engineer's time. For most commercial sites the arithmetic is not close, and it improves every year the site keeps running.

This also tells you when not to bother. A brochure site with 300 visits a month and no transactions will not see meaningful revenue from shaving 400ms. Fix it because it is cheap and it helps SEO, not because it will pay for itself.

The Fixes That Actually Move The Numbers

In order of how much they typically return for the effort involved.

1. Server response time, which sets the ceiling

TTFB is the floor under every other metric. If your server takes 900ms to answer, your LCP cannot be better than 900ms no matter what you do to the front end, and you have spent more than a third of your 2.5 second budget before a single byte of content has rendered. This is the one item on the list you cannot fix with a plugin, and it is why managed WordPress hosting with server-level caching usually produces a bigger jump than any amount of front-end tuning.

2. Images, which are usually the LCP element

On most WordPress sites the Largest Contentful Paint element is the hero image, so image weight is your LCP. Serve WebP or AVIF, size images to their display size rather than uploading straight from a camera, set explicit width and height so the layout does not shift, and load the hero eagerly while lazy loading everything below the fold. Lazy loading the hero image is a common and self-defeating mistake: it delays the exact element you are measured on.

3. JavaScript, which is what INP measures

This is where the metric change bites. Every plugin that runs code on interaction adds to INP, and the worst offenders are sliders, chat widgets, popup builders, heat-map trackers and anything doing analytics on scroll. Audit what runs on click, defer what is not needed for the first interaction, and remove plugins that load their assets on every page whether or not the page uses them.

4. Caching, at every layer

Page caching serves a prebuilt HTML file instead of rebuilding it per visit. Object caching stores expensive database results. Browser caching stops returning visitors refetching what they already have. Together they are the difference between a site that survives a traffic spike and one that falls over, which is covered further in our guide to hosting high-traffic WordPress sites.

5. A CDN, if your visitors are spread out

Distance costs milliseconds that no code change recovers. A CDN serves static files from a location near the visitor, cutting both TTFB and LCP. If your server is in London and a third of your traffic is American, this is likely your single biggest available win, and moving the origin itself to US-based WordPress hosting beats any amount of caching in front of a distant server.

6. The theme and the plugin count

Multipurpose themes ship code for features you will never enable. Every active plugin is code that has to load, and a handful of well-chosen plugins beat thirty that mostly overlap. Deactivating is not enough; delete what you are not using.

Measuring It Properly

The distinction that matters is lab data versus field data, and getting it wrong is why people optimise for months without moving the needle.

Lab data comes from a simulated load on a simulated device: Lighthouse, GTmetrix, WebPageTest. It is repeatable, which makes it excellent for diagnosis and for comparing two versions of a page. It is not what Google uses to assess your site.

Field data is the Chrome UX Report: real Core Web Vitals from real Chrome visitors over a rolling 28 day window. This is what Search Console reports and what counts as a ranking signal. It is also why nothing appears to happen for a month after you fix something, and why people give up too early.

A workable routine: diagnose in PageSpeed Insights, which shows both at once, fix one thing, then watch the Core Web Vitals report in Search Console over the following four weeks. Record your conversion rate before you start, or you will have no way of proving the work paid for itself.