14+ years building on WordPress / Replies in under 5 hours
Performance

Core Web Vitals fixed on an ad-heavy news site — without cutting ad revenue

A US publisher's news site was failing Core Web Vitals and losing search visibility — but the ad scripts causing it were also paying for the newsroom. The fix had to keep both.

31 → 91
mobile Lighthouse
PSI mobile, median of 5 runs
4.2s → 1.5s
Largest Contentful Paint
CrUX field data, 75th percentile
0.31 → 0.04
Cumulative Layout Shift
CrUX field data, 75th percentile
-64%
article page weight
measured on standard article template

Representative engagement. The client's identity is withheld under NDA, and the figures shown illustrate typical outcomes for this type of project rather than one client's audited results. The methodology described below is exactly what I run on real projects.

Client
Publisher
Identity withheld under NDA
Industry
Publishing / news media
Services
Speed optimization
Timeline
4 weeks
In short

An ad-funded news site was brought into Core Web Vitals compliance without removing its ad stack: every ad slot got reserved dimensions to stop layout shift, the ad library was sequenced to load after the article's largest element, and below-fold slots and embeds were deferred until scrolled to.

The challenge

Heavy ad scripts and large lead images had dragged all three Core Web Vitals into the red, which was costing search visibility on a site whose entire business depends on organic reach. The obvious fix — remove the ad scripts — was also the one fix unavailable, because those scripts fund the newsroom. The worst symptom was layout shift: ads loaded asynchronously into unreserved space and shoved the article down mid-sentence, which readers hated and which alone was enough to fail CLS. There was also a measurement problem: the team had been optimising against Lighthouse lab scores, which behave very differently from the field data Google actually ranks on for an ad-heavy page.

Starting point

Field data before the work, 75th percentile mobile: LCP 4.2s, CLS 0.31, INP 290ms — all three failing. Standard article template weighed 4.8MB on first load, of which 2.9MB was advertising and third-party embeds. Eleven ad networks active, lead images served as unoptimised JPEG at full desktop resolution to mobile devices.

Abstract graphic of stacked bars thinning downward, representing reduced page weight

The approach

Ad-funded publishing is a different problem from eCommerce: you can't just delete the scripts paying for the site. The work is about controlling when things load and reserving the space they'll occupy — so the ads still arrive, they just stop hurting the reader and the ranking on the way in.

Switched the target from Lighthouse lab scores to CrUX field data, because that's what actually affects rankings and ad-heavy pages score very differently between the two
Reserved fixed dimensions for every ad slot, which eliminated the large majority of layout shift on its own without touching a single ad unit or line of revenue
Sequenced the ad library to initialise after the article's largest contentful element, so the headline and lead image paint before advertising competes for bandwidth
Rebuilt lead-image delivery with responsive srcset and AVIF/WebP, cutting the single largest payload on every article page
Deferred below-fold ad slots and third-party embeds (video, social) so they cost nothing until a reader actually scrolls to them
Gave ad ops a measured breakdown of blocking time per network, which let them drop two low-revenue networks accounting for a disproportionate share of it — their call, with real numbers behind it

The results

All three Core Web Vitals moved into passing range on field data, with the layout-shift improvement coming almost entirely from reserving ad dimensions — the cheapest fix on the list and the one with zero revenue impact. Page weight fell by roughly two-thirds on the standard article template. The ad stack stayed in place apart from the two networks the client chose to drop after seeing the blocking-time breakdown.

What this didn't cover

Ad revenue optimization was explicitly not in scope. I provided blocking-time measurements per network and flagged which were poor value, but the decision and any revenue trade-off were the client's to make — I'm not in a position to advise on their ad economics. No editorial CMS work, no paywall or subscription changes, and no infrastructure migration. Third-party embeds are deferred but remain heavy once opened; replacing them with click-to-load facades was proposed, costed and deferred by the client to a later phase. INP improved but sits closer to the threshold than the other two metrics, and would need dedicated JavaScript work to build in real headroom.

Services used on this project

Want the same for your site? Start here:

WordPress speed optimization that users actually feel

Common questions

In most cases yes, because the biggest single win — reserving fixed dimensions for ad slots — costs nothing in revenue. It stops ads shoving the article around as they load, which is usually the bulk of a publisher's CLS problem. Sequencing and lazy-loading get you most of the rest. Removing networks is a last resort, and that's a commercial decision with real numbers attached, not a technical one.

Field data, every time. Lighthouse is a lab simulation on a throttled connection; CrUX field data is what your actual readers experience and what Google uses for ranking. Ad-heavy sites diverge sharply between the two, and teams routinely chase a lab number while the field metrics that matter don't move.

Core Web Vitals are assessed on a rolling 28-day window of field data, so expect around a month before the change is fully reflected, and a little longer before any ranking effect settles. Anyone promising results next week is describing a lab score, not the metric Google actually uses.

Verified reviews

What clients say on Google

These are general reviews of working with me, not comments on this specific project.

★★★★★

“Fantastic Developer. Very knowledgeable. Very patient. Works extremely hard. Very good English Skills. Good communication skills. Takes the time to understand the project scope and the minor details in your project. I am very impressed.”

SB
Silvia B
Google Reviews
★★★★★

“Great developers! All the team are professionally, it's a pleasure work with them :). I, sincerely, recommend it.”

LB
Laura Ballart
Google Reviews
★★★★★

“Worked with them in several projects. They are always good and responsive. More projects will be coming.”

AD
Anatano dev
Google Reviews

Want results like these?

Send me your site and goals — I'll tell you exactly what's worth doing.

Start a conversation