PerformanceVarnishLighthouseCore Web Vitals

Lighthouse 100 on a Mass-Volume Regional News Portal

Profile:Regional news portal in Central-West Brazil

A high-volume regional news portal was hemorrhaging readers to slow page loads on mobile. Re-architected the cache layer, eliminated render-blocking, and pushed Lighthouse to a sustained green band — without rewriting the CMS.

Duration6 weeks
Categoryreliability
TechnologiesVarnish 7.x · Cloudflare CDN · Critical CSS inlining · Image lazy loading · WebP · Brotli · WordPress (read-only origin)

Key results

32 → 95
Lighthouse Performance (mobile)
-1.7s
Time to Interactive
+18%
Sessions per user

The problem

A major regional news portal in Central-West Brazil was leaking mobile readers. The audience is 70%+ on mid-tier Android devices on 3G/4G, where every extra second of load time is a measurable bounce. Lighthouse Performance score sat at 32 on mobile. CLS was through the roof from late-loading ad units shifting the article body around.

The constraint: WordPress origin had to stay. Editors are productive there, the team isn't going anywhere, and the publishing workflow couldn't take a CMS migration.

The approach

Fix it at the edge, leave the CMS alone.

Varnish 7.x in front — already in place but under-tuned. Rewrote VCL to normalize cache keys, separated authenticated paths from anonymous, and pushed cache TTLs from minutes to hours where editorial cadence allowed.

Critical CSS inlined for the article and home templates. The full CSS bundle was deferred to post-load. First paint dropped immediately.

JS deferred or removed — half the JS was a tag-manager-of-tag-managers loading scripts that hadn't been used in 18 months. Pruned aggressively.

Images converted to WebP at the edge with a Worker, served with `<picture>` fallback for legacy clients. The image weight on a typical article fell ~60%.

Ad slots reserved with CSS — fixed-height containers that hold space for the ad unit even before it loads. CLS plummeted.

Brotli compression for HTML, CSS and JS. Older deploys were still on gzip.

The whole change set was rolled section-by-section with synthetic monitoring per route. Any regression rolled back automatically.

The outcome

Lighthouse Performance went from 32 to 95 on a sustained basis (median over 30 daily synthetic runs). Time to Interactive on mobile dropped 1.7 seconds. Sessions per user rose ~18% within the first quarter post-launch — the readers were already there, they were just bouncing before the article rendered.

No CMS migration. No editor workflow change. The team kept their tools and got a fast site.

Why it matters

News portals get told they need to migrate to the latest stack to be fast. They don't. They need to stop letting their cache layer rot, stop loading dead JS, and stop letting ad slots reflow the article. Most of the win is hygiene the team already knows about — they just need someone to actually do it without breaking the publishing flow.

A similar engagement for your team?

Every Tyber.io engagement starts with the same question: which problem hurts the most, and which one is the most fixable. Get in touch with the technical lead directly — no SDR funnel, no junior handoff.

Talk to the technical lead