A 100 PageSpeed Score: How a Fast Website Generates More Leads (and What's Killing Yours)

When I tell business owners that my site scores 100 on PageSpeed, the usual reaction is "nice, but who cares about a score." Fair enough — the score itself isn't the goal. But what the score measures is something your customers care about a great deal: how long it takes from the moment they tap your link until they can read, click, and leave their details.

Google's own research has shown the same thing again and again: the slower a page loads, the more people abandon it before ever seeing what you have to offer. Every unnecessary second is leads walking over to the competitor whose site opens instantly. And beyond abandonment, Google uses speed metrics as part of its ranking — so a slow site also gets less traffic in the first place. A double penalty.

After years of fixing slow websites, I can tell you it's almost always the same five suspects. Let's go through them.

The five things that actually kill small-business websites

1. A page builder plus forty plugins

The classic story: the site was built with Elementor or another builder, and over the years plugins piled up — one for forms, one for galleries, one for popups, three "optimization" plugins fighting each other. Every plugin injects CSS and JavaScript files into every page on the site, including pages that never use it. The result: your visitor's browser downloads and executes a mountain of code just to display an "About" page with three paragraphs. The builder itself adds another layer of generic code on top of everything.

2. Unoptimized images

The most common culprit, and the easiest to fix: an image straight out of a camera or Canva, weighing several megabytes, uploaded as-is and displayed at postage-stamp size. The visitor downloads an image thousands of pixels wide to see it in a small grid square. Modern formats (WebP, AVIF), dimensions matched to the actual display size, and lazy loading for below-the-fold images solve most of this problem.

3. Font loading

Beautiful web fonts are a wonderful thing, but the average site loads three or four weights of two fonts from external servers — and while that happens, the text is either completely hidden or jumps and reshapes when the font finally arrives. The fix: host the fonts on your own server, load only the weights you actually use, and configure loading so text is visible immediately, even before the font lands.

4. Third-party widgets

A WhatsApp chat bubble, a floating accessibility overlay, Facebook and TikTok pixels, an embedded Google Map — each one sounds small, and together they sometimes weigh more than the site itself. They load from external servers you don't control, and many of them block or delay the things that actually matter. Incidentally, I wrote a whole article about the floating accessibility overlay — it's problematic for more than just performance. Whatever must stay can be loaded intelligently: after the page has rendered, or only when the visitor actually needs it.

5. Sliders and carousels

The hero slider is perhaps the most popular and least rewarding element on the web: it loads five huge images and an entire JavaScript library so that most visitors see only the first slide and scroll past. One good static, optimized hero image does the job better — both for marketing and for the browser.

The three metrics, in human language

Google measures loading experience through three core metrics (Core Web Vitals). Here's what they mean in practice:

LCP (Largest Contentful Paint) — how long until the largest element on the page — usually the hero image or main headline — appears on screen. This is the metric closest to the feeling of "the site opened": when LCP is slow, the visitor stares at a blank screen wondering whether the link even works.

CLS (Cumulative Layout Shift) — how much the page "jumps around" while loading. You know when you're about to tap a button and an ad loads, pushes everything down, and your tap lands on something else? That's bad CLS. It's caused by images without defined dimensions, fonts that reshape text, and banners injected late.

INP (Interaction to Next Paint) — how quickly the page responds when you interact with it. Opened a menu and it appeared after a half-second of lag? That's bad INP, and the culprit is almost always excess JavaScript keeping the browser busy while the visitor is trying to talk to it.

What does "good" look like?

Google publishes official thresholds for each metric — green, orange, and red — and the free PageSpeed Insights tool will show you exactly where you stand, on both lab data and real-user data. But the simplest test requires no tools at all: open your site on your phone, on mobile data, in an incognito window. Count to yourself. If you reached three before you could read the headline — there's work to do.

A 100 score isn't magic and isn't luck. It's the result of removing everything from the page that doesn't serve the visitor — and loading what's left in the right order.

What's fixable without a rebuild

Good news: a large share of the problems can be handled on the existing site, without touching the design:

• Compressing and converting images to modern formats, with correct dimensions and lazy loading
• Pruning plugins — removing what's unused and consolidating duplicates (three caching plugins is not "extra speed," it's an accident waiting to happen)
• Self-hosting fonts and loading only the necessary weights
• Deferring third-party widgets until after the initial render
• Caching and a CDN configured properly at the server level
• Replacing the slider with a single static hero image

Work like this delivers a noticeable jump for most sites — it's exactly the kind of thing I do in my website fixes and improvements service.

And when does a rebuild pay off?

There's a point where optimization becomes a race against the architecture. If the site sits on a heavy builder with dozens of plugins, every improvement is a fight with the structure's limits: you can climb from a score of 40 to 70, but the last 30 points are locked inside foundations you can't swap without dismantling everything. The signs you've reached that point: every new plugin breaks something, updates scare you, and you've already paid two "speed experts" who barely moved the needle.

At that stage, a new site built lean and correct from the ground up — no layers of generic code, with performance as a baseline requirement rather than an afterthought — pays for itself within a year or two, in both money and leads. That's exactly what I build in my website development service: sites that score 100 because they were built for it, not because someone fought them into submission.

Want to know where your site stands and which route makes more sense in your case — optimization or a rebuild? Get in touch and I'll come back with an honest answer, even if it's "your site is fine, spend the money on marketing instead."