Your Website's Speed Score Isn't Your Developer's Fault

At some point someone will check your website's PageSpeed score and not be happy about it. Maybe it's you. Maybe it's a competitor trying to sell you something. Maybe it's a brief that demands 90+ on mobile.

The instinct is to blame the developer. Sometimes that's fair. A bloated theme, uncompressed images or lazy coding will drag a score down, and that's on whoever built the site.

But often the biggest drag on a PageSpeed score has nothing to do with the developer at all.

What PageSpeed Insights actually measures

Google PageSpeed Insights scores your site from 0 to 100, separately for mobile and desktop. The mobile score is almost always the lower of the two.

The reason is that Google simulates a mid-range phone on a slow 4G connection. Not a flagship phone on wifi. A mid-range device with limited processing power and a slower network. That's deliberate, because it reflects how most people actually browse.

The score looks at things like how quickly the page becomes visible, how quickly it becomes usable, and how much the layout shifts while it's loading. All reasonable things to care about. But the important detail is that it measures everything on the page, including things the developer didn't put there.

The bit that trips people up

Here's where a lot of briefs go wrong. People assume the PageSpeed score is what Google ranks you on. It isn't.

The score you see in the test is lab data. It's a simulation, run once, on a pretend phone. What Google actually uses for rankings is real-world data from people who visit your site on their own devices and connections. That's a different number, and it can look nothing like the lab score.

On top of that, this real-world performance acts as a tie-breaker rather than a main ingredient. It nudges things between two sites that are otherwise neck and neck. It doesn't override good content. So a site can score 50 in the test and still rank perfectly well if real visitors are having a decent experience.

Worth keeping in mind before anyone sets a number in a brief. Chasing a high lab score isn't the same as chasing better rankings, and the two can pull in different directions.

The third-party script problem

Every business website has third-party scripts. These are bits of code that load from someone else's servers to provide a specific feature.

Google Analytics is one. Google Tag Manager is another. Then there's your booking widget. Your live chat tool. Your Trustpilot or Google Reviews badge. Your cookie banner. Your social media embeds. Your Facebook Pixel if you're running ads.

Each one loads external code from servers your developer doesn't control. They can't optimise that code. They can't control how fast those servers respond. And they can't stop those scripts from slowing the page down or shifting the layout about.

A site that scores 95 before any of these are added might score 55 once the business tools are in place. That's a big drop, and the developer hasn't touched a single line of their own code.

How to check what's realistic

Here's something worth doing before you set a target or brief an agency.

Go to pagespeed.web.dev. Paste in the URLs of your three closest competitors. Look at the mobile scores.

Those businesses are running the same kinds of tools you'll be running. Similar booking widgets, similar analytics, similar trust badges. Their scores tell you what's realistically achievable in your market with the same overhead.

If the best competitor in your sector sits in the mid-50s on mobile and your brief demands 90+, that's a gap worth understanding before anyone starts building. It's not that 90 is impossible. It's that nobody in your market is hitting it, and the reason is the third-party scripts, not the developers.

Where the platform choice matters

The starting point matters more than most people realise. A heavyweight setup with plugin overhead puts you in a deeper hole before the third-party scripts even load. A lighter platform gives you more room to work with.

Take WordPress. Most sites built on a classic theme load jQuery by default, and plenty of plugins pull it in too. Many setups also load block editor styling whether you're using blocks or not. And WordPress fires off a background task on page loads to handle its scheduled jobs. All of this adds weight before a single line of your project code runs.

The CMS we've built takes a different approach. No jQuery on the frontend. No block editor assets. Tailwind CSS compiled so that only the classes you actually use get shipped. The page output is the markup you wrote, one compiled CSS bundle, and whatever third-party scripts the project genuinely needs. Nothing more.

That doesn't make scores magically high. The third-party scripts still take their toll. But it means you start with more room, so by the time the booking widget and the analytics and the trust badges have loaded, you're in the 60s or 70s rather than the 30s or 40s.

The honest conversation

None of this is about excusing poor work. A slow site with no third-party scripts is a developer problem and should be treated as one.

But if your site is loading every tool the business needs and the score is lower than you'd like, the right question isn't "why is this slow?" It's "what are the trade-offs, and which tools are worth the performance cost?"

That conversation should happen before the build, not after. And it starts with checking what everyone else in your market actually scores.

If you're worried about your site's speed, or you're setting performance targets for a new build, get in touch. We can help you work out what's realistic and where the biggest wins are.