How We Took Our Site From 62 to 90+ on PageSpeed

On 27 October 2026 our own homepage scored 62 out of 100 for mobile performance. That's awkward for a team that guarantees clients 90+ on Google PageSpeed Insights for every website we design. Here is exactly what was wrong, what we changed, and the numbers before and after. Every figure below was measured on automization.io.

The short answer: Google's Largest Contentful Paint (LCP) metric measures when a page's main content appears, and on our site the main content was being hidden by our own animations and cookie banner. Fixing that, plus two Cloudflare settings, took the key pages past 90.

What is PageSpeed scoring, and why does LCP matter most?

PageSpeed Insights runs Lighthouse on a simulated mid-range phone on a slow 4G connection, and turns five measurements into one score out of 100 (how the score is calculated). The heaviest is Largest Contentful Paint: the moment the biggest piece of text or image in the first screen is drawn. Google rates an LCP of 2.5 seconds or less as good (Core Web Vitals).

One rule explains most of our problems. When Chrome decides what the "largest" element is, it skips elements with an opacity of 0, because the visitor can't see them (how LCP is measured). So if your headline fades in from nothing, the page's main content is whatever else happens to be visible first.

Problem 1: why was the cookie banner our main content?

Our cookie banner was added by JavaScript after the page loaded. On a phone it was the biggest block of text on screen, so Lighthouse treated it as the page's main content, and it only appeared once the scripts had run.

The fix: the banner is now part of the page's HTML, so it's drawn with everything else. A tiny script hides it before the first paint if you've already chosen, so returning visitors never see it flash.

Problem 2: why did the homepage text wait for the 3D logo?

Our homepage hero has a 3D logo built with three.js, the largest file on the site. The headline, paragraph and buttons were hidden until that 3D scene had downloaded and its intro animation had played. On a fast connection that took about 4 seconds. On slow 4G it took more than 7.

We measured when the hero paragraph became visible, in Chrome with an empty cache:

The fix: the paragraph and buttons are now visible from the first paint. The headline still plays its intro once the 3D scene is ready, and if the scene isn't ready within 2.5 seconds, the headline shows anyway and the scene fades in behind it when it arrives.

Problem 3: why did a Cloudflare setting slow every page?

Cloudflare's email address obfuscation hides email addresses from spam bots. To do it, Cloudflare adds a small decode script to every page (Cloudflare's documentation). Lighthouse flagged that script as blocking the first paint, with estimated savings of up to 0.9 seconds on our pricing page.

The fix: we turned it off. A slightly higher chance of spam to one address is a better trade than a slower first paint on every page for every visitor.

Problem 4: why did every visit wait for a server in the US?

Our site runs in the US and sits behind Cloudflare, but Cloudflare wasn't storing our pages, only images and scripts. Every page view travelled to the US and back. From our test connection, the wait after connecting took 240–415 ms.

The fix: a Cloudflare cache rule now stores each page at the nearest Cloudflare location, following the page's own cache settings (cache rules). Pages that change per visitor, like checkout and booking, are never stored. Two things keep it safe:

• Every deploy clears the cache automatically, so nobody gets an old page pointing at files that no longer exist.
• Tiered cache means a location that doesn't have a page yet asks a central Cloudflare cache before it asks our server (tiered cache).

The same request now waits 120–150 ms from the same connection.

Problem 5: why were our other pages still under 90?

With the homepage fixed, Google's PageSpeed Insights on 27 October scored the homepage 90, pricing 94, AI receptionist 94 and cold email 93 on mobile. The hire AI developers page scored 88, and the reason was problem 1 again: every page's opening text faded in from nothing, so the cookie banner became the main content.

The fix: the opening text on every page now slides into place instead of fading in from nothing. It reads the same and looks almost the same, and the page's own paragraph is now its main content.

What should you check on your own site?

1. Run PageSpeed Insights on mobile and open "LCP breakdown". If the element it names isn't your headline, hero image or opening paragraph, start there.
2. Look for content that fades in from nothing. Animate position instead, or start fully visible.
3. Check what your CDN adds to each page. Email obfuscation, analytics beacons and "optimisation" scripts all cost time.
4. Cache pages at the edge, with a purge on every deploy. Never cache pages that change per visitor.
5. Test from Google's servers, not just your own machine. Our local runs swung between 62 and 88 for the same page depending on the network route; PageSpeed Insights gave a steady answer.

Common questions

Is a PageSpeed score of 90 worth chasing?

The score is a lab test, but what it measures is real: how soon a visitor on an average phone sees your offer. For us the fixes meant visitors on slow connections see the offer about 6 seconds sooner. That's the point, not the number.

Did we remove features to get the score up?

No. The 3D hero, the animations, the cookie banner and the analytics all stayed. Every fix was about the order things load in.

Can you do this for our site?

Yes. Every website we design is guaranteed to score 90+ on Google PageSpeed Insights, or we keep working free until it does, and our website maintenance plan keeps it there.

Sources

• Google, Largest Contentful Paint and Core Web Vitals thresholds
• Chrome for Developers, Lighthouse performance scoring
• Cloudflare, email address obfuscation, cache rules and tiered cache
• Our own measurements, 26–27 October 2026: Lighthouse runs against production, Chrome timing runs on emulated connections, and Google PageSpeed Insights (mobile)