Why Your PageSpeed Score Is Costing You Customers

If your website scores below 70 on Google PageSpeed Insights, you are losing customers before they've read a single word. They landed on your page, waited two or three seconds for something to appear, and left. They didn't bounce because your offer was wrong or your prices were high - they left because your site was slow.

This isn't speculation. Google has published the data, and it's not subtle. Here's what's actually happening, why it matters more than most business owners realise, and what you can do about it.

What PageSpeed Insights actually measures

The score you see at pagespeed.web.dev isn't just a speed rating - it's a composite of Google's Core Web Vitals, which are the specific performance signals Google uses to evaluate user experience. There are three that matter most:

These aren't abstract technical metrics. Each one maps directly to a moment of user frustration that makes a potential customer more likely to leave.

The real-world cost of a slow site

Google's own research found that 53% of mobile visits are abandoned if a page takes longer than 3 seconds to load. More than half. And when they improved a site's load time from 10 seconds to 1 second, mobile sessions increased by 70%.

Let's translate that into something more concrete. Say a dental clinic gets 300 website visits per month - a reasonable number for a suburban practice with some local SEO in place. If 30% of those visitors abandon due to load time, that's 90 people who never saw the booking button, never read about the services, never decided to call. At a 5% conversion rate on the visitors who do stay, that's 4–5 fewer enquiries per month.

At an average patient lifetime value of $2,000, those 4–5 missed enquiries represent $8,000–$10,000 in missed revenue. Every month. From one fixable technical problem.

And that's before accounting for the SEO impact. Page speed is a direct Google ranking factor. A slow site ranks lower than a fast one, all else being equal - which means the 300 visits per month might actually be far fewer because the slow site isn't ranking in the first place.

Why WordPress and Squarespace sites score poorly

This isn't a knock on these platforms for every use case - but performance is their consistent weakness, and it's structural.

A standard Squarespace site loads 400–600KB of JavaScript before showing anything. That JavaScript powers the editor, the template system, the ecommerce functionality, the form handlers - everything the platform needs to work as a product, regardless of whether your specific page uses any of it. The visitor's browser downloads all of it anyway.

WordPress compounds this with plugins. Every plugin you install adds its own scripts and stylesheets to every page load - whether that page needs the plugin's functionality or not. A contact form plugin, a booking widget, a gallery, an SEO plugin, a caching plugin, a security plugin - each one contributing to a growing pile of code that the browser has to process before anything appears on screen. WordPress sites with ten or more active plugins routinely score 30–55 on PageSpeed mobile.

A hand-coded site loads exactly what the page needs - nothing more. No platform overhead, no plugin accumulation, no theme framework. Just the HTML, CSS, and JavaScript written specifically for that page. For a full breakdown of how custom-coded sites compare to WordPress, Squarespace, Wix, and Webflow, see our complete guide to custom websites vs website builders in Australia.

PageSpeed benchmarks by platform

Here's what we typically see when testing mobile PageSpeed scores across different website platforms. These are real-world ranges, not lab conditions.

Scores based on Google PageSpeed Insights mobile tests. Ranges reflect typical small business sites on each platform, not best-case configurations. Tested March 2026.

What a 90+ score looks like in practice

Our client Serene Family Dental came to us with a site scoring 45 on PageSpeed mobile. Their previous site took approximately 3.2 seconds to load on mobile - above the threshold where more than half of visitors would typically abandon.

We rebuilt it from scratch - hand-coded HTML and CSS, no WordPress, no plugins, no page builder. Images converted to WebP format and compressed before upload. JavaScript loaded only where needed. The rebuilt site hit 91 on PageSpeed mobile and loads in under one second.

The difference isn't magic - it's just the absence of unnecessary overhead. When you don't have a platform trying to serve every possible use case, you're left with a site that serves exactly one: yours. We wrote a detailed case study on the Serene rebuild covering the full before-and-after, including what we changed and why.

How to check your own score right now

Go to pagespeed.web.dev and enter your URL. Run it. When the results load, switch to the Mobile tab - that's the score that matters most, because that's where the majority of your customers are finding you.

Here's how to read what you're looking at:

What affects PageSpeed most - and what you can fix

Not all performance problems are equal. Some are structural - the way the site is built - and can only be fixed by a rebuild. Others are fixable without touching the code. Here are the most impactful factors, in rough order of how much they affect scores:

Image format and compression

Images are the single biggest contributor to slow load times for most business websites. If your site is serving JPGs or PNGs that haven't been compressed, you're likely sending 2–5x more data than necessary. The fix: convert to WebP format (smaller file size, same quality) and compress before uploading. An image that was 1.5MB as a JPG might be 180KB as an optimised WebP - a massive difference on mobile.

Image dimensions - serving the right size

A common mistake: uploading a 3,000px wide image and displaying it at 400px wide. The browser downloads the full 3,000px image and then scales it down - wasting bandwidth and time. Images should be sized close to their display dimensions before upload, and ideally served at different sizes depending on the visitor's screen using the srcset attribute.

Render-blocking scripts

When a browser encounters a <script> tag without async or defer attributes, it stops rendering the page until that script is downloaded and executed. Chat widgets, analytics, cookie banners, tracking pixels - every one of these that loads synchronously adds to the time before a visitor sees anything. Loading them with defer means the page renders first and the scripts load after - a significant improvement in perceived speed.

Unused CSS and JavaScript

WordPress themes and page builders load their full CSS library on every page - including styles for elements that page doesn't use. A home page might use 8% of the theme's CSS. The other 92% is dead weight the browser still has to download and process. Hand-coded sites only include the CSS that's actually needed on each specific page.

Server response time and hosting

Everything above assumes the server is responding quickly in the first place. Cheap shared hosting can add 0.5–2 seconds to every page load before the browser has received a single byte. For static HTML sites - no PHP, no database queries - Cloudflare Pages is free and delivers pages from servers close to your visitor's location, typically with response times under 50 milliseconds globally. That's a meaningful starting advantage.

---