How We Got Our Own Agency Site to PageSpeed 100

Most agencies that sell speed optimisation run their own sites in the 70s. We didn't want to be one of them, so in April 2026 we put pressforge.co.uk through the exact pass we sell to clients and kept the receipts. This page lists every lever we pulled, what each one saved in real kilobytes, and the things we deliberately chose not to "fix". You can verify the result on PageSpeed Insights right now; the page you're reading runs every technique described below.

Why We Ran the Speed Pass on Our Own Site

Google's own definition is the cleanest argument for the work: "Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools" (web.dev). All web pages includes ours. If we tell a client their site needs to be fast and our own contact page scores 64 on mobile, which it genuinely did before this pass, the pitch is dead on arrival.

So the brief we gave ourselves was the client brief: measurable scores, dated evidence, and no technique we wouldn't deploy on a customer's WordPress site. The work landed on 7 April 2026 and everything below comes from that day's build log.

The WebP Image Pass: 2.8 MB Gone

The single biggest weight on the site was images served larger than they're ever displayed. The fix is unglamorous: measure the real display size, resize to double that for retina screens, re-encode as WebP at a quality level chosen per image set. The audited results across the library:

• Portfolio category images: 1.4 MB down to 290 KB, roughly an 80% cut.
• 45 portfolio industry images resized to a 1200x720 ceiling and re-encoded: 462 KB saved.
• 12 inline blog images re-encoded at WebP quality 75: 280 KB saved.
• The logo: a 19 KB PNG became a 10 KB WebP at exact retina-2x dimensions.
• The favicon a returning visitor's cookie banner loads: a 26 KB 512px PNG became a 3.5 KB 70px WebP.

Total across the library: about 2.8 MB removed without a visible quality difference. On a typical WordPress site we run the same audit against the media library and the theme's asset folder, where page builders routinely ship 2 MB hero images scaled down in CSS.

Per-Page CSS and JS Bundles

The site originally loaded one global stylesheet containing every page's CSS. The refactor split it: a global bundle of roughly 58 KB minified that carries only the shell (navigation, footer, hero, buttons, forms), with each page declaring its own extra styles. A non-blog page stopped downloading around 90 KB of blog styling it never used.

Below-the-fold component CSS goes one step further and loads asynchronously, using the print-media swap so it never blocks first paint:

<!-- Deferred: downloads without blocking render, applies onload -->
<link rel="stylesheet" href="/styles/components/trust-section.min.css"
      media="print" onload="this.media='all'">
<noscript>
    <link rel="stylesheet" href="/styles/components/trust-section.min.css">
</noscript>

JavaScript got the same treatment with esbuild: a global bundle around 20 KB minified, with page-specific scripts (the quote form, blog pagination) extracted so only the pages that need them pay for them.

Lazy reCAPTCHA: The 400 KiB Nobody Was Using

The biggest single win was Google reCAPTCHA. The standard integration loads the API script in the page head, which pulls roughly 400 KiB of JavaScript, CSS and fonts for every visitor to every form page. Most visitors never touch the form, and bots that bounce never should have triggered it at all.

The fix: load nothing until the visitor first interacts with the form, then inject the API and fetch the token at submit time.

// Load reCAPTCHA only when someone actually starts using the form
const prime = () => {
    if (document.getElementById('recaptcha-api')) return;
    const s = document.createElement('script');
    s.id    = 'recaptcha-api';
    s.src   = 'https://www.google.com/recaptcha/api.js?render=' + SITE_KEY;
    s.async = true;
    document.head.appendChild(s);
};

['focusin', 'pointerdown', 'touchstart'].forEach((evt) =>
    form.addEventListener(evt, prime, { once: true, passive: true })
);

That one change took the contact page's mobile performance score from 64 to the mid-90s. A preconnect hint to google.com stays in the head so the eventual lazy fetch is fast when a real human does start typing.

LCP Preloads, Caching and the CDN

Largest Contentful Paint usually decides the performance score, and on content pages the LCP element is the featured image. The browser discovers it late unless you say otherwise, so every article and case study page on this site emits a preload in the head:

<link rel="preload" as="image" type="image/webp"
      href="/blog/images/2026/04/case-study-16x9.webp"
      fetchpriority="high">

Behind that sit the caching layers: static assets carry a one-year immutable cache header (safe because every URL is version-stamped), HTML revalidates quickly for browsers while the CDN edge holds it longer, and the whole site sits behind the StackCDN edge cache included with our hosting at our sister company 365i. Hosting matters here for one number above all: time to first byte. No front-end work rescues a 1.4-second TTFB; on this stack we measure it in tens of milliseconds.

What We Left Alone (Lighthouse Estimates vs Reality)

Honest limitations, because chasing the number for its own sake produces silly decisions:

• PageSpeed still suggests "fixing" our logo. It estimates savings by re-encoding logo-dark.webp at its 1x display size. Our file is sized for retina screens, and re-encoding it smaller actually produced a larger file in testing. We kept the retina file and accepted the advisory note. Lighthouse suggestions are estimates, not commandments.
• A greenfield custom site is the easy mode. This site has no page builder, no plugin stack, no third-party tag soup. A ten-year-old WooCommerce install will not hit the same numbers in a day; it improves in larger steps over a longer pass. Our hand-coded Lockerfella build holds 100/100/100/100 on mobile; for typical WordPress rebuilds, high 90s is the honest target we quote.
• Scores wobble. Lab runs vary a point or two with network and test-server conditions. We optimise for the field data trend, not for screenshotting a single perfect run.

What This Means for Your WordPress Site

Everything above transfers to WordPress: the image audit, the asset splitting, the third-party deferral, the LCP preload and the caching policy. The platform changes the implementation, not the physics. This pass is precisely what our WordPress speed optimisation service performs on client sites, and the same discipline is built into every site we design and build from day one. For the content-and-ranking side of the same philosophy, the Lockerfella case study shows what speed plus non-commodity content achieved for a brand-new local business.

Frequently Asked Questions