Publishers face a false choice — fast pages or ad revenue — because most ad setups are installed, not engineered. Google’s thresholds are fixed and public (LCP ≤ 2.5s, INP < 200ms, CLS < 0.1, on real-user data), and every technique below holds revenue while meeting them. This is the practitioner companion to the revenue views in the AdSense–GA4 guide: speed work protects the RPM that guide measures.

1. Why speed is a revenue metric for publishers

Slow pages lose the auction twice: users bounce before ads view, and viewability-scored demand bids less for inventory it cannot see. On Nepali 4G connections the effect compounds — a 6-second LCP does not just annoy, it structurally discounts every impression. Treat CWV as RPM infrastructure, not SEO decoration.

2. The three vitals, publisher-translated

• LCP (≤2.5s): what renders the biggest content — usually hero image or headline block. Ad scripts competing for early bandwidth delay it directly.
• INP (<200ms): responsiveness to taps — heavy main-thread JS (consent + ads + analytics + chat widgets stacked) is the usual killer.
• CLS (<0.1): visual stability — late-loading ad creatives shoving content down is the classic publisher failure and the most fixable.

3. How advertising degrades each one

Ad tech hurts through three mechanisms: network contention (scripts + creatives vs your content), main-thread cost (auction, rendering, viewability measurement JS), and layout instability (slots with no reserved size). Diagnose which dominates your pages in PageSpeed Insights before prescribing — the fix differs per mechanism.

4. Layout shifts: reserve every slot

• Size every ad container in CSS before the ad loads (fixed heights per breakpoint; fluid only where the layout genuinely reflows by design).
• Never insert units above existing content after load — below-content and sidebar slots shift nothing.
• Sticky units get max-height plus a close control that does not move page content when dismissed.
• Test CLS specifically with ads enabled and with an ad blocker: the delta is your ad-induced shift, and it should round to zero.

5. Lazy loading: what it fixes and where it stops

Lazy-load below-fold ad units and images so initial load carries only the viewport — large LCP wins on long articles. Limits: lazy loading cannot fix above-fold weight, CLS from unsized slots, or main-thread saturation. It is a weight tool, not a stability or responsiveness tool; pair it with §§4 and 8.

6. Images and fonts that stop competing with ads

• Modern formats (WebP/AVIF) with explicit width/height on every image — no layout shift, fraction of the bytes.
• System-font fast path with a metric-matched fallback, webfonts deferred and display:swap — text renders instantly, branding swaps in without reflow.
• Hero image preloaded (one, the LCP element); everything else lazy. Preloading three “maybe” images is slower than preloading none.

7. JavaScript overhead: the publisher audit

List every third-party script (consent, ads, analytics, chat, social embeds, A/B tools) and justify each against revenue or measurement. Defer everything non-critical past first paint; load analytics and ad tech through a staged loader (interaction-or-timeout gates keep INP clean on mid-range Androids that dominate Nepali traffic). Remove dead pixels quarterly — tag accumulation is silent CWV rot.

8. CDN, caching, hosting per stack

• WordPress: page cache + object cache, image optimization pipeline, minimal plugin count (each plugin is JS/CSS you did not choose), PHP 8+, HTTP/2 or 3 from the host.
• Jekyll/static: pre-built pages are already fast — the work is asset discipline (minified bundles, deferred scripts, preconnects) plus CDN caching with sane TTLs.
• GitHub Pages: CDN-backed by default; keep bundles lean since you control no server tuning — every kilobyte is yours.
• Netlify: edge caching plus explicit cache headers for assets; form/analytics functions kept off the critical path.
• All stacks: image CDN or responsive variants for 4G realities; test on throttled mobile profiles, not office fiber.

9. Mobile testing that reflects Nepal

Test on a mid-range Android over throttled 4G — the median reader, not your laptop. PageSpeed Insights mobile tab plus Search Console’s real-user CWV report (field data rules; lab scores guide). Re-test top-earning templates after every ad-layout change, since revenue pages deserve stricter gates than the rest.

10. Toolchain: PageSpeed Insights + Search Console

PSI for per-URL lab diagnosis with the filmstrip (watch when each element moves, not just scores); Search Console CWV for field reality by URL group. When they disagree, trust field data and use lab runs to find causes. Record both monthly per template.

11. Repeatable monitoring process

Monthly, 30 minutes: field CWV per template from Search Console → lab-filmstrip the regressions → one fix per cycle (slots, then scripts, then assets — in that order) → re-measure next cycle. Tie to revenue: overlay page RPM from the Looker dashboard on the same review so speed work prioritizes money pages.

Publisher performance checklist

• All ad slots sized in CSS per breakpoint; zero ad-induced CLS (blocker on/off delta ≈ 0)
• Third-party scripts inventoried, deferred, justified; staged loading for analytics/ads
• Images modern-format with dimensions; fonts swap without reflow; one preloaded hero
• Below-fold units and images lazy-loaded; above-fold weight audited
• Mid-range Android + throttled 4G test passes on top-earning templates
• Search Console field data green per template; monthly review scheduled with revenue overlay

Related reading: AdSense–GA4 integration, Looker revenue dashboard, invalid-traffic prevention, ads.txt setup, and web development.