Speed is one of those metrics no dashboard shows you. You can’t see the pageviews you didn’t get because a script loaded too slowly, or the bid that didn’t come in because the ad slot rendered a second too late. It just quietly disappears: no line item, no alert, nothing to flag it to your team.

That’s exactly why we ran a live session on it. On 9 July, Loïc Dussart and Seraphina Davey hosted a free 45-minute working session for publishers: no slides-only theory, no pitch. This was just a real, live audit of two publisher sites, run in front of attendees, with the fixes explained as we found them.

The flywheel no one’s watching

Speed doesn’t sit in isolation. It drives everything else. A faster page means a better user experience. A better experience means people stay longer. Longer time on page sends a stronger signal to Google, which rewards it with better rankings and more Discover traffic. More qualified traffic, delivered against a faster page, means more revenue per pageview. Slow the page down at any point, and the whole cycle works against you instead of for you.

The numbers make the case on their own:

• A 100ms delay can cost around 1% in conversions
• Publishers can lose roughly 3% in ad revenue for every extra second of load time
• 53% of mobile visitors abandon a page that takes longer than 3 seconds to load
• Only 42% of mobile sites currently pass Core Web Vitals

None of that shows up as a support ticket. It just shows up, quietly, as a smaller number at the end of the month.

What the live audit turned up

Using WebPageTest (the same engine behind Catchpoint), Loïc ran two real publisher sites through a full Using WebPageTest (the same engine behind Catchpoint), Loïc ran two real publisher sites through a full waterfall analysis live on the call, the same process any publisher can run themselves, for free, in a few minutes.

A few patterns came up on both sites:

• Render-blocking fonts. External font files were delaying the page from rendering at all, when the native browser font would have done the job with zero load penalty.
• Unoptimised images. Large JPEGs and PNGs sitting well above their necessary file size — often halvable simply by switching to WebP.
• Images loading outside the viewport. Content the user hadn’t scrolled to yet was competing for load priority with the content directly in front of them.
• Consent (CMP) timing. On one site, the CMP was called several seconds into the page load. Every one of those seconds is a second where demand partners can’t bid, because consent hasn’t been established yet.
• Duplicate or legacy scripts. More than one Google Tag Manager container running on the same page, left over from a previous setup and never consolidated.

None of these are exotic problems. They’re the same handful of issues, in different combinations, on almost every site we’ve ever audited.

Five fixes any publisher can start today

1. Lazy load anything outside the first viewport. If the user hasn’t scrolled to it yet, it doesn’t need to load yet.
2. Question every script. If you can’t say why it’s there, it’s a candidate for removal or deferral.
3. Switch images to WebP. Same visual quality, roughly half the file size.
4. Use native browser fonts. External font files block rendering for no real visual gain in most cases.
5. Understand your ad stack’s load impact. Know which scripts are server-side versus client-side, and how much of your load time is genuinely yours versus your vendors’.

None of these require a redesign. Most are a day’s work for a developer, and the sites that treat speed as a genuine priority tend to see the difference in their Core Web Vitals scores within weeks, not months.

Want your own site looked at the same way? Get in touch. We’re always happy to run through it.