DEV Community: Apogee Watcher

When should you lazy load images (and when does it hurt LCP)?

Apogee Watcher — Thu, 15 Oct 2026 07:36:30 +0000

A theme update or optimisation plugin turns on lazy loading for every image. Bandwidth on long articles looks better in the waterfall, yet PageSpeed Insights still names a deferred hero as Largest Contentful Paint, or lab LCP gets worse than last month. That outcome is common when loading="lazy" is treated as a global performance switch instead of a per-image choice.

The full decision guide, including iframes, video, and lab-versus-field checks, lives on our blog in Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To). Formats, sizing, and CDN work sit beside that in Image Optimisation Strategies for Better LCP Scores. What follows is the short checklist we use in reviews: when lazy loading images helps, when it hurts LCP, and which CMS habits to watch.

Three checks before you lazy-load an image

These three questions usually decide whether loading="lazy" belongs on an <img>:

Is it in the first viewport on phone and desktop? If yes for either primary breakpoint, leave it eager.
Could PageSpeed Insights or Chrome name it as LCP? If it is the hero, primary product shot, or large above-the-fold banner, omit lazy, or set loading="eager" when a plugin injects lazy by default.
Does the markup reserve space? Width and height attributes or an aspect-ratio rule should be present before you defer the fetch, so Cumulative Layout Shift does not replace the LCP problem.

If the template or page builder does not make those answers obvious, identify the first-screen image before you change attributes. A plugin toggle is not a substitute for knowing which image paints first. Note the exclusions in the work item so the next theme update has a clear list.

When lazy loading images helps bandwidth without hurting LCP

Lazy loading images is usually right for content that starts offscreen: article body photos after the fold, related-product grids, footer logos, long category galleries, and comment avatars. Those bytes should not compete with the critical path on first paint. On a long post with many images, native lazy loading can cut early mobile bandwidth sharply without changing what the user sees first.

Eager versus lazy works better as a short policy per template than as a single sitewide switch. Eager fits the LCP candidate and other first-screen images on common breakpoints. Lazy fits everything that needs scroll or a tab change before it matters. Check phone width as well as desktop: an image that looks “below the fold” on a large monitor can sit in the first screen on a phone, and that traffic often dominates field data.

When `loading="lazy"` hurts Largest Contentful Paint

LCP marks when the largest above-the-fold content element becomes visible. If that element is an image marked loading="lazy", the browser may delay the request even though the image is already on screen. Lab tools show that as higher resource load delay and a worse LCP. Google’s guidance and support threads still treat “do not lazy-load the LCP image” as a first triage step, not a rare edge case.

The fix is usually small. Remove loading="lazy" from the named LCP image (and matching sources in <picture>). fetchpriority="high" fits when the LCP URL is known early and other resources are not already marked high. Preloading and lazy-loading the same URL fights itself. A reasonably sized eager hero usually beats a huge lazy hero on LCP, even when a plugin dashboard calls the waterfall optimised.

CMS and theme traps that lazy-load the hero

WordPress themes, page builders, and Shopify settings often inject loading="lazy" on every attachment. Logos, banners, and first product images get deferred with the gallery. Elementor and similar stacks show up often in “lazy load LCP” threads for that reason. A CDN or image plugin that rewrites markup can put lazy back after the theme was fixed once.

When scores drop after a “performance” plugin install, open the LCP element detail before you change hosting plans. Exclude the first-screen image from auto-lazy rules, or override with eager on that node. Record the exclusion in the monthly notes so the next theme update does not silently put lazy back on the hero.

Quick verify: lab LCP element after a lazy-loading change

After any change that touches image markup or lazy defaults, re-run PageSpeed Insights or your scheduled lab profile on the homepage and other priority pages. Check which element is LCP, whether that element is still lazy-loaded, and whether deferred below-the-fold images reserve space with width/height or aspect-ratio. One green Lighthouse run on a staging URL is not enough if production themes differ by template.

Comparing the same lab profile before and after the change, kept in monitoring history, is how agencies catch a theme update that re-applies sitewide lazy loading three weeks later, when nobody remembers the original ticket. Scheduled runs on the homepage and other priority pages are more reliable than another one-off Insights paste after each deploy. That habit turns a one-time attribute fix into something the next quarterly review can still prove.

FAQ

Should every image use loading="lazy"?

No. Offscreen images are the usual fit. Keep the LCP candidate and other first-viewport images eager. Sitewide lazy loading is a common cause of worse lab LCP.

Does lazy loading fix Cumulative Layout Shift?

Not by itself. Reserve space with width and height or aspect-ratio CSS. Lazy loading without reserved space can make CLS worse when images appear late and push the layout.

Is the HTML loading attribute enough, or do we still need a JavaScript library?

For ordinary images, native lazy loading is usually enough in modern browsers. Older themes still ship JavaScript lazy libraries; check whether those libraries also defer the hero. Knowing which mechanism is in use belongs in the work item before anyone blames hosting.

How do we know which image is LCP?

Use the LCP element detail in PageSpeed Insights or Lighthouse on phone and desktop widths. Do not guess from the design mockup alone.

CTA

If lazy loading is already “on” everywhere, treat the toggle as incomplete until the LCP image is named. Below-the-fold images usually stay lazy; the hero stays eager; space is reserved; theme and plugin changes get a retest. For the longer guide with iframes, video, and lab-versus-field detail, use the Watcher lazy-loading post linked above. For formats and sizing that keep eager heroes small enough to ship, use the image optimisation piece. When you need scheduled lab history across many client pages so a theme update cannot silently defer the hero again, run continuous PageSpeed checks in Apogee Watcher.

References

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To) (Apogee Watcher)
Image Optimisation Strategies for Better LCP Scores (Apogee Watcher)
Browser-level image lazy loading for the web (web.dev)
Lazy loading (MDN Web Docs)
Common misconceptions about Largest Contentful Paint (web.dev)

Brotli compression is on: why is PageSpeed / LCP still slow?

Apogee Watcher — Tue, 13 Oct 2026 08:49:26 +0000

The CDN panel shows Brotli enabled and the host checklist ticks compression, yet PageSpeed Insights on the homepage or checkout URL still shows a slow Largest Contentful Paint, or the Performance score barely moves after the change. Those two facts can both be true. Brotli compression shrinks text on the wire; it does not change the LCP element, a slow origin response, or a lab path that never negotiated br on the files that matter.

How to turn compression on without breaking scores is already covered on our blog in Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores. Caching and reuse sit beside that work in Cache-Control Headers for Web Performance. What follows here is the triage we run when the toggle is already green and the lab result is still poor: confirm encoding on the critical path, then address the bottlenecks compression was never going to fix.

Confirm Brotli is actually on the critical path

A dashboard labelled “Brotli” often means the edge can compress. Lighthouse and PageSpeed Insights care whether the HTML document and the render-blocking CSS and JavaScript on that URL arrived with Content-Encoding: br or gzip. Those are different claims. Open the Network panel (or curl -sI with Accept-Encoding: br, gzip) on the document URL and on each large text resource in the critical path. Look for content-encoding and for transfer size versus content size. If the document is compressed but the main stylesheet is not, the Enable text compression audit can still fail, and paint can still wait on uncompressed bytes.

Partial coverage is the usual miss after a “we enabled Brotli” ticket. Origin middleware compresses HTML; the CDN serves fingerprinted CSS from a bucket that never negotiated Brotli; fonts and JSON follow yet another path. Agencies also see the reverse: the lab client hits a cache or region where encoding differs from the URL the engineer tested by hand. Until you can name the encoding on the document and the two or three largest text blockers, treat the toggle as incomplete evidence.

Why Brotli can leave Largest Contentful Paint unchanged

LCP measures when the largest visible element finishes rendering, not when every text file is as small as possible. Compression helps when download time for HTML, CSS, or critical JavaScript was a meaningful slice of that path. It does nothing useful for an LCP image that is still a multi-megabyte JPEG, lazy-loaded by mistake, or discovered late after client-side rendering. Decode and layout work on the main thread also sit outside what compression can fix: a smaller JavaScript transfer still costs the same parse and execute time once the bytes arrive.

In our experience, teams over-credit the compression ticket because it is easy to mark done. The lab waterfall still shows a late LCP resource, a long Time to First Byte, or render-blocking scripts that compression only shortened by tens of milliseconds. When transfer size was never the bottleneck, expecting a Core Web Vitals step-change from Brotli alone is the wrong bet. Use the LCP element detail in PageSpeed Insights or Lighthouse: if the element is an image or a late text block waiting on fonts and scripts, compression is support work, not the fix.

When enabling Brotli makes PageSpeed Insights worse

Compression can raise Time to First Byte (TTFB) when the origin or edge encodes HTML on every request at a high Brotli quality level. Smaller bodies help only after the first byte is available. If CPU queues behind dynamic compression, every paint metric starts later even though transfer size looks healthier in the waterfall. That pattern shows up after someone raised Brotli quality to the maximum on dynamic pages without precompressing static assets or without a moderate quality setting for HTML.

Other regressions are quieter. Double compression (a gzip wrapper around an already-Brotli body, or filters stacked at origin and edge) burns CPU without shrinking useful bytes. Compressing JPEG, PNG, WebP, AVIF, or MP4 as if they were text adds work for almost no gain. Missing or wrong Vary: Accept-Encoding on shared caches can mix encodings across clients and produce flaky lab runs that look like random PageSpeed noise. When the score drops after the toggle, compare Time to First Byte and the server-response audit before chasing image formats again.

What to fix next when the LCP element is not a text file

Once Content-Encoding looks correct on the critical path, return to ordinary LCP triage. Identify the LCP element. If it is an image, check discovery (preload or early HTML), format and dimensions, and whether loading="lazy" was applied to the hero by mistake. If Time to First Byte is high, compression will not hide a cold origin, an uncached HTML document, or a slow application query. If render-blocking CSS and JavaScript dominate, shrinking them with Brotli helps a little; removing or deferring work that is not needed for first paint usually helps more.

Keep compression and caching as paired delivery checks rather than as a substitute for element-level work. Cache-Control decides whether repeat views reuse bytes; Brotli and gzip decide how small the first download of text is. Neither replaces a late LCP image or a client-only render of the hero. For agencies, a clear client update is: compression is done and verified; the remaining LCP risk is named (image, Time to First Byte, or blocking scripts) with an owner and a retest plan.

How agencies verify compression and LCP across a client portfolio

One curl on staging is not enough evidence across a client portfolio. After deploys that touch CDN, origin, or build output, re-check Content-Encoding on each client’s homepage and other priority pages, then re-run the same lab profile you use for monthly reporting. Scheduled PageSpeed monitoring catches the case where Brotli is on in one region and missing in another, or where a theme update reintroduces uncompressed CSS while the dashboard still says compression is enabled. Pair those runs with a short note in the monthly report: encoding verified on the document and main CSS/JavaScript; LCP element and Time to First Byte trend unchanged or improved.

That habit keeps the compression ticket from being closed while LCP is still slow. It also stops the next quarterly review from reopening “we turned Brotli on months ago” when the real issue was always the hero image or the origin. Include compression checks in the same monitoring cadence you already use for Core Web Vitals regressions. A separate ritual that nobody opens after launch week does not help.

FAQ

Does Brotli always improve Largest Contentful Paint?

No. It can shorten download time for text on the critical path when that download was a real bottleneck. It will not fix a slow LCP image, a late-discovered hero, or a high Time to First Byte caused by origin work. Before-and-after lab runs on the same profile show whether the change mattered.

Why does Enable text compression still fail after we turned Brotli on?

The Lighthouse audit looks at individual text resources above a size threshold, not at a single CDN toggle. HTML may be compressed while CSS or JavaScript is not, or the lab path may differ from the URL you checked by hand. Confirm Content-Encoding on each flagged URL.

Can Brotli make PageSpeed scores worse?

Yes. High-quality dynamic compression on every HTML response can raise Time to First Byte. Double compression and compressing already-compressed media waste CPU without helping LCP. Prefer precompressed static assets and moderate settings for dynamic HTML, then retest.

Is gzip still needed if Brotli is enabled?

Yes as a fallback. Keep gzip for clients or hops that do not take br. Verify both encodings on the homepage and other priority pages rather than assuming the dashboard covers every path after a CDN or origin change.

CTA

If the toggle is green and LCP is still slow, treat compression as verified delivery work and name the next bottleneck in plain language. Confirm encoding on the critical path, then put image discovery, Time to First Byte, and render-blocking scripts on the work item with an owner. For enablement detail and MIME allow-lists, use the Watcher compression guide linked above; for caching that sticks beside those bytes, use the Cache-Control piece. When you need scheduled lab history across many client URLs so the next deploy cannot silently drop Content-Encoding, run continuous PageSpeed checks in Apogee Watcher rather than another one-off Insights paste.

References

Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores (Apogee Watcher)
Cache-Control Headers for Web Performance: CDN and Browser Caching That Sticks (Apogee Watcher)
Enable text compression (Chrome for Developers)
Largest Contentful Paint (LCP) (web.dev)
Brotli (MDN Web Docs)

Why CrUX Has No Data for Your Site

Apogee Watcher — Tue, 13 Oct 2026 08:43:52 +0000

“No data” in the Chrome User Experience Report (CrUX) is not a single bug. It is a set of eligibility gates. Google only publishes field percentiles when enough opted-in Chrome sessions meet privacy and quality rules for that origin or URL. PageSpeed Insights and Search Console inherit those gaps. Lab scores from Lighthouse can still look complete on the same screen, which is why teams often treat a blank field block as a tool failure instead of an eligibility outcome.

The sections below walk those gates for client sites: when an origin is missing from CrUX entirely, when a URL is thin while the origin still has data, what to say to the client, and what to monitor until field samples exist. Keep When PageSpeed Insights Shows No CLS or INP for Your URL open for metric-level gaps on a URL that may already show other field rows. For how lab and field clocks differ, use What Are Core Web Vitals? A Practical Guide for 2026 and When to Use Synthetic vs Real User Monitoring as context.

What “no CrUX data” means on a site

CrUX is Google’s public field dataset for how real Chrome users experience popular destinations. It is also the field source behind PageSpeed Insights “Discover what your real users are experiencing” and related Search Console Core Web Vitals views. When CrUX has no data for a query, tools typically show a missing field section, an API NOT_FOUND style response, or a message that Chrome UX Report data was not found. That is different from a red or amber field category. There is no percentile to classify yet.

Agencies usually meet three patterns of “no data” that get mixed together in client chat: (1) origin absent (https://www.client.com or the wrong scheme/host variant is not in the dataset at all); (2) URL thin, origin present (the homepage or a landing path has no URL-level field rows, while origin-level field data still exists); (3) metric missing (some field metrics appear and others do not, for example LCP present and INP absent). Pattern (3) is covered in the PageSpeed Insights “no CLS or INP” guide linked above. What follows focuses on (1) and the client conversation around (2). The practical question is not whether PageSpeed Insights is broken; it is which eligibility gate failed, and what you measure until field data exists. Naming the gate early stops the team from chasing Lighthouse scores that never create field rows.

Chrome UX Report eligibility: user, origin, and page

Google’s CrUX methodology describes three layers that must line up before an experience counts toward page-level field data in PageSpeed Insights and the CrUX API: the user, the origin, and the page. Experiences that meet user and origin rules but not page rules can still feed origin-level data. Pages and origins appear and disappear automatically as eligibility changes. You cannot manually submit a site for inclusion.

User eligibility means the visit came from a Chrome user whose settings allow contribution to the statistics dataset. Not every browser, privacy mode, or visitor is included. CrUX is a sample, not a full count of all traffic in analytics.

Origin eligibility needs two properties: the origin must be publicly discoverable, and it must be sufficiently popular. Discoverability is about whether the root of the origin can be treated as a public page (indexing and successful HTTP status on the root matter; blocked or failing roots are a common trap). Popularity means enough eligible experiences across the origin’s pages for Google to publish anonymised distributions. The exact threshold is not disclosed.

Page eligibility adds that the specific URL must also be popular enough for URL-level distributions. A thin blog post or campaign landing page can lack URL-level CrUX while the origin still has field data. That is expected on long-tail templates.

HTTP versus HTTPS and www versus apex are different origins. So are subdomains. https://shop.example.com does not inherit CrUX from https://www.example.com. When someone says “the client site has no CrUX data,” name the origin string you queried, including scheme and host.

Why an origin is missing from CrUX entirely

Wrong origin string. When tools say the origin is not in the Chrome UX Report, check the origin string before you promise a timeline for field data, then move on to discoverability and sample size. Teams often query http://, omit or add www, or paste a path when the API expects an origin. The CrUX API docs recommend comparing the navigable final URL after redirects with the origin you requested. A 404-style “chrome ux report data not found” response is common when the string is simply wrong.

Root not publicly discoverable. If the root redirects in a way that systems treat as undiscoverable, or if the root fails indexing / HTTP status checks, the origin can drop out even when inner URLs get traffic. Chromium discussion threads have long noted redirect-heavy roots as a reason PageSpeed Insights may show URL-level data after following a redirect while origin-level data is missing. Fix discoverability before you blame sample size alone.

Not enough eligible Chrome traffic. Small sites, brand-new launches, sites that behave like private apps, and niches with little opted-in Chrome usage may never meet popularity. Google does not publish the cut-off. In our experience, waiting a few more PageSpeed Insights refreshes does not create an origin that is structurally ineligible.

Not a ranking penalty by itself. Missing CrUX data is not the same as Search saying the site is slow. It means Google does not have enough public field evidence to publish Core Web Vitals percentiles for that origin or URL slice. Search Console may still show limited or grouped signals. Do not invent a field fail from a blank PageSpeed Insights field block.

URL-level gaps when the origin still has field data

If origin-level field data exists but the client’s main URL shows no URL-level CrUX, you are usually looking at popularity at the page layer, not a dead origin. Homepage and key templates often qualify first; checkout steps, locale paths, and campaign URLs lag. PageSpeed Insights may still show origin-level field categories while the URL field rows are empty. Label that clearly in reports so nobody presents a Core Web Vitals pass for a thin URL using only origin-level fallback.

When the gap is “this metric is missing but others appear,” use the dedicated guide for missing CLS or INP field rows. When the gap is “this URL has no field block but the origin does,” keep synthetic monitoring on that URL and wait for samples. Do not treat origin green as URL green in a client report; say which level the numbers come from.

What to tell the client when field data is unavailable

What we know. Use a short script so the conversation stays honest across accounts. CrUX has no (or incomplete) field data for [origin or URL] right now. That usually means eligibility: discoverability, traffic sample size, or the wrong host/scheme, not a broken lab test. We should confirm the origin string before we talk about traffic volume.

What we do not claim. We are not saying the page passes or fails Core Web Vitals in the field. We do not have the percentiles yet. Lab scores alone cannot fill that gap in a report to the client.

What we will watch instead. Scheduled lab tests on the homepage and other priority URLs (mobile and desktop as separate rows), with budgets and alerts, until URL-level or origin-level field data appears. We will re-check CrUX on a fixed schedule and say when field rows show up. That gives the retainer a measurable trail while field data is empty.

What we need from them. Confirm the public origin (HTTPS, www or apex), that the root is indexable, and which URLs matter for the retainer. If the root redirects oddly or blocks indexing, that is an eligibility fix, not a Lighthouse tweak. Without a correct public root, more lab runs will not create CrUX rows. Pair that script with PageSpeed Insights vs Automated Monitoring: one-off PageSpeed Insights explains a moment, and scheduled runs explain change over time when field data cannot.

What to monitor instead: synthetic budgets on priority URLs

Until field data is available, synthetic (lab) monitoring is what you can report against week to week. Pick a small URL set: homepage, primary landing templates, and checkout or lead paths. Run the same lab profile on a schedule, store history, and alert when LCP, CLS, or related lab metrics cross a budget. How to Schedule PageSpeed Monitoring covers frequency and priority across a portfolio. Synthetic versus real-user roles are spelled out in the synthetic vs RUM guide linked earlier.

Lab data will not replace field eligibility, but it stops the retainer from depending on a blank CrUX panel. When origin or URL field data appears, add it to the same report without throwing away the lab history that covered the gap. In Apogee Watcher, scheduled PageSpeed Insights–backed checks keep that lab trail across client sites while CrUX field rows are absent or partial.

FAQ

Does “CrUX no data” mean the site is slow?

No. It means Google does not have enough eligible Chrome samples (or the origin is not publicly discoverable in the way CrUX requires) to publish field percentiles. Lab tools can still diagnose the template while you wait for eligibility.

Can we force a site into the Chrome UX Report?

No. Inclusion is automatic when eligibility is met. You cannot manually submit an origin. Fix discoverability and grow real Chrome traffic, then re-check later.

Why does PageSpeed Insights show lab scores but no field section?

Lab data comes from Lighthouse on demand. Field data comes from CrUX only when eligibility passes. Both can appear on one PageSpeed Insights page, and either side can be missing independently.

Are subdomains included with the main domain?

No. Each origin is separate. https://blog.example.com needs its own eligibility. Query the origin the client actually cares about, including scheme and host.

How long until field data appears after a launch?

There is no public SLA. CrUX uses a rolling collection window and popularity thresholds. New or low-traffic origins can stay empty for a long time. Plan synthetic monitoring from day one rather than waiting for CrUX before you set budgets.

CTA

If a client site shows CrUX no data, name the origin, check discoverability and host/scheme, and say clearly that field percentiles are unavailable. Then put synthetic budgets on the priority URLs so the retainer still has numbers to report on a schedule. For metric-level PageSpeed Insights gaps, use the no CLS/INP guide. For turning one-off PageSpeed Insights into a schedule across many clients, start with Apogee Watcher or run a check on a public URL from the homepage tools.

References

CrUX methodology (Chrome for Developers)
Overview of CrUX (Chrome for Developers)
How to use the CrUX API (Chrome for Developers)
When PageSpeed Insights Shows No CLS or INP for Your URL (Apogee Watcher)
What Are Core Web Vitals? A Practical Guide for 2026 (Apogee Watcher)
When to Use Synthetic vs Real User Monitoring (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)
How to Schedule PageSpeed Monitoring: Test Frequency and Priority Across a Portfolio (Apogee Watcher)

Multi-tenant PageSpeed monitoring under $100: what agencies actually buy

Apogee Watcher — Sat, 10 Oct 2026 07:37:39 +0000

An agency can open ChatGPT, paste a PageSpeed Insights URL, and get a plausible fix list before lunch. That loop feels like monitoring until the account manager asks for last month’s LCP trend across twenty WordPress clients and nobody has a shared schedule, a named alert owner, or a history that survives holiday leave. Multi-tenant PageSpeed monitoring under $100 is not a cheaper way to run one more free check; it is the purchase of portfolio coverage that still fits a three-digit ops line.

What agencies actually buy in that band is flatter than the vendor shortlist suggests. They buy pooled site and test caps under one organisation subscription, workspaces that keep client brands separate, and reporting an account team can open without pinging the engineer who wrote the cron. The pricing tables and tier caps live on our blog in Affordable Multi-Tenant Performance Monitoring Under $100/Month. The day-to-day shape of one dashboard across many client sites is in Multiple Client Sites, One Dashboard. What follows here is the buying story: what lands on the purchase order when the brief says “keep Core Web Vitals coverage under a hundred dollars.”

What agencies mean by multi-tenant PageSpeed monitoring under $100

In agency language, multi-tenant means one customer account that holds many client organisations, sites, and schedules without minting a new invoice line per domain. Under $100 means the list price for that organisation-shaped monitor fits a three-digit monthly ceiling before you add flagship real-user monitoring (RUM) seats. The job is scheduled lab coverage on money URLs, CrUX context where PageSpeed Insights publishes it, budgets and alerts with named responders, and history long enough for a quarterly business review.

That purchase is easy to confuse with adjacent tools. A free PageSpeed Insights run is a diagnostic, an AI chat that proposes CSS changes is a fix assistant, and an uptime product with a small page-speed monitor allowance is infrastructure health with speed as a sidecar. Agencies that say they want multi-tenant PageSpeed monitoring under $100 usually want the portfolio job, not another one-off score.

If the roster is still under roughly ten priority URLs and one engineer already owns automation, DIY can still hold for a while. Once account managers need shared history and the URL list grows every campaign week, the under-$100 question becomes whether the maths is flat at the organisation or multiplies per monitored slot. That is the fork most agencies hit before they ever open a pricing page.

AI fix loops are not the same purchase as a portfolio schedule

The confusion shows up often on social threads: someone ships an agent that reads Lighthouse findings and opens a pull request, then treats that as “we have monitoring.” Fix loops are useful on sites you can change, yet they are not a substitute for knowing which client homepage went amber on mobile three Tuesdays ago while the developer who owns the agent was offline. The first job remediates; the second proves the roster stayed inside budget when nobody was watching the chat.

A scheduled portfolio monitor answers a different question. It keeps URL inventories current, runs PageSpeed Insights (or equivalent) on a cadence the retainer can defend, stores history the account team can export, and routes budget breaches to someone other than the person who wrote the workflow. The AI loop still belongs in the stack as a remediation layer on sites you deploy, yet it does not replace the system of record for twenty client origins. Buying under-$100 multi-tenant coverage while also keeping an AI fix assistant is a sensible layering story, but buying only the assistant and calling the retainer “monitored” is how QBR slides become screenshots again. The SOW reads cleaner when both jobs are named, so the account team knows which tool answers which question.

What actually lands on the purchase order

When the buy is honest, the purchase order or statement of work names jobs, not logos. Logos without owners still leave the retainer on hero labour. In our experience the under-$100 multi-tenant buy usually includes:

a flat organisation subscription with published site and monthly test caps,
enough workspaces to separate client brands without a second vendor,
scheduled lab runs on agreed money URLs (not “every URL we ever shipped”),
shared history and exports the account team can open,
budgets and alerts with named owners,
a clear non-goal: this is not deep RUM on every brochure domain.

What usually does not land on that same line item: unlimited regions and devices per URL, enterprise RUM seats, or a promise to monitor forty properties when the published site cap is twenty-five. Those gaps belong in a later tier or a thinner URL list, not in silent overages. Saying the non-goals out loud is cheaper than explaining a surprise invoice mid-engagement.

Procurement still needs plain wording for the row. That is a different essay from the purchase shape itself; for translating milliseconds into finance language, see our Hashnode notes on procurement budgets and selling Core Web Vitals monitoring without calling the line item “latency.” Here the decision is simpler: either you are buying organisation-scoped scheduled coverage under a three-digit ceiling, or you are still assembling DIY layers and should say so in the SOW. Ambiguous wording is how “monitoring” gets approved as a free checker and then fails the first multi-client review.

Flat organisation caps versus per-site maths

The under-$100 question collapses to how capacity is counted, and the short table below is the decision frame agencies actually use when three vendor demos arrive in the same week.

Pricing shape	How capacity is counted	Fits under $100 when…	Breaks when…
Per monitored URL / slot	Each URL × device × region consumes a slot	One client, deep lab work	Twenty clients each need homepage + checkout
Per-site SaaS seat	Billing scales with domains	Portfolio stays tiny	Retainer count grows faster than tool budget
Flat organisation cap	Sites, tests, workspaces pool under one subscription	Roster grows inside published limits	You exceed site or test caps and need the next tier
DIY scripts + API	Cash cost is low; labour is not	One engineer owns the pipeline	Quota, reporting, and on-call become unpaid platform work

Agencies that stay under $100 with multi-tenant coverage almost always pick the flat organisation row and accept published caps. Per-slot tools can still win for a single high-traffic property; they are a poor match for “monitor the whole WordPress roster for under a hundred.” DIY wins on cash until the labour row on the same budget is honest. If you cannot name that labour owner, you are not really choosing DIY; you are deferring the purchase. Apogee Watcher’s Professional tier is built as that flat-cap shape under the $100 line at list pricing, with Agency as the published step when site or workspace caps bite. Current numbers live on the pricing page, and the buyer story does not change when a list price moves by a few dollars: you are still choosing organisation caps versus per-site multiplication.

When DIY still wins the budget

DIY PageSpeed Insights API scripts, Lighthouse CI, sheets, and a workflow tool still win the purchase when three conditions hold together: the portfolio is small enough that one person can keep URL lists accurate, nobody expects branded client PDFs from the monitoring layer itself, and the team already treats automation ownership as billable engineering time rather than free evenings.

DIY stops winning the under-$100 comparison when any of these repeat: campaign URLs ship and never join the sheet; the digest dies on leave; account managers rebuild slides from CSV; “nightly for everyone” became “nightly for whoever we remembered” under API quota. At that point a flat-cap portfolio monitor is usually cheaper than the labour you were pretending was free, even when the SaaS line sits at $79 rather than $0. The cash line looks worse; the retainer maths usually looks better. DIY still fits as a layer after the portfolio monitor is in place (Lighthouse CI on templates you ship, manual PageSpeed Insights in teaching conversations), because the purchase under $100 is for the jobs DIY stopped covering reliably, not a mandate to delete every script.

FAQ

Can an agency monitor forty client sites under $100/month?

Often not on a single flat-cap Professional-shaped plan if the published site limit is twenty-five. Realistic under-$100 strategies put priority origins on the paid monitor and leave long-tail pages on free diagnostics, or move to the next published tier when the roster honestly exceeds the cap. Pretending forty equals twenty-five is how retainers over-promise.

Is an AI agent that fixes Lighthouse issues the same as multi-tenant monitoring?

No: an agent remediates findings on sites you can change, while multi-tenant monitoring schedules checks, stores history, and alerts across many client organisations whether or not you control the repository. Most agencies need both jobs named separately rather than collapsing them into one “AI monitoring” line.

What should we put on the purchase order so finance understands the buy?

Organisation-scoped scheduled PageSpeed / Core Web Vitals coverage, included site and test caps, retention, seats, and reporting are the rows that usually clear finance. A three-digit portfolio monitor is a different purchase from a four-hundred-dollar RUM seat on one flagship property. The SOW reads better when it states what is out of scope as well as what is included.

Does multi-tenant PageSpeed monitoring replace uptime tools?

No: uptime and SSL watches answer “is the site reachable,” while portfolio PageSpeed monitoring answers “are LCP, INP, and CLS drifting on money URLs.” Many agencies keep both, because green uptime does not mean green Core Web Vitals, and a green Lighthouse score does not mean the origin stayed up overnight.

Buy the portfolio job, then layer the rest

What agencies actually buy under $100 for multi-tenant PageSpeed monitoring is organisation-shaped coverage: flat caps, shared schedules, and history the account team can defend in a review. AI fix loops, free checkers, CI gates, and selective RUM stay in the stack as layers, yet they are not the same line item. The pricing maths and tier caps sit in Affordable Multi-Tenant Performance Monitoring Under $100/Month. For the product shape of many clients in one view, Multiple Client Sites, One Dashboard is the shorter walkthrough, and you can run a check on a client URL before schedules move into a trial.

References

PageSpeed Insights (Google)
PageSpeed Insights API (Google)
Apogee Watcher pricing (Apogee Watcher)
Affordable Multi-Tenant Performance Monitoring Under $100/Month (Apogee Watcher)
Multiple Client Sites, One Dashboard (Apogee Watcher)
3 Agency PageSpeed Stacks for 2026 (Apogee Watcher)

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To)

Apogee Watcher — Sat, 10 Oct 2026 07:35:19 +0000

Lazy loading images and a fast Largest Contentful Paint (LCP) pull in opposite directions when the same rule is applied to every <img>. Deferring offscreen bytes is usually right, but deferring the hero that PageSpeed Insights later names as LCP is usually wrong. The loading="lazy" attribute is only a browser hint for that trade-off. It is not a global “make the site faster” switch that themes and optimisation plugins can sprinkle without review.

What follows is a decision guide for agencies and product teams: when lazy loading images helps, when it hurts LCP or Cumulative Layout Shift (CLS), and how to prove the change with scheduled lab checks rather than one green Lighthouse run. For the wider image pipeline (formats, sizing, CDN), keep Image Optimisation Strategies for Better LCP Scores open beside this piece. When text paint competes with the hero, Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP still belongs in the same sprint.

What the `loading="lazy"` attribute does

The HTML loading attribute on <img> and <iframe> tells supporting browsers whether to fetch the resource immediately or wait until it is near the viewport. Per MDN’s lazy loading guide and web.dev’s browser-level image lazy loading article, loading="lazy" is the deferred path and loading="eager" (or omitting the attribute for images that default to eager) is the immediate path. Native lazy loading replaced most custom Intersection Observer snippets for ordinary image galleries, yet the browser still decides how far ahead of the viewport it starts the fetch.

That nuance matters for agency audits. “We enabled lazy loading” can mean native attributes, a WordPress filter that injects loading="lazy" on every attachment, a Shopify theme setting, or a JavaScript library that swaps data-src after scroll. All of those can defer the LCP candidate if the first screen image is included, so the mechanism belongs in the ticket before anyone blames hosting.

Native lazy loading is progressive enhancement: older browsers ignore unknown attributes and load images normally. That is fine for bandwidth on modern Chrome and Safari, yet it does not excuse shipping a hero with loading="lazy" on the browsers that dominate your CrUX population. Progressive enhancement is not permission to defer the element field users actually paint as LCP.

Why lazy-loading the LCP image hurts Largest Contentful Paint

LCP marks when the largest above-the-fold content element becomes visible. On marketing and commerce pages that element is often a hero image, product photo, or poster frame. If that resource is marked loading="lazy", the browser may delay the request until layout work suggests the image is “near” the viewport, even though it already is. The result shows up as higher resource load delay in Lighthouse and PageSpeed Insights, and as a worse lab LCP, which Google’s common LCP misconceptions post still flags as a frequent own-goal.

Search threads for “lazy load LCP” are full of Elementor, WordPress, and theme support tickets for the same pattern: a plugin or theme applied lazy loading sitewide, the logo or banner became LCP, and scores collapsed until someone excluded the first image. Weston Ruter’s comparison demos of lazy-loaded versus eager LCP images make the timing difference visible without arguing theory. Disabling lazy load on the LCP image is a first triage step in those threads, not a last resort after a CDN rewrite.

The fix is usually boring. Once PageSpeed Insights or Chrome Performance names the LCP element, remove loading="lazy" from that image (and any identical mobile/desktop sources in <picture>). fetchpriority="high" fits when you know the LCP URL early; a preload fits only when the markup path cannot put that URL in the initial HTML. Preloading and lazy-loading the same URL fights itself.

When lazy loading images is the right default

Lazy loading images is the right default for content that starts offscreen: article body photos after the fold, related-product grids, footer badges, long category galleries, and comment avatars. Those bytes should not compete with the critical path on first paint. On a twenty-image blog post, native lazy loading can cut early bandwidth sharply on mobile without changing the story the user sees first.

On retainer sites we treat eager versus lazy as a short policy, not a plugin toggle. Eager (no lazy, or explicit eager) covers the LCP candidate, a logo when it is LCP, the primary above-the-fold product image, and any image inside the first viewport on common breakpoints. Lazy covers everything that requires scroll or a tab change before it matters.

That policy needs a mobile-width check as well as desktop. An image that looks “below the fold” on a large monitor can sit in the first screen on a phone, and that phone traffic often dominates CrUX. Audits that only run at 1440px tend to lazy-load the wrong assets for the field population.

Above-the-fold images, `fetchpriority`, and eager loading

“Above the fold” is not a CSS property; it is a judgement about what appears in the initial viewport for your primary breakpoints. When that judgement is wrong, lazy loading above the fold recreates the LCP delay problem even if the CMS labelled the block “content” rather than “hero.” Breakpoints disagree more often than teams expect, especially between a design mockup and a phone-width lab run.

For the confirmed LCP image, loading="lazy" comes off (or loading="eager" overrides a stack that injects lazy by default), accurate width and height or aspect-ratio CSS reserve layout space, and fetchpriority="high" fits when the image is the clear LCP candidate and other resources are not already marked high. An appropriately sized file matters so eager does not mean downloading a 4000px PNG; the image optimisation post linked above covers formats and srcset. Theme and page-builder defaults often invert that list: every attachment gets lazy, none get fetch priority, and the hero is still a huge JPEG. Attribute policy belongs ahead of another CDN plan. A smaller eager hero usually beats a huge lazy hero on LCP, even when the waterfall looks “optimised” in a plugin dashboard.

Iframes, video, and other lazy media caveats

The loading attribute also applies to <iframe>, so below-the-fold embeds (maps, secondary YouTube players, chat widgets) are usually sensible lazy candidates. A first-screen video iframe that is also your LCP or a large layout box can delay paint and still risk CLS if dimensions are missing. A facade (poster image + click-to-load) fits heavy third-party players when the embed is not required for the first view. That pattern pairs with Cross-Origin YouTube Embeds and CLS.

Background images in CSS cannot use loading="lazy". If the LCP element is a CSS background, attribute fixes will not help; you need a real <img> or <picture> in the document, or a different LCP strategy. JavaScript lazy libraries that leave src empty until hydration can also create late discovery worse than native lazy, especially when the library bundle itself is deferred. Video posters and <video> elements have their own preload behaviour, so “lazy images are on” does not automatically cover posters and iframes. The LCP node type in the trace matters, because a poster frame can win LCP while the checklist only mentions <img loading>.

Lazy loading and CLS: reserve space first

Lazy loading does not cause CLS by itself; missing dimensions do. When a lazy image finally loads into a box with no reserved height, the page shifts and CLS rises. That failure mode is easy to miss in a lab run that never scrolls to the image, then appears in field data when users do scroll.

Lazy loading images still needs intrinsic size hints: width and height attributes, width/height in CMS media metadata, or CSS aspect-ratio on the container. Responsive srcset still needs a consistent aspect ratio across candidates. If a theme wraps images in a collapsing container until load, the container belongs in the ticket before anyone argues about Core Web Vitals thresholds. Hero images that are eager still need reserved space: eager versus lazy is an LCP timing decision, while dimensioning is a CLS decision, so agencies should treat them as two checklist rows rather than one vague “images” ticket.

Lab vs field when lazy loading hides LCP regressions

A single PageSpeed Insights run on the homepage can look fine after you “enable lazy loading,” especially if the lab viewport and your CMS preview disagree about what is on screen. Field LCP in CrUX or the PageSpeed Insights field section can still worsen when real devices, slower networks, and cookie banners change which element wins LCP. Mobile users may also hit a lazy hero that desktop lab never marked as LCP, so one desktop screenshot is not proof.

Scheduled lab checks on money URLs (home, category, product, key landing pages) before and after attribute changes, on both mobile and desktop strategies, keep the claim honest. LCP element identity matters more than the score alone. If the LCP node switches from a heading to an image after a deploy, that image’s lazy attribute is the next place to look. For portfolio monitoring across many client sites, Apogee Watcher keeps those lab histories in one place so an attribute change does not vanish into a one-off PDF.

Lab green and field amber can both be honest, because lab may scroll less, block third parties differently, or use a colder cache. When lazy loading is in the diff, read resource load delay for the LCP URL in the lab diagnostics before you close the ticket. If load delay stays high after “optimisation,” suspect the attribute before you rewrite the media query set.

Agency checklist before you ship “lazy everything”

Before a theme update or “speed plugin” goes to production, a short pass usually pays for itself. The current LCP element and time on mobile and desktop for each money URL set the baseline, then templates and plugin settings get a search for global loading="lazy" injection. The LCP candidate (and logo if needed) stays off the lazy list, and width/height or aspect-ratio get confirmed on lazy and eager images alike. Lab checks run again until the LCP element and load delay move the right way; field LCP is watched for the 28-day window after release rather than declared fixed on day one; and the exclusion list is written down so the next plugin install does not re-lazy the hero. That pass is cheaper than a month of “we improved PageSpeed” conversations while CrUX stays amber, and it gives the next developer a written exclusion list instead of tribal knowledge about “the hero must stay eager.” The list belongs in the repository or the retainer runbook so plugin reinstalls do not undo it quietly.

FAQ

Should every image use loading="lazy"?

No: lazy loading images is for offscreen content, while the LCP image and other critical above-the-fold images should load eagerly. Sitewide lazy defaults from CMS plugins are a common source of LCP regressions on retainers.

Does loading="lazy" on the LCP image always break field data?

Not always, because browsers and viewports differ, but it is a high-risk pattern that Lighthouse and many case studies associate with longer LCP. The LCP candidate usually stays eager unless you have measured no harm on mobile and desktop for that template.

Is native lazy loading better than a JavaScript lazy library?

For ordinary images, native lazy loading is usually enough and avoids waiting on a script. Libraries still appear for older patterns or fancy placeholders; they must not leave the LCP src undiscovered until late JavaScript runs.

Can lazy loading improve CLS?

Indirectly, only if it reduces contention and you already reserve space. Lazy loading without dimensions often worsens CLS when images pop in during scroll, so sizing belongs ahead of another lazy-loading toggle.

What about logos?

If the logo is the LCP element (common on simple brochure sites), it should stay eager. If a large hero is LCP and the logo is small, the logo can follow normal theme defaults, but still reserve space to avoid header shift.

Ship eager heroes, lazy galleries

Lazy loading images remains one of the strongest bandwidth defaults on long pages, as long as the LCP image stays eager, dimensions protect CLS, and iframes or video facades are handled on purpose. The loading="lazy" attribute is a scalpel for offscreen media, not a blanket for every attachment ID in the CMS. The exclusion list travels with the theme update so the next speed plugin cannot quietly reverse it.

For format and sizing work around the same LCP element, continue with Image Optimisation Strategies for Better LCP Scores. When font files compete with the hero, use Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP. To keep attribute changes honest across a client roster, start a free trial or run a check on a money URL before and after you remove lazy from the hero.

References

Browser-level image lazy loading for the web (web.dev)
Lazy loading (MDN)
Common misconceptions about how to optimize LCP (web.dev)
HTML attribute: loading (MDN)
Image Optimisation Strategies for Better LCP Scores (Apogee Watcher)
Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP (Apogee Watcher)
Lighthouse: Don't lazy load Largest Contentful Paint image (GTmetrix / Lighthouse audit explanation)
Cross-Origin YouTube Embeds and CLS: What Publishers Can Actually Fix (Apogee Watcher)

What PageSpeed monitoring stack should an agency run in 2026?

Apogee Watcher — Thu, 08 Oct 2026 06:55:41 +0000

The roster hits twenty client sites, yet the “monitoring stack” is still a shared folder of PageSpeed Insights screenshots, one engineer’s n8n flow nobody else can edit, and a promise to check Core Web Vitals before the QBR. That is not a PageSpeed monitoring stack for agencies; it is a coping habit with a product roadmap glued on. The gap shows up the first time two account managers need last month’s LCP trend and only one person knows which sheet tab is current.

What agencies should run in 2026 is usually simpler than the vendor shortlist suggests. A multi-site portfolio monitor works best as the system of record for lab history, budgets, and alert ownership, while DIY PageSpeed Insights scripts and Lighthouse CI stay as layers on sites you deploy. Paid real-user monitoring (RUM) belongs on the one or two flagship properties where field depth pays for itself; everything else is optional seasoning.

The full recipes and failure modes live on our blog in 3 Agency PageSpeed Stacks for 2026, and the feature checklists sit in Comparing PageSpeed Monitoring Tools. What follows here is the opinionated pick: which stack to run first when the account team asks for a decision, not another comparison table.

What a PageSpeed monitoring stack is (for agencies)

A stack is a small set of jobs with named owners, not a shopping cart of logos. For agency work those jobs are predictable:

scheduled lab coverage on money URLs (PageSpeed Insights or equivalent),
history an account manager can open without asking engineering,
budgets and alerts that fire for someone other than the person who wrote the cron,
optional CI gates on templates you ship,
optional RUM depth where a snippet and seat cost are justified,
a clear split between uptime/health tools and Core Web Vitals work (they are not the same purchase).

If any of those jobs live only in one person’s head, you do not have a stack yet. You have a hero, and heroes do not scale across twenty organisations. Named owners in the tool turn the same checklist into something the account team can run without a private Slack ping.

The default stack most agencies should run in 2026

Default: portfolio monitor first for multi-client PageSpeed / Core Web Vitals coverage, DIY and CI as supporting layers, RUM as a selective add-on.

That default fits when you manage roughly ten or more client sites, sell performance or SEO retainers that mention LCP/INP/CLS, and cannot put a RUM snippet on every brochure domain. The monitor owns schedules, URL inventories, budgets, and shared history; Lighthouse CI stays in the repositories you control; PageSpeed Insights remains the lab dialect clients already recognise in Search Console conversations. Once those three layers are named, the weekly argument stops being “which vendor is best” and becomes “which job is failing.”

Apogee Watcher is built for that portfolio shape, and peers exist in the same job class. The recommendation is the shape, not a claim that only one vendor can fill it, so layer rather than rip out: keep DebugBear, SpeedCurve, or Calibre where you already pay for flagship RUM, and skip pretending every client needs that seat maths on day one. The unpaid work is deciding which sites never get a snippet, not collecting logos.

Buying “the best RUM” and rolling it out everywhere sounds tidy until seat cost, privacy reviews, and install friction kill portfolio coverage before the first amber LCP is fixed. Staying on DIY forever sounds frugal until URL lists drift, quotas collide, and reporting hours eat the retainer. The default sits between those failure modes on purpose.

When DIY PageSpeed Insights + sheets is enough

DIY (PageSpeed Insights API or self-hosted Lighthouse, Lighthouse CI, Sheets or Notion, n8n or cron) is enough when the portfolio is small, one engineer already owns automation, and nobody expects branded client PDFs from the monitoring layer. It also fits when you only need merge gates on sites you deploy, with occasional API checks elsewhere. Outside that band, DIY becomes unpaid platform work dressed up as thrift.

DIY stops being a sound primary system when any of these show up more than once a month:

campaign URLs ship and nobody added them to the sheet,
the digest email dies because the workflow owner is on leave,
account managers rebuild slides from CSV because clients will not open the spreadsheet,
“nightly for everyone” became “nightly for whoever we remembered” under API quota.

When those signals repeat, a portfolio monitor becomes the primary system and DIY stays as a layer. That is DIY versus managed PageSpeed without the false choice of deleting your pipelines: managed here means shared schedules and history, not abandoning Lighthouse CI on the templates you still ship. The roster can grow without the monitoring story living in one export again.

When to add RUM on flagship sites only

RUM earns its place when a single property funds deep field investigation: high revenue, stubborn INP, or a client who already bought SpeedCurve, DebugBear, or Calibre and needs you to operate it. The portfolio monitor still covers the long tail so brochure sites keep scheduled lab history, because paying for flagship depth while the rest of the roster goes dark is how retainers look busy and still miss regressions. Selective RUM is a budget decision, not a purity test.

Waiting for perfect RUM coverage before any monitoring starts is the other trap. Multi-site PageSpeed monitoring fails when teams refuse to schedule anything until every domain has a snippet, while lab schedules plus CrUX context from PageSpeed Insights or Search Console (where eligible) already answer most retainer questions. Field depth is a zoom lens, not the only camera.

Jobs the stack must cover (without a vendor matrix)

Treat the table below as a go-live checklist: if a row has no owner and no tool, the stack is incomplete, so fill those gaps before another logo appears on the slide.

Job	Default owner in 2026
Scheduled lab on money URLs	Portfolio monitor (or DIY if still under ~10 priority URLs)
Merge protection on shipped templates	Lighthouse CI in your repos
Shared history for account teams	Portfolio monitor (not a private n8n)
Budgets / alerts with named responders	Portfolio monitor
Deep field waterfalls	RUM on 1–2 flagships only
Reachability / SSL / status pages	Separate uptime suite (layer; do not confuse with CWV)

When someone asks for “the best tools,” the tools comparison is the right hand-off. When they ask “what should we run next quarter?,” the default above plus the three recipes on agency PageSpeed stacks are the operational answer. The first question is research; the second is delivery.

FAQ

What PageSpeed monitoring stack should an agency run in 2026?

For most multi-client agencies, a portfolio PageSpeed / Core Web Vitals monitor is the system of record, DIY scripts and Lighthouse CI stay as layers, and RUM sits only on flagship sites that justify the seat. DIY-only still fits if the roster is tiny and automation is already owned, so write that choice into the retainer scope and sales and delivery argue from the same default.

Is PageSpeed Insights alone enough?

As a diagnostic, yes. As the only continuous system for fifteen retainers, no: you still need schedules, history, budgets, and someone other than the founder to receive the alert.

Do we need RUM on every client site?

Usually not. RUM belongs where revenue or stubborn field issues pay for it, while the long tail stays on scheduled lab monitoring and CrUX where Google publishes it.

How is this different from a tools roundup?

A roundup lists features; a stack names jobs and a default order of purchase. Use both: pick the shape here, then validate vendors against a feature checklist.

CTA

If the current “stack” is still screenshots and a private automation, this quarter is a good moment to make a portfolio monitor primary and write DIY exit criteria into the runbook. A free Apogee Watcher trial is useful when you want multi-tenant schedules and budgets without rebuilding the sheet again, while RUM and uptime tools stay where they already earn their keep.

References

3 Agency PageSpeed Stacks for 2026 (DIY, Portfolio Monitor, RUM + Monitor) (Apogee Watcher)
Comparing PageSpeed Monitoring Tools: Features Agencies Need (Apogee Watcher)
PageSpeed Insights API (Google)
Lighthouse CI (GoogleChrome)
When to Use Synthetic vs Real User Monitoring for Performance (Apogee Watcher)

WordPress Speculation and Prerender Plugins vs Core Web Vitals

Apogee Watcher — Thu, 08 Oct 2026 06:51:19 +0000

WordPress speculative loading started as a Performance Team feature plugin and landed in WordPress 6.8 as Core behaviour for most public front ends. The browser still does the work through the Speculation Rules API: JSON rules tell Chromium-class browsers which URLs to prefetch or prerender before the click finishes. Agencies then face a practical choice. Keep Core’s conservative prefetch, install (or leave) the Speculative Loading plugin with stronger prerender defaults, or layer a third-party wordpress prefetch / prerender plugin on top of both.

That choice is not “faster equals always better.” Speculative loading can make the next navigation feel instant and can improve Interaction to Next Paint (INP) on the path the user actually takes. It can also pull HTML, scripts, and third-party tags for pages nobody visits, inflate bandwidth on mobile, and confuse first-visit Largest Contentful Paint (LCP) or Cumulative Layout Shift (CLS) when teams measure the wrong navigation. What follows is a WordPress-centric how-to for retainers: when speculation rules help Core Web Vitals, when a wordpress prerender plugin hurts, and how to verify with lab schedules instead of a single homepage paste.

For broader WordPress monitoring context, see WordPress Performance Monitoring: A Complete Guide. When the site is still slow after delivery tweaks, keep Why Your WordPress Site Is Slow (It Is Not Always Hosting) in the runbook: speculation will not fix plugin asset storms on the current URL.

What WordPress speculative loading is (prefetch vs prerender)

Speculation rules are progressive enhancement. Unsupported browsers ignore the script. Supported Chromium browsers (Chrome, Edge, Opera at current versions) may act on the rules subject to memory, Data Saver, and other heuristics. Treat every rule as a hint, not a preload contract.

Two modes matter on WordPress sites:

Mode	What the browser roughly does	Typical CWV upside	Main risk
Prefetch	Fetches the document (and often related resources) early	Shorter wait before paint on the next navigation	Extra bytes if the user never clicks
Prerender	Loads the page in a hidden background state, ready to activate	Near-instant next navigation; load CLS can finish before activation; INP can look better because work finished early	Runs client JS earlier; analytics and personalisation bugs; higher CPU/memory; more wasted work on wrong guesses

Chrome’s documentation is explicit: prerender can drive near-zero LCP and reduce CLS for the activated view when load shifts happen before the user sees the page, and it can improve INP because interaction lands on a warmer page. The same docs warn against over-prerendering because of memory and network cost. WordPress Core and the Speculative Loading plugin are different opinions about how aggressive that trade-off should be by default.

Older wordpress prefetch plugins (Flying Pages-style link hover prefetch, theme “instant page” scripts, some cache-plugin toggles) sit adjacent to this story. Some now emit Speculation Rules; others still use older link-rel or mouseover fetch patterns. For agency audits, treat “prefetch on hover” and “Speculation Rules prerender” as different levers with different failure modes.

Core 6.8 defaults vs the Speculative Loading plugin

WordPress 6.8 enables speculative loading on the front end by default when the visitor is logged out and the site uses pretty permalinks. The effective Core starting point is prefetch with conservative eagerness: speculation starts around the beginning of a click. That is intentionally close to configurations large CDNs have used at scale. It buys a short head start with a low rate of unused fetches.

Core disables the feature for logged-in users and when pretty permalinks are off, because query-string “action URLs” (cart adds, favourites, state changes via GET) are common in the plugin ecosystem and must not be guessed into. URLs with query parameters are excluded by default. Filters such as wp_speculation_rules_configuration and wp_speculation_rules_href_exclude_paths let engineers raise eagerness, switch to prerender, or exclude path patterns such as /cart/*.

The Speculative Loading plugin remains useful after the Core merge. Its defaults are more aggressive: prerender with moderate eagerness (typically on link interaction), plus a Settings → Reading UI for mode and eagerness. The plugin also documents opt-ins for authenticated front-end users when the host can absorb the load (object cache strongly recommended). On WordPress 6.8+, the plugin builds on Core’s API rather than replacing the whole idea; agencies should know which layer owns the live configuration before they “install one more speed plugin.”

HTTP Archive and CrUX analysis cited in the Core note reported roughly a 1.9% median lift in LCP passing rate for sites that enabled speculative loading via the feature plugin over the study window. That is a population signal, not a promise that every client homepage will drop 200 ms in lab LCP after you flip prerender to moderate.

When speculation helps navigation INP and next-page LCP

Speculation pays off when users move through predictable internal links: article → related post, category → product, docs hub → guide. The win shows up on the destination navigation, not on the cold first entry from search or ads. Agencies selling “instant site” from a single PageSpeed Insights homepage score are measuring the wrong clock.

Helpful patterns we see in practice:

Core prefetch / conservative on content sites with clean pretty permalinks and few GET action URLs.
Plugin or filter prerender / moderate on a small set of high-confidence destinations (primary nav, top product cards) after cart and account paths are excluded.
Chromium-heavy audiences (many B2B and ecommerce dashboards) where progressive enhancement still covers Safari/Firefox users without harm.

INP can improve on the activated page because main-thread work and hydration had a head start. Next-page LCP can look excellent when the LCP image and text were already in the prerender. Neither outcome excuses a heavy first HTML response or third-party tags on the URL the user opened first. Speculation multiplies whatever that destination loads; it does not delete unused JavaScript.

When a WordPress prerender plugin hurts first-visit LCP, CLS, or bandwidth

Problems show up when teams install a wordpress prerender plugin (or raise Core to prerender/eager) and then judge success only from a warmed multi-page lab session, or when unused prerenders compete with the current page for CPU and network on mid-range mobiles.

Common failure modes:

First visit from search or paid landings stays untouched. Speculation does not prerender the entry URL from Google. If mobile LCP is poor on that landing template, fix the LCP resource and server path first.
Eager or broad prerender on mega-menus. Hovering a header with forty links can queue many documents. Bandwidth and main-thread cost rise; field INP on the current page can worsen while “next page” demos look great in the office.
Cart, checkout, account, and nonce URLs. Prefetching a GET add-to-cart or wishlist URL can change state without a full navigation. Core excludes many query-string URLs; custom rewrite “action URLs” still need wp_speculation_rules_href_exclude_paths (or the plugin’s plsr_speculation_rules_href_exclude_paths) and no-prefetch / no-prerender classes on blocks.
Analytics and personalisation. Prerender runs page JS early. Providers that do not wait for activation can double-count or set cookies too soon. Chrome documents delaying analytics until activation; many major tags already do this, but custom theme JS often does not.
CLS “improvements” that hide layout debt. Load CLS that finishes during prerender may not appear at activation, which is good for users and scores, but it can mask unreserved embeds that still break when prerender is cancelled or unsupported. Keep fixing reserved space.
Stacked plugins. Core + Speculative Loading + Flying Pages + a cache plugin’s “preload links” toggle can emit overlapping hints. Pick one speculation owner per site.

If lab LCP on the entry URL got worse after enabling prerender, check whether the test device is fighting background prerenders while measuring the current document. If field LCP improved only on internal navigations, say so in the client report; do not imply organic landing LCP moved the same way. Separating those clocks is what keeps the retainer honest when a plugin changelog promises “instant LCP.”

Safe settings for agency WordPress retainers

Use a staged default rather than a global “enable prerender” checkbox on every brochure site.

Site type	Starting point	Escalate only when
Marketing / blog, pretty permalinks	Core prefetch / conservative (6.8 default)	Internal nav is the KPI and Chromium share is high
WooCommerce / membership	Core default + exclude `/cart/*`, checkout, account, wishlist paths	Host capacity proven; action URLs audited
High-traffic content with clear next clicks	Speculative Loading plugin or Core filter to prerender / moderate on selected patterns	Analytics and tag managers verified under prerender
Logged-in app-like front end	Leave disabled until object cache and exclusions exist	Product owners accept extra authenticated load

Agency checklist before go-live:

Confirm WordPress version and whether Core already injects speculation rules (View Source for a speculationrules script type).
Inventory other prefetch/prerender plugins and cache-plugin toggles so one owner remains.
Exclude cart, checkout, logout, nonce, and any GET action paths.
Decide logged-in behaviour explicitly (usually off).
Document mode and eagerness in the retainer runbook so the next plugin cleanup does not reset them.

Theme and page-builder “instant load” marketing copy is not a configuration record. Write the actual mode (prefetch vs prerender) and eagerness (conservative / moderate / eager) into the handoff. The next engineer should not have to reverse-engineer View Source to learn what you enabled.

How to verify with lab schedules and field data

Measure two journeys separately.

Entry URL (first visit): PageSpeed Insights or scheduled Lighthouse on the money landing template with a cold load. Speculation should not be the primary fix here. Watch LCP resource, TTFB, and third-party blocking.

Internal navigation: From a listing or article, follow a primary link in Chrome with Speculation Rules debugging enabled (Chrome documents debugging flows for prerender). Compare activation feel and performance panel timings with rules on versus off. For portfolio retainers, keep scheduled lab history on both the entry URL and one representative destination URL so a plugin change cannot hide behind a single score.

Field data (CrUX via PageSpeed Insights or Search Console) mixes navigations. A rise in origin LCP after enabling prerender may reflect faster subsequent views, a changing Chrome population, or unrelated template work. Annotate the speculation change in your monitoring notes the same week you ship it. WordPress Performance Monitoring: A Complete Guide covers ongoing schedules; use those schedules so “we turned on prerender” is a dated event next to the charts.

Apogee Watcher fits the verification loop for agencies: multi-site lab schedules on entry and destination URLs, budgets when LCP regresses after a plugin change, and history account managers can open without re-running a laptop test. Speculation remains a WordPress and browser feature; monitoring tells you whether the retainer got faster for the journeys you sell. Without that history, every prerender debate restarts from a single screenshot.

FAQ

What are WordPress speculation rules?

They are Speculation Rules API instructions WordPress prints so compatible browsers can prefetch or prerender likely next URLs. WordPress 6.8 includes a conservative prefetch default for logged-out users on pretty-permalink sites.

Is the Speculative Loading plugin still needed on WordPress 6.8?

Often yes if you want prerender, moderate eagerness, or a wp-admin UI. Core’s default is safer and milder. The plugin (or Core filters) is the escalation path, not a required install on every site.

Will a wordpress prerender plugin fix homepage LCP from Google?

Usually not by itself. Speculation targets subsequent navigations. Fix the landing template’s LCP resource, CSS, and server response for entry traffic first.

Can speculative loading break WooCommerce?

It can if add-to-cart or other GET action URLs are guessed. Cart, checkout, and account paths belong on the exclude list, and Core’s conservative defaults are the safer starting point until those exclusions are proven. POST-based cart flows remain the healthier pattern regardless of speculation.

Does wordpress prefetch help Safari and Firefox?

Those browsers ignore Speculation Rules today. Users still get a normal navigation; they simply miss the head start. Do not promise cross-browser instant navigation.

How do we know it helped Core Web Vitals?

Compare scheduled lab tests on entry versus destination URLs before and after the change, and annotate field dashboards with the ship date. Destination LCP or INP gains matter only when entry-URL scores and bandwidth stay within the budgets you already sold.

If a client’s WordPress stack already ships Core 6.8, start by documenting the live speculation configuration before installing another prerender plugin. Keep lab schedules on the URLs you sell in the retainer, and treat speculation as a navigation optimisation with explicit exclusions. Start a free Apogee Watcher trial when you want those WordPress URLs monitored across clients without pasting PageSpeed Insights by hand after every plugin toggle.

References

Speculative Loading in 6.8 (Make WordPress Core)
Speculative Loading (WordPress plugin) (WordPress Performance Team)
Prerender pages in Chrome for instant page navigations (Chrome for Developers)
Implementing speculation rules (Chrome for Developers)
Speculation Rules API (MDN)
WordPress Performance Monitoring: A Complete Guide
Why Your WordPress Site Is Slow (It Is Not Always Hosting)

TTFB Is Not Only the Server: The Unattributed Slice Agencies Should Name in Reports

Apogee Watcher — Wed, 07 Oct 2026 06:58:57 +0000

Time to First Byte is often treated as a synonym for back-end time. In the browser it is wider: everything from the start of the navigation until the first byte of the final response arrives. Redirects, DNS, connection setup, TLS inside that connection, network latency, CDN and origin work, and browser overhead can all sit inside the same number. When agencies paste a high Waiting (TTFB) bar into a client slide and write “server response,” they may be describing only the part the waterfall labels clearly.

Unattributed Navigation Overhead (UNO) is the residual after you subtract the phases Navigation Timing can name. Harry Roberts documented the metric and the agency reporting problem in UNO Is Underrated, building on Tim Vereecke’s framing: measure the whole journey to the first byte, subtract every attributed phase, and keep whatever is left. The leftover may be hard to pin on one owner. It is still time users paid for. Naming it stops missing milliseconds from being assigned to origin PHP by default.

What follows is a how-to for agencies who already walk delivery-layer TTFB in Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. When the attributed server phase is the real bottleneck after the residual is accounted for, hand off to TTFB Won't Go Down? Server-Side Culprits Beyond the Theme.

What unattributed navigation overhead (UNO) is

UNO is not a browser-provided metric. It is a calculated remainder:

UNO = TTFB − redirect − DNS − connection − (request → responseStart)

In Navigation Timing terms, TTFB for this purpose is responseStart − startTime (or the nearest equivalent your RUM tool exposes). Subtract the visible redirect span, DNS lookup, full connection span (TCP plus TLS when the API folds them together), and the span from requestStart to responseStart. What remains, floored at zero, is UNO.

That residual can include browser initialisation, delays while unloading the previous page, disk or cache access, resource contention, and timings hidden by cross-origin restrictions. It is not another name for redirect time. Hidden cross-origin redirects are a common source of UNO, but treating every unexplained millisecond as “a tracking redirect” repeats the same attribution mistake with a different label.

CrUX can tell you field TTFB is poor. It cannot decompose that time into phases, so it also cannot compute UNO. Without a Navigation Timing breakdown from real navigations (or a careful local reproduction), all of TTFB is effectively unattributed in the Google field dataset.

Navigation Timing TTFB breakdown: redirect, DNS, connection, request

A useful client-facing breakdown starts with the named hops, then shows the residual. Keep the language plain enough for a non-engineer stakeholder, and precise enough that engineers can map it back to DevTools. If the slide only shows total Waiting, every remedy conversation defaults to hosting.

Phase	What it usually covers	Where teams over-blame
Redirect	Visible same-origin (or opted-in) redirects before the final response	Ignoring hidden cross-origin hops that never appear in `redirectCount`
DNS	Domain lookup for the final host	Blaming “DNS” when connection or residual dominates
Connection	TCP + TLS setup for the final host	Calling all Waiting “TLS” when connect is short
Request → first byte	Time from sending the request until `responseStart`	Calling this alone “the server” when UNO is large
UNO	Everything in TTFB not in the rows above	Leaving it unnamed so it inherits the server label

Lighthouse and PageSpeed Insights still surface high first-byte time under diagnostics such as Reduce initial server response time. That audit name is historically server-shaped. It does not prove that PHP, WordPress cron, or database load owns the whole bar. Pair the lab label with a Navigation Timing breakdown before you write the remediation paragraph. PageSpeed Insights versus automated monitoring explains why a single paste also misses hour-of-day and campaign-mix effects that change which phases dominate.

For DNS, TLS, HTTP version, and CDN cache rules that actually move the attributed network phases, stay inside the network performance guide. The focus here is the slice those guides do not name: the unattributed remainder.

Why redirect, DNS, and connection phases still leave a gap

Navigation Timing often fails to add back up to TTFB. Gaps exist between timestamps. Some timings are deliberately hidden. The browser still includes that time in TTFB; it simply will not (or cannot) attribute it in the redirect, DNS, or connection fields.

Cross-origin redirects are the clearest example. When a navigation includes a cross-origin hop, Navigation Timing has traditionally reported redirectStart, redirectEnd, and redirectCount as zero. Overall TTFB still includes the hop. The redirect vanishes from the breakdown and lands in UNO. Common journeys include affiliate or ad tracking wrappers, URL shorteners, social outbound wrappers, and even http:// to https:// on the same hostname. A change of scheme is a change of origin. What looks like a harmless first-party canonicalisation can still hide redirect timing.

Synthetic tests that open the final landing URL never walk that chain. CrUX folds the cost into TTFB. Agencies comparing a clean lab homepage to a paid-search landing path then argue past each other: one chart shows a short Waiting bar, the other shows field TTFB that “must be the server.” Segment by landing page, campaign, and referrer when UNO rises. Reproduce representative journeys in DevTools instead of assuming origin compute.

Chrome has started improving opt-in visibility for some cross-origin redirect timing via Timing-Allow-Origin on redirecting servers. Adoption across shorteners and campaign platforms will be uneven for a long time. Even with better visibility, UNO still matters: not every residual is a redirect, and not every redirect will opt in.

How to calculate UNO from Navigation Timing

On a page you control, open DevTools Console after a hard navigation and read the navigation entry. The shape matches Harry’s public snippet:

const navigation = performance.getEntriesByType('navigation')[0];
const span = (end, start) => Math.max(0, end - start);

const uno = Math.max(0, Math.round(
  (navigation.responseStart - navigation.startTime) -
  span(navigation.redirectEnd, navigation.redirectStart) -
  span(navigation.domainLookupEnd, navigation.domainLookupStart) -
  span(navigation.connectEnd, navigation.connectStart) -
  span(navigation.responseStart, navigation.requestStart)
));

Do not treat a single Console value as portfolio truth. Cache warmth, device, connection, and previous-page unload all move the residual. For client work, collect UNO as both a duration and an occurrence count in RUM (or in a small beacon you control), then segment. Chart it beside redirect, DNS, connection, attributed server waiting, total TTFB, and Largest Contentful Paint. When LCP is TTFB-sensitive, unexplained first-byte time is not academic; it delays paint. A Quick Way to Fix LCP: Four Changes That Cut Time to Paint still applies after you know whether the early wait is attributed server time or UNO.

For a quick sanity check of hidden redirects, open a shortened URL that lands on a known host, then compare redirectCount (often zero) with a non-zero UNO. Contrast that with a same-origin trailing-slash redirect that does enumerate. The point is not the demo URL; it is that visible redirect count alone is a poor map of real campaign traffic.

What agencies should name in client reports when TTFB looks “server-only”

Client reports need a labelled residual. A practical slide or appendix row looks like this:

Total TTFB (lab on the money URL, plus field TTFB when CrUX exists).
Attributed phases you can defend: redirect (visible), DNS, connection, request→first byte.
UNO as “unexplained navigation time inside TTFB,” with a one-line definition.
Next action by owner: campaign/redirect chain, delivery (DNS/TLS/CDN), or origin application.

Write the sentence that prevents the wrong ticket. Prefer: “Field TTFB is elevated; Navigation Timing leaves X ms unattributed after redirect, DNS, connection, and request timing. We will reproduce campaign landings before we open a hosting upsizing ticket.” Avoid: “Server response is slow” when the only evidence is a total TTFB bar.

Use Performance Budget Thresholds Template so money URLs have explicit first-byte budgets, then annotate whether breaches are attributed server time or UNO-heavy. Schedule lab coverage on priority URLs with PageSpeed monitoring test frequency and priority across a portfolio so you are not inventing the breakdown from a single Friday afternoon paste. Watcher’s multi-tenant schedules keep those lab baselines comparable week to week; they do not replace RUM for UNO segmentation, and you should say that plainly when the residual only appears on campaign landings.

When the attributed server phase is the real bottleneck

Name UNO first. Then look at the request→responseStart span (and any RUM “server” or Waiting attribution your tool exposes after known network phases). If that attributed slice dominates, and DNS/connect/UNO are small, origin work is the honest story.

That is when TTFB Won't Go Down? Server-Side Culprits Beyond the Theme becomes the runbook: WP-Cron storms, cold PHP workers, missing object cache, database load, backup plugins at peak. Do not start there when UNO or hidden redirect chains explain most of the bar. Do not skip there when the residual is already named and still tiny beside a long attributed wait.

Pattern	Likely owner	First move
High UNO on campaign/referrer segments; lab direct URL fine	Redirect / landing path	Reproduce chain; talk to tracking/shortener owners
High DNS or connect; UNO modest	Delivery / network	[Network performance checklist](https://apogeewatcher.com/blog/network-performance-dns-tls-http-cdn-cache-rules)
High request→first byte; UNO and connect small	Origin application	[Server-side TTFB checklist](https://apogeewatcher.com/blog/ttfb-wont-go-down-server-side-culprits-beyond-theme)
Everything elevated after a browser-major mix shift	Population / measurement	Annotate releases; do not only ship origin tickets

TTFB is not a Core Web Vital, but it still gates LCP because HTML must arrive before the largest content can paint. Keep that link explicit in reports so stakeholders do not treat first-byte work as vanity once LCP is the slide title. Naming UNO does not replace LCP fixes; it stops you spending the LCP budget on the wrong first-byte owner.

Why CrUX and one-off lab runs miss the unattributed slice

CrUX reports field TTFB without the Navigation Timing phases needed for UNO. Useful as a population signal; useless as a phase budget. One-off PageSpeed Insights or Lighthouse runs on the final URL skip affiliate and shortener chains, warm different caches, and label the wait with server-shaped language. Neither artefact is wrong for what it measures. Both are incomplete if your clients’ money arrives through wrapped links.

Proper RUM (commercial, open-source, or homegrown) that retains navigation timestamps, page-view context, and dimensions is how UNO becomes actionable. You need duration and occurrence count, not only a p75. You need breakdowns by landing page, campaign, referrer, browser, device, and connection. Synthetic schedules still matter for regression detection on known URLs; they answer a different question. When to use synthetic versus real user monitoring is the pairing guide when a stakeholder asks which chart to trust.

FAQ

What is unattributed navigation overhead?

It is the part of Time to First Byte left after subtracting the redirect, DNS, connection, and request-to-response phases exposed by Navigation Timing. It is a residual metric, not a single browser-reported timer. You calculate it so unexplained time has a label instead of inheriting the server narrative.

Is UNO the same as redirect time?

No. Hidden cross-origin redirects often inflate UNO, but browser work, cache access, unload delays, and other gaps can sit there too. Do not rewrite “unattributed” as “redirects we have not counted yet” without evidence from reproduction and referrer or campaign data.

Why are some redirects missing from Navigation Timing?

For privacy and origin-boundary reasons, cross-origin navigation redirects have traditionally reported zero redirect timing and count even when TTFB includes them. Scheme changes such as HTTP to HTTPS count as cross-origin even on the same hostname. The hop still costs users; only the breakdown loses it.

Can CrUX report UNO?

No. CrUX exposes field TTFB without the phase timestamps required to calculate the residual. Use RUM or a Navigation Timing beacon on your own traffic if you need the split.

How should we talk about this in a client report?

Show total TTFB, the named phases, and a labelled UNO row. State the next owner (campaign path, delivery, or origin) instead of defaulting every elevated first-byte chart to “upgrade hosting.” One honest residual row prevents a week of origin tickets that never touch the real journey.

When do we optimise the server instead?

When the attributed request→first-byte (or tool-equivalent server) phase dominates after UNO and network phases are small. Use the server-side TTFB checklist. That hand-off is intentional: UNO naming first, origin work second.

If your retainers still describe every Waiting bar as server time, add UNO to the next report cycle on two or three campaign-heavy URLs and compare it with a direct lab navigation. Keep scheduled lab baselines on those URLs while you wire RUM (or a small beacon) for the Navigation Timing breakdown clients never see in CrUX alone. Start a free Apogee Watcher trial when you want those lab checks on a multi-tenant schedule without pasting PageSpeed Insights by hand.

References

Unattributed Navigation Overhead (UNO) Is Underrated (Harry Roberts / CSS Wizardry; metric coined by Tim Vereecke)
Web-Perf Wednesday 006 – Faster Browser Releases Change Your RUM Population (CSS Wizardry)
Navigation Timing Level 2 (W3C)
Time to First Byte (TTFB) (web.dev)
Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules
TTFB Won't Go Down? Server-Side Culprits Beyond the Theme
A Quick Way to Fix LCP: Four Changes That Cut Time to Paint
PageSpeed Insights versus automated monitoring
Performance Budget Thresholds Template
PageSpeed monitoring: schedule test frequency and priority across a portfolio
When to use synthetic versus real user monitoring

Oh Dear alternative? Uptime green is not Core Web Vitals portfolio monitoring

Apogee Watcher — Tue, 06 Oct 2026 06:58:22 +0000

The uptime dashboard is green, SSL is fine, and the status page is quiet, yet a client still forwards a PageSpeed Insights screenshot where mobile Largest Contentful Paint sits in Needs improvement. Nobody can explain how both truths coexist. Searching for an Oh Dear alternative feels like the next step, but that query usually returns more uptime and white-label status products, not a Core Web Vitals portfolio monitor.

The gap is not that Oh Dear is weak at its job; it is treating reachability as proof that shoppers experience a fast page. Green uptime and healthy Core Web Vitals are different clocks, so conflating them is how retainers buy the wrong primary tool. The search phrase “Oh Dear alternative” then steers buyers back onto the uptime shelf when the screenshot was about experience.

What “Oh Dear alternative” usually means in search

Oh Dear sits in a crowded agency niche: uptime checks, SSL and DNS health, broken-link crawls, status pages, and often a scheduled Lighthouse or response-time layer under one login. When agencies outgrow a free ping tool, “Oh Dear alternative” is a natural buying phrase. The search box does not know whether you meant “better status pages” or “finally watch LCP.”

Open that SERP today and you mostly see other agency uptime suites: white-label status pages, client PDF uptime reports, multi-region pings, SSL and domain expiry. Those products compete on the uptime axis, and they are sensible shortlists when the failure mode is “the site returned an error” or “the certificate expired on Friday night.” That shelf is crowded for a reason: downtime still burns retainers.

They are a weak answer when the failure mode is “HTTP 200, but LCP and Interaction to Next Paint are amber across the money path.” That job needs scheduled lab history, CrUX field context where Google publishes it, URL inventories that keep up with CMS churn, and budgets written in Core Web Vitals units. Uptime clones do not become that stack because the brochure says “performance,” so the buying phrase and the failure mode have to match before you shortlist.

Uptime green is not a Core Web Vitals signal

Uptime answers whether this origin responded successfully from the checker’s vantage point, while Core Web Vitals answer how real Chrome users (field) or a throttled lab browser (Lighthouse / PageSpeed Insights) experienced load and interactivity on specific URLs. Both can be “true” on the same Tuesday and still describe different risks. That mismatch is what the green dashboard hides.

A site can stay up while:

the LCP image ships late on mobile category templates,
a new extension blocks the main thread on add-to-cart (INP),
a promo bar shifts layout without reserved space (CLS),
third-party tags grow for a campaign week that never shows as downtime.

None of those failures flip a classic uptime monitor red, but they do show up in PageSpeed Insights lab runs, in CrUX when the URL is eligible, and in client SEO conversations that already use Google’s Good / Needs improvement / Poor bands. Calling the origin “healthy” because the ping is green trains account teams to ignore the metric set the retainer actually sells. The screenshot arrives anyway; the dashboard just never warned anyone.

For the wider lab-versus-field map, see When to Use Synthetic vs Real User Monitoring for Performance. Synthetic uptime and synthetic Lighthouse are both lab-shaped, but they measure different artefacts, so keep the labels honest in the pack. Readers who skip that distinction spend the next quarter arguing about which green is “real.”

What Oh Dear-class suites cover (and what they leave out)

Oh Dear-class products are genuinely strong when you need one place for “is it up?”, certificate risk, and a client-facing status story. Many also run HTTP timing on the same fetch path, or a daily Lighthouse score on selected URLs, and those extras matter. They still sit beside uptime economics: pricing and product roadmaps usually scale with sites and check frequency, not with multi-URL Core Web Vitals portfolios and discovery.

What they typically leave as a separate purchase:

continuous PageSpeed Insights history across many client organisations,
CrUX field bands stored next to lab runs for the same URL set,
automated discovery when a CMS adds templates you never pasted into the monitor list,
budgets and alerts written primarily against LCP, INP, and CLS rather than millisecond TTFB on the uptime probe.

Daily Lighthouse is closer to “pagespeed” than a ping, but it is still not the same as a portfolio programme built around Google’s PageSpeed Insights API and field context. Mixing “we have Lighthouse in the uptime tool” with “we monitor Core Web Vitals for SEO” without labelling the difference is how false confidence survives a QBR. One score on one URL is a check; a retainer needs a series.

A fair pairwise feature split (Oh Dear versus a CWV-first portfolio tool) lives in Oh Dear vs Apogee Watcher: Uptime Suite vs Core Web Vitals Portfolio Monitoring. Use that matrix when you are already comparing vendors; what follows here is the job split before you open the spreadsheet. The spreadsheet is useless if you still think both columns measure the same risk.

When to keep the uptime suite and add a CWV layer

Keep (or replace within) the uptime axis when the pager must fire because HTTPS is down, certificates expire, or clients need a branded status page. An Oh Dear alternative that stays on that axis is a valid purchase.

Add a Core Web Vitals portfolio layer when you sell performance retainers, report LCP/INP/CLS in client decks, or manage many origins where the expensive failure is slow-but-up. Layer rather than rip out. Agencies that already run Oh Dear (or Pingdom, Better Stack, UptimeRobot, and similar) usually need a second product for CWV depth, not a single suite that pretends both jobs are free.

Replace Oh Dear only when you never needed the uptime bundle and the trial proved you were paying uptime economics for a CWV-only brief. That is a narrower case than the search phrase suggests.

A practical split for retainers

Job	Prefer
Reachability, SSL, status pages	Oh Dear or another uptime / health suite
Cold-load lab + opportunity text	PageSpeed Insights lab or scheduled PSI-style monitoring
SEO-facing field categories	CrUX via Search Console / PageSpeed Insights field
Many client sites, CWV budgets, discovery	Multi-tenant PageSpeed / CWV portfolio monitor

Write both truths in the pack with labels: “Uptime (reachability)” versus “Lab PageSpeed / CrUX (experience).” Green on the first column does not clear the second, and clients notice when the PDF pretends otherwise.

FAQ

Is searching for an Oh Dear alternative the right move for Core Web Vitals?

Only if you also need a better uptime suite. If the pain is amber LCP on money pages while pings stay green, shortlist a CWV portfolio monitor instead of another status-page vendor. The search phrase and the failure mode have to match.

Does Oh Dear’s Lighthouse check cover Core Web Vitals monitoring?

It covers a scheduled lab score on the URLs you configure, but it does not automatically equal a multi-client PageSpeed Insights programme with field context and discovery. Treat it as a useful signal on the uptime product, not as the whole CWV retainer.

Should we rip out Oh Dear and switch to a PageSpeed tool?

Usually no. Keep uptime where downtime is the risk, and add CWV monitoring where experience is the risk. Rip-and-replace only when the uptime bundle was never the job.

Why do uptime tools say “performance” then?

Because HTTP timing and Lighthouse scores are performance-adjacent. The word still collapses three jobs (reachability timing, lab audits, field Core Web Vitals) into one brochure line. Ask which artefact the alert fires on before you trust the label.

What to do next

A useful starting pass is to list every production origin on the retainer, mark which ones already have uptime coverage you trust, and note last lab LCP/INP/CLS (plus whether CrUX exists) for each money-path URL. If uptime is green and lab or field is amber, you do not need another status page first. You need a scheduled CWV layer and a report that names both clocks.

For the pairwise Oh Dear versus portfolio decision, use Oh Dear vs Apogee Watcher. For how synthetic lab fits beside real-user field data, keep Synthetic vs Real User Monitoring in the same pack. Two links, two jobs, one retainer language.

References

Oh Dear (product)
Oh Dear vs Apogee Watcher: Uptime Suite vs Core Web Vitals Portfolio Monitoring (Apogee Watcher)
When to Use Synthetic vs Real User Monitoring for Performance (Apogee Watcher)
Understanding Core Web Vitals and Google search results (Google Search Central)

Is Vercel Speed Insights enough for Core Web Vitals monitoring?

Apogee Watcher — Sun, 04 Oct 2026 06:54:50 +0000

Agencies often turn on Vercel Speed Insights for a Next.js client, see route-level Core Web Vitals, and assume monitoring is “done.” For that Vercel project, the product is genuinely useful. For a book of WordPress, Shopify, Magento, and mixed hosts, it is not enough. Core Web Vitals monitoring means knowing when Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift moves on the URLs you promised to watch. Host RUM answers that for instrumented Vercel deployments. It does not schedule lab checks across thirty other origins or give you one organisation view for account leads.

What follows draws a clean line: when Speed Insights is enough, when you still need PageSpeed Insights field (Chrome UX Report) and scheduled lab coverage, and how agencies usually split the stack. For the synthetic-versus-field vocabulary, see When to Use Synthetic vs Real User Monitoring. For how agencies assemble DIY, portfolio, and RUM-plus-monitor recipes, see 3 Agency PageSpeed Stacks for 2026.

What Vercel Speed Insights actually measures

Vercel’s Speed Insights is first-party real-user monitoring for projects on Vercel. It collects Core Web Vitals and related timings from visitors on your deployed previews and production. The dashboard supports filters by route, device, time range, and (on paid Speed Insights tiers) richer breakdowns such as element-level views and geography. Vercel also stresses shorter windows than Google’s typical 28-day Chrome UX Report aggregation, which helps engineering see the effect of a deploy sooner.

That is RUM scoped to the Vercel runtime and their collector. It is not Lighthouse. It is not a cold lab load from Google’s PageSpeed Insights workers. It is not a multi-tenant agency console for sites that never deploy to Vercel.

Free and Plus packaging change how much detail you see (Vercel documents Real Experience Score on every plan, with fuller Core Web Vitals breakdowns on Plus). Pricing and feature gates move; treat the docs as source of truth for what your client’s plan includes.

Where Speed Insights beats PageSpeed Insights for engineering

PageSpeed Insights field data is Chrome UX Report: Chrome users, eligibility thresholds, origin or URL when sample size allows, rolling roughly 28-day window. That dataset matters for SEO conversations because it aligns with what Google publishes for page experience. It is a poor day-to-day triage tool when you need “which route broke after yesterday’s merge?”

Speed Insights wins for Vercel engineering when you need:

Route-level RUM on your own traffic, including browsers CrUX undersamples.
Faster iteration windows after a deploy or branch, instead of waiting on a long CrUX lag.
Attribution that names routes (and, on higher tiers, elements) instead of a single origin badge.

Vercel’s own Core Web Vitals guides make the same split: use CrUX / PageSpeed Insights field for the SEO-facing view; use Speed Insights (or another RUM path) for engineering triage on the Vercel app. Treat those as complementary field sources, not substitutes.

Where it is not enough for agency portfolios

Agencies fail when they generalise from one Vercel client to the whole book.

Hosts that are not on Vercel. Most retained sites still run on WordPress hosts, Shopify, Magento, static elsewhere, or custom VPS stacks. Speed Insights does not cover those origins. You still need scheduled lab tests (PageSpeed Insights API / Lighthouse-class runs), CrUX where published, and a place to store history per client organisation.

No shared multi-tenant workflow. Account leads need one login, roles, budgets, alerts, and client-ready reports across many domains. A Vercel project dashboard per deployment is the wrong primitive for that job.

Lab diagnosis still matters. RUM tells you users felt a regression. Lab (and PageSpeed Insights opportunities) still help engineers reproduce LCP and CLS causes on a cold load. Speed Insights does not replace that diagnostic loop.

CrUX remains the SEO reference. When a sponsor asks “what does Google show?”, answer with Search Console or PageSpeed Insights field / CrUX, not only your first-party RUM chart. The two can disagree (browser mix, window length, URL versus origin). Label both.

Enough when: the engagement is one Vercel-hosted product, engineering owns the Vercel dashboard, and you only promise route-level RUM plus occasional CrUX checks for SEO.

Not enough when: you sell portfolio monitoring across many client hosts, need discovery and schedules without a snippet on every domain, or need white-label reporting for non-Vercel properties.

A practical stack split

Job	Prefer
Route RUM on a Vercel Next.js app	Vercel Speed Insights (or equivalent first-party RUM)
SEO-facing field categories	CrUX via Search Console / PageSpeed Insights field
Cold-load lab + opportunity text	PageSpeed Insights lab or scheduled PSI-style monitoring
Many client sites, one org, budgets/alerts	Multi-tenant portfolio monitor (see the agency stack recipes linked above)

A common agency pattern: keep Speed Insights on the Vercel flagship; put scheduled lab-plus-CrUX monitoring on the rest of the portfolio; use CrUX as the shared SEO language in retainer packs. That matches the “RUM + monitor” stack idea without pretending one product covers every host.

Do not disable Speed Insights to “avoid duplicate tools.” Duplicate tools are fine when they answer different questions. Duplicate unlabelled numbers in a client PDF are not.

FAQ

Does Speed Insights replace PageSpeed Insights?

No. Use Speed Insights for Vercel RUM triage. Use PageSpeed Insights (or Search Console) when you need CrUX-aligned field categories and lab diagnostics on a public URL.

Can I rely on Speed Insights alone for SEO?

Risky. Google’s published field story is CrUX. First-party RUM helps you ship fixes faster; it is not the same dataset Search Console shows.

What if only one of twenty clients is on Vercel?

Instrument that one with Speed Insights. Monitor the other nineteen with a host-agnostic schedule. Do not wait for every client to migrate to Vercel before you watch regressions.

Is free Speed Insights “enough”?

Enough for a basic Real Experience Score on a Vercel project may be. Enough for element-level and geographic triage depends on the paid tier your client enables. Check Vercel’s current plan matrix before you promise those views in a retainer.

What to do next

List every production origin on the retainer. Mark which ones deploy on Vercel. Turn on Speed Insights (and the right paid tier) only where the runtime supports it. For every other origin, pick a scheduled lab-plus-CrUX path and write budgets in the same units you already use in client reviews. Put both field sources in the pack with labels: “Vercel RUM (this app)” versus “CrUX / PageSpeed Insights field (SEO window).”

If you are choosing the portfolio half of the stack, start from the three recipes in 3 Agency PageSpeed Stacks for 2026 and the lab-versus-RUM framing in When to Use Synthetic vs Real User Monitoring.

References

Speed Insights Overview (Vercel docs)
How to improve Core Web Vitals (Vercel)
How Core Web Vitals affect SEO (Vercel)
3 Agency PageSpeed Stacks for 2026 (Apogee Watcher)
When to Use Synthetic vs Real User Monitoring for Performance (Apogee Watcher)

Brotli and Gzip Compression: Shrink Text Assets Without Breaking PageSpeed Scores

Apogee Watcher — Sat, 03 Oct 2026 06:54:43 +0000

The CDN dashboard shows compression enabled. A host panel lists Brotli as on. A lab run on the priority URL still flags Enable text compression, or the Performance score barely moves while Time to First Byte gets worse after someone raised the Brotli level on dynamic HTML. In our experience the gap is rarely “nobody turned compression on.” It is a mismatch between which responses are compressed, which layer applies Content-Encoding, and what Lighthouse actually measures on that URL.

What follows is a delivery guide for teams who already walk DNS, TLS, HTTP, and cache rules in Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. That piece explains where edge and origin sit on the path to first byte. Here the focus is Brotli compression and gzip for text assets: how teams enable Brotli with a safe fallback, and how to keep PageSpeed Insights and Lighthouse honest after the change. Pair it with Cache-Control Headers for Web Performance. Caching decides whether bytes are reused; compression decides how small those bytes are on the first download.

What Brotli and gzip change on the response path

HTTP compression shrinks the body of a response before it travels over the network. The client advertises what it accepts in Accept-Encoding (commonly br, gzip, and deflate). The server or CDN chooses an encoding and returns Content-Encoding: br or Content-Encoding: gzip when it compresses. The browser decompresses before parsing HTML, CSS, or JavaScript. Transfer size drops; the uncompressed size the parser needs does not.

That distinction matters for Core Web Vitals work. Smaller transfer size can shorten download time for render-blocking CSS and for JavaScript that sits on the critical path. It does not rewrite a slow origin query, a third-party script, or an oversized Largest Contentful Paint image. Compression is a bandwidth and decode trade-off on text responses. It sits beside Time to First Byte and LCP resource priority; it is not a substitute for the fixes in A Quick Way to Fix LCP: Four Changes That Cut Time to Paint.

Lighthouse and PageSpeed Insights surface missing compression under audits such as Enable text compression (uses-text-compression). Google’s older Enable Compression guidance still frames the same idea for agencies reading mixed reports: text resources that benefit from gzip or Brotli should arrive compressed when the client supports it. Gzip compression on the web is still the safety net when Brotli is unavailable on a hop; both belong in the same verification pass.

Brotli vs gzip for web delivery (and when gzip still wins)

Brotli versus gzip is not a purity contest. Brotli usually produces smaller text payloads than gzip at comparable quality settings, especially for HTML, CSS, and JavaScript. Gzip is older, universally supported for compressed HTTP responses, and cheap to encode at moderate levels. Most modern browsers prefer Brotli when the server offers br and the negotiation succeeds.

Dimension	Brotli (`br`)	Gzip
Typical text ratio	Often smaller than gzip at similar effort	Good baseline; larger than Brotli for many CSS/JS bundles
Encode CPU	Higher at high quality levels on dynamic content	Lower at common levels (for example gzip 4–6)
Browser support for HTTP	Broad for current Chrome, Firefox, Safari, Edge	Universal for compression-capable clients
Best use	Precompressed static assets; edge or origin for text	Fallback when `br` is unavailable; always-on safety net
Risk if mis-set	High dynamic Brotli quality can inflate TTFB	Double-gzip or gzip on already-compressed binary wastes CPU

For static fingerprinted files, precompressing at build time (.br and .gz siblings) and serving the matching encoding avoids burning origin CPU on every request. For HTML that changes per request, compression at the CDN or reverse proxy with a moderate quality setting usually works better, with gzip kept as the fallback for clients or intermediaries that do not take Brotli. That split (offline high effort for static, moderate online effort for HTML) is what keeps transfer size down without quietly raising Time to First Byte.

Zstandard (zstd) appears in some CDN and origin stacks as another encoding. It is useful optional coverage where the edge already supports it. Brotli and gzip remain the baseline pair until client and intermediary support for your traffic mix is proven. Delivery checklists we use with client sites still verify gzip, Brotli, and zstd where the stack claims them.

Which responses to compress (and which to leave alone)

The responses that benefit are those whose payload is mostly text and is not already in a compressed container. A practical allow-list looks like this, and it is what we expect to match Lighthouse’s text-compression audit when the page is otherwise healthy:

text/html
text/css
text/javascript / application/javascript / application/x-javascript
application/json / application/ld+json
image/svg+xml
text/xml / application/xml (where XML is not already packaged)
Often font/woff is already compressed; woff2 is compressed by design, so wrapping it again rarely helps
application/wasm may benefit in some stacks once size and CPU are checked on a representative URL

Brotli or gzip as a blanket over JPEG, PNG, WebP, AVIF, MP4, or other already-compressed media rarely shrinks transfer size and can add latency and CPU. Agencies still hit this when a “compress everything” host preset includes image/* or when a plugin gzip-filters the whole response stack. The win is smaller text on the wire, not a second envelope around media that is already compressed.

Partial compression is another common miss. HTML compressed at the edge while CSS and JavaScript miss Content-Encoding still fails Lighthouse’s text-compression audit for those URLs. The audit looks at individual text resources above a size threshold, not at a single dashboard toggle labelled “Brotli.”

How to enable Brotli with a gzip fallback at origin and CDN

Enabling Brotli only helps when negotiation survives to the browser. Clients send Accept-Encoding with br and gzip. Stacks that prefer Brotli when available, and fall back to gzip without serving identity encoding for large text bodies, clear audits more reliably than a lone dashboard switch.

Origin and reverse proxy patterns

Common patterns we see work in delivery:

NGINX with Brotli module. Configuration that turns brotli on; for the MIME types above, sets a moderate brotli_comp_level for dynamic responses, and keeps gzip on; with overlapping types so clients without br still compress. Google’s ngx_brotli and NGINX Brotli docs cover module loading; production still needs a check that the module is loaded, not only present in a staging snippet.
Apache. mod_brotli / mod_deflate with explicit AddOutputFilterByType (or equivalent) for the text MIME list works when filter chains do not compress twice.
Application middleware. Express compression, Laravel or Rails middleware, and similar helpers often default to gzip. Brotli belongs here only when the library and deployment target support it; otherwise compression at the proxy in front of the app is the cleaner path.
Precompressed static assets. Emitting .br / .gz at build, mapping Accept-Encoding to those files, and setting Vary: Accept-Encoding keeps shared caches from mixing encodings.

CDN and edge

Many CDNs offer automatic Brotli and gzip for cacheable text. Three facts in the live response matter more than the marketing checkbox, because PageSpeed Insights tests the hostname you give it, not the checkbox label in a vendor UI:

The origin response for HTML, CSS, and JavaScript either arrives compressed or is compressible at the edge without being marked uncacheable for the wrong reason.
The edge returns Content-Encoding: br or gzip on a cold and warm fetch from a client that sends both encodings.
Vary: Accept-Encoding (or CDN-equivalent vary behaviour) is present so caches store separate variants.

Cloudflare and similar platforms document serving Brotli from origin and compression rules. Reading the vendor guide is not enough if an origin Cache-Control: private or a page rule disables optimisation on the hostname you test in PageSpeed Insights. Compression and caching interact; the Cache-Control post covers HTML versus fingerprinted assets in more depth.

Fix Lighthouse “Enable text compression” without breaking PageSpeed scores

The Lighthouse audit Enable text compression fails when text resources are large enough to benefit from compression and arrive without a recognised Content-Encoding. Clearing the audit means those URLs gain compression on the lab client’s path. It does not mean raising Brotli quality to the maximum on every HTML response.

A workflow that keeps scores honest usually looks like this:

Pull the audit URLs from the Lighthouse JSON or PageSpeed Insights diagnostics list (HTML document, CSS, and JavaScript files named in the audit).
Request each URL with Accept-Encoding: br, gzip and inspect Content-Encoding, Content-Type, and transfer size in DevTools or curl -H "Accept-Encoding: br, gzip" -I.
Turn compression on for the MIME types that failed, while leaving images and already-compressed fonts alone.
Re-run the same lab profile (same device and throttling) after deploy, watching Performance score and Time to First Byte / LCP, not only the green tick on the audit.
If Time to First Byte rises while transfer size falls, lower dynamic compression quality or move compression to precompressed static files and edge caching so origin CPU is not on the critical path for every HTML hit.

PageSpeed scores break when teams chase the audit alone: double compression, compressing PDFs or images, or saturating the origin so first byte suffers. The audit is a checklist item. The score reflects the full lab experience. Both belong in the same verification loop.

Compression mistakes that hurt TTFB, LCP, or lab scores

These failure modes show up repeatedly on agency portfolios:

Double compression. Origin gzip plus CDN Brotli on an already-encoded body, or a plugin that gzip-filters output already compressed by the proxy. Symptoms include unexpected Content-Encoding chains, larger transfer sizes, or decode errors. One compression layer per response class, with a clear owner (origin or edge), avoids that class of failure.

Wrong MIME allow-list. Compressing image/jpeg or skipping text/css because a preset used outdated type strings. Allow-lists that match what Lighthouse actually requests on the page clear the audit faster than generic host presets.

High Brotli quality on uncached HTML. Quality 11 on every HTML response can cost more CPU milliseconds than the download saves on a fast connection. Moderate levels suit dynamic HTML; high effort fits offline precompression of static assets.

Missing Vary: Accept-Encoding. Shared caches serve a gzip body to a Brotli-capable client (or the reverse), which produces confusing lab versus browser results and intermittent audit failures.

Assuming the CDN checkbox covers third-party hosts. Lighthouse flags text files on your origin and on hosts you control in the waterfall. A script or stylesheet on a tag manager domain you do not configure will keep failing until that host compresses or the file leaves the critical path.

Expecting compression alone to fix LCP. If the LCP element is a hero image, Brotli on HTML and CSS helps the document and styles, but the image path still dominates. Compression works alongside the LCP levers in the quick-fix guide, not instead of them.

Verify Content-Encoding on live URLs after every deploy

Compression belongs in the same habit as Cache-Control: prove it on the live hostname after release, then watch it on a schedule so a platform default does not silently revert.

A useful checklist per priority URL:

The HTML document and two to three render-blocking CSS/JavaScript URLs from the lab waterfall.
Content-Encoding of br or gzip from a client that sends both in Accept-Encoding.
Transfer size materially smaller than content size for those text files.
LCP images left alone by the compression layer (no accidental re-encoding).
A PageSpeed Insights or Lighthouse run before and after so the Enable text compression audit and the Performance score share the same baseline.
A re-check after CDN rule changes, host panel toggles, and major theme or plugin releases.

Apogee Watcher fits as the scheduled lab layer across client sites. After Brotli and gzip are configured correctly, scheduled re-tests on priority URLs catch a host migration or “optimisation” plugin that drops Content-Encoding without a ticket. Monitoring layers onto the stack you already run; a single red audit is not a reason to rip out an existing CDN.

For a starting point on one URL before you standardise a portfolio, apogeewatcher.com/check is enough. For ongoing multi-site schedules and budgets after compression and cache work, start a trial. Either path keeps the same question in view: does Content-Encoding still match what you configured last week?

FAQ

What is Brotli compression on the web?

Brotli is a compression format (content coding br) commonly used for HTTP responses. For web performance it mainly shrinks text assets such as HTML, CSS, and JavaScript when the client advertises support in Accept-Encoding. MDN’s glossary entry is a short reference; production work still needs header checks on live URLs.

Should I enable Brotli or gzip?

Both. Brotli when negotiation succeeds, gzip when the client or path cannot use br. Disabling gzip solely because Brotli exists leaves older clients and some intermediary hops on identity encoding for large text bodies.

Why does Lighthouse still say Enable text compression?

A dashboard toggle is not enough. Individual text resources above the audit threshold must arrive with Content-Encoding: br or gzip on the lab request path. Headers and MIME type on each failing URL usually explain the miss faster than another host-panel screenshot.

Does Brotli improve Core Web Vitals?

It can reduce download time for text on the critical path, which may help LCP and related lab metrics when those files were the bottleneck. It will not fix a slow origin alone or an uncompressed LCP image. Before-and-after runs on the same lab profile show whether the change mattered.

Can compression make PageSpeed scores worse?

Yes. Excessive dynamic compression CPU, double compression, or compressing the wrong asset types can raise Time to First Byte or add work without shrinking useful bytes. Lab tests after every change, with precompression preferred for static files, catch those regressions early.

Do I need zstd as well?

Only when your CDN and clients benefit from it in production. Brotli and gzip remain the baseline pair for agency portfolios until zstd support is verified for your traffic.

Compression belongs in the same delivery contract as caching and CDN rules. Naming the layer that owns encoding, limiting it to text that benefits, and verifying Content-Encoding on live URLs after every deploy keeps the setup honest. When Brotli and gzip are configured that way, Lighthouse’s Enable text compression audit tends to clear without trading away Time to First Byte or inventing a false PageSpeed win.

Ready to keep compression and Core Web Vitals honest across a client portfolio? Start a free trial of Apogee Watcher or run a single URL check.

References

Enable text compression (Lighthouse) (Chrome for Developers)
Enable Compression (PageSpeed Insights / Google)
Brotli compression (MDN Glossary) (MDN)
gzip compression (MDN Glossary) (MDN)
NGINX Brotli module (NGINX Docs)
google/ngx_brotli (GitHub)
google/brotli (GitHub)
Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules
Cache-Control Headers for Web Performance: CDN and Browser Caching That Sticks
A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

Why is PageSpeed Insights worse than my local Lighthouse score?

Apogee Watcher — Fri, 02 Oct 2026 07:53:43 +0000

You run Lighthouse in Chrome DevTools on a client URL and see Performance 94. You paste the same URL into PageSpeed Insights and the lab Performance score drops to the sixties. The audits look related. The numbers do not. Neither result is “lying.” They ran the same Lighthouse family of audits on different machines, with different throttling behaviour, and often with different cache and extension state.

That gap shows up constantly in agency Slack threads and client calls. People then optimise against the friendlier number, or treat PageSpeed Insights as broken. What follows explains why PageSpeed Insights lab data is often worse than a local Lighthouse run, how to compare fairly, and which result to trust for client work. For how Lighthouse turns metrics into a score, see How Lighthouse Performance Scores Are Recorded and Calculated. For when one-off PageSpeed Insights checks stop being enough, see PageSpeed Insights vs Automated Monitoring.

Same Lighthouse engine, different machines

PageSpeed Insights lab results are Lighthouse runs on Google’s shared infrastructure. Chrome DevTools Lighthouse and the Lighthouse CLI run on your laptop. The audit set is related. The CPU is not.

Lighthouse records a benchmarkIndex (device score) that describes how fast the host can run JavaScript before the audited page load. A powerful developer machine often scores much higher than the PageSpeed Insights workers. Mobile runs also apply a CPU slowdown (commonly described as about 4×) so the lab approximates mid-tier phones. Four times a fast laptop is still faster than four times a slower shared worker. Long tasks, Total Blocking Time, and Interaction to Next Paint proxies move first when the host is slower. Largest Contentful Paint and other paint timings can move too when layout and script work stretch.

Network path and test location add another layer. PageSpeed Insights picks from a small set of regions. Your laptop sits on your office fibre next to a nearby CDN edge. Cold loads on a distant worker see different latency even before CPU differences matter.

So a lower PageSpeed Insights lab score does not prove the site “got worse overnight.” It often proves you compared two hosts.

Why Total Blocking Time jumps on PageSpeed Insights

Total Blocking Time is especially sensitive to host speed. It sums the portions of long tasks that exceed 50 milliseconds during page load. On a fast local CPU, many tasks finish just under that line and never enter Total Blocking Time. On a slower PageSpeed Insights worker, the same work crosses 50 milliseconds and the metric spikes. Performance score then falls even when First Contentful Paint only moved a little.

That pattern is well documented in developer threads and Lighthouse discussions: throttling and slower hosts push borderline tasks over the threshold. Simulated throttling (PageSpeed Insights lab default) is also not the same as packet-level throttling used by some other lab tools. Treat PageSpeed Insights lab numbers as one environment, not as a perfect replay of your MacBook.

Local pollution: extensions, cache, and warm state

Local Lighthouse can look better for reasons that have nothing to do with the production HTML.

Chrome extensions inject scripts and change network behaviour. A warm disk cache and service worker can skip work that a cold PageSpeed Insights load always pays. Cookie banners and consent layers may already be dismissed on your profile. Antivirus, VPN, and other processes on the machine add noise. DevTools may warn when it detects conditions that skew the audit; PageSpeed Insights starts from a cleaner cold profile on Google’s side.

Use an Incognito window with extensions disabled, or the Lighthouse CLI against a clean profile, when you need a local baseline. Even then, expect residual host-speed differences versus PageSpeed Insights. A clean local profile removes extension noise; it does not turn your laptop into Google’s lab workers.

Do not mix PageSpeed Insights field data with local lab

PageSpeed Insights shows two stories on one page. The top block is Chrome UX Report field data when enough real Chrome users visited the origin or URL. The lower block is a fresh Lighthouse lab run.

Your local Lighthouse score is lab only. Comparing a local Performance score to the field Core Web Vitals categories is a category error. Field windows cover days of real devices and networks. Lab is one controlled load. Lab-versus-field reconciliation is a separate topic; here the focus is local lab versus PageSpeed Insights lab.

If field looks healthier than PageSpeed Insights lab, users may be on faster devices, revisit with cache, or you may be reading origin-level field against a URL-level lab run. Calibrate, do not average the two into one fake “truth.”

How to compare fairly (and what to trust for client work)

Source	What it measures	Best use
Chrome DevTools / local CLI	Lab on your machine	Before/after while debugging the same URL
PageSpeed Insights lab	Lab on Google’s workers	Shareable cold-load baseline close to what clients paste
PageSpeed Insights field (CrUX)	Real-user Core Web Vitals	Trend and eligibility, not a Lighthouse score twin

Rules that keep agencies from mixing incompatible scores:

Compare before and after on the same tool. Local 94 → local 88 after a change is useful. Local 94 versus PageSpeed Insights 61 is not a regression proof.
Match strategy. Mobile versus mobile. Desktop versus desktop.
Prefer cold loads when you claim a public score. Clear cache or use a clean profile locally.
Read the device score / environment notes in the Lighthouse JSON when you need to explain a gap to a technical lead.
For client reporting, prefer a stable lab path. Scheduled PageSpeed Insights-style runs from a monitoring product reduce “my laptop versus your laptop” arguments. Spot checks still help debugging; they are a weak single source of truth for retainers.

DebugBear’s comparison of PageSpeed Insights and Lighthouse, and Google’s own Lighthouse variability notes, make the same point: synthetic scores depend on CPU, location, Chrome version, and throttling method. Absolute equality across tools is the wrong goal. Directional agreement on the same tool is the right one.

FAQ

Is PageSpeed Insights “more accurate” than local Lighthouse?

For cold-load lab diagnostics that clients can reopen in a browser, PageSpeed Insights is often the better shared reference. For day-to-day engineering, local Lighthouse before/after on the same machine is faster and still valid. Neither replaces field Core Web Vitals when you need real-user truth.

Why does my local Lighthouse match PageSpeed Insights sometimes?

When host speeds are closer, the URL is light on main-thread work, or the runs simply land nearer each other, gaps shrink. Heavy JavaScript and layout work widen them. Treat occasional agreement as luck on a light page, not proof that the two environments are interchangeable.

Should I raise local CPU slowdown until scores match PageSpeed Insights?

You can experiment with CLI throttling for research. Do not treat a personalised slowdown as a contract with the client unless everyone agrees that environment is the baseline. Document the tool and settings you will use in the retainer.

Does a better local score mean Search Console will improve?

Not by itself. Search Console and Chrome UX Report track field data. Lab wins help you find fixes; field windows confirm whether real users felt them.

What to do next

Pick one money URL. Run Lighthouse twice locally in a clean profile and note the spread. Run PageSpeed Insights lab on the same URL and strategy. Write down host differences instead of merging the scores. Put the PageSpeed Insights lab number (or a scheduled monitoring run) in the client pack when you need a shareable baseline, and keep local Lighthouse for the fix loop.

If you manage many client origins, automate the PageSpeed Insights-shaped lab path so every site uses the same cold-load recipe. That is the operational answer to “whose Lighthouse do we believe?”: agree the environment once, then track change inside it. Spot laptop runs stay useful for debugging; they should not be the only number in the monthly pack.

References

PageSpeed Insights vs. Lighthouse: What's the Difference? (DebugBear)
Lighthouse variability / scoring environment (Chrome Lighthouse docs)
Why Lighthouse via PageSpeed Insights API differs from CLI (Stack Overflow)
Why TBT on PageSpeed Insights differs from a local machine (Stack Overflow)
How Lighthouse Performance Scores Are Recorded and Calculated (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)

DEV Community: Apogee Watcher

When should you lazy load images (and when does it hurt LCP)?

Three checks before you lazy-load an image

When lazy loading images helps bandwidth without hurting LCP

When loading="lazy" hurts Largest Contentful Paint

CMS and theme traps that lazy-load the hero

Quick verify: lab LCP element after a lazy-loading change

FAQ

CTA

References

Brotli compression is on: why is PageSpeed / LCP still slow?

Confirm Brotli is actually on the critical path

Why Brotli can leave Largest Contentful Paint unchanged

When enabling Brotli makes PageSpeed Insights worse

What to fix next when the LCP element is not a text file

How agencies verify compression and LCP across a client portfolio

FAQ

CTA

References

Why CrUX Has No Data for Your Site

What “no CrUX data” means on a site

Chrome UX Report eligibility: user, origin, and page

Why an origin is missing from CrUX entirely

URL-level gaps when the origin still has field data

What to tell the client when field data is unavailable

What to monitor instead: synthetic budgets on priority URLs

FAQ

CTA

References

Multi-tenant PageSpeed monitoring under $100: what agencies actually buy

What agencies mean by multi-tenant PageSpeed monitoring under $100

AI fix loops are not the same purchase as a portfolio schedule

What actually lands on the purchase order

Flat organisation caps versus per-site maths

When DIY still wins the budget

FAQ

Buy the portfolio job, then layer the rest

References

Lazy Loading for LCP and CLS: When to Use loading="lazy" (and When Not To)

What the loading="lazy" attribute does

Why lazy-loading the LCP image hurts Largest Contentful Paint

When lazy loading images is the right default

Above-the-fold images, fetchpriority, and eager loading

Iframes, video, and other lazy media caveats

Lazy loading and CLS: reserve space first

Lab vs field when lazy loading hides LCP regressions

Agency checklist before you ship “lazy everything”

FAQ

Ship eager heroes, lazy galleries

References

What PageSpeed monitoring stack should an agency run in 2026?

What a PageSpeed monitoring stack is (for agencies)

The default stack most agencies should run in 2026

When DIY PageSpeed Insights + sheets is enough

When to add RUM on flagship sites only

Jobs the stack must cover (without a vendor matrix)

FAQ

CTA

References

WordPress Speculation and Prerender Plugins vs Core Web Vitals

What WordPress speculative loading is (prefetch vs prerender)

Core 6.8 defaults vs the Speculative Loading plugin

When speculation helps navigation INP and next-page LCP

When a WordPress prerender plugin hurts first-visit LCP, CLS, or bandwidth

Safe settings for agency WordPress retainers

How to verify with lab schedules and field data

FAQ

References

TTFB Is Not Only the Server: The Unattributed Slice Agencies Should Name in Reports

What unattributed navigation overhead (UNO) is

Navigation Timing TTFB breakdown: redirect, DNS, connection, request

Why redirect, DNS, and connection phases still leave a gap

How to calculate UNO from Navigation Timing

What agencies should name in client reports when TTFB looks “server-only”

When the attributed server phase is the real bottleneck

Why CrUX and one-off lab runs miss the unattributed slice

FAQ

References

Oh Dear alternative? Uptime green is not Core Web Vitals portfolio monitoring

What “Oh Dear alternative” usually means in search

When `loading="lazy"` hurts Largest Contentful Paint

What the `loading="lazy"` attribute does

Above-the-fold images, `fetchpriority`, and eager loading