Your site loads in 4.1 seconds. You know this because you've just run PageSpeed Insights after reading a LinkedIn post about Core Web Vitals. What you don't know yet is how much that number is costing you every month.
← Back to InsightsGoogle's research shows that as page load time goes from 1 second to 3 seconds, the probability of a mobile visitor bouncing increases by 32%. From 1 second to 5 seconds, it's 90%. Those aren't soft UX figures. They're the mechanism by which a slow site destroys revenue.
Consider the arithmetic. If your site converts 2% of visitors at a 1-second load time, the same site at 4 seconds converts closer to 1.1%. On 1,000 visitors a month, that's 9 enquiries lost, before a single ad has run or a single SEO article has been written. For a business where one client is worth £5,000, that's £45,000 in annual pipeline gone. Not from a marketing failure. From a technical problem that's fixable.
Most founders see their website as a branding asset. The ones who grow fastest treat it as a conversion machine. The speed at which it loads is part of the machine. When the machine is running slow, leads are leaving before they've even read your headline.
Google has used page speed as a search ranking factor since 2010 for desktop and 2018 for mobile. Core Web Vitals became a confirmed ranking signal in 2021. This means a slow site doesn't just convert worse. It ranks lower, which means fewer visitors in the first place, which means fewer opportunities to convert at whatever rate your page manages.
The compounding effect here is significant and often invisible until someone measures it properly. A site ranking in position 6 instead of position 3, partly because of speed-related signals, receives roughly half the organic clicks. That drop in traffic, multiplied against your already-suppressed conversion rate, is a number worth calculating before you spend another pound on ads or SEO content.
Speed and rank are not separate problems. They're the same problem viewed from two angles.
In practice, the culprits behind poor page speed are consistent across the majority of slow sites. Understanding which one is your primary issue determines whether this is a half-day fix or a rebuild conversation.
Page builders are the most common structural cause. Elementor, Divi, WPBakery and their equivalents generate bloated HTML, load large JavaScript bundles on every page, and apply inline styles that compound with every new section you add. The ceiling for performance on a page builder site is lower than on a custom-coded one. Not because of any single problem, but because of the accumulated weight of the architecture.
Unoptimised images are the most common quick-win fix. Full-size JPEGs loaded at mobile viewport sizes, images with no compression, no lazy-loading, no next-gen formats. These are often responsible for 30–50% of total page weight on sites where nobody has touched the media library since launch.
Beyond those two: too many plugins each adding their own JavaScript to every page load, render-blocking scripts loaded in the page head before content renders, and shared hosting that throttles resource allocation under any real traffic. Most of these are addressable without a full rebuild. But you need to know which ones apply to your site before you start.
Run your site through Google PageSpeed Insights. Use your homepage URL and your highest-traffic landing page if they're different. Focus on the mobile score. That's the one Google weights in its ranking algorithm. Desktop performance matters, but mobile is the number to fix first.
The scoring bands are straightforward. Under 50 is poor. 50–89 needs improvement. 90 and above is good. Most UK startup sites we audit for the first time score between 35 and 65 on mobile. A custom-built site on quality hosting should be scoring 85 or above without significant optimisation effort.
Once you have your score, scroll to the Diagnostics section. The top 3–5 items are your priority. "Serve images in next-gen formats" and "Properly size images" are usually quick wins that any competent developer can address in a short session. "Reduce unused JavaScript" and "Eliminate render-blocking resources" typically require a developer, and on a page builder site they may indicate that the structural problem runs deeper than a patch can fix.
Compressing and converting images to WebP makes a measurable difference on almost every site. This alone can cut 20–40% off page weight. Pair it with lazy-loading for below-the-fold images and you've addressed one of the most common performance drains without touching a line of code.
Removing unused plugins is underestimated. Every active plugin has the potential to add HTTP requests, database queries and JavaScript to your page load, even on pages where it does nothing. Auditing and removing plugins you no longer need can shave 0.5–1 second on its own.
Hosting is frequently the single biggest performance variable on a slow site. Shared US-based hosting, the kind that costs £3 a month and hosts 2,000 other sites on the same server, is responsible for chronically poor Time to First Byte (TTFB) scores. Moving to quality managed UK hosting with dedicated resources is often the change that moves a site from a 45 to a 70 before any code has been touched.
For a site where speed is persistently poor and the underlying architecture is a page builder, patching is the wrong strategy. A custom-coded WordPress theme removes the structural cause rather than managing the symptoms. There's no plugin that compensates for the overhead of a page builder at scale. A rebuild is a one-time cost that pays back in every month of improved rankings and conversion rates that follows.
The sites we build at Mode score 90+ on mobile PageSpeed Insights at launch. Not because we run optimisation sprints after the fact. Because the architecture doesn't create the problem in the first place.
Mode builds on custom WordPress themes, UK-managed hosting, optimised from day one. No page builders, no speed ceiling.
FIX YOUR SITE SPEED