DEV Community: Apogee Watcher

Checkout is not the homepage: e-commerce signals we watch

Apogee Watcher — Sat, 04 Jul 2026 08:20:15 +0000

A Shopify client sent us a screenshot last quarter: homepage Largest Contentful Paint in the green, performance score in the high eighties, and a checkout step where address autocomplete took four seconds to respond on a mid-range Android phone. Revenue had dipped on mobile. Search Console still showed "Good" for most URLs because the origin average looked fine.

That pattern is common enough that we stopped treating it as a one-off. E-commerce monitoring fails quietly when the test list mirrors marketing priorities (home, campaign landers) instead of the path where money changes hands. Checkout is not the homepage. The signals worth paging someone for are not the same either.

Below is how we split retail URLs, Core Web Vitals, and alert thresholds when we manage multiple storefronts. It is opinionated and operational, not a metric glossary. For research-backed funnel context and a full page-type playbook, our Watcher blog carries the depth; this post is what we actually watch week to week.

Why homepage-first PageSpeed monitoring misses checkout regressions

Homepages are easy to reason about in a client call. One hero, one LCP element, a before-and-after screenshot. Product listing pages add thumbnails and filters. Product detail pages add galleries and review widgets. Cart and checkout add coupons, cross-sells, payment scripts, and validation that only run after intent is high.

Sitewide averages hide that staircase. A store can improve campaign LCP while checkout Interaction to Next Paint (INP) drifts because a new fraud script landed on step two. Lab runs on / will not catch it. Field data aggregated at origin level may still look acceptable if PLP traffic dominates volume.

We see three recurring mistakes on agency accounts:

The URL list stops at PDP because "that is where SEO traffic lands."
Alerts fire on global performance score instead of template-level budgets.
Mobile and desktop are merged into one number when mobile carries most retail sessions (often 70%+ on the accounts we monitor).

None of these are malicious. They are what happens when performance reporting follows the org chart (marketing owns the homepage) instead of the funnel.

Core Web Vitals by funnel step: PLP, PDP, cart, and checkout

Google's Core Web Vitals stay the same everywhere: LCP for loading, INP for responsiveness after load, CLS for layout stability. What changes in a shop is which metric bites first on which template.

On listing and product pages, image weight still drives most LCP pain. That is the story clients already expect. On cart and checkout, INP and CLS take over: variant pickers, address fields, payment iframes, and dynamically inserted trust badges all compete for the main thread after the shopper has decided to buy.

We keep a simple mapping on the whiteboard for new retail onboardings:

Funnel step	What usually breaks first	What we chart separately
PLP / category	Thumbnail grids, sort/filter JS	LCP, INP on filter taps, CLS as rows load
PDP	Large gallery, reviews embeds	LCP, INP on variant change, CLS from late modules
Cart	Cross-sell strips, coupon widgets	INP, CLS
Checkout	Payment + validation scripts	INP, CLS; server timing on API-backed steps

If you only add one segment beyond the homepage this month, make it mobile PDP plus checkout. That is where small responsiveness gaps show up in conversion data before they show up in a slide deck.

INP on checkout beats a green homepage LCP

When INP replaced First Input Delay in March 2024, many retail accounts already had acceptable FID on cold loads. The gap we cared about was sustained interaction latency on logged-in flows and guest checkout, not the first tap on a hero button.

Checkout INP failures often trace to third parties added without a before/after run: address lookup, BNPL widgets, analytics bundles that were "just one more tag." Industry samples (including Yottaa's 2025 index, cited in our longer e-commerce guide) repeatedly put third-party share of load time in the 40%+ range on retail templates. The tax is rarely visible on /.

Our practical rule: any new vendor on cart or checkout gets a scheduled lab run on a real basket URL, mobile profile, before and after enablement. If INP moves more than an agreed internal band, the change does not ship without a named owner. That is slower than "paste the snippet," and it has prevented more Friday-night reversions than any Lighthouse trophy.

Core Web Vitals and SEO on PLPs vs checkout conversion

Retail SEO work still concentrates on PLPs and PDPs: rankings, snippets, internal linking. That is correct. It also tempts teams to treat CWV as "fixed once product templates pass."

Google uses field Core Web Vitals as a page experience signal, mostly as a tiebreaker when content and links are otherwise similar. In crowded product niches, that tiebreaker shows up in Search Console before anyone mentions checkout. Our write-up on how Core Web Vitals affect SEO rankings walks through the data and timelines; the retail takeaway we reuse in client calls is narrower.

Good PLP and PDP CWV protect discovery and click-through. They do not excuse checkout friction. A shopper who ranks you, lands on a fast PDP, and abandons on a sticky payment step still costs you money; Search Console will not file that under "Poor CWV."

We therefore split the conversation with SEO-led clients:

Search-facing templates: LCP and CLS first, mobile field data, compare against competitors on the same SERP.
Revenue-facing templates: INP and CLS on cart/checkout, synthetic runs after every deploy that touches payments or shipping logic.

That split stops the "we already fixed Core Web Vitals" objection when conversion teams raise checkout complaints.

Third-party inventory per template, not per site

Retail tag maps sprawl. Analytics, personalisation, reviews, chat, A/B frameworks: each vendor lands on a different subset of templates. A global "third-party audit" slide rarely says which script moved on checkout step three.

We ask for a template-level inventory before we configure monitoring:

List active tags on PLP, PDP, cart, checkout (not "sitewide").
Tie each tag to a business owner and a last-reviewed date.
Attach a lab URL and mobile run to any enablement ticket.

When a client enables a new reviews widget on PDP only, we extend budgets on PDP URLs. When they add BNPL to checkout, we extend checkout URLs. Mixing those into one sitewide threshold produces either false calm or alert noise.

Agencies managing many stores can copy the same shape per client without copying the same numbers. Shopify, WooCommerce, and Magento differ in how apps inject scripts; the monitoring shape (template, device, metric) stays constant.

E-commerce performance monitoring: synthetic runs, CrUX, and checkout alerts

We use scheduled synthetic PageSpeed-style runs for regressions we can act on this week: deploy markers, app updates, theme releases. Chrome User Experience Report field data (where Google publishes it) tells us what shoppers actually saw over the last 28 days. It lags, and low-traffic checkout URLs sometimes lack coverage entirely.

That gap matters for alerts. We do not page someone because CrUX flipped amber on a low-volume checkout URL with wide confidence intervals. We do page when two consecutive synthetic runs on the same mobile checkout URL breach an agreed INP or LCP budget after a tagged deploy.

Field data still belongs on the monthly client report, especially for SEO stakeholders. Lab data belongs in the engineering channel. Mixing them in one Slack thread guarantees someone argues about methodology instead of fixing the script.

If you want the full comparison of synthetic, CrUX, and first-party RUM in a retail context, the e-commerce performance monitoring guide on our blog covers research citations, seasonal cadence, and checklist items we did not repeat here.

Portfolio habits: same structure, different thresholds per store

Running monitoring across dozens of storefronts breaks when every client inherits the homepage-only URL list from the pitch deck. We standardise structure and localise numbers.

Structure we reuse:

Four URL groups per store: home/campaign, PLP exemplar, PDP exemplar, cart or checkout entry.
Mobile and desktop runs on the same URLs (retail divergence by breakpoint is routine).
Separate contract thresholds (client-facing report) from internal early warning (tighter, stays inside the agency).
Alerts on budget breaches with cooldowns, not on every lab wobble.

Numbers stay per client: a luxury PDP with a video hero does not share an LCP budget with a dense grocery PLP. The mistake is not the variance; it is failing to document which URL group owns which budget.

Seasonal events get a temporary fourth cadence: daily synthetic on PDP and checkout for two weeks before and after the sale window, then back to weekly. Black Friday post-mortems that only mention the homepage are a sign the test list was wrong, not that performance did not matter.

E-commerce page speed KPIs we removed from client dashboards

A few metrics still appear in legacy reports because they photograph well, even when they mislead:

Sitewide performance score as a single KPI (masks checkout).
Desktop-only runs for clients whose analytics show 75%+ mobile revenue.
TTFB on static marketing pages while checkout API steps degrade (measure both, do not substitute).
"All green in PSI" screenshots without listing which URLs were tested.

We replaced most of that with a one-page funnel view: worst mobile INP on checkout, worst mobile LCP on top PDP, count of budget breaches by template, last deploy marker. Clients ask better questions when the dashboard names the step, not the average.

Next step: add checkout to one client's test list this week

Pick the noisiest retail account on your roster. Copy four URLs into your monitoring tool: their best-traffic PLP, best-traffic PDP, cart, and the first checkout step with payment scripts. Run mobile and desktop once, file the INP and LCP numbers, and compare them to the homepage you already report.

If checkout is more than one internal band worse than PDP on mobile, you have a backlog item that marketing metrics were hiding. Set budgets and alerts on those URLs before the next campaign launch adds another hero image.

For the research layer and a printable monitoring checklist, read Performance Monitoring for E-Commerce: What Metrics Matter Most. For how CWV interact with rankings when PLPs get competitive, pair it with How Core Web Vitals Impact SEO Rankings: What the Data Shows.

Retail performance is funnel discipline. The homepage is one step. Checkout is where the argument ends.

Generic AI visibility prompts and generic monitoring URL lists fail the same way

Apogee Watcher — Fri, 03 Jul 2026 14:23:49 +0000

The agency Slack channel had two screenshots in the same hour. One was a GEO report: green visibility for "best pagespeed monitoring tool 2026." The other was a client spreadsheet with three monitored URLs, all homepages, last updated when someone remembered to run PageSpeed Insights before a QBR.

Nobody connected them. The GEO vendor was answering a prompt that no real buyer types. The spreadsheet was answering a monitoring question with the same abstraction: which URLs matter when a Shopify theme ships, when docs move behind a new path, or when procurement asks whether checkout is included in the retainer. Generic AI prompts and generic URL lists fail the same way: they look rigorous because the columns are full, and they stop being useful the moment a decision depends on context.

Why do generic AI visibility prompts and homepage-only monitoring fail the same way?

Traditional rank tracking assumes a stable query returns a stable set of results. AI visibility tools often copy that shape: define a prompt list, run it weekly, graph mention rate. Large language models do not behave like Google results pages. The same prompt can produce different answers depending on phrasing, session context, and model version. Measuring them like ranks produces tidy charts that may not reflect how your buyers actually research.

Performance monitoring has a parallel failure mode. A three-URL plan is clean, scalable, and easy to paste into a proposal. It also rarely matches how regressions show up in production: a campaign landing page, a help article, a checkout step, a post-deploy category template. The homepage stays green while the URLs that carry revenue or citations drift.

In both cases the input is under-specified. You are scoring visibility or speed for a hypothetical user on a hypothetical set of pages.

What do generic AI search prompts and three-URL watch lists leave out?

GEO prompt libraries love category queries. They are easy to compare across vendors and easy to report upward. They also strip away the constraints that shape real agency work: how many client sites, which templates change every sprint, whether the buyer cares about field data for mobile checkout, whether AI crawlers can fetch documentation without timing out.

We have seen the same pattern in monitoring audits. Search Console and a homepage Lighthouse run look healthy. Server logs show GPTBot timing out on long-tail help URLs, or a JavaScript shell on first response for a path the marketing team already pitched for AI Overviews. The monitored list never included those routes, so the regression had no owner.

The buyer who does not exist in a generic GEO prompt is the same buyer who does not exist in a homepage-only monitoring plan: no history, no template mix, no release cadence, no named stakeholder who needs a PDF on Friday. Context is not a nice-to-have. It is the difference between a score and a workflow.

What should agencies monitor when a client asks about AI visibility?

When a client asks whether they appear in ChatGPT, we split the answer into layers we can defend.

Probabilistic layer (citation and mentions)

Citation and mention patterns across LLMs and AI Overviews need prompt design with real buyer contexts, not only category leaderboards, and often a dedicated GEO or visibility product. We do not sell that layer. We do not pretend a PageSpeed monitor replaces it.

Deterministic layer (fetchability and speed)

Priority URLs must stay fast, fetchable, and stable enough for crawlers and humans: robots rules for AI bots, response times under load, Core Web Vitals on the routes that matter, alerts when a deploy breaks a template. That layer is measurable on a schedule, across a portfolio, with named owners.

Our longer technical write-up on crawlability for AI bots covers the fetch side: Why AI Crawlers Need Fast, Crawlable Pages — and How to Stay Ready. For how AI Overviews change click behaviour and why surface presence is not the same as traffic, see AI Overviews Are Killing Clicks: What the Data Shows and How to Respond. Fix the deterministic layer first: a visibility score on generic prompts does not rescue URLs that bots cannot read or pages that time out under a normal crawl budget.

How should you build buyer-context AI prompts and performance monitoring URL lists?

Better GEO measurement builds prompts around personas, intent stage, and the questions buyers ask when they are close to a decision, not only "best tool in [year]." Better monitoring builds URL lists the same way.

For a performance retainer, that might mean:

Home and primary conversion paths, not only the marketing homepage.
Documentation and pricing routes if AI search and procurement research cite them.
Template families that change often (category, product, checkout), not one URL per client chosen at onboarding.
Paired mobile and desktop checks where field data already shows a split.

The list should answer: if we ship on Thursday, which URLs will tell us on Monday that something broke? Generic prompts should answer: when our actual buyer describes their stack and constraints, does our brand show up reliably? Same design problem, different channel.

If your team already separates daily tooling verbs from procurement matrices, apply the same discipline here. Stack versus buyer matrix is not only a free-tools question. It applies to GEO prompt libraries and monitoring scopes alike.

Why will more GEO prompts not fix a weak PageSpeed monitoring scope?

The instinct when generic inputs fail is to add volume: more prompts, more synonyms, more regions; or more URLs in the monitor until the plan looks comprehensive. Volume without context produces expensive noise.

A thousand variations on "best pagespeed tool" still describe a user who does not match your agency buyer. A hundred homepages in a dashboard still miss the campaign URL that went live Tuesday. More rows in the spreadsheet do not assign ownership when LCP crosses a budget on checkout.

Probability-style visibility needs representative prompts. Portfolio monitoring needs representative URLs. Both need constraints from real retainers, not from a vendor default template.

How should agencies answer "Are we visible in ChatGPT?"

We do not dismiss GEO tracking. Buyers use ChatGPT, Perplexity, and AI Overviews. Invisibility in those surfaces is a real risk. We also refuse to treat a green visibility widget as proof that the site is ready to be cited.

Our practical sequence:

Name the URLs that must stay fast and fetchable for humans and bots.
Put them on a cadence with alerts, not on someone's calendar.
Add GEO or citation analytics when the client needs probabilistic brand measurement, with prompts that reflect their market, not only category generics.
Report both layers separately so procurement does not merge them into one vanity metric.

That sequence keeps Apogee Watcher in its lane: scheduled PageSpeed monitoring, budgets, and portfolio coverage. It leaves room for GEO specialists without asking performance tooling to impersonate them.

If you are revising either list this quarter, start with one real client scenario. Write the prompt a technical lead would actually type after a bad deploy. Write the URL list you would need to catch that deploy before the client notices. Delete the generic rows that do not serve that scenario. Then scale.

Shopify Speed Optimization: Core Web Vitals Guide for E-Commerce

Apogee Watcher — Wed, 01 Jul 2026 21:22:36 +0000

Shopify speed optimization is not the same problem as speeding up a marketing brochure site. Your theme renders product grids, variant pickers, and cart drawers; your app stack injects reviews, personalisation, and chat on top of Liquid templates you may not fully control. Core Web Vitals still measure the outcome shoppers feel: LCP when the product image or hero appears, INP when taps on size or colour respond, CLS when a banner or widget shoves the add-to-cart button mid-click.

What follows is a practical Shopify playbook aligned to those metrics: which URLs to optimise first, what typically breaks each vital on Online Store 2.0 themes, and how scheduled lab monitoring plus field data fits once fixes ship. For metric definitions and funnel-wide priorities, start with What Are Core Web Vitals? and Performance Monitoring for E-Commerce: What Metrics Matter Most; here the focus stays on Shopify implementation choices.

Which Shopify URLs matter most for Core Web Vitals

Sitewide averages hide the pages that carry revenue. On most Shopify stores, prioritise lab and field coverage in this order:

Product detail pages (PDPs): largest media, variant interactions, review widgets; strongest link to add-to-basket progression in published retail speed research summarised on web.dev.
Collection and search results: many thumbnails, filter and sort UI; INP and CLS risks as rows load.
Cart and cart drawer: coupons, upsells, persistence scripts; interaction-heavy even when LCP looks fine.
Checkout: Shopify-hosted checkout limits how much theme code you can change, but payment and form responsiveness still matter for INP; monitor the URLs you can test and treat checkout regressions as release incidents.
Home and campaign landers: heavy heroes and promotional sections; important for acquisition, but do not let them crowd out PDP and cart in your test list.

Agencies should document this list per client in the onboarding file. A store that only monitors the homepage will miss the PDP regression that shows up in support tickets first.

LCP on Shopify: images, heroes, and product media

Largest Contentful Paint on Shopify is usually an image problem before it is a server problem. Shopify serves storefront assets through its CDN; the win is sending the right width, format, and priority, not bypassing the platform.

Theme and section hygiene

Audit Online Store 2.0 sections on the homepage and PDP templates. Duplicate hero sliders, autoplaying video heroes, and oversized background images are common LCP offenders. Remove sections you are not using; each active section can add CSS and JavaScript even when it looks empty on mobile.

Use Shopify’s image APIs and theme settings that output responsive srcset and explicit width parameters rather than uploading 4000px masters into a 600px slot. Our image optimisation strategies for better LCP applies directly to product galleries and collection grids.

Product media

On PDPs, the first visible gallery image is often the LCP element. Preload only when you have measured that element in Lighthouse or PageSpeed Insights; blind preloading every variant image wastes bandwidth. For video or 3D media, defer non-critical players until after the primary image paints.

Fonts and render blocking

Custom fonts from theme settings or apps can delay text and push LCP to a late paint. Subset fonts where possible, limit weight variants, and use font-display: swap in theme CSS when you control the declaration. Font subsetting guidance in our font subsetting how-to is relevant when merchants self-host display faces outside Shopify’s defaults.

INP on Shopify: variants, filters, and app JavaScript

Interaction to Next Paint reflects how quickly the page responds after a shopper taps. Shopify themes and apps add listeners on variant radios, colour swatches, collection filters, cart drawers, and sticky headers. Long main-thread tasks from analytics or personalisation often show up here before they move LCP.

Variant pickers and quick-add

Test INP on PDP with throttled mobile profiles. If changing size stalls the UI, profile with Chrome DevTools performance recordings and look for synchronous work in theme JavaScript or app embeds tied to inventory updates. Split heavy work across frames or load non-critical features after the selection state updates.

Collection filters and sort

Faceted navigation triggers DOM updates and sometimes refetches. Filters that re-render large product grids on every click are a common INP regression after merchandising changes. Prefer incremental updates and skeleton states that do not block the next input.

Cart drawer and mini-cart

Opening the cart drawer often loads recommendations or loyalty modules. Defer those requests until after the drawer animation completes if your theme allows it. INP on “add to cart” is a better alert threshold than homepage LCP for many Shopify retainers.

For a general method to rank script cost, use Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders; on Shopify, the offenders are usually apps rather than hand-pasted tags.

CLS on Shopify: apps, embeds, and dynamic inserts

Cumulative Layout Shift punishes layout movement without reserved space. Shopify stores see CLS from review star widgets, consent banners, promo bars, lazy-loaded images without dimensions, and recommendation carousels that mount late.

Reserve height for embed containers in theme Liquid where you can. For app blocks you cannot edit, ask the vendor for a fixed-aspect placeholder or load the block below the fold on mobile. Compare CLS on long collection pages with infinite scroll; each appended row is a shift risk if image heights are unknown.

Sticky headers and announcement bars compete for the same viewport. If marketing enables both, measure CLS on PDP and checkout paths, not only the homepage.

Shopify apps: audit, defer, and remove

Apps are the fastest way to undo theme work. Each installed app can inject JavaScript through theme app extensions, ScriptTag legacy patterns, or checkout UI extensions. Merchants often add apps for reviews, search, subscriptions, and upsells without a performance review.

Run a quarterly app audit:

List every installed app and which templates it touches.
Disable suspect apps on a duplicate theme or staging preview and re-run PageSpeed Insights on PDP and collection URLs.
Remove apps that duplicate native Shopify features you already pay for.
Gate new apps with a before-and-after lab run stored in your monitoring history.

Shopify’s own performance team publishes aggregated theme and vitals context on the Shopify performance blog; use it for platform-level baselines, then prove your store’s numbers with your URL list.

Theme choices without a full rebuild

You do not always need a new theme to improve Shopify speed. Before a migration project, try:

Disabling unused sections and app blocks on high-traffic templates.
Replacing carousel heroes with a single optimised image on mobile.
Moving non-critical scripts to defer or loading them on interaction when theme architecture allows.
Aligning image aspect ratios in collection cards so the grid does not reflow as images arrive.

When a rebuild is justified, favour lean Online Store 2.0 themes with minimal JavaScript on PDP and collection templates, and verify demo store scores on mobile, not desktop-only marketing screenshots.

Set performance budgets for Shopify templates

Speed work sticks when thresholds are written down. Use separate mobile and desktop budgets per site in your monitoring tool, with tighter bands on PDP and cart than on policy pages. The performance budget thresholds template includes ecommerce-friendly starting values; mark them provisional for the first month while apps and seasonal campaigns settle.

Example emphasis for Shopify:

Template	Metrics to weight	Notes
PDP	LCP, INP, CLS	Gallery, variants, reviews
Collection	LCP, INP	Filters, many thumbnails
Cart / drawer	INP, CLS	Upsells, coupons
Home	LCP, CLS	Hero, promo sections

Pair budgets with email or digest alerts so a theme deploy or app update triggers investigation before CrUX reflects the regression weeks later.

Monitor Shopify stores with scheduled PageSpeed tests

Synthetic lab runs through PageSpeed Insights give repeatable before-and-after proof when you change a theme or remove an app. Schedule mobile and desktop tests on the URL set above, with higher frequency during sale periods. How to schedule test frequency and priority across your portfolio covers cadence when you manage multiple merchant sites.

Apogee Watcher is built for that portfolio pattern: one organisation, a site per client store, discovery from sitemaps where Shopify exposes them, and budgets on the templates you list. We do not replace Shopify’s admin analytics; we give agencies a shared history and alert layer without a separate API key per merchant. Setup steps live in Getting Started with Apogee Watcher: A Step-by-Step Setup Guide.

Read CrUX percentiles beside lab scores when Google publishes field data for a URL. Field data answers what shoppers saw; lab data answers what changed after last night’s deploy. Both belong in client reports; neither alone is enough for Shopify where apps change weekly.

Shopify speed optimization checklist

Use this as a release gate before peak season or after a major app install:

Mobile and desktop lab runs on homepage, top collection, top three PDPs, and cart path.
LCP element identified on PDP; image dimensions and priority verified.
INP spot-check on variant change, filter toggle, and add to cart.
CLS check with promo bar and consent banner enabled as in production.
App inventory reviewed; unused apps removed.
Budgets set per template; alert recipient confirmed.
Baseline note stored with owner and three follow-up actions.

Agencies can mirror the same checklist across clients with the Core Web Vitals monitoring checklist for agencies.

FAQ

What is a good LCP for a Shopify store?

Google’s public guidance treats LCP at or below 2.5 seconds at the 75th percentile as good in field data. Lab targets can be stricter on PDP during optimisation sprints. Compare mobile separately; Shopify traffic skews mobile for many merchants.

Why is my Shopify PageSpeed score different from CrUX?

Lab tests use simulated conditions on a single run; CrUX aggregates real Chrome users over a rolling window. Apps, traffic mix, and geography differ. Use lab for regressions after deploys; use CrUX for whether shoppers broadly experience the vitals band you promise.

Do Shopify apps always hurt Core Web Vitals?

Not always, but unmanaged apps are the most common regression source we see on merchant stores. Audit before install and measure after.

Can I optimise Shopify checkout theme code?

Checkout is largely platform-hosted. Focus on cart, accelerated checkout buttons, and any scripts that run before checkout handoff. Monitor checkout URLs where tests are permitted and treat payment-step INP issues as vendor or platform support cases when you cannot edit the template.

How is Shopify speed optimization different from WooCommerce?

Metrics are the same; implementation differs. Shopify centralises theme and app embed patterns; WooCommerce often mixes plugins and hosting. Optimise and monitor per platform, not with one generic plugin list.

Should agencies monitor every Shopify URL?

No. Start with ten to twenty priority URLs per store, emphasising PDP, collections that drive revenue, and cart. Expand when alert triage stays manageable.

Does improving Core Web Vitals increase Shopify conversion?

Published retail studies link small speed gains to measurable funnel effects; exact uplift depends on baseline speed and traffic. Use monitoring to prove before-and-after on your client’s templates rather than citing industry averages alone.

Shopify speed optimization that lasts pairs template-level fixes with a short URL list, explicit budgets, and scheduled tests that survive the next app install. Fix PDP and cart first, audit apps quarterly, and keep mobile lab runs in the same rhythm as theme releases.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets on Shopify client sites, or run a free domain PageSpeed check on a storefront before you scope the first optimisation sprint.

Getting Started with Apogee Watcher: A Step-by-Step Setup Guide

Apogee Watcher — Tue, 30 Jun 2026 21:30:59 +0000

You signed up for scheduled PageSpeed monitoring because manual PageSpeed Insights tabs do not scale. The gap is usually not motivation but sequence: which screen comes first, how many URLs belong in week one, and when budgets should start paging someone. What follows is a practical Apogee Watcher setup path from empty account to a site that runs on its own, with mobile and desktop lab results, optional CrUX context where Google publishes field data, and email when thresholds breach.

If you are onboarding a client under contract, pair these product steps with our agency onboarding workflow for kickoff, client comms, and day-thirty handoff. If you are comparing DIY Lighthouse CI with a managed product first, read How to Set Up Automated PageSpeed Monitoring for Multiple Sites for the broader build-versus-buy picture, then return here for the in-app clicks.

What you need before Apogee Watcher setup

Gather a short list before you open the dashboard. You will move faster and avoid re-work on URL scope.

You need a production hostname you are allowed to test (or a staging URL if that is explicitly in scope). You need three to fifteen priority paths, not every tag archive on day one: homepage, primary conversion URL, and a few template representatives. You need one internal owner for alerts and one decision on mobile versus desktop, which for most public sites means both strategies enabled. You need a rough cadence: daily for high-change properties, weekly for stable brochure sites; our guide on scheduling test frequency and priority across a portfolio explains quota trade-offs when you add more clients later.

You do not need a Google Cloud project or a PageSpeed Insights API key. Apogee Watcher holds that integration so your team configures sites inside the product instead of rotating keys per domain. You also do not need a JavaScript snippet on the site; monitoring is synthetic lab testing through PageSpeed Insights, plus CrUX when available for the URL.

Optional but useful: run the public free domain PageSpeed check on the hostname first. You get a multi-page snapshot and emailed report without configuring schedules, which helps you sanity-check discovery and pick starter URLs before you commit them to a recurring plan.

Create your organisation and sign in

Create a free account with the email that should receive billing and, by default, budget alert digests for organisation admins. After verification, you land in your organisation workspace: the container for sites, team members, quotas, and shared history.

Agencies usually keep one organisation and add a site per client rather than spinning up separate logins. Solo operators do the same with one site to start. If you expect several teammates to configure monitoring, skim team roles and access control before you invite anyone: Admins manage billing and membership, Managers tune sites and budgets, Viewers read results without changing settings.

Check plan limits in My Account if you are on a tier with caps on sites, monthly tests, or organisations. Upgrade or trim URL scope early so the first scheduled week does not hit quota mid-run.

Add your first site to monitor

From the dashboard, open Sites and create a site record for the property you are responsible for. Give it a name your team recognises (client brand plus environment if you run staging separately) and enter the canonical domain. The domain anchors discovery and URL validation; keep it aligned with the host users actually load in the browser.

One site equals one monitored property in Apogee Watcher. Homepage, pricing, and checkout paths live as pages under that site, not as three separate site records unless they truly belong to different hosts. When you later manage many properties, the multi-site dashboard is simply this pattern repeated with portfolio-level navigation.

Build your page list with discovery and manual URLs

Monitoring only works on URLs you list. You can add pages manually or run discovery from the site view.

Run Discover Pages

Use Discover Pages on the site when a sitemap exists. Watcher reads sitemap.xml and nested indexes first, then can crawl same-domain links if the sitemap is thin. Discovery respects caps on depth and URL count so a large estate does not import thousands of parameter variants in one pass. Review the results, deactivate noise (search facets, preview paths, admin routes), and keep conversion templates even if they sit deep in the crawl output. The product marks auto-discovered URLs so you can filter them later; see the page discovery spotlight for the full pipeline.

Add priority URLs by hand

Force-add anything discovery misses: campaign landers, freshly launched /pricing variants, or routes blocked from crawlers but public in production. A sensible first pass is one homepage, two to five conversion URLs, and five to ten template representatives. Expand after alert triage stays manageable.

Each page row controls whether mobile tests, desktop tests, or both run, plus a priority band that influences ordering in reports and digests. Enable both strategies unless you have a written reason to skip one; sponsors still ask about desktop even when analytics skew mobile.

Configure test schedule and priority per page

Scheduled testing is the core of Apogee Watcher setup. Open the site schedule settings and choose a cadence your plan allows: hourly for risky release windows, daily for active commerce, weekly for stable marketing sites. Match frequency to release risk, not equality across every URL on the account.

Set page priority so the URLs that drive revenue or leads surface first in roll-ups and alert summaries. A blog tag page rarely deserves the same priority as checkout. When you are unsure how aggressive to be, start conservative on URL count and daily cadence, then tighten after you see a week of quota usage in the dashboard.

Run your baseline PageSpeed tests

Before you rely on alerts, confirm data is flowing. Trigger a test run on priority pages or use the site action to test all active pages once. When results return, open a few rows and verify mobile and desktop series both populated where expected.

Record a lightweight baseline note outside the product if you are setting up for a client: date, owner, LCP, INP, CLS, and performance score on the top three URLs, plus one line on likely cause for any fail. Numbers without context do not survive the first review meeting. For metric definitions, use What Are Core Web Vitals? and LCP, INP, and CLS explained.

CrUX percentiles may appear beside lab scores when Google publishes field data for that URL and strategy. Treat CrUX as a lagging field signal; lab results from the same run are what budgets evaluate immediately after deploy.

Set performance budgets on the site

Budgets turn scores into pass-or-fail rules. Open the site budgets screen. Watcher creates default mobile and desktop budget rows per site; replace placeholder thresholds with numbers that match your contract or internal standard. Typical starting bands for marketing sites follow our performance budget thresholds template: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1, and a minimum performance score you are willing to defend in a client call.

You can cap FCP and TBT as supporting lab metrics when INP or LCP regressions need faster diagnosis; see FCP and TBT: supporting metrics beyond Core Web Vitals if those fields matter for your stack. Deactivate a strategy’s budget row if you genuinely monitor only one form factor for that property.

Mark provisional thresholds in your internal notes for the first month. Tighten after you see how often deploys or third-party scripts trigger noise versus real regressions.

Turn on email alerts and confirm delivery

Alerts connect budgets to humans. Set the alert channel to email on the budget rows you want enforced. When a scheduled run finishes and violations exist, organisation admins receive a site-level digest listing the worst pages first, with counts for total breaches and breakdown by metric. Cooldown logic avoids repeating the same fire while a metric stays outside the band; details are in the performance budgets and email alerts spotlight.

Validate routing once: temporarily lower a threshold on a staging URL you control, run a test, confirm the digest arrives, then restore the real numbers. If mail does not arrive, check spam folders and confirm the recipient is an active organisation admin.

Slack and webhooks remain on the roadmap for many teams; email is enough to prove the loop during initial setup.

Invite teammates with the right roles

When more than one person will respond to regressions, invite them before the first client-facing review. Assign Admin only to people who should change billing and membership; give Managers to leads who tune budgets and schedules; use Viewer for account managers who need read access without risking accidental configuration changes.

Document internally who triages alerts versus who speaks to the client. Without that split, digests land in a shared inbox and regressions age quietly. For alert philosophy, read From Reactive to Proactive: How Smart Alerts Change Performance Monitoring.

What happens after setup: daily and weekly routines

Setup is complete when scheduled runs execute without manual PSI tabs, budgets reflect agreed thresholds, at least one person receives alert mail, and you can name three current actions from the baseline.

Daily, glance at new alerts. If none fired, note it and move on. Weekly, scan trends for gradual drift on priority URLs and adjust page scope if marketing shipped new templates. Monthly, generate or export client-facing summaries and revisit budgets using the monthly performance review template if you report on a fixed cadence.

Optional next layers, not required on day one: prospecting with domain reports, comparing tools for portfolio scale, or adding Lighthouse CI in development while Watcher watches production. Lighthouse CI vs managed monitoring covers that split for agencies.

Apogee Watcher setup for multiple client sites

The same sequence repeats per client site inside one organisation: add site, discover or list URLs, schedule, baseline, budgets, alerts. Standardise a starter URL pack per vertical (brochure, ecommerce, SaaS marketing) so delivery does not reinvent scope every kickoff. Keep one role map across clients so new hires know who may change thresholds.

When the portfolio grows past a handful of properties, resist separate logins per client. One organisation with strict site separation preserves quota visibility and lets you answer portfolio health questions from a single sites list, which is the operational habit described in our Core Web Vitals monitoring checklist for agencies.

FAQ

How long does Apogee Watcher setup take?

A single marketing site with ten to fifteen URLs, daily scheduling, and starter budgets typically fits one focused afternoon. Client onboarding with stakeholder email and role assignments may stretch across a week; that timeline is process, not product loading time.

Do I need a PageSpeed Insights API key?

No. Apogee Watcher uses the PageSpeed relationship on your behalf. You configure domains and pages in the dashboard.

Can I monitor staging or password-protected URLs?

You can add any URL the PageSpeed service can fetch. Staging hosts work when they are reachable from the public internet without auth walls. Authenticated app shells are a poor fit for synthetic lab monitoring; use first-party RUM there if the client requires session-level proof. See When to Use Synthetic vs Real User Monitoring for Performance for how to layer tools.

How many pages should I add on day one?

Start with ten to twenty priority URLs, not the entire sitemap. Expand after triage proves the alert path works.

What is the difference between this guide and the multi-site setup how-to?

The how-to compares approaches (DIY Lighthouse CI, managed platforms, hybrid workflows). This guide is the product-specific click path inside Apogee Watcher once you have chosen hosted monitoring.

Does setup include client reporting?

Setup covers measurement and alerts. Branded PDF reports and scheduled delivery depend on plan features; configure reports after the baseline run looks trustworthy.

Where do I get help if discovery returns too many URLs?

Deactivate low-value paths, lower discovery caps, and prefer manual adds for a tight first set. Re-run discovery after the client fixes sitemap quality if the estate publishes one.

Apogee Watcher setup boils down to organisation, site, pages, schedule, baseline, budgets, and alert routing. Run through that sequence once on a real domain and the product carries weekly measurement without another spreadsheet of PSI scores.

Start a free Apogee Watcher account and walk the steps above on your first site, or baseline a hostname with the free domain PageSpeed check before you add it to a recurring schedule.

Two device stories, one URL: why averages lie

Apogee Watcher — Mon, 29 Jun 2026 19:35:05 +0000

The account manager pasted a portfolio screenshot into Slack: average Core Web Vitals pass rate across twelve client sites was 81 percent, up three points from last month. Engineering opened the same week’s export and found checkout on one retailer at 94 on mobile and 41 on desktop, both from the same URL, both in field data. The average looked like progress; the paired rows looked like a revenue problem waiting for a marketing campaign to send desktop traffic to a route that could not convert.

Same URL, two device stories. That is normal for Core Web Vitals, not a tooling glitch. Google’s own field datasets already treat mobile and desktop as separate populations: the Chrome UX Report (CrUX) stores experiences by form factor, and Search Console’s Core Web Vitals report labels each URL group independently for mobile and desktop. The gap is not that vendors lack the split; it is that internal dashboards and client decks collapse the split back into one comforting number.

Why mobile and desktop Core Web Vitals diverge on one URL

Largest Contentful Paint often tracks different elements after responsive layout: a hero image on desktop and a text block or product tile on mobile. Interaction to Next Paint reflects touch versus pointer paths, menu density, and how much main-thread work survives on lower-end hardware. Cumulative Layout Shift spikes when ads, banners, or consent UI appear only under certain viewports. None of that shows up if you only store a single “page score” per URL.

Lab runs make the split obvious when you compare mobile and desktop emulation on the same template. Field data from CrUX does the same by form factor, which is why PageSpeed Insights shows separate rows and accepts strategy=mobile or strategy=desktop in its API. Google’s web.dev guidance on lab versus field data adds a further wrinkle: Lighthouse returns the same LCP candidate every time, while field data on one URL often spans several LCP elements depending on viewport and scroll depth. Stopping at whichever row looks better, or averaging them for a client deck, hides that variance. For metric definitions and fix paths, our LCP, INP, and CLS guide on the Watcher blog stays the reference.

Where blended scores and portfolio averages mislead

We see three patterns that produce misleading comfort in dashboards and decks.

Single-number client reports. A weekly PDF that lists one LCP or one “performance score” per URL without a form-factor column implies one experience. Sponsors assume the number covers how most users browse; in our experience mobile share is often higher on the URLs that matter, but desktop still carries high-value sessions on B2B and admin-heavy flows. Public CrUX aggregates show the same skew: mobile origin pass rates typically trail desktop by several points, so a blended headline can flatter phone-heavy sites even when mobile is the weaker side.

Portfolio rollups. Agency dashboards that average pass rates across domains treat a mobile fail on checkout and a desktop pass on a blog post as partial credit. The rollup climbs while the conversion path stays broken. We prefer worst-of or paired counts: how many priority URLs pass on both mobile and desktop, not how many pass on either. Search Console labels URL groups separately per device; a group can be Good on mobile and Need improvement on desktop. Exporting one “site health” percentage without that dimension is how an eighty-one percent portfolio average coexists with checkout at forty-one on desktop.

“Good enough” thresholds on the stronger device. Teams sometimes ship when desktop clears a budget while mobile INP stays red because desktop was the default Lighthouse profile in continuous integration. The deploy log shows green; support tickets mention “laggy on phone.” A related trap is treating PageSpeed Insights origin-level field data as proof that a specific URL is fine: when URL-level CrUX samples are thin, PSI falls back to origin aggregates, which can mask a single high-traffic template that fails on one form factor only.

Each pattern shares the same fix: store and show mobile and desktop as separate series for the same URL, then alert on the weaker side.

How we report paired device data to clients and internally

We stopped leading with averages in QBR slides. The first table for priority URLs lists mobile LCP, INP, and CLS beside desktop values for the same route, with a column for “both pass” rather than “either pass.” When one side lacks field data, we label it lab-only and do not merge it into a blended pass/fail. For alerts, device-specific thresholds beat a single budget line: a regression that hits mobile INP on checkout triggers the same channel as a desktop LCP fail on the homepage, but the message names the form factor so triage does not waste a day reproducing on the wrong profile.

Internal stand-ups that read “mobile fail / desktop pass” in the subject line have saved us from closing tickets too early, because the split is visible before anyone opens the chart. When a client asks for one headline number, we give them a paired summary: “ten of twelve money URLs pass on both mobile and desktop; two fail on mobile only.” That sentence is less flattering than an eighty-one percent average, and it is the one that gets engineering budget for the checkout script audit. Schedules, budgets, and portfolio views are in mobile versus desktop Core Web Vitals monitoring on the Watcher blog; Watcher holds the checklist, while Hashnode holds the reporting argument.

What to change in monitoring this week

If your stack stores one row per URL, add form factor to the grain before the next client send. Re-run baselines on five conversion URLs with mobile and desktop explicitly selected in PageSpeed Insights or your monitoring product, and note where field data exists for each. When PSI shows origin-level field data only, tag those rows as origin fallback so nobody mistakes them for URL-level proof on both devices. Rewrite one alert policy so a mobile-only breach on a tagged “money URL” cannot be drowned out by desktop green scores on the same path, and add a “both pass” metric for priority tiers if portfolio reporting is automated; the first time that metric drops while the average rises, you will know the blended number was hiding a split.

Next step

Pick one checkout or lead-form URL and publish a paired mobile/desktop baseline internally before the next client-facing report goes out. Use the mobile and desktop monitoring guide for schedules and budgets, and the LCP, INP, and CLS explainer when someone asks what the columns mean. Two device stories on one URL are expected; one averaged story is the number that usually costs you the argument.

When to Use Synthetic vs Real User Monitoring for Performance

Apogee Watcher — Fri, 26 Jun 2026 21:59:50 +0000

Performance monitoring conversations often collapse two different questions into one: "Are we fast in a controlled test?" and "Are we fast for real visitors?" Synthetic monitoring answers the first; real user monitoring (RUM) answers the second. Teams that pick only one layer usually discover the gap after a deploy, when lab scores look fine but conversion drops on mobile, or when CrUX turns red a week later. What follows is a practical split for web teams and agencies: what each method measures, when each is worth the operational cost, and how scheduled PageSpeed monitoring with CrUX context fits beside first-party RUM without forcing a rip-and-replace.

What is synthetic monitoring for web performance?

Synthetic monitoring runs automated tests against URLs you choose, on a schedule you control, in a lab environment, loading each page with a fixed device profile, simulated network, and throttled CPU (for example Lighthouse mobile emulation through PageSpeed Insights) so results stay comparable run to run.

Typical outputs include:

Core Web Vitals from the lab run (LCP, INP, CLS where Lighthouse reports them).
Lighthouse Performance score and supporting timings (FCP, TBT, Speed Index).
Diagnostics and opportunities (render-blocking resources, image sizing, third-party cost).
Chrome User Experience Report (CrUX) percentiles when Google publishes field data for that URL and strategy.

Synthetic monitoring is not a one-off PSI paste into a browser tab. It is the same class of measurement, repeated and stored so you can trend, alert, and report. Our PageSpeed Insights vs automated monitoring guide explains why spot checks fail once you manage more than a handful of URLs. Agencies use synthetic schedules to cover client portfolios (homepage, pricing, lead forms, checkout paths, and campaign landers), usually on both mobile and desktop strategies.

What is real user monitoring (RUM)?

Real user monitoring collects performance data from actual browser sessions on your site. A JavaScript snippet, or tag manager injection, records timings, navigation, and often custom attributes (logged-in state, plan tier, locale) as users browse, which is why RUM reflects real networks, devices, cache states, ad blockers, and consent banners rather than a fixed lab profile.

First-party RUM products (PageVitals, DebugBear, SpeedCurve, Datadog RUM, and others) let you:

Segment by page, device, geography, and custom tags.
See distributions and percentiles from your traffic, not only Google's aggregate.
Monitor routes CrUX rarely covers well (authenticated app shells, low-volume templates).
Tie performance to business events when you connect analytics or product data.

That traffic mix is also why RUM is harder to compare week to week unless you control for seasonality and campaigns. For metric definitions shared by both lab and field programmes, start with What Are Core Web Vitals? and LCP, INP, and CLS explained.

CrUX vs first-party RUM: both are field data, but not the same thing

Teams comparing RUM vs synthetic monitoring sometimes treat CrUX as "free RUM," yet it is field data without session-level detail, and that distinction matters when you choose tooling or write a client report.

Source	What it is	Strength	Limit
CrUX	Google's aggregated Chrome experience for URLs with enough traffic	Aligns with Search Console and SEO reporting; no snippet required	Rolling window; URL-level; limited segmentation
First-party RUM	Your snippet on your origin	Session paths, custom tags, logged-in views	Consent, tag governance, maintenance per site
Synthetic lab	Scheduled Lighthouse-style runs	Same-day, repeatable, works on staging	Simulated users, not real cache or ad mix

PageSpeed Insights and many monitoring tools show CrUX beside lab results, which helps public marketing URLs, but that pairing does not replace RUM when stakeholders ask what paying customers on 4G in Germany experience on a specific checkout step. Mobile vs desktop Core Web Vitals monitoring matters here as well: CrUX and lab both split by strategy, yet RUM segmentation is where device and connection reality show up for product decisions.

Synthetic vs RUM: comparison for web teams

Question	Synthetic (scheduled lab)	First-party RUM
Needs a script on the site?	No	Yes
Works on staging / pre-release URLs?	Yes	Usually no (no real traffic)
Comparable numbers every run?	Yes	Depends on traffic mix
Catches deploy regressions same day?	Yes, if scheduled	Yes, with enough sessions
Good for SEO / CrUX alignment?	Lab + CrUX in PSI output	CrUX separate; RUM is your own dataset
Portfolio scale without per-site snippets?	Favourable for agencies	Harder (consent and client approvals)
Multistep flows (checkout, signup)?	Per-URL unless tool supports journeys	Strong when tagged correctly

Neither approach wins outright because they answer different risk questions: synthetic shows whether yesterday's release broke lab thresholds on URLs you list, while RUM shows whether real users felt it across segments you care about.

When synthetic monitoring is the right choice

Choose synthetic as your primary web performance layer when you manage many sites or URLs and need one schedule, one history store, and one alert policy without installing tags on every client origin. That is the common agency constraint on marketing sites, brochureware, and public app URLs where the client will not approve another analytics script.

Synthetic also fits when you need repeatable baselines before and after a change. Lab runs on the same URL, strategy, and daypart make comparisons honest, whereas field data drifts when traffic mix shifts. The same logic applies to low-traffic or new pages where CrUX may show "no data" for months while scheduled lab runs still return LCP, INP, and CLS every time.

Use synthetic for staging, preview, or password-protected builds before production, because RUM cannot run where users do not visit yet. Pair schedules with performance budgets and alerts when you need a steady measurement source, and with portfolio reporting when clients want trend lines instead of a PDF assembled from manual PSI tabs; Automated vs manual PageSpeed testing shows the time cost when that layer is missing. Synthetic monitoring still does not replace backend APM, error tracking, or session replay: it measures web URLs in the browser lab, plus CrUX where published, not API latency inside your cluster.

When real user monitoring is the better fit

Choose first-party RUM when authenticated experiences dominate the product. Dashboards, account settings, and checkout after login often lack stable CrUX samples, and RUM with custom tags is how you prove INP on those routes. The same applies when stakeholders require segment-level proof by plan tier, locale, experiment bucket, or campaign source, because CrUX will not break down your traffic that way.

RUM also belongs in the stack when you already operate observability tooling and need web vitals beside traces and errors, when CI/CD or feature flags need session-level validation after release, or when multistep journeys must be measured as flows rather than isolated URLs. Legal and client approval for another script varies by estate, and if RUM is already installed you can add synthetic for URLs RUM under-samples or for pre-production checks, while teams with synthetic schedules add RUM where lab and CrUX disagree with support tickets or conversion data.

How agencies combine synthetic and RUM across client portfolios

Agencies rarely get a single answer across thirty clients, but a workable default is to run scheduled synthetic on mobile and desktop for public marketing and lead-gen URLs, read CrUX from the same test results, and keep budgets and alerts in one place without a snippet on every domain. For flagship SaaS or ecommerce clients with RUM already installed, keep their RUM vendor for logged-in app routes and use synthetic for the URLs the retainer covers and for prospects during performance audit outreach; when clients refuse third-party scripts, synthetic plus CrUX is often the entire programme, so say that explicitly in proposals rather than implying session replay is included.

In client reporting, separate slides for lab trends on priority URLs and for RUM segment summaries from the analytics team. Blending both into one green chart invites arguments about methodology. For tool selection by client shape, see comparing PageSpeed monitoring tools for agencies and PageVitals vs Apogee Watcher when RUM and CI/CD are part of the brief. SaaS product teams face a similar split at single-company scale; our SaaS performance monitoring guide covers URL priorities without repeating the full decision tree here.

How scheduled PageSpeed monitoring fits beside RUM vendors

Apogee Watcher is built for scheduled synthetic monitoring across many sites: PageSpeed Insights-backed lab runs, CrUX when Google returns field data, vitals and optional FCP/TBT budgets, portfolio alerts, and multi-tenant organisations for agencies. We do not ship first-party RUM; we sit beside RUM, APM, and Lighthouse CI gates rather than replacing them, so when a client needs session-level RUM, PageVitals, DebugBear, or an observability vendor still belongs in the stack.

Watcher is often the better primary monitor when you run many client domains under one subscription without per-site RUM rollout, when automated page discovery should keep new templates on the schedule without spreadsheet maintenance, when retainers promise ongoing CWV oversight on public URLs rather than full product instrumentation, or when you want prospecting and free evaluation via the domain PageSpeed check before a client signs. Configure mobile and desktop strategies per URL, set budgets, route alerts, and review history in the app, and use RUM elsewhere when the question requires your traffic, your tags, and your logged-in routes.

FAQ

What is the difference between RUM and synthetic monitoring?

Synthetic monitoring runs controlled lab tests on chosen URLs on a schedule. RUM records performance from real user sessions in the browser, usually via a script you install. Synthetic is repeatable and works without site traffic; RUM reflects actual devices, networks, and behaviour, which is why most mature teams treat the two as complementary rather than interchangeable.

Is CrUX the same as RUM?

No. CrUX is Google's aggregated field dataset for URLs with sufficient Chrome traffic, while RUM is first-party data you collect from your visitors. Both describe real loads in the field sense, but CrUX is not session-level RUM and cannot replace custom segmentation on your origin.

Should I use synthetic or RUM for Core Web Vitals?

Use both when you can. Synthetic and CrUX (via scheduled PSI runs) cover public URLs, staging, and low-traffic pages; first-party RUM covers segmented and authenticated experiences CrUX does not explain. SEO and client reporting often lean on CrUX, while product teams often lean on RUM for route-level proof.

Do agencies need RUM on every client site?

No. Many retainers cover public marketing and key templates where synthetic plus CrUX is enough, and you add RUM when the contract includes logged-in app routes, the client already owns a RUM tool, or stakeholders require session-level segmentation that CrUX cannot supply.

Can synthetic monitoring replace RUM?

Not fully. Synthetic answers whether lab thresholds breached on listed URLs, while RUM answers what users experienced broken down by segment, so use synthetic for portfolio scale and pre-release checks and RUM where traffic truth and custom tags matter.

Does Apogee Watcher include RUM?

No. Watcher schedules PageSpeed lab tests and shows CrUX where available, and you should layer it with your RUM or observability vendor when you need first-party session data on authenticated or heavily segmented routes.

How often should synthetic tests run compared to RUM sampling?

Synthetic frequency is a schedule you set (daily, weekly, or higher on risky URLs), while RUM sampling is continuous or rate-limited by your vendor. Match synthetic cadence to release risk, use RUM for always-on field truth where installed, and see test frequency and priority across a portfolio for scheduling patterns across many sites.

Pick synthetic when you need repeatable lab coverage at portfolio scale without a snippet on every domain, and RUM when session segments and authenticated routes drive decisions. Most mature stacks use both, with clear owners for each signal, rather than debating which single tool should own performance end to end.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets across your sites, or run a free domain PageSpeed check to baseline a URL before you add RUM or expand monitoring.

First two weeks of a performance onboarding (realistic scope)

Apogee Watcher — Thu, 25 Jun 2026 21:56:07 +0000

A new client signed the monitoring retainer on Monday and asked on Wednesday when checkout would be green in Lighthouse. Fair question: the SOW mentioned Core Web Vitals, and their last agency had sent a PDF full of red bars.

We had not finished agreeing which checkout URL counted, who owned first response on alerts, or whether mobile field data even existed for that template yet. The work was not missing; the calendar was wrong.

Most onboarding failures we see are scope failures, not skill failures. Teams either treat week one like a mini audit with twenty remediation tickets, or they spend fourteen days in tooling setup and call it done without a baseline the client can repeat. Below is the two-week frame we use with agencies: what we promise, what we defer, and how it lines up with the longer checklists on our main blog.

What goes wrong when onboarding scope is vague on day one

Without a written two-week boundary, three collisions are common. Sales language drifts into delivery: "We will monitor performance" becomes "we will improve Core Web Vitals" in the client's head while engineering still waits for staging access. The URL list balloons when someone exports a sitemap, adds every campaign landing page from the last three years, and schedules tests before anyone marks which routes actually convert. Remediation starts before measurement is trusted when a developer fixes hero images on the homepage while checkout still lacks field data and nobody has agreed on alert severity.

Procurement and delivery can both be happy if week one and week two have named outputs. Those outputs are not "site is fast"; they are "we know what we watch, who acts, and what broke first."

Week one: what to lock before you run PageSpeed tests

Week one is contracts and context, not optimisation. We aim to close five agreements in writing (email is fine):

Primary domain and environments (production first; staging only if the client expects pre-release checks).
Five to ten priority URLs: homepage, main conversion path, one high-traffic template, and commerce or form routes if they exist.
Mobile and desktop coverage (both, unless the client has a documented mobile-only audience).
Alert recipients and a named first responder (one person, not a channel full of @here).
Reporting rhythm: weekly internal scan, monthly client-facing review, and who owns each.

If access is slow, week one still produces a blocker log: who owes credentials, which firewall ticket is open, which analytics consent rule blocks synthetic tests. That log is a deliverable, and it prevents week two from quietly slipping to week four.

Our site audit checklist for onboarding new clients into performance monitoring has the full tick list for access, URL inventory, and handover. On Hashnode we are only arguing for order: scope and owners before quotas and schedules.

Week two: baseline, thresholds, and the first client-safe summary

Week two is when tools earn their place. Run initial tests on the priority URL set from week one, record LCP, INP, and CLS for mobile and desktop where data exists, and mark pages with no field data so nobody interprets a lab-only score as a production guarantee.

Set conservative thresholds on those same URLs. Tight budgets on day ten usually mean alert noise by day seventeen, so we would rather start slightly loose, watch one full weekly cycle, and tighten after we see variance.

Wire alerts to the routes agreed in week one: one internal channel for regressions that need same-day eyes, and a separate, slower route for client-visible summaries if the contract includes them.

Draft a short "what we monitor and why" note the account lead can send without engineering in the thread. Three paragraphs cover which URLs, which metrics, what happens when a threshold breaks, and what is explicitly out of scope for the monitoring retainer.

End week two with three actions from the baseline, each with an owner and a due date. They can be investigative ("confirm whether tag X loads on checkout") rather than shipped fixes; the client should see prioritisation, not a promise that all three close before month end.

What we deliberately defer past the first two weeks

Saying no early protects the retainer later. Full template coverage across hundreds of URLs belongs in month two unless the contract priced it; CI gate design, CrUX versus lab reconciliation workshops, and third-party script triage across every tag manager container are real work, but they are not week-two work.

We also defer client-facing dashboard polish, because a screenshot of a green score without context creates the same false confidence as the PDF they received from the previous vendor. Remediation sprints stay separate from monitoring setup unless the SOW merged them with hours attached; mixing the two in fortnight one is how agencies absorb unpaid engineering.

If the client pushes for fixes immediately, we point to the three actions from the baseline and offer a change order for implementation. Monitoring onboarding is complete when everyone can answer what broke first, who got pinged, and what we do next.

How the two-week frame maps to ongoing CWV operations

Fortnight one is intake; the recurring habit starts afterward. After week two, we hand teams the Core Web Vitals monitoring checklist for agencies for weekly scans, monthly deep dives, and deploy checks. That document assumes monitoring is live and scoped. Without the two-week frame, teams treat the checklist like a one-off audit and abandon it when the first sprint ends.

In practice the split looks like this:

Phase	Question it answers	Typical owner
Weeks 1–2 (this post)	What do we watch, who responds, what is the baseline?	Delivery lead + technical lead
Week 3 onward (Watcher checklist)	What do we do every Monday and every month?	Account manager + engineering

Agencies managing several clients benefit from the same shape every time. Portfolio onboarding is repetitive; the client's internal politics are not. Reusing the two-week boundary makes it easier to compare sites without pretending each onboarding is bespoke heroics.

What to put in the client email at the end of week two

We keep the end-of-fortnight email short enough to forward inside the client's organisation:

Confirmed URL list (with one-line business reason per URL).
Baseline table for LCP, INP, CLS on those URLs (note where field data is missing).
Alert routes and first responder name.
Top three findings with owners (not necessarily fixes).
Explicit "starts week three" items: expanded coverage, remediation quotes, workshop dates.

That email sets expectations better than another Lighthouse export: procurement sees deliverables, engineering sees assigned tickets, and sponsors see that monitoring is operational rather than a slide in the pitch deck.

Next step

If you are onboarding a client this month, write the two-week outputs before you buy more test quota. Use the site audit checklist for ticks inside each week, then move into the agency CWV checklist once alerts have survived a full weekly cycle without being muted. Realistic scope is not pessimism; it is how monitoring retainers survive contact with real clients.

Lighthouse CI vs Managed Monitoring: Build vs Buy for Agencies

Apogee Watcher — Fri, 12 Jun 2026 05:42:11 +0000

The agency lead inherited twelve client repositories, each with a Lighthouse CI workflow that passed on Friday and missed a checkout regression by Monday. Reporting meant exporting JSON, pasting scores into slides, and hoping the account manager could explain why /cart turned red while the homepage stayed green.

That pattern is common in r/webdev and r/TechSEO threads: Lighthouse CI is the right starting point, then monitoring becomes a second job. Incumbent SaaS tools often price per site or push enterprise tiers, so teams keep patching YAML while client evidence stays messy.

This guide compares Lighthouse CI (build) with managed PageSpeed monitoring (buy) for agency portfolios. We are not arguing you should delete CI. We explain where DIY breaks at scale, what a managed layer adds, and how to keep both without turning web performance into unpaid operations work.

What is Lighthouse CI and why do agencies adopt it first?

Lighthouse CI runs Lighthouse inside your pipeline: collect scores on a preview URL, store history, and assert against budgets before a merge ships. It is open source, free to run on your runners, and familiar to developers who already gate tests in GitHub Actions, GitLab CI, or Jenkins.

Agencies adopt it for sensible reasons:

Merge protection on home, pricing, or a heavy template before deploy.
Reproducible lab numbers on a candidate build, not a one-off paste into PageSpeed Insights.
No SaaS invoice while the portfolio is small and one engineer owns the scripts.

Our performance budgets in CI/CD guide walks through lighthouserc, assertions, and preview URLs. For a wider tool map, see best free PageSpeed monitoring tools, which places Lighthouse CI beside PageSpeed Insights, WebPageTest, and managed monitors.

Lighthouse CI answers: did this build pass the thresholds we configured on the URLs we added to the workflow? It does not, by itself, answer: which client URL regressed in production this week, and what do we send the sponsor?

Why Lighthouse CI maintenance becomes a full-time job for agencies

The friction rarely appears on client one. It appears when you add client five, then fifteen, each with different hosts, preview providers, authentication walls, and template sets.

Per-repository scripts do not scale across a portfolio

Lighthouse CI is repository-centric. Agencies are portfolio-centric. Copying lighthouserc into every client repository means version drift: one client pins Lighthouse 11, another still runs 10, assertions differ, and nobody knows which workflow is authoritative.

Preview URL patterns change when a client moves from Netlify to Vercel or adds staging basic authentication. A green CI run on / does not guard /checkout if that route never entered the configuration. Teams discover the gap when scheduled checks or a sponsor's manual PageSpeed Insights run shows red.

Flaky builds and muted alerts

Lighthouse in CI is sensitive to runner CPU, network, and cold caches. Intermittent failures train teams to re-run until green or silence the job. Once alerts are muted, the pipeline becomes theatre: it passes, but nobody trusts it.

Keeping intermittent failures down means engineering time: pinned Chrome channels, warm caches, median-of-N runs, relaxed thresholds that are too loose to catch real regressions, or strict thresholds that block merges on noise.

No client-ready reporting layer

CI output is for engineers. Client sponsors want a short narrative: what changed, on which URLs, against which budget, with field context where it exists. Exporting Lighthouse CI artefacts into slides each month does not scale. Account managers should not need terminal access to defend a retainer.

Field drift and CrUX are outside the pipeline

CI sees the candidate build in a lab environment. It does not track CrUX movement on production URLs after deploy, competitor content management system changes, or third-party script weight that shifts without a merge. Agencies need both merge gates and ongoing schedules on the URLs clients actually care about.

In our experience, the tipping point is often five to ten production sites with more than two templates each. Below that, a motivated engineer can babysit scripts. Above it, maintenance competes with billable delivery unless monitoring is a productised service line with its own tooling budget.

What managed PageSpeed monitoring adds for multi-site agencies

Managed monitoring products schedule Lighthouse and CrUX-backed checks across many URLs, retain history, fire alerts, and present a portfolio view. They are built for the questions CI leaves open.

Job	Typical Lighthouse CI setup	Managed PageSpeed monitoring
Block a bad merge on a preview URL	Strong	Not the primary job
Track 50+ URLs weekly without editing YAML per client	Weak	Strong
Show lab + field context in one place	Manual export	Built in
Alert when `/checkout` crosses a budget	Only if wired and maintained	Schedule + threshold per URL
Client-facing evidence without custom scripts	Rare	Dashboards and exports
Onboard a new site in minutes	New repository work	Add domain, discovery, budgets

Apogee Watcher is one managed option aimed at agencies: multi-tenant dashboard, automated discovery, performance budgets, lab plus CrUX on scheduled runs, and team roles without per-client API key juggling. It layers beside your stack; it does not replace Git, your content management system, or your existing CI gates.

For a feature-level comparison across vendors, read comparing PageSpeed monitoring tools: features agencies need. For the manual-vs-automated framing, see PageSpeed Insights vs automated monitoring.

Build vs buy: decision criteria for agency PageSpeed monitoring

Use this checklist when you are choosing between extending Lighthouse CI and buying managed monitoring.

1. Count the hidden engineering hours

Estimate monthly time on:

Updating Lighthouse versions and runner images across repositories.
Fixing preview URL or authentication breakage after client infrastructure changes.
Tuning assertions when legitimate design work triggers false failures.
Building reports for client quarterly business reviews from CI artefacts.

If that total exceeds the subscription cost of a managed monitor and still leaves reporting manual, buy is usually cheaper in margin terms.

2. Price at portfolio scale, not per repository

Lighthouse CI has no licence fee, but runners are not free. More repositories mean more minutes, more storage for artefacts, and more on-call context switching. Managed tools should be judged on cost at 10–20–50 sites, not on a single-project quote.

Agency tiers exist because per-site pricing from premium monitors (often cited in the $90–$500+/month range for enterprise-style real user monitoring stacks) breaks retainers. Watcher's positioning is multi-tenant first: one subscription for the portfolio, not a surprise line item per client domain.

3. Separate merge gates from production surveillance

CI should stay thin: a small set of URLs on the merge path, bundle limits, and assertions you are willing to enforce. Production surveillance belongs on a schedule across templates you will never add to every pipeline, including routes marketing does not own.

Trying to make CI do both produces either huge workflows or neglected configurations. Split the jobs explicitly.

4. Reporting is a product requirement, not a nice-to-have

If clients pay for performance oversight, the deliverable is evidence they understand. CI logs are not a deliverable. Before you commit to build, name who produces the monthly report and how long it takes. If the answer is "the lead developer, ad hoc," buy addresses the bottleneck.

5. Integrate, do not rip-and-replace

Keep Lighthouse CI where it already works. Add managed monitoring for portfolio schedules, CrUX drift, and alerts. Link findings back to tickets. This matches how mature teams use PageSpeed Insights for spot checks, WebPageTest for deep dives, CI for gates, and a monitor for ongoing defence.

When should agencies keep Lighthouse CI in the stack?

Keep Lighthouse CI when:

You ship frequently on a defined preview URL and need hard merge blocks.
Bundle or request-count budgets are part of your definition of done.
A platform team can own one golden workflow template cloned to new repositories.

Reduce reliance on CI alone when:

Clients change hosts or templates faster than you update workflows.
Sponsors ask for field metrics and history CI never collected.
Engineers describe monitoring as "another thing we maintain" rather than a service you sell.

Our automated PageSpeed monitoring setup guide covers schedules, discovery, and budgets on the managed side. Pair it with CI gates from the performance budgets CI/CD post so pre-merge and post-deploy responsibilities stay clear.

How to move from fragile CI-only monitoring to a managed layer

You do not need a single cutover migration. A practical sequence:

Inventory URLs clients care about beyond the CI defaults: checkout, account, search, key landing pages. Use a site audit checklist during onboarding so the list is explicit.
Leave CI on one or two gate URLs per repository with stable assertions. Remove noisy checks that teams already ignore.
Add scheduled monitoring on the full URL set per client with shared budgets. Align thresholds with what you already assert in CI where it makes sense.
Route alerts to owners using policies people follow. Fewer routes beat a flood of critical pings nobody answers. See from reactive to proactive smart alerts for routing patterns.
Standardise client reporting from the monitor's dashboard or exports instead of rebuilding slides from Lighthouse CI JSON each month.

New clients should get the managed layer on day one; retrofit CI-heavy accounts during the next quarterly business review when reporting pain is already on the agenda.

Where incumbents leave gaps agencies still feel

Enterprise monitors invest in deep single-site real user monitoring and synthetic suites. That is valuable for product companies with one flagship application. Agencies running 10–50+ client sites routinely report different gaps in community threads:

Per-site pricing or API key overhead that does not match retainer economics.
Dashboards built for one product team, not a portfolio with separate sponsors.
Slow roadmap movement on multi-tenant workflows, white-label reporting, or prospecting-friendly exports.

Watcher is positioned in that gap: monitoring-first, agency-shaped pricing, lab plus CrUX without you holding PageSpeed Insights API keys, and a path toward client-ready reporting. It is not a replacement for your CI system or for specialised real user monitoring where a client already instruments their application.

FAQ

What do agencies mean by a Lighthouse CI alternative?

Lighthouse CI is not a substitute for itself; it is the open-source path for CI gates. When teams look for an alternative, they usually want a managed monitor that covers portfolio schedules, alerts, and reporting without maintaining Lighthouse CI across dozens of repositories. Keep CI for merges; add managed monitoring for ongoing surveillance.

Can managed monitoring replace Lighthouse CI entirely?

We do not recommend that for most agencies. Managed monitoring is weak as a merge gate on ephemeral preview URLs unless the vendor integrates directly with your pipeline. Use CI to block bad builds; use managed monitoring to watch production templates and client-facing routes on a cadence.

How does this compare to DebugBear, SpeedCurve, or Oh Dear?

Those are SaaS monitors with their own pricing and depth trade-offs. Lighthouse CI is DIY on your runners. The build-versus-buy question here is engineering time versus subscription for portfolio workflows. For vendor-by-vendor feature rows, use the agency PageSpeed tools comparison and dedicated comparison posts where they exist.

What should we enforce in CI versus in monitoring?

CI: a small URL set on the merge path, bundle limits, and assertions you will actually fix before merge. Monitoring: full template coverage, CrUX-aware budgets, alerts, and history sponsors can see. Overlap is fine on critical URLs; duplication of every check in both places is not.

Does Apogee Watcher require ripping out existing scripts?

No. Watcher is designed to layer beside PageSpeed Insights, WebPageTest, CI, and client content management system workflows. Add domains, set budgets, and schedule tests; keep Lighthouse CI where it already protects merges.

Next steps for agency teams

If monitoring still feels like a full-time job built from scheduled cron jobs, YAML configuration, and slide exports, treat that as a build-versus-buy signal. Keep Lighthouse CI for merge protection. Add a managed monitor for portfolio schedules, field context, and client evidence.

Start a free trial and baseline your top client URLs, or run a free domain PageSpeed check on a prospect site before you scope the next retainer. For onboarding checklists and URL priorities, pair this article with how to onboard a new client for performance monitoring.

Performance Monitoring for SaaS: Metrics That Matter for Product Teams

Apogee Watcher — Thu, 11 Jun 2026 07:02:51 +0000

A SaaS product team opens the observability dashboard and sees healthy API latency. Signup still drops after a frontend deploy. Marketing reports strong traffic on pricing, but trials do not convert. The gap is familiar: backend APM measures services and databases. It does not tell you whether the pricing page, signup flow, or logged-in shell feels fast in Chrome on a mid-range phone.

SaaS performance monitoring for product teams starts on the web surfaces users actually load: marketing sites, documentation, authentication routes, and the JavaScript-heavy app URLs you can test on a schedule. This guide separates front-end web monitoring from backend APM, lists the metrics worth tracking first, and shows how to layer scheduled PageSpeed monitoring beside the tools you already run.

What does SaaS performance monitoring mean for product teams?

For product and growth leads, performance monitoring means catching regressions on revenue paths before they show up in funnel dashboards. That includes:

Public marketing URLs (home, pricing, comparisons, security pages).
Acquisition flows (signup, trial activation, invite acceptance).
High-traffic app entry routes (dashboard home, project list, first-run onboarding).
Documentation and help centres that support activation and reduce support load.

It does not mean replacing Datadog, New Relic, or OpenTelemetry on APIs. Those tools answer whether the server responded quickly. Core Web Vitals and scheduled lab tests answer whether the page rendered and responded in the browser.

SaaS teams that monitor only backend metrics often discover UI regressions late: a new analytics bundle slowed INP on signup, a chart library pushed LCP on the dashboard, or a hero video on pricing hurt mobile conversion. Product teams need both layers, with clear owners.

Front-end web performance vs backend APM for SaaS

Question	Backend APM / tracing	Web performance monitoring
Did the API return in time?	Yes	No
Did the browser paint and respond?	No	Yes
Works without app instrumentation on public URLs?	Partial	Yes (synthetic + CrUX)
Catches third-party script weight on marketing?	Rarely	Yes
Ties to SEO and page experience?	No	Yes (field CWV)

Use APM for service health, database queries, and queue backlogs. Use web performance monitoring for URLs where marketing, SEO, and product UX meet.

If your SaaS is a single-page application, many "product" screens still load as URLs. Monitor the routes that matter for activation and retention, not only api.example.com health checks.

Agencies managing SaaS clients follow the same split. The retainer covers marketing and key app URLs; the client's platform team owns service-level APM. Reports should say which layer moved, not blend them into one green dashboard.

Core Web Vitals metrics SaaS product teams should track

Google's field programme centres on LCP, INP, and CLS at the 75th percentile. For SaaS web applications, we treat all three as first-class, with stricter INP expectations on interactive product surfaces.

Largest Contentful Paint (LCP)

LCP measures loading of the largest visible element. On SaaS sites it often maps to hero content on marketing pages, skeleton states on dashboards, or the first meaningful chart/table in app shells. Slow LCP on pricing or signup hurts consideration before a user reaches your APM-instrumented API.

Interaction to Next Paint (INP)

INP is usually the metric product teams feel first. Signup forms, command palettes, filters, drag-and-drop boards, and inline editors all depend on main-thread responsiveness. Our INP guide covers debugging; for SaaS, prioritise INP on routes where hesitation costs trials or daily active use.

Cumulative Layout Shift (CLS)

SaaS UIs load dynamic components: toast notifications, modals, async tables, and banner slots. CLS spikes cause mis-clicks on mobile and erode trust during payment or permission steps. Budget CLS tightly on onboarding and billing templates.

For metric definitions and fix patterns, see LCP, INP, and CLS explained.

Supporting lab metrics for JavaScript-heavy SaaS UIs

SaaS front ends ship large JavaScript bundles. Field INP may lag a week after a deploy. Lab metrics from scheduled Lighthouse runs help you catch regressions earlier.

First Contentful Paint (FCP) shows when the UI first paints. Total Blocking Time (TBT) estimates main-thread blocking during load. Both appear in PageSpeed Insights lab output. They are not Core Web Vitals ranking signals on their own, but they often move before field INP updates on heavy React or Vue apps.

Our FCP and TBT guide explains when to add them to budgets. For SaaS dashboards and settings pages, TBT regressions frequently predict INP pain on filters and modals.

Which SaaS URLs and flows to monitor first

You cannot monitor every route on day one. Start with URLs tied to money and activation:

Marketing home and pricing (SEO and paid landing traffic).
Signup, login, and password reset (conversion and support load).
First-run onboarding or empty-state dashboard (activation).
One high-traffic in-app list or report view (retention signal).
Documentation index and top help article (reduces tickets, supports SEO).

Run mobile and desktop strategies on each. SaaS INP often fails on phones while desktop looks fine; see mobile vs desktop CWV monitoring.

Add routes when releases touch them. A quarterly manual audit misses the deploy that broke signup on Tuesday.

Performance budgets for SaaS web applications

A performance budget turns "slow" into a threshold your team can enforce. Without numbers, product debates drift into subjective "it feels fine on my laptop."

Our performance budget guide explains the model. The budget thresholds template includes a SaaS / web applications row. Typical starting points from that template:

Metric	Mobile budget (starter)	Desktop budget (starter)	Priority
LCP	2,500 ms	2,000 ms	High
INP	100 ms	75 ms	Critical
CLS	0.05	0.05	Critical
FCP	1,500 ms	1,200 ms	High
TBT	150 ms	100 ms	Critical

Record a baseline month before tightening. SaaS apps with heavy client-side routing may need slightly looser lab score targets than marketing-only sites, but INP and CLS should stay strict on signup and billing.

Alerts and scheduled tests make budgets operational. Our performance budgets and alerts product overview describes how we implement site-level thresholds and notifications in Apogee Watcher.

Synthetic scheduling vs field data in SaaS release cycles

SaaS teams ship weekly or daily. Field CrUX updates on a rolling window. Scheduled synthetic tests give you a comparable number every run on the same URL and device profile.

Use field data (CrUX, Search Console) when you have volume on public marketing URLs and need SEO-aligned reporting. Use scheduled lab tests when:

a URL is new or low-traffic;
you need same-day feedback after a frontend release;
you compare mobile and desktop on identical scripts;
you monitor staging or preview URLs before promotion.

PageSpeed Insights vs automated monitoring covers why spot checks fail at SaaS cadence. Manual PSI runs are useful for debugging; they are not a monitoring programme.

Product analytics (trial starts, activation steps) remains the business ground truth. Web performance metrics explain why a funnel step worsened after a deploy. Connect them in reviews: "signup INP regressed 40 ms; trial completions down 6% on mobile."

How agencies monitor performance across multiple SaaS clients

Agencies running retainers for SaaS marketing sites or product marketing microsites face portfolio scale problems: different stacks, different release cadences, one reporting template.

Patterns we see work:

One organisation per client, shared page groups by template (marketing vs app shell).
Standard starter URL sets per vertical (pricing, signup, docs landing).
Paired mobile/desktop strategies with the same schedule.
Client reports that separate marketing CWV from "app URLs we monitor" without claiming backend APM coverage.
Automated monitoring setup once, then clone patterns per new SaaS client.

When prospects ask for SaaS performance monitoring, clarify whether they mean public URLs, logged-in RUM, or API latency. Our tools comparison for agencies explains where scheduled synthetic monitoring fits beside RUM vendors.

Where Apogee Watcher fits in a SaaS monitoring stack

Apogee Watcher monitors web and mobile-web URLs on a schedule: PageSpeed lab results, CrUX where available, vitals and optional FCP/TBT budgets, portfolio alerts, and multi-tenant organisation structure for agencies.

We do not replace SaaS APM, error tracking, or session replay. Layer Watcher on marketing and priority app URLs. Keep Datadog, Sentry, PostHog, or your RUM vendor for logged-in behaviour and API traces.

In the app, you configure sites, discovery rules, mobile/desktop strategies, budgets, and alert channels per client or per product line. Export and API access keep data portable.

If poor performance is already hurting pipeline, translate metrics into business language using our cost of poor web performance guide before you present charts to leadership.

FAQ

What is SaaS performance monitoring?

For product teams it usually means tracking how fast marketing and app web URLs load and respond in browsers: Core Web Vitals (LCP, INP, CLS), optional lab metrics (FCP, TBT), and trends over scheduled tests. Backend APM is complementary, not a substitute.

Which SaaS performance metrics matter most?

Start with LCP on acquisition URLs, INP on signup and core product interactions, and CLS on dynamic layouts. Add FCP and TBT in lab monitoring when JavaScript weight is high. Tie changes to funnel steps you already measure in product analytics.

Should SaaS teams use stricter INP budgets than marketing sites?

Often yes on authenticated app routes. Interactive surfaces should feel immediate. Use the SaaS row in our performance budget template as a starter, then adjust from baselines.

Does SaaS performance monitoring require RUM instrumentation?

Not for public URLs. Scheduled synthetic tests and CrUX field data cover marketing and many app routes without a browser snippet. Logged-in-only flows may still need RUM from your analytics or observability vendor for session-level proof.

How often should SaaS teams run performance tests?

Match release risk: weekly at minimum on priority URLs, daily or post-deploy on signup and pricing during active frontend work. Test frequency and priority scheduling helps portfolios avoid testing everything equally.

Can Apogee Watcher monitor SaaS API performance?

No. Watcher monitors web URLs via PageSpeed schedules and vitals budgets. Use APM for APIs and services. Use Watcher for marketing sites, docs, and key app URLs across clients or product lines.

SaaS product teams need web performance monitoring on the URLs that drive trials and daily use, not only green API dashboards. Track Core Web Vitals on priority routes, add lab metrics when JavaScript is heavy, set SaaS-shaped budgets, and layer scheduled monitoring beside APM and RUM.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets on marketing and app URLs, or run a free domain check on a SaaS pricing or signup page that regressed after the last frontend release.

Core Mobile Vitals: What Web Performance Teams Should Know (and What to Monitor Today)

Apogee Watcher — Thu, 11 Jun 2026 07:02:33 +0000

Your portfolio probably mixes responsive sites, hybrid apps with WebViews, and native iOS or Android products. Sponsors ask for "mobile vitals" in one breath. The metrics behind that phrase depend on where the user actually loads content.

Google's Core Web Vitals apply to pages in Chrome. Native apps use different instrumentation, different release cycles, and different failure modes. Embrace and SpeedCurve are now promoting Core Mobile Vitals as a user-focused framework for native experiences.

Web performance teams need a clear split: what is settled on mobile web, what is still forming for native apps, and what you can monitor this quarter without inventing thresholds that do not exist yet.

What are Core Mobile Vitals?

Core Mobile Vitals (CMV) is an initiative led by Tammy Everts (SpeedCurve) and Embrace. The goal is a shared vocabulary for mobile app experience quality, similar to what Core Web Vitals did for the web.

Embrace describes CMV as user-focused and tied to business outcomes, not developer-only timings. The framework is still taking shape. Embrace publishes posts on Core Mobile Vitals and why mobile deserves an equivalent to CWV. There is no Google-style public threshold table for CMV yet.

That matters for planning. You cannot copy LCP or INP pass bands into a native app RFP and call it done. CMV starts with experience pillars and goals. Metrics follow as the community agrees on definitions and field collection.

Web teams should follow the conversation, especially when clients ship both a marketing site and a store app. CMV is not a replacement for CrUX on URLs.

Do not confuse CMV with mobile Core Web Vitals. Mobile CWV means LCP, INP, and CLS on phone form factors in Chrome: field data from CrUX, lab data from Lighthouse mobile emulation. Same three metrics, different device profile.

This post uses "Core Mobile Vitals" for the native-app framework and "mobile CWV" for vitals on mobile web unless the context is obvious.

Why Core Web Vitals gave web teams a shared language

Before CWV consolidated around LCP, INP, and CLS, performance meetings drifted. One week it was Time to Interactive. The next it was Speed Index, custom RUM percentiles, or whichever Lighthouse score someone ran that morning. Sponsors could not compare templates. Agencies could not write one monitoring clause.

CWV fixed the vocabulary problem for public web content:

Three field metrics at the 75th percentile, reported in CrUX and Search Console.
Lab companions in Lighthouse for debugging, not for ranking pass/fail on their own.
A clear split between SEO page experience (field vitals) and engineering diagnostics (lab output).

That shared language is why mobile vs desktop CWV monitoring is a portfolio question, not a philosophical one. You still monitor LCP, INP, and CLS. You run paired mobile and desktop strategies because the numbers diverge.

Our LCP, INP, and CLS guide stays the technical anchor for fixes once monitoring shows a regression.

Native mobile never inherited that consolidation. App teams still juggle cold start, frame drops, ANRs, crash-free sessions, and screen-level traces from their APM or RUM vendor. Product and engineering can agree that "the checkout screen feels slow" without agreeing on which metric proved it.

CMV is an attempt to standardise that vocabulary for apps, not for websites.

Why native mobile apps still lack an equivalent framework

Several structural differences slow a single "mobile vitals" standard for native apps.

Platforms and runtimes differ

iOS and Android expose different lifecycle hooks, threading models, and GPU behaviour. A metric that is straightforward on UIKit may need a different definition on Jetpack Compose. Web CWV benefits from one rendering pipeline in Chrome. Native apps do not.

Session shape differs

Users background apps, resume mid-flow, and move through stacks of screens rather than linear page loads. Screen Load in CMV language maps to view-controller timing, not to a single HTML document. Responsiveness includes gestures, animations, and offline queues that INP on a URL never sees.

Distribution and measurement differ

CrUX samples real Chrome users at scale. Native RUM depends on SDK instrumentation, sampling rates, and privacy rules in each store ecosystem. You can standardise definitions. You cannot assume a free public dataset like CrUX for every app's screens.

Ownership differs on mixed portfolios

Agencies often own the WordPress or headless storefront but only advise on the companion app. Web retainers cite Search Console. App work sits with mobile engineering and a different vendor contract. Without a shared framework, quarterly reviews compare incomparable charts.

CMV does not remove those splits. It gives native teams a shared target for measurement conversations. Web teams still need an explicit lane for mobile web.

Embrace's four experience pillars for native apps

Embrace groups early CMV thinking around four experience pillars. Treat these as goals, not final published metrics with universal thresholds. Embrace and partners are still defining how each pillar maps to field measurements across iOS and Android.

Screen Load

How quickly a user sees meaningful content after navigating to a screen: view loading, first render, and time until the screen is usable. Native SDKs can instrument UIViewController lifecycle stages (for example viewDidLoad through viewDidAppear) and correlate slow screens with abandonment.

This is the app analogue to caring about LCP on web. It is screen-scoped, not URL-scoped.

Smoothness

Frame pacing and jank: scrolls, transitions, and animations that drop frames or hitch. Web CLS captures layout shift. Native smoothness is closer to GPU and main-thread frame budgets during motion. Teams already using mobile RUM often have jank or slow-frame reports under different names.

Responsiveness

Tap-to-feedback latency across the session, not only the first interaction. It parallels INP in intent (did the app feel slow after I touched it?) but must cover native controls, gestures, and offline retries. Hybrid apps may need both INP on WebView URLs and native responsiveness on shell screens.

Stability

Crashes, hangs, and broken flows that end the session or block completion. Web CLS and vitals do not replace crash-free rate or ANR counts. Sponsors still ask for stability even when LCP is green.

In our experience, the useful takeaway for web-led teams is directional. When a client cites CMV in a workshop, ask which pillar they mean and whether the pain is on a native screen, a WebView, or the mobile browser site. Do not invent CMV "good" bands in contracts until Embrace and the community publish them.

Core Web Vitals on mobile web: what to monitor today

For responsive sites and mobile-browser traffic, mobile CWV is the settled standard. Monitor LCP, INP, and CLS on a mobile strategy alongside desktop on priority URLs.

Use field data when CrUX has volume. Use scheduled lab runs when a URL is new, low-traffic, or you need week-to-week comparability.

Practical checks we see in agency portfolios:

Home, category, and article templates on mobile and desktop with the same cadence.
Checkout or logged-in flows where INP on phones often fails first.
Third-party and tag weight that hurts mobile LCP before desktop moves (supporting lab metrics like FCP and TBT often shift on mobile first).
CMS-driven properties where plugins defer assets differently per breakpoint; WordPress performance monitoring is a common example.

PageSpeed Insights and CrUX both expose mobile form factor data where Google publishes it. Your monitoring tool should store strategy per URL (mobile vs desktop), apply budgets per strategy, and alert when either side regresses.

Many "core mobile vitals" searches actually mean mobile web. That is the operational baseline above.

How web performance teams should combine web monitoring and native RUM

Think in three layers rather than one blended score:

Layer	What the user opens	What to use today
Mobile web	Chrome (or in-app browser) on a URL	CWV field + lab on mobile strategy; CrUX in PSI
Hybrid WebView	App shell loads your URL	Mobile CWV on the URL plus native traces for shell navigation
Native screens	Swift/Kotlin UI	Vendor RUM/APM (Embrace, etc.); watch CMV pillar definitions as they mature

Apogee Watcher fits the web and mobile-web layer: scheduled PageSpeed tests, LCP/INP/CLS and optional FCP/TBT budgets, multi-tenant sites and pages, portfolio alerts, and CrUX in test results where available.

We do not ship a native app SDK or CMV dashboards in-product. Layer Watcher beside native observability. Do not replace an app RUM stack because a web monitor covers marketing URLs.

For mixed retainers, split the report. Show mobile CWV trends for public URLs and native pillar notes from the app team's vendor. Call out when a WebView URL fails mobile INP while the native shell scores well on Screen Load. Clients trust that honesty more than a single blended "mobile score."

What agencies should document in retainers

Until CMV thresholds exist, write contracts in plain terms:

Mobile web: field LCP, INP, and CLS at agreed percentiles on a mobile test strategy; reference Search Console where SEO is in scope.
Native app: reference the client's chosen RUM vendor and CMV pillar goals when the mobile team adopts them; avoid copying CWV numbers into app SLAs.
Hybrid: list which URLs are monitored as web properties and which screens stay with the app team.

Revisit the doc when Embrace publishes firmer CMV metric definitions. Link internally to your Core Web Vitals monitoring checklist and onboarding guides so delivery teams configure both strategies on day one.

FAQ

Are Core Mobile Vitals the same as Core Web Vitals on phones?

No. Mobile Core Web Vitals are still LCP, INP, and CLS, measured on mobile form factors in Chrome. Core Mobile Vitals is a separate, emerging framework for native app experiences from Embrace and SpeedCurve. Hybrid products may need both.

Does Google rank native apps on Core Mobile Vitals?

No. CMV is not a Google Search ranking programme. Google's page experience signals apply to web content in Search. Native app discovery and store policies use different signals.

What mobile app performance metrics should we track while CMV matures?

Keep your existing native stack: cold start, screen timing, crash-free sessions, ANR rate, and key funnel completion. Map them informally to Screen Load, Smoothness, Responsiveness, and Stability when talking to sponsors. Do not rename vendor metrics to CMV in contracts until definitions stabilise.

Should we monitor mobile and desktop Core Web Vitals separately?

Yes. Run paired strategies on priority URLs. Mobile often fails first on LCP and INP even when desktop looks healthy. See our mobile vs desktop CWV guide.

Can Apogee Watcher monitor Core Mobile Vitals in native apps?

No. Watcher monitors web and mobile-web URLs via scheduled PageSpeed tests and supports vitals plus optional FCP/TBT budgets per mobile or desktop strategy. Use native RUM for app screens; use Watcher for URL portfolios and client sites.

Where can we read more about Core Mobile Vitals?

Start with Embrace's posts on Core Mobile Vitals and their broader mobile performance guides. Pair that with our Core Web Vitals primer and supporting lab metrics guide for the web side.

Web teams already have a standard for mobile browser experience: Core Web Vitals on a mobile strategy, monitored beside desktop. Core Mobile Vitals is the parallel conversation for native apps, organised around Screen Load, Smoothness, Responsiveness, and Stability until shared metrics and thresholds catch up.

Monitor what is defined today. Layer tools instead of forcing one score across web and app.

Start a free Apogee Watcher account to schedule mobile and desktop PageSpeed tests with vitals budgets across client URLs, or run a free domain check on a mobile strategy that regressed after the last release.

Outgrowing GTmetrix: what agencies ask next

Apogee Watcher — Wed, 10 Jun 2026 21:35:03 +0000

The Slack message is familiar: "Can you run GTmetrix on the homepage and send the PDF?" For one client, that habit works. The report is legible, the waterfall helps when LCP looks wrong, and stakeholders recognise the format.

At ten or fifteen retainers, the same request starts to sound like a coverage plan. Nobody intends to monitor three URLs forever, but the bookmarks multiply, the monitored-slot maths gets awkward, and the person who "owns GTmetrix" becomes a bottleneck. In our experience, agencies do not outgrow GTmetrix because the product failed. They outgrow the workflow of treating every performance question as a one-off lab run.

Below is what teams ask once spot checks stop scaling, what we still send people to GTmetrix or WebPageTest for, and how we add scheduled PageSpeed monitoring on top without a rip-and-replace pitch.

When "run GTmetrix" stops matching how your agency works

The break point is rarely a bad score. It is operations.

You add a campaign landing page on Tuesday. By Friday, nobody has added it to the monitored list. A developer ships a cache change on a category template; the homepage still looks green because that is the URL everyone tests. A new account manager asks for "the performance report" and receives three different PDFs from three different tools, each from a different week.

That is the moment the conversation changes from "which tool has the prettier waterfall?" to "how do we know what shipped last week actually stayed in budget?" Spot-check tools answer the first question well. They do not, by themselves, answer the second across a portfolio.

We hear four follow-up questions in agency channels once that gap is visible. They are less about Lighthouse versions and more about who maintains lists, who gets alerted, and what clients see without another manual run.

What GTmetrix-style spot checks still do well

GTmetrix, WebPageTest, and a fresh PageSpeed Insights tab are still the right call when you need depth on one URL. Regional test locations, connection profiles, filmstrips, and waterfall detail matter when you are debugging routing, third-party weight, or a template that behaves differently in Chrome than in your headless CI job.

That work is diagnosis. Portfolio monitoring is coverage. Confusing the two is how teams end up with excellent reports on five URLs and silence everywhere else.

We keep spot-check tools for deep-dive debugging on one URL. We stop expecting them to carry weekly accountability across every client property. The shift is intentional: GTmetrix or WebPageTest for "why is this page slow right now?" and scheduled monitoring for "did any priority URL drift since we last looked?"

Multi-site PageSpeed monitoring: four questions agencies ask next

These questions show up in different words, but the shape is consistent.

Do we have coverage without multiplying monitored slots?

On slot-based monitors, each URL plus region, device, and connection profile can consume its own slot. A handful of clients, each with a homepage, a lead form, and one campaign path, in two regions, eats a plan quickly. The maths is not mysterious; it is just not how agencies think about retainers. They think in sites and templates, not permutations.

The ask becomes: can we monitor priority paths across many sites without negotiating slot arithmetic every quarter? That is where multi-tenant monitors and discovery (sitemaps, crawls) come up. Manual lists rarely survive busy release weeks without automation behind them.

Who maintains the URL list after every deploy?

In small teams, one senior developer keeps a spreadsheet of "URLs we care about." That works until holidays, handovers, or a rush of microsites. The question is really about ownership: when a new template ships, does monitoring update automatically, or does someone need to remember a paste step?

Agencies that solve this assign monitoring updates to the same rhythm as release notes, not to whoever has five minutes before a client call. Scheduled runs with stored history make that handover easier than a folder of PDFs with mismatched dates in the filename.

Can we report without another manual test run?

Client reporting often reuses the audit pattern: run a test, export, attach, repeat next month. It is credible; it is also labour-heavy at scale. The next question is whether leadership can see trend lines and budget breaches without booking another lab session for every site on the roster.

That does not mean automated reports replace explanation. It means the account team starts from "here is what changed since baseline" instead of "hang on, I will run the test again."

Will anyone notice a regression before the client does?

Bookmarks do not alert. They wait. Teams that outgrow spot checks usually want thresholds on LCP, INP, or CLS (and supporting lab signals where field data is thin) with a route that reaches a human who can open a ticket.

The bar is low and specific: not "AI tells us everything," but "we do not learn about a deploy problem from the client's support inbox." Email alerts, Slack routes, or webhooks are implementation details. The decision is whether performance is operational like uptime, or ceremonial like a quarterly slide.

Free PageSpeed tools vs paid monitoring in a growing portfolio

Free tiers are not the wrong place to start. PageSpeed Insights, Lighthouse in CI, and generous free quotas on lab hosts cover a lot of ground for a single product or an early agency bench.

The friction appears when free tools stay on manual triggers while the portfolio grows. PSI is authoritative for a URL you paste today; it does not tell you which client path regressed on a quiet Tuesday. Lighthouse CI belongs in the merge path; it does not replace field drift on production URLs you did not model in the build.

Our Watcher roundup of free PageSpeed monitoring tools separates what we keep in the free layer (PSI, WebPageTest, CI budgets) from what we expect a paid monitor to carry (schedules, portfolios, alerts, client-ready history). The point is not "pay for everything." It is "name which job each layer owns so free tools do not pretend to be a portfolio system."

How to compare GTmetrix alternatives without a feature matrix audit

Procurement and technical leads both want comparisons. A fifty-row feature spreadsheet is rarely what changes the decision. In our experience, three workflow tests work better:

Add two new URLs that shipped this month. How many manual steps until they are on a recurring check?
Pick one regression you missed last quarter. Would your current setup have alerted someone, or would you have needed a calendar reminder?
Ask who produces the client-facing report today. Count the minutes from "open tool" to "send PDF."

Those tests show which tool fits faster than scoring checkmarks for white-label PDFs or API access. When a team wants a structured GTmetrix vs multi-tenant monitor split, we point them to our GTmetrix vs Apogee Watcher for agencies article on the Watcher blog. It is honest about where lab hosts win and where portfolio workflows win. This post is the earlier stage: recognising you have reached the question.

Layer, do not rip-and-replace. Keep GTmetrix or WebPageTest for deep dives. Add scheduled monitoring and budgets for the URLs that would hurt if they drifted unnoticed. Keep CI gates for bundles and templates you control at build time. You add tools; the decision does not have to become a vendor turf war.

A two-week portfolio exercise before you buy tools

If you are past the "one bookmark per client" stage, try a lightweight portfolio exercise before you buy anything:

List every client with a production URL you would be embarrassed to see red in a stakeholder call.
Mark which of those URLs received a lab test in the last fourteen days.
Note who would get paged if LCP moved from "good" to "poor" on a path not on that list.

The gaps on that page are your requirements document. They usually mention discovery, schedules, and alerts more than waterfall cosmetics.

Pick ten URLs that matter, set budgets, and run scheduled checks for a month. Keep your GTmetrix login for the afternoons when you need waterfall detail. If you want a multi-tenant workflow built for that pattern, start a free trial of Apogee Watcher and map one organisation per client group. The goal is not another dashboard. It is fewer surprises between audits and a reporting trail that does not start with "let me run the test again."

FCP and TBT: Supporting Metrics Beyond Core Web Vitals

Apogee Watcher — Tue, 09 Jun 2026 21:22:13 +0000

Your client opens PageSpeed Insights and asks about two numbers that are not in the Core Web Vitals row: First Contentful Paint (FCP) and Total Blocking Time (TBT). LCP, INP, and CLS are in the contract. FCP and TBT are not ranking signals on their own, yet they appear in every scheduled Lighthouse run and often change before the vitals do.

This guide explains what first contentful paint and total blocking time measure, how they relate to the three Core Web Vitals, and when to track them in performance budgets across a portfolio. For the vitals themselves, start with What Are Core Web Vitals? and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

Are FCP and TBT Core Web Vitals?

No. Google's Core Web Vitals programme includes only three field metrics at the 75th percentile: LCP, INP, and CLS. FCP and TBT appear in Lighthouse and PageSpeed Insights lab output. They help you find causes, but they do not replace CrUX field scores for pass or fail in Search Console.

That distinction matters in client conversations. Sponsors sometimes treat every red Lighthouse metric as a ranking emergency. You can say plainly: vitals come from real Chrome users in the field; FCP and TBT come from lab runs and help explain why a template might fail LCP or INP after the next deploy.

What First Contentful Paint measures

First Contentful Paint records when the browser first paints any text, image, non-white canvas, or SVG from the DOM. It tells you the page has started to render, before the largest element (LCP) finishes.

FCP measures a different moment than LCP. LCP waits for the biggest visible content. FCP records the first visible paint. On a hero-image landing page, FCP might be a headline or skeleton while the image still loads; on a text-heavy article, FCP and LCP are often similar.

Lighthouse and PageSpeed Insights report FCP in milliseconds. Google's lab thresholds match the universal table in our Performance Budget Thresholds Template:

Rating	FCP (lab)
Good	≤ 1,800 ms
Needs improvement	1,800–3,000 ms
Poor	> 3,000 ms

CrUX does not report FCP the same way it reports LCP, INP, and CLS. You see FCP in lab runs, synthetic monitoring, and developer tools. Agencies track it because scheduled tests return FCP on every run, even when CrUX has little or no data for a new URL.

What Total Blocking Time measures

Total Blocking Time sums main-thread blocking time after First Contentful Paint and before Time to Interactive in a Lighthouse run. A "long task" is any main-thread task longer than 50 ms. TBT adds the portion of each long task above 50 ms during that window.

TBT is a lab metric. It estimates how much the main thread is blocked while the page is still loading and becoming interactive. It does not measure a specific user click; it measures blocking during load and early hydration.

Google's TBT documentation treats the metric as related to, but not the same as, Interaction to Next Paint (INP). INP is a field metric for responsiveness across the visit. TBT is main-thread blocking during load in a controlled lab test. Both often worsen when JavaScript blocks the main thread, especially on pages with many tags, but you can pass TBT in lab and still fail INP on post-load interactions (menus, carts, client-side routes). Our third-party scripts guide explains that difference with examples.

Lab thresholds (same source as the budget template):

Rating	TBT (lab)
Good	≤ 200 ms
Needs improvement	200–600 ms
Poor	> 600 ms

How FCP relates to LCP in diagnosis

LCP and FCP share parts of the loading path. Slow server response (TTFB), render-blocking CSS, and font loading can hurt both. They differ when the LCP element is a heavy image or video while something lighter renders first.

Typical patterns we see in agency audits:

FCP poor and LCP poor: slow loading across the page (server, critical CSS, early JavaScript blocking render).
FCP good, LCP poor: first paint is fast but the hero image or largest block is delayed (image weight, lazy-loading mistakes, CDN cache misses). See image optimisation for LCP.
FCP good, LCP good, TBT poor: LCP and FCP pass but the main thread is busy; INP may still fail on interactions after load.

When you report to clients, show FCP and LCP for the same URL and device strategy. "FCP improved 400 ms" is useful context when LCP is still poor because the hero image loads slowly.

How TBT relates to INP in diagnosis

INP replaced First Input Delay in March 2024 as the responsiveness Core Web Vital. Teams use TBT in lab when CrUX INP is missing or when scheduled synthetic runs need a comparable number week to week.

Use TBT when:

you are debugging main-thread JavaScript during load and early hydration;
you want a budget on marketing sites that share one tag manager across dozens of clients;
you are comparing lab runs week to week on the same URL and throttling profile.

Fixing TBT does not guarantee an INP pass. Post-load handlers, single-page transitions, and third-party scripts that run after load can hurt INP without changing TBT much. The INP guide covers that gap in detail.

For ecommerce and app-heavy flows, see e-commerce performance monitoring for how we prioritise INP, TBT, and LCP on checkout templates.

When agencies should track FCP and TBT in monitoring

Track vitals first. Add FCP and TBT when they help you catch regressions earlier or explain why LCP, INP, or CLS changed to non-technical sponsors.

Practical cases:

Content and publishing sites: FCP on article templates shows when a CMS change added render-blocking CSS or a slow web font. LCP on the hero image may change later; FCP often changes first.
Marketing sites with heavy tags: TBT increases when analytics, chat, or A/B scripts grow without review. One tag change can affect every page using the same container.
Multi-site portfolios: the same third-party bundle on twelve clients means one regression can raise TBT on every property. Portfolio monitoring reports that without opening PageSpeed Insights for each site.
Performance budgets in retainers: when clients ask for thresholds beyond LCP, INP, and CLS, FCP and TBT give lab numbers you can enforce on scheduled runs. Copy starter values from the budget thresholds template and mark them provisional for the first month.

In Apogee Watcher, site-level budgets can include FCP and TBT alongside vitals on mobile and desktop strategies. Alerts send when lab results exceed the thresholds you set. That supplements CrUX in test results; it does not replace field INP.

Common causes of poor FCP and TBT

FCP regressions

Slow TTFB or cold cache on HTML.
Render-blocking stylesheets and synchronous scripts in <head>.
Web fonts that delay first text paint (FOIT).
Large inline critical CSS or server-side work before first byte.

TBT regressions

Large JavaScript bundles parsed on the main thread during load.
Long tasks from tag managers loading many vendors at once.
Framework hydration on top of marketing scripts.
Synchronous layout or style work before load completes.

The same fixes often help vitals: reduce JavaScript, defer non-critical scripts, split code, and audit third parties. Poor FCP or TBT often means LCP or INP will slip next if you do not fix the underlying issue before CrUX updates.

Lab vs field: what to tell stakeholders

PageSpeed Insights shows lab Lighthouse data and CrUX field data when Google publishes it for the URL. FCP and TBT appear on the lab side only. LCP, INP, and CLS can appear in both, but only field percentiles count for Core Web Vitals pass rates in tools that use CrUX.

A clear client line: "We track FCP and TBT in scheduled lab tests to catch regressions early. We judge SEO page experience on field LCP, INP, and CLS." That matches Google's page experience documentation without treating lab metrics as ranking signals.

For setup across many sites, use the Core Web Vitals monitoring checklist for agencies and automated PageSpeed monitoring setup.

FAQ

Is First Contentful Paint a Core Web Vital?

No. FCP is a Lighthouse lab metric. It shows when the page first renders and often correlates with LCP, but Google does not include FCP in the Core Web Vitals set used for page experience evaluation.

Is Total Blocking Time the same as INP?

No. TBT is a lab metric for main-thread blocking after FCP during load. INP is a field metric for responsiveness across user interactions during the visit. Improving TBT often helps INP when JavaScript blocks the main thread early, but post-load interactions need separate testing.

What is a good FCP score?

In Lighthouse lab terms, FCP at or below 1,800 ms is "good", using the same bands as our performance budget template. Adjust thresholds per site after you record a baseline.

What is a good TBT score?

Lab TBT at or below 200 ms is "good" on the same scale. Sites with heavy JavaScript may need stricter internal budgets even when the public band says "good."

Should we add FCP and TBT to client reports?

Yes, as supporting metrics under the vitals summary, not as replacements. One line each on what changed and whether it points to loading (FCP) or main-thread JavaScript (TBT) is enough for most quarterly reviews.

Does CrUX show FCP and TBT?

CrUX reports Core Web Vitals and related field metrics. FCP and TBT come from lab and synthetic tests. Use scheduled PageSpeed or Lighthouse runs to track them over time.

Can we set performance budgets on FCP and TBT?

Yes. Many teams set provisional FCP and TBT limits per template alongside LCP, INP, and CLS. Tighten after a month of scheduled runs so alerts stay useful.

FCP and TBT are supporting lab metrics beside LCP, INP, and CLS: early render time and main-thread blocking during load. Add them to budgets when they help you explain score changes and catch regressions before CrUX field data updates.

Start a free Apogee Watcher account to schedule PageSpeed tests with vitals plus FCP and TBT budgets across client sites, or run a free domain check on a URL that scored worse in a recent Lighthouse run.