Insights · Websites

How we built a 100/100 PageSpeed website, and what we removed to get there

Our site scores 100/100 for performance on Google's PageSpeed test, on a simulated phone, repeatedly. What we built, what we deleted, and what a perfect score does and does not mean.

Run this site through Google's PageSpeed test right now. Please do, that is rather the point of this post. On the mobile test, the hard one, we score 100 for performance. Not once, on a lucky run, but consistently. Most agency websites do not manage it. Plenty of agencies selling "blazing fast websites" do not manage it on their own homepage.

We have already written about why speed is a feature commercially. This post is the engineering half: what actually got us the last twenty points, because they were not where we expected. The honest summary is that we built less, not more.

The foundation: nothing thinking at request time

The site is static files on a global edge network. No server assembling pages, no database queries, no client-side framework booting up before content appears. The critical CSS is inlined into every page, so the first request already contains everything needed to paint. Fonts are self-hosted, trimmed to the exact weights the design uses, and only the faces visible above the fold are preloaded.

That last point taught us something. We once added a fourth font preload, a completely reasonable-looking optimisation, and watched the mobile loading time jump by around three seconds across repeated live tests. Four small files competed for the same narrow slice of bandwidth that the largest visible content needed. We removed it and the score recovered. Lesson: on a throttled mobile connection, every preload is bidding against your content, and the test is honest about it.

The mistake that costs most sites their score

The single biggest fix was not a clever addition. It was removing an animation. Our hero text, the largest element on the page, faded in from invisible. Elegant, and catastrophic: Google measures when the largest content becomes visible, and ours was deliberately invisible while it animated. That one fade was costing us three full seconds of measured loading time. We moved the entrance animation to the supporting elements and let the headline paint instantly, and the metric dropped from 4.7 seconds to 1.7.

If your site "feels fast" but scores badly, this is the first thing to check. The report names the element it measured. If that element is fading, sliding through opacity, or waiting for JavaScript, you have found your problem, and fixing it costs nothing but restraint.

What we deleted: every third-party script

Here is the uncomfortable one. The final barrier to a consistent 100 was analytics. Google Analytics, loaded the recommended way, was repeatedly the largest remaining drag on our own score, which has a certain irony to it.

So we removed it. Not just deferred it, removed it, along with the cookie consent banner it required. This site now loads zero third-party JavaScript. Visitor counting happens with a tiny first-party beacon: no cookies, nothing stored on your device, no personal data, page-view counts and referrers only. Because nothing is stored on the visitor's device, UK privacy rules do not require a consent banner, so that overlay, its script, and its small tax on every single visitor went too.

We would not prescribe this for everyone. If you run paid campaigns, you likely need the heavier measurement and consent that go with them. But most small business sites are carrying GA4, a consent platform, a chat vendor and two tracking pixels to answer questions a lightweight first-party count answers fine. Every one of those scripts is paid for by every visitor, on every visit.

Keeping it at 100

A score you hit once is a screenshot. A score you keep is engineering. The pieces that keep it stable: below-the-fold sections do not render until you approach them, ambient animations stay off the loading path and only animate properties the graphics processor composites, assets ship with fingerprinted filenames so they cache for a year yet update instantly when changed, and every change gets tested on a simulated mid-range phone before it ships. Speed is a budget, and each addition has to pay its way against it.

What a perfect score is not

Some honesty, so this post ages well. PageSpeed scores wobble a little between runs; the difference between 98 and 100 on any single test is partly noise, and we score 100 consistently rather than claiming some permanent state of grace. A perfect score also does not mean the best website: it measures loading performance, not whether the copy converts or the proposition makes sense. And the final few points carry a real cost in discipline that not every business should pay. For most sites, the mid-nineties with sane trade-offs beats a fragile 100. We wanted 100 because speed is one of the things we sell, and we think you should be able to check that claim in thirty seconds, on our own site, without taking our word for anything.

Curious where your site lands? Test it on PageSpeed first, then get our free website review for the why behind the number, or book a discovery call if you would rather talk it through.

Common questions

What is a good PageSpeed score?

Above 90 on mobile is genuinely good; most business websites score between 30 and 60. The mobile score matters far more than desktop, because it simulates a mid-range phone on a slow connection, which is closer to how real customers first meet your site. Chasing 100 only makes sense when speed is central to what you offer; the low nineties with sensible trade-offs serves most businesses well.

Does a perfect PageSpeed score improve Google rankings?

Page experience, including the Core Web Vitals that PageSpeed measures, is a confirmed ranking signal, but a modest one: going from 95 to 100 will not leapfrog you over better content. The larger commercial effect is on people, not rankings. Slow pages lose visitors before they see anything, and those losses compound with every second of loading.

Why does my PageSpeed score change every time I run it?

The test simulates a device and network, and simulation has natural variance, so a few points of wobble between runs is normal. Judge the trend and the individual metrics rather than a single run. If your score swings wildly, that usually points at third-party scripts, whose size and timing you do not control.

Can I score 100 while keeping Google Analytics?

Realistically no, not consistently on mobile: GA4 and a consent banner together typically cost several points on their own. The decision is whether that measurement earns its cost. If you run paid campaigns it usually does. If you only need to know visit counts and where visitors come from, a first-party, cookie-free counter answers that with zero third-party scripts and, because nothing is stored on the device, no consent banner either.

Nathan McDonald
Nathan McDonald · Founder

Nathan McDonald is the founder of Smarter Sites, a digital studio in Northwich, Cheshire. He has spent 15 years in web development and digital marketing, and now builds the websites, portals and automation that growing businesses run on. More about the studio →

Want to talk it through?

Book a 30 minute discovery call and ask us directly.