Forem: Apogee Watcher

The Real Cost of Poor Web Performance: A Data-Driven Analysis

Apogee Watcher — Tue, 14 Apr 2026 19:27:50 +0000

“Performance is a nice-to-have” dies the moment you put a number next to latency. Poor web performance is not an abstract UX problem; it is a measurable drag on acquisition, conversion, and support load. This article is for anyone who needs the business case before picking metrics: agency leads, marketers pitching retainers, and engineers asking for sprint time.

It is not a vertical-specific monitoring playbook. If you run e-commerce and want PLP/PDP/checkout priorities, third-party tax, and page-type tables, read Performance monitoring for e-commerce: what metrics matter most first; it goes deeper on retail than we will here. Below we keep the cross-industry story: what “cost” means, what published studies establish about delay and money, and how to connect Core Web Vitals to budgets and monitoring without repeating that guide.

It also complements Core Web Vitals, how CWV relate to SEO, and automated PageSpeed monitoring. The focus here is justification and trade-offs, not a metric-by-metric tutorial.

Why “cost” is more than lost sales

When people talk about the cost of poor performance, they often mean one of three things:

Direct revenue: fewer conversions, smaller basket or contract size, or abandoned payment because the experience feels broken at the moment of commitment.
Funnel leakage: higher bounce and lower progression between steps (landing → offer → signup or checkout, depending on your model).
Indirect cost: more support tickets, lower ad efficiency (paying for clicks that never become productive sessions), and slower experimentation because every release feels risky.

All three show up in data once you stop treating “site speed” as a single score and start mapping speed to URLs that matter for your business model.

What published research says (and what to read elsewhere)

Retail and large-brand mobile studies (summary)

Two sources show up in almost every business-case deck. Google’s Milliseconds make millions work with Deloitte (summarised on web.dev) tracked tens of millions of mobile sessions across dozens of brands: small improvements in speed-related signals correlated with measurable funnel and spend changes, including roughly +9% progression to add-to-basket and higher spend in retail conditions. Yottaa’s 2025 Web Performance Index reports on the order of 3% higher mobile conversions per second saved across large e-commerce samples, plus a heavy third-party share of total load time.

Those numbers are real; they are also retail-heavy. For the full breakdown (funnel steps, PDP versus PLP, third-party sequencing, and what to monitor first in a shop), use our dedicated piece: Performance monitoring for e-commerce: what metrics matter most. Here we treat them as proof that latency shows up in P&L, not as instructions for your category.

Engagement and bounce (all verticals)

Google’s think with Google materials, including work with SOASTA (now Akamai), tie faster mobile experience to lower bounce; industry summaries often cite bounce probability rising by about a third when load stretches from about one second to three. Use that as directional context for any site where traffic is paid or organic and the first screen must earn the next click.

Takeaway: the cost of poor performance often shows up first in session quality, before you attach a revenue model.

Forms, checkout, and trust

The 2013 StrangeLoop / Radware study is dated, but it made the pattern visible: multi-second delays at checkout correlated with sharp abandonment in the tested setup. The mechanism still applies: long tasks at payment or account creation destroy trust. Same for long lead forms and identity steps in B2B: if INP is poor, you lose completions before you can argue about SEO.

Lead gen, SaaS, and services: your data is the headline

Published studies skew toward retail because the samples are large and the money is easy to storyboard. If you sell trials, demos, or high-ticket services, your first-party funnel (visit → signup → activation, or visit → meeting booked) is where you prove cost. Segment by landing page and time-to-interactive or CWV buckets; the shape of the curve (worse speed, worse conversion) is what matters for the CFO, not a generic blog statistic. Use industry studies to show that the pattern is normal, then use your own exports to show that it is your problem size.

Core Web Vitals as a shared language for “cost”

Google’s Core Web Vitals (LCP for loading, INP for interaction latency, CLS for visual stability) give teams a vocabulary that connects lab tests to user-perceived quality. They are not a complete picture of business outcome (nothing replaces your own analytics), but they align engineering work with behaviours that correlate with frustration and abandonment.

Where you have Chrome UX Report (CrUX) data for a URL or origin, you can quote percentiles (for example, “75th percentile LCP was 2.8s last month”). Finance and product leads can track that month to month. Lab tests from PageSpeed Insights or your monitoring tool then answer why a regression happened (which script, which image, which long task) and whether a fix worked before you roll it out widely.

High LCP on templates that earn the next step (home, pricing, category or listing, key landers) hurts discovery and consideration; see our image optimisation guide.
Poor INP on interactive flows (search, filters, configurators, carts, address and payment fields) feels broken even when headline load time looks acceptable; see Understanding INP.
CLS spikes drive mis-taps and form errors, which inflate support tickets and quietly erode conversion on mobile.

When you report internally, translate metrics into pages and journeys (“pricing mobile LCP,” “signup flow INP”), not only sitewide scores. Retail readers can map those labels to PLP/PDP/checkout using the e-commerce article linked above.

If CrUX is not available for a URL yet, synthetic schedules still matter: they create a repeatable baseline you can compare after every release. The business question is not “what is our score?” but “did we move money-critical pages in the wrong direction this week?”

Hidden costs: ads, SEO, and operations

Paid media efficiency

Slow landing pages waste acquisition spend: you pay for the click, then lose the session before the value proposition renders. Teams often discover this only after segmenting conversion rate by landing page or by page speed band, not by campaign name alone. That segment is the bridge between Google Ads cost and engineering priority: without it, marketing blames creative while engineering never sees the URL list.

Organic search and AI-mediated discovery

Organic traffic is under pressure from AI Overviews and zero-click SERPs; publishers have reported large year-on-year traffic declines in aggregate studies. Performance is not the only lever (content quality and brand matter), but fast, crawlable pages remain the foundation for both classic rankings and AI retrieval. Our article on AI Overviews and click-through covers the search side; performance is part of resilience.

Engineering and opportunity cost

Every manual “can someone run Lighthouse?” thread is time not spent shipping. Teams without continuous monitoring often oscillate between firefighting after complaints and over-optimising vanity pages. The cost is velocity: fewer safe releases, slower experiments, and harder prioritisation.

Agencies: proof beats opinion in renewals

Retainers live or die on evidence. When you can show a client that LCP on the primary conversion path (checkout for retail, signup or booking for others) stayed inside an agreed band across releases, and flag the one deploy that pushed it out, you are no longer debating taste; you are showing operational control. The same evidence supports upsells: additional URLs, higher test frequency, or stricter budgets once stakeholders trust the baseline. Without trend data, “we should invest in performance” becomes a calendar debate every quarter.

Turning data into a monitoring posture

You do not need perfect attribution to act. A practical sequence:

Inventory revenue-critical URLs for your model: key landers, pricing, signup or checkout, authenticated app shells, not only the homepage.
Set budgets aligned with your risk tolerance; start from our performance budget thresholds template and adjust per client or brand.
Monitor on a schedule with lab data and watch for regressions after deploys; pair with field data where you have CrUX or RUM.
Alert on sustained breaches, not every noisy blip. Policy guidance in Slack alert policy template translates well to email-first teams too.

If you are an agency, the same evidence supports retainers: you are not selling “a score”; you are selling reduced revenue leakage and predictable releases, a story procurement understands when backed by numbers and trends.

FAQ

What is the single best statistic to quote to a CFO?

There is no universal number. Use your funnel: conversion rate by landing page, support ticket volume correlated with releases, or revenue per session by page group. Published studies back direction; for retail-specific figures and page-type context, see Performance monitoring for e-commerce: what metrics matter most. They are not a substitute for internal analytics.

Are Core Web Vitals a ranking guarantee?

No. Google uses page experience signals among many factors; improving CWV does not guarantee a position bump. The business case for speed is often conversion and retention, with SEO as a supporting benefit. See How Core Web Vitals impact SEO rankings for nuance.

How does automated monitoring reduce cost?

It reduces surprise: you catch regressions when they are small (one deploy, one template) instead of after a week of paid traffic pointed at a slow landing page. Automated PageSpeed monitoring for multiple sites walks through the setup for portfolios.

Where should we start if we have one week?

Fix LCP on your top three money URLs, INP on the flows where users commit (search, filters, forms, cart), and CLS on pages with ads or late-loading embeds. Measure before and after; that is your internal case study for the next budget round.

Poor web performance has a real cost: measurable in the funnel, visible in operational load, and containable with disciplined monitoring. The studies above are not magic formulas; they are a reminder that small delays compound across sessions and campaigns. If you want to operationalise the same signals across many client sites, Apogee Watcher is built for multi-tenant PageSpeed monitoring, budgets, and alerts. Create a free account to start tracking without wiring your own PageSpeed API keys.

How to Set Up Performance Budgets in CI/CD Pipelines

Apogee Watcher — Sun, 12 Apr 2026 21:51:48 +0000

A performance budget in production is a line you refuse to cross. In CI it is the same line, enforced before a merge or deploy lands. Done well, the pipeline fails fast when a change regresses Core Web Vitals proxies, bundle weight, or your own custom thresholds, so you fix it in the branch instead of shipping first.

This guide assumes you already know why budgets matter. For the full conceptual frame and metric tables, read The Complete Guide to Performance Budgets for Web Teams. Here we focus on wiring budgets into CI/CD: tools, config shapes, and operational pitfalls.

What “performance budget in CI” usually means

In pipelines, teams typically enforce lab metrics (Lighthouse scores and timings such as LCP, CLS, INP where available, TBT, and so on) against numeric ceilings or floors; resource budgets (caps on JS, CSS, image bytes, request counts, or third-party weight); or custom checks (synthetic steps that call your own scripts or APIs after a build).

Lighthouse CI is the common open path for lab metrics because it runs Lighthouse in a controlled environment, stores results, and supports assertions against budgets. Pair it with bundle analysers or size limits when regressions come from dependency drift rather than layout alone.

CI budgets are not a substitute for field data or scheduled monitoring across many URLs. They gate the build you are about to ship. Products such as Apogee Watcher focus on ongoing lab schedules, portfolios, and alerts; see How to Set Up Automated PageSpeed Monitoring for Multiple Sites for that workflow.

Before you write YAML: pick URLs and environments

CI runs should be deterministic enough to trust. Preview URLs from Netlify, Vercel, Cloudflare Pages, or internal preview hosts work if the pipeline waits until the deploy is reachable. Local static servers (serve, http-server) suit static sites; SPAs often need the production build and a correct BASE_URL. Auth walls break Lighthouse unless you script login or use a dedicated test route.

Document which URLs represent home, a heavy template, and checkout or app shell if those differ. One URL with a loose budget hides regressions on another; at minimum, list primary templates in lighthouserc or equivalent.

Path 1: Lighthouse CI (LHCI)

Install

Add Lighthouse CI to the repo (dev dependency is typical):

npm install --save-dev @lhci/cli

Minimal `lighthouserc` (assertions + collect)

LHCI reads configuration from lighthouserc.js or lighthouserc.json. Example JSON shape:

{
  "ci": {
    "collect": {
      "url": [
        "https://your-preview.example.com/",
        "https://your-preview.example.com/pricing"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Notes:

numberOfRuns: multiple runs reduce noise; three is a common starting point.
Assertion keys map to Lighthouse audit IDs; align numeric budgets with your performance budget template and team policy.
upload.target: temporary-public-storage is fine for getting started; teams often move to LHCI server or skip upload in pure gate mode.

Wire the CI job

Invoke LHCI after the app is built and the target URL responds. Typical flow:

Install dependencies.
Build the site (if needed).
Deploy to preview or start a static server in the background.
Wait until the test URLs return HTTP 200.
Run lhci autorun (or lhci collect then lhci assert).

If you use GitHub Actions, a dedicated job with timeout-minutes and a health-check step avoids flaky “site not ready” failures. A minimal pattern is to probe the preview URL before lhci autorun, for example with curl -fsS --retry 5 --retry-delay 5 --retry-connrefused "$PREVIEW_URL". --retry-connrefused matters because a deploy that is not listening yet often returns “connection refused”, which plain curl retries do not treat as transient by default. Store the same base URL in a CI variable and pass it into lighthouserc or environment overrides your setup supports, so you do not duplicate hostnames in three places.

Resource limits: `budgetsFile` vs assertions

Lighthouse CI can assert against a budget.json-style file via assert.budgetsFile (path relative to the working directory). In the upstream configuration model, that budgetsFile mode is an alternative to filling assert.assertions with audit IDs; it is not mixed with other assert options in the same way. Check the Lighthouse CI configuration reference for the exact rules your CLI version supports.

If you want lab metrics (LCP, CLS, and so on) and transfer or request budgets in one assertions block, use Lighthouse CI’s resource-summary assertions (for example resource-summary:script:size, resource-summary:third-party:count) alongside the audit keys. Sizes there use bytes in assertion options; the standalone budget.json format often documents kilobytes, so keep units straight when you copy numbers between files.

Whether you use a checked-in budget file or assertion rows, treat the file like any other policy: generate from your design system pipeline or review diffs in PRs so “max JS kilobytes” does not drift silently.

Path 2: GitHub Actions sketch

Below is a pattern, not a drop-in for every stack: replace build commands, Node version, and URL discovery with your own.

name: Lighthouse CI
on:
  pull_request:
    branches: [main, develop]

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      # Example: wait for preview deploy via your provider’s CLI or API, then:
      - run: npx @lhci/cli autorun
        # Optional: set LHCI_GITHUB_APP_TOKEN if you use the Lighthouse CI GitHub App
        # so upload can post PR status checks. Not required for a local pass/fail gate.
        # env:
        #   LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Many teams split build and LHCI across workflows so preview deploy completes first; use workflow_run or provider webhooks if needed. The critical invariant is that Lighthouse runs against the same artifact users will get, not a half-built tree.

On GitLab CI, CircleCI, or Buildkite the same steps apply: install Node, build, wait for URLs, then run npx @lhci/cli autorun (or your package script). Cache node_modules between runs when your runner allows it; cold installs dominate wall time on small changes.

Resource budgets alongside Lighthouse

Lab metrics can pass while JavaScript weight creeps up on every sprint. Add at least one of: bundle size limits (bundlesize, size-limit, or webpack’s performance hints), or dependency reviews in the PR template so someone notices a multi-megabyte new dependency.

Treat resource budgets as complementary to LCP and CLS gates. A slow-LCP fix might add twenty kilobytes and still help users; a green Lighthouse run with a nine-hundred-kilobyte main bundle remains fragile.

Flakiness and false positives

CI environments are colder than a developer laptop. Variance in LCP and CLS is normal: mitigate with multiple runs, pinned Chrome, and stable network throttling settings in LHCI. Third-party ads or A/B scripts can differ run to run; block known domains in a test profile or point at a clean route. A cold CDN edge on the first request after deploy can skew timings; an optional warmup GET before LHCI helps.

If the main branch is red every other day, teams stop trusting the job. Prefer warnings on noisy metrics and errors on stable ones until baselines settle.

How this pairs with product-side budgets and alerts

CI answers whether this change broke your thresholds on the URLs you chose. Scheduled monitoring answers whether you are still inside budget next week across the pages you track in production.

If you already use performance budgets and email alerts in Apogee Watcher, treat CI as the pre-merge gate and Watcher as the continuous check on real site inventories. Same vocabulary, different phase of the lifecycle.

Apogee Watcher and CI: agency API (in active development)

You do not need a vendor API to get value from Watcher next to LHCI. Many teams keep Lighthouse CI (or Lighthouse CLI) in the pipeline for fast feedback on the preview URL, and keep budgets, schedules, and digests in Apogee Watcher so production-facing URLs and client reporting stay in one product. Align the numbers: copy thresholds from your performance budget template into both LHCI assertions and Watcher site budgets so “green in CI” and “green in monitoring” mean the same thing.

Apogee Watcher is building a plan-gated customer HTTP API (under /api/v1) aimed at agency workflows. It is in active development: behaviour, routes, and reference documentation will firm up as releases land. Eligible plans will expose the capabilities below; exact rollout timing will follow release notes.

For agency users, the API will be supporting:

Check test results: read latest (and historical) PageSpeed outcomes for monitored pages without opening the dashboard.
Trigger a new test: request a fresh run after a deploy so CI or a script can wait on Watcher instead of calling the Google PageSpeed API key from your own workers.
Retrieve aggregated reports: pull summary or roll-up reporting suitable for client packs or internal gates.
Retrieve historical trends: chart-friendly series so pipelines or internal tools can compare this build against last week, not only the last run.

Why that matters next to LHCI: once those endpoints are live, a pipeline will be able to trigger a test, poll until results land, then fail if metrics breach the same budgets you set in the app. Quota and retries will stay on Watcher’s side, and the failing run will remain tied to stored results and trends for client conversations, not only a line in your CI log.

Until the public reference and stable endpoints are published, keep using LHCI for branch gates and the Watcher UI for schedules and alerts. Follow the Product & Brand category on the blog for product news and API-related updates, and check plan details for API access when you are ready to wire automation. If you are interested in early beta tester access to the agency API, contact us.

Checklist: ship a credible CI budget

[ ] Listed representative URLs (not only /).
[ ] Chose numeric thresholds aligned with your complete guide or client contract.
[ ] Set numberOfRuns ≥ 2 for stability.
[ ] Documented preview URL or static server startup in the workflow.
[ ] Added at least one resource or bundle guard for JS/CSS creep.
[ ] Separated error vs warn assertions to reduce alert fatigue.

FAQ

Is Lighthouse CI the only option?

No. Some teams wrap plain Lighthouse CLI, use Playwright traces, or rely on vendor-specific speed tools in CI. LHCI is widely documented and gives assertions + history-friendly uploads out of the box.

Should performance CI block every PR?

Often yes for main, with optional paths for docs-only changes. Use path filters so markdown edits do not run full LHCI unless you want them to.

Can I enforce budgets without a preview deploy?

Yes for static sites: build, serve locally in CI, and point LHCI at localhost. Dynamic server-rendered apps may need a test server with seed data.

Does this replace RUM or Search Console field data?

No. Lab CI validates the candidate build; field metrics validate real users. Both belong in a mature performance program.

What if our budgets are stricter than Lighthouse in CI can reliably hit?

Loosen CI thresholds slightly below production targets, or scope strict checks to stable audits (CLS, bundle size) and use warnings for high-variance metrics until your environment is stable.

Can I trigger Apogee Watcher tests from CI with an API?

That workflow is in active development. The customer API will support checking test results, triggering new tests, retrieving aggregated reports, and retrieving historical trends from automation for agency users on eligible plans (subject to published docs and plan limits). It is not a stable, copy-paste integration yet. For today’s deploy gates, use LHCI or Lighthouse in CI; keep Watcher for scheduled runs, budgets, and alerts. When the reference documentation and endpoints are public, they will be the supported way to align CI with dashboard budgets without putting a PageSpeed API key in your pipeline.

Performance Budgets and Email Alerts in Apogee Watcher

Apogee Watcher — Thu, 09 Apr 2026 22:05:16 +0000

A performance budget on paper is only a policy. In production it needs two things: thresholds your tests actually enforce, and notifications people will read without muting the sender. This product spotlight walks through how Apogee Watcher connects performance budgets to email alerts so regressions show up in your inbox as structured digests tied to each scheduled run.

If you are new to the vocabulary, our Core Web Vitals monitoring checklist for agencies covers the operational habits around budgets; here we focus on what the product does with those numbers after each PageSpeed Insights-backed test completes.

Why budgets and alerts belong together

Teams adopt budgets for different reasons. Some need a line in the sand before a release train ships. Others need evidence for a client retainer (“we agreed LCP stays inside this band”). Without automated checks, those thresholds become a PDF you filed once. With scheduled lab tests, the same thresholds can answer a simpler question: did this week’s deploy move any URL outside the band we care about?

Alerts are the other half. If every breach generated a separate message per URL and per metric, a single bad deploy on a large site would bury your team in mail before anyone opened a dashboard. Apogee Watcher sends one digest email per site per budget-check run when the alert channel is email. The digest lists up to ten pages with the worst scores first, plus totals for how many pages breached budgets and how violations break down by metric. That design follows the same instinct as a good incident summary: enough detail to triage, not enough to replace your issue tracker.

What “a budget” means inside Watcher

Budgets in Apogee Watcher are site-level and strategy-specific. For each monitored site you configure separate rows for mobile and desktop lab strategies. That matters because retail and content sites often diverge sharply by breakpoint: a template can pass mobile LCP while desktop TBT balloons after a script change.

Each active budget stores thresholds the product compares against stored lab results from scheduled runs. You can set caps and floors across the metrics PageSpeed Insights exposes in our results model, including the following:

Performance score (minimum acceptable Lighthouse-style score)
Largest Contentful Paint (LCP) as a time budget
Interaction to Next Paint (INP) where the API supplies it
Cumulative Layout Shift (CLS)
First Contentful Paint (FCP)
Total Blocking Time (TBT)
Speed Index

Not every team enables every field. A content marketing site might care most about LCP and CLS; an app-heavy property might weight INP and TBT more heavily. The performance budget thresholds template post includes starter numbers you can copy before you tune per client.

When you add a site, the product creates default budget rows for both strategies so you are not starting from an empty configuration. You still choose which numbers reflect your contract or internal standard, and you can deactivate a strategy’s budget if you only monitor one form factor for a given property.

From a scheduled test to an alert row

The loop is intentionally boring, which is what you want from monitoring infrastructure:

Scheduled tests run on the cadence allowed by your plan (hourly, daily, weekly, and so on). Each run produces fresh lab metrics per page and strategy.
Budget evaluation compares those metrics to the active budget for the same site and strategy. When a value is worse than the threshold (for example LCP above your maximum seconds, or performance score below your minimum), the system records an alert with the metric name, the threshold you set, and the value observed.
Resolution happens automatically when a later test shows the metric back inside the budget. Resolved alerts stop contributing to “open” noise; you keep history for auditing without treating old breaches as current fires.

That pipeline sits on top of the same automated PageSpeed monitoring setup this blog has covered before: organisations, sites, pages, and scheduled tests. Budgets do not replace discovery or URL hygiene; they judge the URLs you already chose to measure.

Email digests: what actually arrives

When new violations exist after a run and your budget’s alert channel is set to email, Apogee Watcher sends the budget-violation digest to each active organisation admin. The mail is scoped per site, not per page. Inside one digest you will typically see:

Summary counts for how many pages had violations and how many individual metric breaches occurred, plus a breakdown by metric type so you can tell whether the deploy mainly hurt LCP or spread pain across several signals.
Detailed rows for up to ten pages, prioritised so the weakest performance scores surface first, then by URL when scores tie. If more than ten pages failed, the email tells you that you are viewing the first ten of a larger set, while the totals still reflect the full picture.

Digest timing aligns with your scheduled test frequency for that site. The footer of the email states that it was generated from the automated schedule, which keeps expectations aligned: this is not a real-time push from your CDN; it is the post-run account of what the lab saw after the last completed sweep.

Recipients are organisation admins because alert routing is tied to account responsibility. If you need a wider broadcast inside a client team, forward the digest or pull the same numbers into your stand-up doc. For Slack-first teams, the product’s data model reserves other alert channels for when those integrations ship end to end; today’s reliable path for delivery is email.

Cooldowns and why they exist

A page that fails a budget on Monday will often fail again on Tuesday until someone ships a fix. Without guardrails you would receive a fresh digest with the same headline every day. Apogee Watcher applies cooldown logic keyed to page, strategy, and time since the last alert for that combination. The goal is simple: signal when something newly breaks or re-breaks, not to ping you on every run while the underlying issue is unchanged.

Cooldowns interact with your schedule. A site on a daily cadence still gets timely reminders; a weekly site batches more change into each run. If you tighten budgets after a major refactor, expect a burst of legitimate new violations while the system learns what “normal” looks like under the new line. That is working as intended.

How this fits next to policy and people

Budgets answer what crossed a line. People still answer who fixes it and how it gets prioritised. Many teams pair Watcher with a lightweight policy doc so on-call knows which breaches page the SEO lead versus the platform team. Our Slack alert policy template for web performance teams is written for Slack-shaped workflows, but the same sections (ownership, severity, quiet hours) translate directly to email-first teams: paste the digest link into the ticket, attach the URL list, and move on.

If you sell performance work to clients, budgets also give you a defensible story: you are not arguing from a one-off Lighthouse screenshot taken on someone’s laptop; you are pointing to thresholds you agreed in writing and time-stamped breaches after scheduled runs. That pairs naturally with the prospecting angle in From monitoring to pipeline, even though this spotlight stays on product mechanics rather than sales motion.

Getting started in a few concrete steps

Add or select a site and confirm your page list covers the templates you care about. Use automatic page discovery if the inventory has drifted.
Open budgets for that site and set mobile and desktop thresholds to match your standard or the client contract. Start from the template post if you do not want to guess at seconds and milliseconds.
Choose email as the alert channel on each active budget row your plan allows, and verify admin membership on the organisation so the right inboxes receive digests.
Let at least one scheduled run complete after deploy. If nothing breaches, you will not get mail, which is also useful signal.

When you are ready to stress-test the workflow, temporarily lower a threshold on a staging URL you control, run a test, and confirm the digest lists the expected metric. Roll the threshold back once you have validated routing.

Create a free account to configure budgets, scheduled PageSpeed tests, and email digests without wiring the PageSpeed Insights API yourself.

FAQ

Do I need separate budgets for mobile and desktop?

You should set both if you care about both experiences. Lab scores often diverge because assets, layout, and third-party behaviour differ by viewport. Empty or inactive strategies simply skip evaluation for that form factor.

Will I get one email per failing page?

No. Email notifications are digests: one message per site per run (for the email channel), with detailed rows for up to ten pages and summary totals for the full set of violations.

Who receives the digest?

Active organisation admins on the account. Viewer or manager roles do not automatically receive budget mail; adjust membership if someone else should be in that admin list.

What if I only want alerts on production, not staging?

Keep staging on its own site record with stricter or looser budgets, or pause budgets on environments you do not want to page yourself about. The product evaluates whatever URLs you attach to that site.

Does Apogee Watcher replace my status page or incident tool?

No. It tells you that lab metrics crossed thresholds you set after scheduled PageSpeed runs. You still route that signal through your normal engineering and client communication channels.

Are Slack notifications available?

Additional channels are part of the roadmap. Today, rely on email digests for delivery; check current plan details in the app for which channels your tier exposes.

Performance Monitoring for E-Commerce: What Metrics Matter Most

Apogee Watcher — Tue, 07 Apr 2026 17:15:07 +0000

E-commerce is not “a website that happens to sell things.” It is a sequence of pages: listing, product detail, cart, and checkout, each with different assets, scripts, and failure modes. Performance monitoring for stores only works when you align metrics with those steps and with how shoppers actually behave: mostly on mobile, often on middling networks, and rarely patient.

This article separates signal from noise: which numbers deserve dashboards and alerts for retail, what published studies say about speed and revenue, and how synthetic monitoring plus field data (where available) fit together. It complements our guides on Core Web Vitals, LCP, INP, and CLS, and mobile versus desktop monitoring, applied to the shop context.

Why e-commerce needs its own metric priorities

Three forces push retail sites toward a specific monitoring profile:

Funnel depth: A slow PLP (product listing page) costs discovery; a slow PDP (product detail page) costs consideration; a slow checkout costs payment. The same “good” global average can hide a catastrophic last step.
Third-party weight: Tags for analytics, personalisation, reviews, chat, and A/B tests stack on top of your own assets. Industry analyses repeatedly show third parties consuming a large share of total load time on retail properties (see below). Monitoring lab metrics without watching what third parties add is incomplete.
Mobile share: Large-scale retail benchmarks continue to show mobile traffic in the 70%+ range for many brands. Yottaa’s 2025 analysis of over 500 million visits across 1,300+ e-commerce sites notes that more than 70% of traffic came from mobile devices, and ties one-second load-time improvements to measurable conversion gains (Yottaa press release, Jan 2025).

Your monitoring plan should reflect all three: page-type coverage, third-party awareness, and mobile-first thresholds.

What the research says: small delays, large business effects

Google and Deloitte: sub-second gains move the funnel

Google commissioned research by 55 and Deloitte, published as Milliseconds make millions. Google’s summary on web.dev explains the setup: 37 brand sites, 30+ million user sessions, mobile load times tracked over 30 days at the end of 2019, with no UX redesigns during the study.

The study looked at a 0.1 second improvement across four speed-related dimensions (including metrics in the FMP / latency / page load / TTFB family; note FMP is deprecated today; LCP is the modern loading metric). For retail specifically, the reported effects included:

+9.1% progression from product detail page to add-to-basket
+3.2% progression from product listing page to product detail page
+9.2% higher spend among retail consumers in the measured conditions

Those are progression and spend effects from very small speed improvements, which is why retail teams treat performance as a P&L topic, not only a Lighthouse score.

Yottaa 2025: seconds, bounce, and third-party tax

Yottaa’s 2025 Web Performance Index (analysis of 500+ million visits, 1,300+ sites) reports:

3% increase in mobile conversions for each one second of page load time saved
Third-party applications accounting for 44% of total page load time on average
63% of shoppers abandoning pages that take more than four seconds to load
Underperforming third-party apps associated with a conversion deficit of more than 1% in aggregate; each poorly optimised app linked to roughly 0.29% conversion reduction on average
Product detail pages: optimising load (Yottaa’s “application sequencing” context) reduced PDP load by 1.9 seconds on average, with 8% lower bounce

Use these figures as order-of-magnitude context when you prioritise fixes: third-party review, image pipeline, and checkout responsiveness often beat chasing marginal gains on static marketing pages.

Core Web Vitals: what to watch in a shop

Google’s Core Web Vitals remain the standard user-centric set for field and lab measurement: LCP (loading), INP (interaction latency), CLS (visual stability). For e-commerce, the usual mapping is:

LCP (Largest Contentful Paint)

When the main content finishes loading (often a hero image or product image on a PDP).

Listing and product pages are image-heavy. Slow LCP reads as “the product is not there yet,” especially on mobile. The Deloitte study’s retail funnel steps (PLP → PDP → add to basket) are exactly where large elements dominate.

Track LCP separately for PLP, PDP, and home; aggregate sitewide LCP can miss the PDP regressions that hurt add-to-basket. Our image optimisation guide ties directly to LCP work on commerce templates.

INP (Interaction to Next Paint)

Responsiveness after taps and clicks: search filters, variant selection, “add to cart,” address fields.

Checkout and cart are interaction-dense. Long tasks from third-party scripts or unoptimised JavaScript show up here before they show up in a simple “load time” number. INP replaced FID as the responsiveness Core Web Vital because it better reflects real pages with many interactions.

Pay special attention to INP on cart and checkout URLs and after third-party load. A PDP can look fine on a cold load and still feel sticky when the shopper engages.

CLS (Cumulative Layout Shift)

Unexpected layout movement: banners, embeds, late-loading fonts, dynamically inserted recommendations.

Mis-taps on “add to cart,” accidental navigation, and distrust at checkout have direct revenue implications. Media-heavy PLPs and personalised modules are frequent CLS sources.

Compare CLS on long PLPs and infinite scroll implementations; these patterns often fail intermittently when new rows load.

Supporting lab metrics (still useful)

Lighthouse and PageSpeed-style runs still expose Total Blocking Time (TBT), First Contentful Paint (FCP), and Time to First Byte (TTFB). They are not Core Web Vitals, but they help diagnose:

TTFB / server: slow origin or edge before the browser can do useful work
TBT: main-thread congestion that often predicts INP pain
FCP: early paint when LCP is blocked by one huge asset

For a full metric glossary, see LCP, INP, CLS explained.

Page-type playbook: what to optimise first

Page type	Primary risks	Metrics to emphasise
Home / campaigns	Heavy heroes, marketing tags	LCP, CLS, third-party share
PLP / category	Many thumbnails, filters, sort	LCP, INP (filters), CLS as rows load
PDP	Large gallery, variants, reviews widgets	LCP, INP, CLS; watch third-party reviews
Cart	Coupons, cross-sell, persistence	INP, CLS
Checkout	Forms, payment scripts, validation	INP, CLS; TTFB for API-backed steps

If you only instrument one custom segment for alerts, make it PDP + checkout on mobile; that is where the Deloitte study’s add-to-basket and Yottaa’s bounce figures bite hardest.

Synthetic monitoring, CrUX, and RUM: how they fit

Synthetic (scheduled lab tests): repeatable, comparable across releases and competitors; good for regressions and budgets. Apogee Watcher is built for scheduled PageSpeed / Lighthouse-style runs and performance budgets across many URLs and sites, useful when you manage multiple storefronts or markets. See how to set up automated PageSpeed monitoring.
CrUX (Chrome User Experience Report): real-user field data from Chrome users where Google publishes it for a URL or origin. It appears in PageSpeed Insights results when coverage exists. It answers “what are real shoppers seeing?” but not “why,” and it lags deployment.
Full RUM: first-party instrumentation on the site; strongest for business correlation (sessions, revenue segments) but requires implementation and privacy review.

For most e-commerce teams, synthetic + CrUX is the practical minimum for ongoing monitoring; RUM deepens analysis when you need segment-level proof for roadmap fights.

Third parties: measure the tax explicitly

Because third parties can account for a large fraction of load time on commerce pages (Yottaa: 44% on average in their 2025 index), your monitoring workflow should include:

Inventory: tag map per template (PLP, PDP, checkout).
Before/after: lab runs when enabling a new vendor.
Per-page budgets: not one global score; PDP budgets differ from static content. Our performance budget guide and thresholds template help formalise that.

Practical checklist: what “good” e-commerce monitoring includes

Mobile and desktop runs for the same key URLs (commerce diverges sharply by breakpoint; see mobile vs desktop Core Web Vitals).
Core Web Vitals per critical template, not only sitewide.
Alerts on regressions (budget breaches), not on every lab noise fluctuation. Pair thresholds with cooldowns so ops teams trust the signal.
Checkout and cart in the test list even when marketing focuses on campaign landers.
Third-party changes gated with a performance review; data supports that their cost is measurable in conversion (Yottaa 2025).
Regular comparison against your own previous period; retail is seasonal, and week-on-week beats arbitrary industry averages.

Agencies scaling this across clients can align the same structure with our Core Web Vitals monitoring checklist for agencies.

FAQ

What is e-commerce performance monitoring?

It is the practice of measuring web speed and stability metrics (especially Core Web Vitals, server timing, and third-party impact) across the shopping funnel, with enough granularity (page type, device) to act before revenue is affected.

Which metrics matter most for online stores?

LCP for listing and product pages, INP for cart and checkout interactions, CLS wherever layout shifts cause mis-taps or distrust. Supporting signals: TTFB, TBT, and third-party share of load time.

Does improving page speed increase e-commerce conversion?

Published studies link small speed gains to measurable funnel and revenue effects. The Deloitte / Google research summarised on web.dev shows strong retail effects from 0.1 s improvements across measured dimensions; Yottaa’s 2025 index ties one second saved to 3% higher mobile conversions in their sample (press release). Exact uplift depends on your baseline and traffic.

How often should we run performance tests on a store?

Often enough to catch deploys and vendor changes: typically daily or weekly synthetic runs on representative URLs, plus continuous field data where available. Seasonal events (sales, Black Friday) merit tighter cadence and explicit PDP/checkout coverage.

Should we monitor Shopify or WooCommerce differently?

The metrics are the same; the implementation differs (themes, apps, plugins). Third-party app load is a common differentiator: budget per template and track INP on interactive components.

Retail performance is not one number: it is funnel discipline backed by user-centric metrics and honest accounting for third parties. Start from PLP → PDP → checkout, prioritise mobile, and wire budgets and alerts to the pages that actually carry revenue. If you are responsible for many storefronts or markets, automated, scheduled monitoring with clear thresholds scales further than ad-hoc Lighthouse runs alone. Set up automated PageSpeed monitoring when you are ready to operationalise it.

Sources and further reading

Google / Deloitte: Milliseconds make millions (case study) and full Deloitte report
Yottaa: 2025 Web Performance Index press release (methodology: 500M+ visits, 1,300+ sites)
Google: Core Web Vitals overview

Apogee Watcher vs PostHog Web Vitals: Synthetic PageSpeed Monitoring and Product Analytics Compared

Apogee Watcher — Sun, 05 Apr 2026 10:57:44 +0000

Core Web Vitals show up in two different places. One is real users: metrics from the browser, fed by an analytics SDK. The other is scheduled tests: Google’s PageSpeed machinery runs on a URL you choose, on a cadence you set.

PostHog is the first kind for performance. Its Web Vitals live under Web Analytics and use the same posthog-js SDK as the rest of product analytics. Apogee Watcher is the second kind: multi-tenant PageSpeed monitoring on the PageSpeed Insights API—Lighthouse lab data plus CrUX where Google publishes it—for teams covering many sites without putting a script on every domain.

PostHog is a strong product stack (flags, replay, experiments, warehouse analytics). We are not building that. PostHog’s Web Vitals module also does not replace synthetic monitoring for sites you never instrument, and it does not include Watcher’s automated discovery, performance budgets, or agency RBAC by default. The decision is which problem you are solving first—and whether you need both.

What PostHog Web Vitals actually is

PostHog’s docs describe Web Vitals autocapture for FCP, LCP, INP, and CLS via Google’s web-vitals library. You turn on Web vitals autocapture in project settings (separate from generic autocapture) and run posthog-js v1.141.2 or newer. Events are named $web_vitals, with properties such as $web_vitals_LCP_value per metric.

The UI is built for analysts: Web Analytics → Web Vitals gives trends, the same filters as the rest of Web Analytics, and a URL table in good / needs improvement / poor buckets against PostHog’s thresholds (same bands as web.dev). You can view p75, p90, or p99; PostHog recommends p90 as a balance between signal and noise. The toolbar shows vitals for the page you are on plus history for that page—handy while you debug in product.

Operationally, the SDK batches vitals (a few seconds’ flush by default). You can sample $web_vitals in before_send if billable events are a worry. PostHog suggests roughly 30 $web_vitals events per 100 $pageview events on average; vitals bill like any other event—see pricing.

Cookieless mode. With PostHog’s cookieless tracking (cookieless_mode: 'always', or the cookieless branch of on_reject), posthog-js does not send usable $web_vitals data: each vitals payload needs session and window IDs, and in these modes the usual session path is not there, so metrics are dropped. If you run banner-free always cookieless, do not expect a filled Web Vitals dashboard from PostHog alone—you give up that slice of analytics depth on purpose. SDK details change; check PostHog’s docs when you upgrade.

You only measure visitors who load the snippet and whose sessions allow vitals (consent, ad blockers, cookieless settings, whether the page ran long enough to emit metrics). That fits your product when capture is on. It does not cover dozens of client domains you never instrument, or a prospect URL before you have access.

Budgets and email alerts: how much setup each tool expects

PostHog has no monitoring-style “CWV budget” object—no per-URL LCP/INP/CLS cap with a built-in schedule and cooldown the way ops teams mean “budget.” You explore vitals in the Web Vitals UI; alerts hook onto trends insights in Product Analytics.

To get “email when this metric crosses a line,” you build or open a trend that plots the right series (often from $web_vitals fields), pick the series the alert watches, set a fixed or relative threshold, choose a check interval (hourly to monthly), and add email, Slack, or webhooks. Goal lines on the chart can match the threshold, but you are still in the insights product—not “add a budget for this URL” in one step. Someone has to keep those insights valid when events, filters, or properties change, and to align percentiles and sampling with what you are alerting on.

Watcher puts performance budgets and email next to scheduled PageSpeed tests for the org, site, or page you already track—no trend model first. Cooldowns are there to reduce alert noise for ops, not for funnel review. That is synthetic + CrUX only; it does not replace PostHog alerts on signups, revenue, or anything non-PageSpeed.

Teams deep in PostHog often fine-tune vitals insights and alerts and are right to. If the job is “keep client sites inside CWV limits with little glue,” a monitoring product usually means fewer steps.

What Apogee Watcher optimises for

Apogee Watcher is monitoring-first, not analytics-first. We run scheduled PageSpeed tests via Google’s API, store history per organisation, site, and page, and surface lab and CrUX together so you can see both “what Lighthouse saw” and “what Chrome users experienced at scale” when CrUX has data for that URL. You do not deploy our code on your clients’ sites to get baseline monitoring—we hit public URLs from Google’s test infrastructure.

That design choice matters for agencies:

Add staging or production URLs even when marketing controls the tag manager and will not add another script.
Organisations, sites, pages, and Admin / Manager / Viewer roles match how agencies staff work—not one analytics property per product.
Sitemap and HTML crawl so new templates and landers are not stuck behind a manual URL list.
Budgets and alerts aimed at “tell us before the client’s CWV drifts for a week,” not funnel charts.
Leads Management for new business: prospect URL, one-page reports, time-limited share links, score-band outreach—revenue workflows, not session analytics.

We do not ship a full product analytics stack, session replay, or feature flags. If you need those, use a tool built for them—often PostHog.

Side-by-side: where the overlap ends

Topic	PostHog (Web Vitals)	Apogee Watcher
Primary job	Product analytics OS; Web Vitals are real-user metrics from the browser	Synthetic PageSpeed monitoring + CrUX in results
Instrumentation	Requires `posthog-js` on the site	No script on monitored sites
Metrics	FCP, LCP, INP, CLS from real sessions (`$web\_vitals`) when capture runs	Lighthouse lab + CrUX (where available) via PSI
Cookieless analytics	With `always` (and cookieless paths without session IDs), `$web\_vitals` does not populate—see Cookieless mode above	No snippet; tests do not use PostHog session state
Best for	“How do my users experience my app?”	“How are these URLs doing on a schedule—and across many clients?”
Multi-site agency	Analytics projects and teams—not Watcher’s org/site/page model	Multi-tenant orgs, roles, discovery, budgets
Budgets & email alerts	Insight-based—build trends from `$web\_vitals`, attach [alerts](https://posthog.com/docs/alerts) with thresholds, frequency, destinations; maintain as analytics evolves	Monitoring-native—performance budgets and email alerts tied to scheduled tests; no separate insight to curate first
Extras	Flags, replay, experiments, cohorts, warehouse pipelines	PDF-style reporting direction, Leads prospecting workflows
Cost shape	Event-based (vitals count toward event quotas)	Plan-based subscription; PSI quota bundled—verify [pricing](https://apogeewatcher.com/pricing)

Use the table as a decision grid, not a spec sheet. Both products change; verify details on each vendor’s site before you buy.

When PostHog is the better primary choice

Choose PostHog when you own the app, already want product analytics, and need real-user vitals next to releases, experiments, and segments. If the question is “did that React change hurt INP for paying customers on Safari?”, you want RUM inside analytics—not only a nightly PSI run.

Feature flags and experiments sit next to Web Vitals, so you can tie score moves to what shipped. We do not replace that layer.

When Apogee Watcher is the better primary choice

Choose Watcher when synthetic coverage and agency workflow matter more than in-app events:

You watch many client or third-party sites where you will not (or cannot) deploy PostHog for a baseline.
You want scheduled checks, regressions, and budgets even when traffic is quiet this week.
Automated discovery matters because CMSs and URL lists change constantly.
You sell retainers and need client-ready reporting plus role separation (internal vs customer).

For the upgrade story from manual checks, see PageSpeed Insights vs Automated Monitoring. For setup at scale, How to Set Up Automated PageSpeed Monitoring for Multiple Sites tracks the same workflow we care about.

The complementary stack (layer, do not replace)

For many agencies the practical setup is both: PostHog (or similar) for behaviour and real-user vitals on sites you control, plus Watcher for multi-site synthetic monitoring, CrUX where Google provides it, and prospecting workflows. Different questions:

PostHog Web Vitals — What did users experience on routes we instrumented?
Watcher — Are our URLs still inside budget—what did lab + CrUX show on the last scheduled run?

RUM alone can miss pre-launch or zero-traffic URLs. Synthetic alone can miss logged-in or heavy-JS interaction pain. Together they cover more ground.

If you already use PostHog, what does Watcher add?

You already have $web_vitals, charts, and optional trend alerts—except in cookieless setups where vitals do not fire (see above). Watcher does not copy flags, replay, or experiments. It adds:

CWV signals when PostHog cannot send vitals. Cookieless always (or the no-session cookieless branch) leaves the Web Vitals view empty. Watcher still runs scheduled PSI + CrUX on the URLs you care about—independent of cookies, consent, or snippet load.

Scores without traffic. PSI can run on a timetable when visits are rare, the page is new, or the build is on staging without production tagging. PostHog needs visitors; Watcher needs a public URL.

Sites with no PostHog. Retainers, handovers, marketing-owned stacks, or prospects before contract: you still get lab + CrUX from Google without another analytics install per domain.

Portfolio shape. Orgs, sites, pages, Admin / Manager / Viewer, and sitemap + crawl discovery match “many clients, many URLs,” not one analytics project per product.

Monitoring alerts. Thresholds and email on test results and cooldowns, without building a trend per metric (see Budgets and email alerts above).

Sales workflows. Leads Management—prospect URL, one-page report, share link, score-band outreach—where PageSpeed is part of new business, not product analytics.

Two lenses on one site. On your own marketing site you can compare browser RUM with scheduled lab + CrUX. When they disagree, that is often lab vs field vs session—useful, not contradictory.

Watcher is not a second analytics product. It adds external monitoring, agency access control, and stored synthetic history next to what PostHog already does.

Limitations we will not sugar-coat

Watcher is not session replay, funnels, or feature flags.

PostHog Web Vitals are event streams from the browser, not Watcher’s stored PSI runs with full Lighthouse context on a schedule. They are different pipelines. In cookieless PostHog setups where $web_vitals never lands, you have no CWV series in PostHog at all—synthetic monitoring (here or elsewhere) is how you keep scores without changing your privacy settings.

Cookieless PostHog and Watcher work side by side: your analytics privacy choice does not block server-side PageSpeed tests.

CrUX needs enough real Chrome traffic; quiet URLs may show no field data. RUM, CrUX, and lab can disagree—that is normal.

Bottom line

PostHog’s Web Vitals docs cover real-user vitals for teams on the SDK. Watcher covers scheduled synthetic + CrUX for teams running many URLs and client-facing workflows. Decide on coverage (script or not), question (users vs URLs), and org model (analytics project vs agency portfolio)—then use one tool or both.

If Watcher matches how you work, check pricing and features for solo operators and agencies—including what is live for Leads Management—before you assume every seat gets full prospecting access.

FAQs

Is Apogee Watcher a PostHog alternative?

No. PostHog is product analytics; Web Vitals are one part. Watcher is PageSpeed / CWV monitoring across portfolios. Use neither, one, or both.

Does PostHog replace scheduled Lighthouse monitoring?

No for URLs you never instrument, or environments with no traffic. Synthetic runs still matter.

Does Watcher replace real-user vitals?

No. RUM captures post-load behaviour (SPAs, logged-in flows). CrUX helps at URL level when Google has data; it is not full RUM.

Which percentile should I trust?

PostHog offers p75–p99 and suggests p90 on Web Vitals. Watcher follows PSI / CrUX distributions. Use each for what it measures.

Is CWV alerting harder in PostHog than in Watcher?

Usually yes if you mean “alert on scheduled page performance.” PostHog: trends + alert rules on insights. Watcher: thresholds on test results. Different upkeep.

Does PostHog Web Vitals work in cookieless mode?

Not in strict cookieless setups (always, and paths where vitals cannot attach session IDs—see above). For lab + CrUX without that stream, add synthetic monitoring (Watcher or another PSI workflow).

SDK versions, event names, and prices change. Check posthog.com/docs/web-analytics/web-vitals and apogeewatcher.com before you buy.

Understanding INP: The Newest Core Web Vital and Why It Matters

Apogee Watcher — Sat, 04 Apr 2026 08:10:57 +0000

If you have been optimising for Core Web Vitals for a few years, you will remember First Input Delay (FID) as the “interactivity” metric. That role now belongs to Interaction to Next Paint (INP). Google promoted INP to a stable Core Web Vital on 12 March 2024 and retired FID from the programme at the same time. INP is not a minor rename—it measures a fuller slice of the experience, and it is the number you should expect in PageSpeed Insights, Search Console, and any serious performance report.

This article explains what INP is, why the change happened, and what to do about it in day-to-day work—including when you are responsible for many client sites rather than a single product. For step-by-step fixes, pair it with our deeper guide on LCP, INP, and CLS; for the wider CWV picture, start with What Are Core Web Vitals?

What INP measures (in plain terms)

INP captures responsiveness: how long it takes from a user’s discrete action until the browser can paint the next frame that reflects that action. Eligible interactions are clicks, taps, and key presses on the page. Hovering and scrolling are out of scope for INP, which keeps the metric focused on deliberate gestures that expect immediate feedback.

Google’s documentation breaks each interaction into phases that developers actually debug: input delay (waiting for the main thread), processing time (your event handlers), and presentation delay (work before the next paint). The slowest of those phases dominates the interaction’s latency. The page’s reported INP is derived from the interactions observed during the visit—for most pages that is effectively the worst interaction; on very chatty pages, the methodology discounts rare outliers so one freak delay does not drown out an otherwise snappy experience.

Field scoring uses the 75th percentile of page loads (split by mobile and desktop), consistent with other Core Web Vitals. The public thresholds are:

Rating	INP (field)
Good	≤ 200 ms
Needs improvement	200–500 ms
Poor	> 500 ms

Those numbers are not aspirational labels—they are what Google uses when it evaluates real-user experience at scale.

Where INP sits next to LCP and CLS

Core Web Vitals are still a set of three: LCP for loading, INP for responsiveness, CLS for visual stability. They answer different questions. You can ship a fast first paint and still fail INP if the main thread is busy when someone opens a menu; you can pass INP on a lean marketing page and still fail CLS if images without dimensions push content around. In practice, teams prioritise LCP first because it is easy to explain to stakeholders and often tied to hero assets and CDN configuration. INP rewards the same discipline—JavaScript budget, tag governance, framework choices—but shows up in different URLs and flows, especially after hydration. Treat the three metrics as separate dials, not one score.

Why FID was not enough

FID only looked at the first interaction on a page, and only at input delay: time before the browser started handling the event. That made FID useful for catching catastrophic main-thread blocking during load, but it ignored everything that happens after the page is interactive. Google notes that Chrome usage data shows most of a typical visit happens after load; a slow menu, cart step, or client-rendered route change could leave FID looking fine while users still felt a sluggish product.

INP closes that gap by measuring responsiveness across the full session and including processing and presentation, not just the queue in front of the first handler. That is why INP is a better match for modern sites heavy on JavaScript, third-party widgets, and single-page transitions—exactly the stacks agencies ship for clients every week.

Why INP matters for SEO and for users

Core Web Vitals are part of Google’s page experience signals. INP is the responsiveness pillar: poor scores indicate real friction—double taps, abandoned forms, rage clicks—while good scores mean the UI keeps up with input. Search is not the only reason to care; conversion and support tickets follow the same physics.

For teams managing portfolios of sites, INP adds a wrinkle: the worst interactions often sit on templates (navigation, checkout, lead forms) or on third-party scripts shared across properties. One slow pattern can drag INP for every page that uses it. That is less visible in a one-off Lighthouse run than in field data or repeated URL-level checks over time—which is why operational monitoring and regression alerts matter alongside manual audits.

How to see INP in practice

PageSpeed Insights pulls field data from the Chrome User Experience Report (CrUX) when your origin or URL has enough traffic; that is the authoritative place to see whether you pass INP at the 75th percentile. Lab tools do not compute INP directly; Lighthouse’s Total Blocking Time (TBT) is a rough proxy for main-thread contention that often tracks with INP problems, but it is not interchangeable. When CrUX data is missing—common on small or new sites—use real user monitoring (RUM) if you have it, or fall back to manual profiling in Chrome DevTools for representative flows.

Search Console’s Core Web Vitals report surfaces INP (and no longer treats FID as a Core Web Vital) after the March 2024 transition, so keep INP in scope when you triage URL groups and templates.

If you are building a repeatable workflow for clients—baselines, fixes, then proof—our Core Web Vitals monitoring checklist for agencies ties these metrics to review cadence and ownership. For setup across many monitored URLs, How to Set Up Automated PageSpeed Monitoring for Multiple Sites walks through the operational pieces.

What usually hurts INP

These patterns show up repeatedly in audits:

Long tasks on the main thread — parsing and executing large JavaScript bundles, synchronously updating heavy DOM trees, or blocking styles/layout after an interaction.
Third-party tags — analytics, chat, consent banners, and A/B snippets competing for the same thread as your UI handlers.
Large DOMs and expensive selectors — interactions that trigger wide reflows or style recalculations on complex pages.
Client-heavy rendering — SPAs that wait on data or hydration before showing feedback; users perceive that as “nothing happened” even when the network is fast.

A concrete pattern we see on client sites: the first click after load feels fine (FID would have looked healthy), but the fifth interaction—opening a filtered product grid, submitting a multi-step form, or toggling a sticky nav—hits a long task left behind by a tag or a bundle split. INP catches that; FID did not. Embeds deserve attention too: slow interactions inside iframes still count toward the page-level INP users see, while your own JavaScript cannot inspect cross-origin iframe code—so field data and DevTools frame selection matter when CrUX and RUM disagree.

Google’s own guides on optimising long tasks, input delay, and interaction diagnostics are the right next step once you know which interaction is slow.

INP and Apogee Watcher

Apogee Watcher is built to run scheduled PageSpeed-class tests across many sites and routes, surface lab and field signals where the API provides them, and alert you when scores move. INP is fundamentally a field-first metric: fixing it means reproducing real interactions, trimming main-thread work, and re-checking user journeys—not a single synthetic number in isolation. Use Watcher to watch for regressions when you ship framework upgrades, tag managers, or new client themes; pair those signals with DevTools and CrUX for the interactions CrUX cannot explain line-by-line.

If you are not monitoring yet, start with a baseline on your highest-traffic templates, then expand. Create a free account to add sites and budgets without wiring up PSI by hand for every property.

FAQ

When did INP replace FID as a Core Web Vital?

INP became an official Core Web Vital and replaced FID on 12 March 2024, per Google’s Web Vitals programme.

What is a good INP score?

At the 75th percentile of field data, 200 ms or less is “good”, over 500 ms is “poor”, with a band between for “needs improvement”—see Google’s INP documentation.

Does INP include scrolling or hover?

No. INP observes click, tap, and keyboard interactions. Scrolling and hover are not part of the metric, though some gestures may include a click or tap that is measured.

Is INP the same as Total Blocking Time?

No. TBT is a lab proxy related to main-thread blocking during load. INP is a field metric covering full-session interactions. They often move together when JavaScript is the culprit, but they are not identical.

Why should agencies track INP separately from LCP?

LCP measures loading; INP measures responsiveness after content is on screen. A page can have an acceptable LCP and still fail INP because of client-side code, third parties, or heavy UI after load—common on marketing sites and apps your clients maintain for years.

Further reading (Google): Interaction to Next Paint (INP), INP becomes a Core Web Vital — March 12, Optimize Interaction to Next Paint.

Web experts needed!

Apogee Watcher — Fri, 03 Apr 2026 13:22:49 +0000

We're glad to announce that we have opened our free account plan!

Apogee Watcher is built for portfolio-wide web performance monitoring in one multi-tenant dashboard. We auto-discover pages (sitemap + crawl fallback), run scheduled PageSpeed tests, track Core Web Vitals with lab + field (CrUX) data, set performance budgets to catch regressions early, and generate client-ready PDF reports/white-label outputs without cobbling exports.

If you would like to join the free beta test group with higher limits and up to 5 sites, sign up with code DEVTO, and get access to a 3-month free Starter account in exchange for your feedback as we refine workflows for multi-site teams. Available to 50 users only.

Features you can see now are

managing sites and pages with autodiscovery,
running ad hoc tests or setting schedules,
setting performance budgets per site,
mail alerts when a scheduled test finds a problem,
a first version of our lead prospecting feature, which you can use to attract new clients.

Our roadmap includes a) white-label reports you can share with clients, b) AI-powered suggestions for fix c) grouping of test results per type of pages (homepage vs product, etc).

Happy to answer any questions!

GTmetrix vs Apogee Watcher: PageSpeed Monitoring for Agencies Compared

Apogee Watcher — Fri, 03 Apr 2026 12:14:13 +0000

If you run performance work for clients, you have almost certainly opened GTmetrix. It is fast to explain, the reports look familiar, and tests run in Chrome with a wide set of analysis options (region, connection speed, device profiles on PRO). GTmetrix’s Performance Score is Lighthouse-based (captured with GTmetrix’s browser, hardware, and your chosen options), and reports also include CrUX field data where available—see their report guide. That matters when you need to pick the test region and compare lab vs field in one report.

Apogee Watcher is a different kind of product. We use Google’s PageSpeed Insights API (Lighthouse lab data plus CrUX field data where available) inside a multi-tenant workflow: many sites, scheduled tests, budgets, and alerts—without treating every client URL as a separate science project. Beyond monitoring, we also ship Leads Management for prospecting—analyse a prospect URL with PageSpeed (mobile and desktop), one-page performance reports with shareable links, and score-band outreach with lead stages—capabilities GTmetrix does not productise (it stays in the lab-and-monitor lane). What is self-serve for each tenant role is spelled out on our product pages and in the Leads section below.

This article is for teams who are outgrowing ad-hoc checks and want a straight answer: where GTmetrix wins, where a multi-site monitor wins, and when to use both.

What GTmetrix is genuinely good at

GTmetrix’s headline is not “dashboard for fifty retainers.” It is deep, repeatable lab testing with waterfall charts, speed visualisation (frame-style load capture in the Summary tab), optional video of the load, and—on higher PRO tiers—access to many test locations. As of GTmetrix’s own locations page, there are 113 servers across 25 global locations; how many locations your plan can use depends on the tier (e.g. Lite and Core include fewer than 25—see PRO pricing). That matters when:

You are debugging a slow first paint and want waterfall, visual load breakdown, and optional video evidence you can share.
You suspect a geographic angle (CDN edge, routing, or third-party latency) and want to run the same URL from more than one place.
You need a single URL or a small set of monitored URLs with monitoring and alerts, PDF exports, and REST API access—documented in monitoring and alerts and the API docs.

PRO plans include full report PDFs. White-label PDF reports are called out for Enterprise / custom plans, not bundled on every tier. That Enterprise track is contact-for-quote—GTmetrix does not publish a price for white-label or other custom entitlements; you only get a number after sales. That is different from self-serve PRO (Lite, Core, Advanced, Expert), where USD prices are listed (yearly billing is shown on the same page). Many shops still deliver performance as audit + report: run the test, attach the PDF, move on. For that pattern, GTmetrix is a credible tool.

None of that is “wrong” for Core Web Vitals work. The question is whether your job is mostly diagnosis or mostly ongoing coverage across many properties.

Where agencies feel friction with GTmetrix-style workflows

When you move from “one client, one site” to ten, twenty, or thirty production sites, the bottleneck is rarely “can we run Lighthouse?” It is operational:

URL hygiene — Every new landing page, campaign path, or template variant needs a manually maintained list. Miss a URL and you do not monitor it. Automated discovery is not the core story.
Monitored slots — On GTmetrix, a monitored slot is one URL plus a full set of analysis options (test region, device profile, connection speed, and anything else that defines that monitor). This is not “one slot per site”: the same homepage from Seattle and London, or desktop and mobile, consumes multiple slots. Plans cap total slots (e.g. Expert lists 50 monitored slots on the customise page; lower tiers have fewer). So real portfolios shrink fast: a handful of clients × a few key URLs × more than one region or device can eat the whole allowance without covering every property you care about. GTmetrix explains the model in their “What is a Monitored Slot?” FAQ.
Flat structure — You can organise projects and monitors, but you are still managing slots and lists, not a first-class organisation → sites → roles model built for agencies who hand work between people. On GTmetrix self-serve PRO, Lite, Core, and Advanced are single-seat only (no additional team seats—primary account only). Expert is the first tier that lists five team seats on the customise page. Apogee Watcher publishes unlimited team members with Admin / Manager / Viewer roles on every tier on pricing.
Scaling headcount — More clients usually means more human steps to keep monitoring aligned with what actually shipped last week.

GTmetrix is often described as single-site at heart for a reason: it shines when you drill into one URL. Apogee Watcher is built for the opposite problem—many URLs across many clients, with scheduled runs and budgets so regressions surface before the next quarterly review.

A pattern we see in agency Slack channels: one person owns “the GTmetrix bookmarks,” another runs PSI for quick checks, and a third tracks releases in the CMS. None of that is wrong—it is what happens when the portfolio outgrows a single-tool habit. The fix is rarely “buy another login.” It is usually one system of record for scheduled scores and ownership, with room to drop into a debugger when the headline numbers look off.

What Apogee Watcher optimises for

We are not trying to replace WebPageTest or GTmetrix when you need a deep diagnostic session. We are trying to reduce the weekly work of “did any of our clients’ key pages drift out of budget?”

PageSpeed Insights API — Lab and field data (where CrUX has volume) in line with how Google surfaces performance signals. Transparent about methodology: Lighthouse-style lab data, not a substitute for your own RUM.
Multi-site, multi-organisation — Add sites to a portfolio, team roles (Admin, Manager, Viewer), and a single place to see status—built for agencies, not bolted on as a custom plan. Capacity is site and test quotas per tier on pricing, not a separate slot for every region/device permutation of the same URL (see monitored slots above).
Automated discovery — Sitemap + HTML crawl so new paths do not rely on someone remembering to paste a URL. For a longer product-side view, see how Apogee Watcher discovers pages automatically.
Leads Management (prospecting) — Use PageSpeed evidence in new-business workflows: analyse a prospect URL, build one-page reports (HTML and PDF), share time-limited public links, and move leads through stages with score-band campaign messaging. GTmetrix offers nothing comparable; synthetic monitoring competitors typically stop at scheduled tests and alerts. Context: From Monitoring to Pipeline: Why PageSpeed Data Works for Agency Prospecting and The PageSpeed Prospecting Workflow.
Budgets and alerts — Set thresholds for LCP, INP, CLS (and related signals in the test output). Get email alerts when something crosses the line; Slack and webhook delivery are on the roadmap—check our current product pages for what is live when you read this.
Reporting — Client-facing reporting direction is aligned with agency plans; compare to GTmetrix’s PDF story, but judge us on what your tier includes today.

API and quota: Google’s PageSpeed relationship sits with us—your team does not manage API keys per client site. That is part of the “no DIY glue” positioning we repeat in why agencies need automated monitoring: fewer moving parts for the same PSI-backed scores.

If you want the broader “manual vs automated” framing first, read PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough. For setup patterns, How to Set Up Automated PageSpeed Monitoring for Multiple Sites walks through the same workflow we care about.

Side-by-side: what to compare on paper

Figures change—always verify pricing and limits on each vendor’s site before you buy. Use this as a decision grid, not a quote.

Topic	GTmetrix (typical positioning)	Apogee Watcher
Lab engine	Lighthouse-based Performance Score in Chrome; GTmetrix adds Structure Score and custom audits	PageSpeed Insights API (Lighthouse lab + CrUX where available)
Test locations	[25 global locations](https://gtmetrix.com/locations.html), 113 servers; lower PRO tiers use a subset	Centralised via Google’s PSI infrastructure—not a multi-region debugger
Multi-client portfolio	Monitors and projects; capacity is monitored slots (each URL + analysis options = one slot—see GTmetrix [FAQ](https://gtmetrix.com/pro/customize))	Multi-tenant: organisations, sites, roles
Team seats	Lite, Core, Advanced: single seat only; Expert: five team seats ([customise](https://gtmetrix.com/pro/customize))	Unlimited team members with roles on all published tiers ([pricing](/pricing))
Page discovery	Manual URL entry	Automated sitemap + crawl
Prospecting / new business	Not part of the product	Leads Management: prospect URL analysis, one-page reports, share links, score-band outreach, lead stages (GTmetrix has no parallel)
Best day-one use	Deep single-URL investigation	Scheduled cross-portfolio monitoring
Alerts	Email (and related features by plan)	Email; more channels in roadmap
Pricing (public list)	Self-serve PRO: Lite through Expert with published monthly USD on [customise](https://gtmetrix.com/pro/customize) (e.g. $4.99–$49.99/mo when billed yearly at time of writing—confirm before you buy). Enterprise / custom (white-label PDFs, priority support, POs): no public price—[request a quote](https://gtmetrix.com/contact.html?type=enterprise-quote).	Published tiers on [pricing](/pricing): $9 Personal, $29 Starter, $79 Professional, $199 Agency (USD/mo, features as listed on the page). Enterprise: custom pricing for bespoke limits and support—same “call for numbers” pattern as GTmetrix’s top tier.

Apples-to-apples on cost: GTmetrix PRO is not the same thing as Enterprise—PRO is the self-serve line with list prices; Enterprise is where white-label PDFs live, with no published fee. If you need branded client PDFs from GTmetrix, you are comparing an unknown quote to Apogee Watcher’s listed $199/mo Agency plan (white-label reporting on the pricing page) or $79/mo Professional (custom PDF reports there). For pure monitoring overlap, you can line up Watcher’s public tiers against GTmetrix’s self-serve Expert ($49.99/mo yearly on their site at time of writing) only if the capabilities match—still confirm both sites before you buy.

Mitigation we are open about: if your job is “prove this page in Tokyo vs London with a real browser,” GTmetrix’s location story is a fair advantage. If your job is “keep twenty client sites inside CWV budgets without a spreadsheet,” we bias our roadmap toward that.

When GTmetrix is the better primary tool

Choose GTmetrix (or keep it alongside) when:

You are debugging one or two URLs and need waterfall detail, speed visualisation or video, and choice of test region (where your plan allows).
Stakeholders want a PDF from a single deep run (self-serve PRO includes full report PDFs; white-label is Enterprise / custom on GTmetrix with no public price—compare to Watcher’s published Agency tier if branded client reports are the requirement).
You are not trying to run a weekly portfolio review—your cadence is “investigate when someone complains.”

When Apogee Watcher is the better primary tool

Choose Apogee Watcher when:

You manage enough sites that manual URL lists rot every month.
You need scheduled tests, stored history, and budgets so regressions do not wait for the next audit.
Team access and role separation matter more than a single shared login.
You want PageSpeed-backed prospecting in the same product as client monitoring (lead analyses, shareable reports, outreach stages)—GTmetrix does not offer that. Alongside multi-tenant structure, automated discovery, and team roles, Leads Management is an extra axis that general lab-and-monitor tools in this class typically skip.

Use both: diagnostics on top of monitoring

We do not pitch “rip and replace.” A practical stack often looks like:

Apogee Watcher — scheduled coverage, discovery, alerts, portfolio view.
GTmetrix or WebPageTest — when a single metric looks wrong and you need a deeper lab story.

That is the same “diagnostics vs monitoring” split we use in Best Free PageSpeed Monitoring Tools: PSI, WebPageTest, Lighthouse CI, Pingdom, and More: free or paid diagnostics answer why; monitoring answers whether it stayed fixed.

Practical next steps

Before you change tools, change the question from “which logo do we like?” to “who will own the cadence when we have twice as many sites next year?” The stack should make that person’s job smaller, not busier.

Write down your count — How many production sites, how many key URLs per site, how often releases ship.
Decide your failure mode — “We miss regressions” vs “we cannot deep-debug a single bad page.”
Trial the workflow — Run a week of scheduled tests on your noisiest clients and see whether alerts match how your team actually ships.

FAQ

Is Apogee Watcher a GTmetrix alternative for agencies?It is an alternative if your priority is multi-site monitoring, discovery, and budgets across a portfolio. It is not a feature-for-feature replacement for GTmetrix’s single-URL depth (waterfall, speed visualisation, optional video, and regional Chrome tests where your plan allows).

Does Apogee Watcher use the same data as PageSpeed Insights?We use the PageSpeed Insights API, so lab and field data align with the same sources Google’s public tools surface. GTmetrix also uses Lighthouse-derived lab scores for its Performance Score, but GTmetrix and PSI can still differ because of test region, hardware, throttling, and GTmetrix’s own Structure Score and grading—GTmetrix states this explicitly when comparing to PSI. Use both as signals, not as identical numbers.

Can we use GTmetrix and Apogee Watcher together?Yes. Many teams use a monitoring platform for coverage and a diagnostic tool for investigation.

Does GTmetrix “one monitored slot” mean one website?No. GTmetrix counts one slot per monitored configuration: the URL and the chosen options (region, device, connection speed, etc.). The same page under two regions or two devices uses two slots, which is why slot limits can cap how many sites and pages you can cover—see their monitored slot explanation.

Does GTmetrix offer lead prospecting or outreach workflows?No. GTmetrix is built around testing and monitoring URLs you configure. Apogee Watcher adds Leads Management for prospecting (analyse prospect URLs, reports, share links, score-band messaging, lead stages)—see the links in the main article. Availability per tenant role follows our current product and changelog.

What about Slack or webhook alerts?Email alerting is available today; Slack and webhook delivery are planned—confirm on the features and changelog pages before you rely on them for an SLA.

Where do I start with Core Web Vitals basics?Read What Are Core Web Vitals? A Practical Guide for 2026 and browse our Core Web Vitals category for deeper posts.

Apogee Watcher is multi-tenant PageSpeed monitoring and reporting for agencies and teams—scheduled tests, budgets, and discovery without the overhead of manual URL lists. See plans and sign up or explore automated monitoring on the blog.

Image Optimisation Strategies for Better LCP Scores

Apogee Watcher — Thu, 02 Apr 2026 07:58:48 +0000

On many marketing and product pages, Largest Contentful Paint (LCP) is not abstract. It is a hero photograph, a product shot, or a full-width banner. The metric tracks when that largest visible element finishes rendering; if the element is an image, your optimisation work is mostly bytes, dimensions, and discovery order—not another round of “general speed tips”.

This guide assumes you already know what LCP measures. If you need the full picture first, read What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Here we go deep on image-specific strategies that move LCP toward the “good” band (≤ 2.5 seconds in the field), and how to pair them with performance budgets so improvements stick.

Start by identifying the real LCP element

You cannot optimise “the page” in the abstract. LCP is tied to one element in the viewport. In PageSpeed Insights or Lighthouse, open the diagnostics and note which node is reported as LCP—often an <img>, sometimes a text block or a background.

If the tool points at an image:

Confirm the URL you are actually serving (CDN vs origin, srcset winner, and any CMS transforms).
Check the file size after compression. A 2.5 MB hero on a 360 px wide phone viewport is a sizing problem first, not a format problem.
Trace load order: is something else blocking discovery (late CSS, client-rendered markup, or a lazy attribute on the hero)?

Skipping this step is how teams ship a perfect WebP pipeline and still fail LCP because the LCP element was a different image—or text—than they assumed.

Pick modern formats and tune quality deliberately

AVIF usually beats WebP on file size at comparable visual quality; WebP still beats most JPEG for photos. The practical approach for 2026:

Serve AVIF with WebP or JPEG fallbacks using <picture> or rely on your CDN’s automatic format negotiation if you trust its tests.
Avoid shipping a single giant JPEG “because it works everywhere” unless you have measured that the conversion pipeline genuinely cannot run yet.
For illustrations with flat colour, SVG or optimised PNG can win; for large photographic heroes, raster formats dominate.

Quality settings are not universal. A quality of 75 in one encoder is not the same as 75 in another. Pick a default (for example AVIF at a sensible quantiser, WebP at 75–80), then visually compare at real display widths. Automated tools help, but a human glance at banding on skies and skin tones still catches regressions.

When you change format, re-measure LCP on the same URL. Lab scores can move for reasons unrelated to user-perceived quality, so keep before/after filmstrips or screenshots for stakeholders.

Match dimensions to rendered size, not to the asset library

LCP often fails because the browser decodes a 4000 px image into a 400 px slot. Responsive design does not mean “one huge master file for all breakpoints”.

Export or generate variants at the maximum CSS width they will occupy, per breakpoint, with a small margin for DPR (device pixel ratio). A 2× retina asset should be roughly 2× the CSS pixels, not 5× “for safety”.
Strip metadata you do not need; it is wasted bytes on every request.
If your CMS offers “automatic resizing”, verify the actual output dimensions in Network, not the checkbox in the admin UI.

If you only do one thing after reading this section: open DevTools → Network, click the LCP image, and compare Intrinsic size (natural width/height) to Rendered size. If the intrinsic side is many times larger than rendered, fix that before touching anything else.

Use `srcset` and `sizes` so the browser picks a sane file

Giving the browser a range of widths beats a single src for almost all content images.

srcset lists candidate widths or descriptors (480w, 800w, …).
sizes tells the browser how wide the image will be in the layout at different viewport widths, so it can pick the right candidate before downloading the wrong one.

Common mistakes:

sizes="100vw" on an image that is only half the layout width—so the browser pulls an unnecessarily large file.
Omitting sizes when using w descriptors, which can lead to poor selections.
Using loading="lazy" on an image that is above the fold and is your LCP element. The browser may defer work you needed immediately.

For a full-width hero, sizes="100vw" is often correct. For a card grid, describe the column width at each breakpoint. MDN’s documentation on responsive images is worth bookmarking for copy-paste patterns you can adapt.

Loading order: preload, priority, and lazy boundaries

Preload the LCP image when you know the URL early in the document:

<link rel="preload" as="image" href="/images/hero-800.avif" type="image/avif">

Use this when the hero URL is stable and not swapped by heavy client-side logic. If the URL only appears after JavaScript runs, preload may fire too late—fix when the URL is known, not only how it is loaded.

fetchpriority="high" on the LCP <img> nudges the browser to fetch that image sooner relative to other images. Use it sparingly (setting high on more than one or two images is usually not helpful) and pair it with not marking that same image as lazy.

Lazy loading belongs on below-the-fold images. For anything in the first screen, omit loading="lazy" or you risk delaying the very resource that defines LCP.

Decoding: decoding="async" can help keep the main thread responsive; test on low-end hardware if you are borderline on LCP.

CSS background images and LCP

Background images set in CSS are not <img> elements. They are still eligible for LCP, but the browser can’t reliably discover the underlying image URL until after CSS is parsed—so you can end up with extra LCP resource load delay. You also lose straightforward alt semantics for critical content.

If your hero is purely decorative, a background can be fine—but you still pay the same byte and timing costs. If the hero carries meaning (product, banner text is not enough), prefer semantic <img> or <picture> so preload and priority hints map cleanly to the resource.

When you must keep a background, preload it explicitly (e.g. link rel="preload" with fetchpriority="high" or a matching Link header) so it starts fetching early, and make sure the CSS/JS that reveals it doesn’t block rendering.

Third-party CDNs and transforms

Image CDNs that resize, reformat, and cache at the edge can shrink time-to-bytes dramatically. When you adopt one:

Lock URL parameters (width, quality, format) so marketing edits in the CMS do not silently generate new uncached variants.
Watch cache hit ratios after deploys; a “small” config change can bust effective caching.
Align transforms with your srcset strategy—duplicating the same logical image under twenty unbounded parameter combinations is a recipe for cache fragmentation.

CMS uploads and the “full size” trap

Many CMS/theme setups default new uploads to full resolution and then display them small. The HTML still references a massive file unless your theme registers proper image sizes and the markup uses them.

If you inherit a WordPress or similar build, check: (1) registered image sizes for hero slots, (2) whether the template uses wp_get_attachment_image with a named size or blindly outputs the original, (3) whether page builders inject full URLs into inline styles. One corrected template often beats dozens of hand-compressed assets nobody uses.

Verify in the lab, then confirm in the field

After changes:

Run PageSpeed Insights (or Lighthouse) on mobile and note LCP and the LCP element breakdown (TTFB, resource load delay, duration, render delay).
Compare field data (CrUX) where available—lab wins do not always match real users on slow networks.
If you use automated monitoring, add or check budgets for LCP on key templates so regressions surface when someone ships a new hero asset.

For a before/after story, WebPageTest filmstrips or Lighthouse’s View Trace help show whether you shortened resource load duration or merely shifted work. If TTFB or render delay still dominates, image tweaks alone will not get you to green.

Document one baseline number (median LCP or Lighthouse LCP) per template so the next redesign has a reference point.

Tie optimisation to budgets and ownership

Image work is easy to undo: a new campaign drops a 4 MB PNG into the hero and nobody notices until Search Console complains. Add a simple budget per template: maximum dimensions, maximum encoded kilobytes, and allowed formats. Our Performance Budget Thresholds Template is a starting point if you do not have internal standards yet.

Assign who approves hero assets in the CMS—often a designer uploads once and the performance contract is forgotten. A short checklist in the handover doc beats a post-launch fire drill.

What to do next

Identify the LCP element on your top templates.
Resize and re-encode; wire srcset/sizes correctly.
Remove lazy loading from above-the-fold heroes; add preload or fetchpriority where appropriate.
Re-test in the lab and watch field metrics after release.

Small, measurable steps beat a sweeping “image audit” that never ships.

FAQ

Is the hero image always the LCP element?

No. LCP is the largest visible element in the viewport; it can be a headline block, a video poster, or another image. Always confirm in your tooling before optimising the wrong asset.

WebP or AVIF first?

Prefer AVIF with a WebP or JPEG fallback for broad support, or use CDN negotiation if you have verified behaviour across browsers you care about.

Does lazy loading hurt LCP?

Lazy-loading your actual LCP element can delay LCP. In practice, omit loading="lazy" for the first-screen hero (and for any image the diagnostics report as LCP).

Do I need a CDN to pass LCP?

Not always, but a CDN often cuts latency and improves repeat visits. If TTFB or download time dominates your LCP breakdown, origin geography and caching deserve attention alongside image bytes.

Site Audit Checklist: Onboarding a New Client for Performance Monitoring

Apogee Watcher — Wed, 01 Apr 2026 12:44:18 +0000

Most onboarding checklists are either too light ("run a test and send a report") or too heavy (a long enterprise worksheet no one follows). Agency teams need something in between: a practical checklist you can run repeatedly, with enough structure to avoid blind spots.

This guide is built for teams onboarding client sites into ongoing performance monitoring. The goal is clear: move from "new client handover" to "monitoring is live, scoped, and actionable" without spending two weeks in setup mode.

If you need the monthly review workflow after onboarding, pair this with Monthly Performance Review Template for Agency Teams.

What teams usually need from a site audit checklist

Most teams need three things from an onboarding checklist:

A template they can copy directly.
A sequence of actions in the right order.
Clarity on what matters most in the first week.

This article covers all three. It starts with a copy/paste checklist, then explains how to use each section so your first monitoring cycle produces decisions, not just numbers.

Before you touch tools: lock scope and ownership

Do not begin with a full crawl and a 200-row spreadsheet. Start with agreement.

For each client, lock these five items first:

Primary domain and critical subdomains
Priority templates (homepage, lead form, pricing, service/product, checkout)
Mobile and desktop coverage
Reporting cadence (weekly internal, monthly client-facing)
Alert recipients and first-response owner

If you skip this step, the first client conversation usually becomes "why are these pages here?" instead of "what do we fix first?"

Site audit checklist (copy/paste template)

Use this in your docs tool, ticketing system, or onboarding runbook.

// Site Audit Checklist — Performance Monitoring Onboarding
// Client: [NAME]
// Domain(s): [DOMAIN]
// Owner: [NAME]
// Date: [YYYY-MM-DD]

1) Access and context
- [ ] Confirm primary domain + environments (prod/stage)
- [ ] Confirm CMS / stack basics (WordPress, Shopify, custom, etc.)
- [ ] Confirm deployment owner / technical contact
- [ ] Confirm analytics and consent constraints

2) URL inventory
- [ ] Pull URLs from sitemap(s)
- [ ] Add business-critical URLs manually (pricing, lead form, key landing pages)
- [ ] Remove obvious noise pages (search params, utility pages, test paths)
- [ ] Group pages by template type where possible

3) Measurement setup
- [ ] Enable mobile + desktop testing
- [ ] Set test frequency by site priority
- [ ] Confirm test quota and page limits match plan
- [ ] Confirm data retention expectation (30/90/365 days or plan default)

4) Baseline capture (first run)
- [ ] Run initial tests for priority pages
- [ ] Record baseline LCP / INP / CLS and performance score
- [ ] Mark currently failing pages and highest-severity regressions
- [ ] Note pages with no field data so expectations are clear

5) Budgets and alerts
- [ ] Set initial thresholds (LCP, INP, CLS) per site/template
- [ ] Set alert channels (email / Slack / webhook where available)
- [ ] Confirm cooldown and escalation owner
- [ ] Confirm who receives alerts and who owns first response

6) Reporting readiness
- [ ] Decide client-facing summary format (call, email, PDF/report link)
- [ ] Define monthly review owner and calendar slot
- [ ] Draft first "what we monitor and why" note for client
- [ ] Confirm next review date

7) Handover
- [ ] Create top 3 actions from baseline findings
- [ ] Assign owner + due date for each action
- [ ] Log blockers (hosting, scripts, release dependencies)
- [ ] Share final onboarding summary internally

How to run each section without adding overhead

The checklist above is the scaffold. This section explains how to keep it efficient.

1) Access and context

This is where most onboarding delays begin. The most common blocker is not technical complexity; it is missing ownership.

Minimum acceptable output from this section:

one technical contact who can approve changes,
one business contact who can prioritise pages,
one statement on environment scope (production only, or production + staging).

If that is not settled, pause setup and resolve it before running baseline tests.

2) URL inventory

Start with sitemap URLs, then force-add business-critical pages. Sitemaps are useful, but they often miss campaign pages, dynamic pricing paths, or recently launched funnels.

A practical first pass for most sites:

1 homepage URL
2-5 conversion URLs (pricing, lead form, checkout, booking)
5-10 high-traffic content or service templates

That gives you enough coverage to catch meaningful regressions without drowning your team in low-value alerts.

3) Measurement setup

Always enable both mobile and desktop. Even if the client says "our users are mostly desktop", mobile regressions still affect search visibility and user experience on mixed traffic.

Set test cadence based on risk:

high-change sites: daily
medium-change sites: weekly
stable sites: weekly or monthly

Avoid a false precision setup where every site gets the same frequency. Match cadence to release behaviour and business risk.

4) Baseline capture

A baseline is not "export all scores". It is a snapshot you can compare against in four weeks.

For each priority page, record:

current LCP, INP, CLS
current performance score
current status (within threshold / out of threshold)
one likely cause if out of threshold
one likely business impact

That last two lines are what make the baseline usable in client calls.

5) Budgets and alerts

Budgets and alerts are where monitoring becomes operational.

Do not over-tune on day one. Set initial thresholds, then adjust after one month of data. The objective is a stable signal, not perfect thresholds in the first week.

When setting alert channels, define response paths explicitly:

who receives first alert,
who triages,
who communicates externally,
what counts as escalation.

Without this, alerts become noise and trust drops quickly.

6) Reporting readiness

If the client is onboarding, they need clarity more than polish.

First-cycle reporting should answer:

What we monitor.
What is currently failing.
What we will fix first.
What we need from you (if anything).

You can upgrade format later (dashboards, PDFs, branded summaries). Start with consistency.

7) Handover

A clean handover has only three mandatory outputs:

top three actions,
owner and due date for each action,
known blockers.

If you end onboarding without those, you have setup but not momentum.

Priority matrix for first-week triage

Use this quick matrix when multiple regressions appear at once:

Impact	Effort	Priority
High business impact	Low effort	Do first
High business impact	High effort	Plan this cycle
Low business impact	Low effort	Batch with other fixes
Low business impact	High effort	Backlog unless it trends worse

This keeps your first month focused on visible wins rather than interesting low-impact fixes.

Common onboarding mistakes and how to avoid them

Tracking too many pages too early

A long page list feels thorough, but it slows triage and increases alert fatigue. Start with the minimum meaningful set, then expand after your first review cycle.

No alert owner

Shared inbox alerts with no owner create silent regressions. Assign one response owner before the first scheduled run.

Baseline with no narrative

"LCP is 3.8s" alone is not useful. Pair every key metric with context:

page type,
suspected cause,
likely user/business impact.

That turns metrics into decisions.

Promise mismatch on reporting

Do not promise polished monthly packs before setup stabilises. First cycle should prioritise baseline clarity and top actions.

Mixing diagnosis with onboarding

Onboarding is not root-cause analysis on every issue. Capture the issue, assign severity, and create an action list. Deep diagnosis can run in delivery sprint time.

Suggested first-month cadence after onboarding

Use a straightforward rhythm:

Week 1: onboarding, baseline, first top-three action list
Week 2: ship highest-impact fixes
Week 3: verify against fresh runs
Week 4: run monthly review and reset priorities

If thresholds still feel loose, use Performance Budget Thresholds Template before your first full client review.

Example onboarding summary you can send to a client

Use this short format once setup is complete:

Subject: Performance monitoring onboarding complete — next steps

We have completed onboarding for [DOMAIN].

Monitoring scope:
- [N] priority pages across [template groups]
- Mobile and desktop tracking enabled
- Baseline recorded for LCP, INP, CLS, and performance score

Current status:
- [X] pages within thresholds
- [Y] pages needing attention
- Top risk: [short description]

Next three actions:
1) [Action] — owner [name], due [date]
2) [Action] — owner [name], due [date]
3) [Action] — owner [name], due [date]

This is usually enough for the first cycle. You can move to a fuller monthly format once trends are visible.

FAQ

How many pages should we include in the first onboarding pass?

Usually 10-20 priority URLs is enough for a reliable baseline. Expand only after your team can keep up with triage.

Should we onboard mobile first or both mobile and desktop?

Both. One-device monitoring hides regressions and creates reporting gaps.

Do we need complete page-type classification before monitoring starts?

No. Start with practical buckets (homepage, conversion pages, core templates), then refine over time.

What if the client has no clear target thresholds yet?

Use pragmatic starter thresholds, mark them provisional, and revise after one month of observed data.

How long should onboarding take per client?

For typical brochure/ecommerce sites, setup and first baseline can usually be done in 30-90 minutes if ownership and access are clear.

What should we do if alerts spike in week one?

Check whether scope is too broad or thresholds are too strict. Triage by business impact and fix ownership before widening coverage.

A good site audit checklist does more than capture URLs and scores. It creates operating rhythm: clear scope, clear owners, and clear next actions. That is what makes monitoring useful after month one.

Monthly Performance Review Template for Agency Teams

Apogee Watcher — Tue, 31 Mar 2026 20:39:36 +0000

Most agency teams do not struggle with data. They struggle with rhythm.

You already have scores, alerts, and test history. The friction starts when the month ends and you need to answer four questions quickly:

What improved?
What regressed?
What matters for the client right now?
Who is doing what next?

This template gives you a repeatable monthly review in 30-45 minutes per client—built for multi-site teams where consistency beats perfect slides.

If you need setup guidance before review cadence, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites. If you need a client-facing deliverable, pair this with Client-Ready Core Web Vitals Report Outline.

What we mean by a monthly performance review

Many “monthly performance review” templates are built for HR one-to-ones. This one is for website performance: Core Web Vitals, regressions, and the work your team ships—so clients who pay for speed and stability get a steady rhythm instead of one-off updates when something breaks.

You need: a clear agenda, a small set of metrics you can defend, copy that works in a client email, and three actions with owners—not “we will keep an eye on it”. The script below is that meeting. Run it internally first; the next section covers the client conversation.

Use this template as a meeting script

The structure below works as:

an internal monthly review meeting
a client-facing performance call
a handover note between technical and account teams

Copy this into your docs tool and reuse it every month.

// Monthly Performance Review — [CLIENT / SITE]
// Period: [YYYY-MM]
// Meeting date: [DATE]
// Owner: [NAME]
// Participants: [NAMES]

1) Snapshot
- Overall status: [Healthy / Needs attention / Critical]
- Portfolio summary:
  - Sites monitored: [N]
  - Pages monitored: [N]
  - Tests run this month: [N]
  - Alerts triggered: [N]
  - Alerts resolved: [N]

2) Metric trend review (mobile + desktop)
- LCP: [value] (last month: [value], delta: [value])
- INP: [value] (last month: [value], delta: [value])
- CLS: [value] (last month: [value], delta: [value])
- Performance score: [value] (last month: [value], delta: [value])
- Comment: [What changed and why]

3) Biggest wins this month
- Win #1: [change made] -> [metric impact] -> [business impact]
- Win #2: [change made] -> [metric impact] -> [business impact]

4) Regressions and risks
- Regression #1: [page / template]
  - Detected: [date]
  - Suspected cause: [release, script, image, third-party, etc.]
  - Current impact: [SEO / UX / conversion]
  - Severity: [High / Medium / Low]
- Regression #2: [...]

5) Top 3 actions for next month
- Action 1: [task]
  - Owner: [name]
  - Due: [date]
  - Success metric: [target]
- Action 2: [...]
- Action 3: [...]

6) Decisions and dependencies
- Client decisions needed: [yes/no + details]
- Cross-team dependencies: [dev, content, design, hosting]
- Blockers: [list]

7) Client communication summary
- What we will tell the client this month (3 bullets max)
- Confidence level: [High / Medium / Low]
- Escalation needed: [yes/no]

Internal review first, then the client

Do not skip the internal pass. Half-explained metrics on a client call usually mean the team argues about interpretation in front of them—or nobody agreed what “green” meant before you dialled in.

Run sections 1–6 with tech plus account or delivery (15–20 minutes). Align on severity, strip noise, agree what you can say externally. Then use section 7 plus one executive line for the client call or email (20–30 minutes; account-only is fine for low-touch clients). Clients rarely need every alert ID—they need proof you are in control and a clear ask when their content, scripts, or hosting blocks progress.

On maintenance and monitoring retainers, this meeting is often the clearest proof of value. Still complete section 3 (wins). Stability after a heavy release month is a win worth naming.

Why this format works for agencies

It forces one pass from raw metrics to accountable actions.

Many reviews fail because teams stay in reporting mode: charts and discussion, then no owner. This template keeps one output in view: actions with names and deadlines. Keep budget targets visible in the room. If thresholds are still loose, set them with Performance Budget Thresholds Template before the next cycle.

A practical scoring model for monthly status

Use a simple status system so everyone speaks the same language:

Healthy: no high-severity regressions open; core templates stay within agreed thresholds
Needs attention: one or more key templates out of threshold, but impact is contained
Critical: high-impact regressions on revenue or lead pages, unresolved for multiple runs

Keep the labels simple. The goal is faster decisions, not a perfect classification scheme.

What to prepare before the meeting

Keep prep under 20 minutes per client:

Pull this month versus last month metric deltas
Export or copy the top alert events and resolution notes
Select the 2-3 most important pages (homepage, pricing, lead form, key product template)
Draft the three client-facing bullets in advance

Technical lead: confirm URLs, mobile and desktop, and budgets still match what you monitor. One line of suspected cause per regression; realistic effort for the top three actions.

Account or delivery lead: what the client already saw in tickets or Slack; promises in writing; whether section 7 reads like a service update, not a post-mortem.

If prep runs long, use the same export, comparison window, and three priority URLs every month.

After the meeting: outputs that close the loop

Tasks — three actions with owner and due date in your PM tool, not only in notes.
Client touchpoint — short email with section 7 bullets plus a dashboard or PDF link, or a call with the same content; depth should match the contract.
Threshold sanity — if the same template stays “Needs attention”, fix the budget, fix the page, or reset expectations in writing.

Optional: one line in your internal monthly business review—“Performance: [status] — top risk: [X]”—so web performance stays visible next to SEO and content.

Common mistakes this template avoids

1) Mixing diagnosis with decision-making

You can spend an hour debating why a metric moved and still leave without a plan. Keep root-cause deep dives separate when needed. The monthly review should end with owned actions.

2) Reporting averages only

Averaged scores hide broken high-value pages. Always include at least one section on key templates and business-critical URLs.

3) No link between performance and client impact

Clients do not buy "better Lighthouse numbers". They buy risk reduction, stability, and fewer surprises. Translate each major change into likely impact on user experience and search visibility.

4) Too many priorities

If every item is urgent, nothing is urgent. Keep the next-month action list to three items max.

Suggested monthly cadence

Week 1: run the review and lock actions. Weeks 2–3: ship fixes. Week 4: verify and draft next month’s notes. Busy sites can add weekly tactical checks; still hold one monthly reset.

If you are still deciding what to monitor, start with Core Web Vitals Monitoring Checklist for Agencies. If the same pages fail every month, read The Complete Guide to Performance Budgets for Web Teams and reset thresholds.

FAQ

How long should a monthly performance review meeting take?

30-45 minutes per client is enough if prep is done and the agenda is fixed. Longer meetings usually mean unclear ownership or too much ad-hoc debugging inside the call.

Who should attend from the agency side?

At minimum: one technical owner and one account owner. Technical owners explain causes and options; account owners align recommendations with client priorities and communication.

Is this the same as an HR performance review template?

No. This article is for website performance and delivery reviews with clients or internal delivery teams. It does not cover employee appraisals or performance improvement plans.

Should we include every monitored page in the review?

No. Review trends portfolio-wide, then focus discussion on business-critical templates and the highest-impact regressions.

What if nothing significant changed this month?

That is still a useful outcome. Record stability, confirm thresholds are still appropriate, and document one preventive action for next month.

How is this different from a client report template?

This template is for decision meetings. A client report is a polished output for stakeholders. Use this review first, then summarise outcomes in a client-ready report format.

What should I put in the calendar invite?

Title: “Monthly web performance review — [Client] — [Month YYYY]”. Body: link to the dashboard or report, four-bullet agenda (snapshot, trends, regressions, three actions), attendees.

Can we run this monthly review for a single site?

Yes—set section 1 counts to one site; the rest of the script stays the same.

Same agenda every month and every action owned—that is how monitoring reads as a service. Sign up for scheduled PageSpeed checks with less manual prep.

Watcher's Free plan rolling out ahead of full launch

Apogee Watcher — Sun, 29 Mar 2026 22:08:01 +0000

We are still in private beta, but as of today you can sign up without a credit card and start on the Free plan. You get a real organisation, one site, and the same PageSpeed Insights–backed testing as we will have on paid plans.

We want more real URLs and real feedback beyond our closed private beta testers and we'd love your feedback. However, this is not a test or a temporary offering, we will always have a free plan for developers, freelancers and people with no need for the features of paid plans.

What the Free plan includes

One website to monitor.
15 PageSpeed tests per month, including manual runs and scheduled checks.
14 days of result history.
Monthly schedules only. If you need weekly runs, you will need a paid plan.
Email alerts when budgets fail (no Slack or other channels on Free).
One user in the organisation—built for solo evaluation.
Fully working plan within those limits: you are not locked to read-only while your subscription is active.
Lab metrics and CrUX in results where Google provides field data, same as elsewhere in the product.

What the Free plan does not include

Free is for monitoring and alerts for a single domain with a basic set of features. It does not bundle PDF export, white-label branding on reports, REST API access, the leads prospecting tools, or AI Insights. You still get full PageSpeed Insights lab metrics and CrUX field data where Google provides it—the difference is the extras for export, client-ready delivery, integrations, and AI-guided next steps.

See the pricing page for which plan includes what. In short:

AI Insights — Prioritized, fix-oriented guidance from your PageSpeed results. Available from Personal upward; not on Free. Where your plan includes it, monthly usage follows the same ceiling as your PageSpeed test allowance for that tier.
PDF reports — Downloadable client-ready reports. From Professional upward (not on Personal or Starter).
White-label reports — Your branding on reports. From Professional upward, alongside PDF-capable tiers.
REST API access — Integrate monitoring data with your own systems. Agency and Enterprise on our public pricing; smaller tiers do not include API access.
Leads management — Prospecting pipeline (capture leads, analysis, campaigns). Agency and Enterprise.

Signup today

If you have more than one site, sign up today and you will be eligible for a time-limited trial on a paid tier as we make progress with our launch.

Forem: Apogee Watcher

The Real Cost of Poor Web Performance: A Data-Driven Analysis

Why “cost” is more than lost sales

What published research says (and what to read elsewhere)

Retail and large-brand mobile studies (summary)

Engagement and bounce (all verticals)

Forms, checkout, and trust

Lead gen, SaaS, and services: your data is the headline

Core Web Vitals as a shared language for “cost”

Hidden costs: ads, SEO, and operations

Paid media efficiency

Organic search and AI-mediated discovery

Engineering and opportunity cost

Agencies: proof beats opinion in renewals

Turning data into a monitoring posture

FAQ

How to Set Up Performance Budgets in CI/CD Pipelines

What “performance budget in CI” usually means

Before you write YAML: pick URLs and environments

Path 1: Lighthouse CI (LHCI)

Install

Minimal lighthouserc (assertions + collect)

Wire the CI job

Resource limits: budgetsFile vs assertions

Path 2: GitHub Actions sketch

Resource budgets alongside Lighthouse

Flakiness and false positives

How this pairs with product-side budgets and alerts

Apogee Watcher and CI: agency API (in active development)

Checklist: ship a credible CI budget

FAQ

Performance Budgets and Email Alerts in Apogee Watcher

Why budgets and alerts belong together

What “a budget” means inside Watcher

From a scheduled test to an alert row

Email digests: what actually arrives

Cooldowns and why they exist

How this fits next to policy and people

Getting started in a few concrete steps

FAQ

Performance Monitoring for E-Commerce: What Metrics Matter Most

Why e-commerce needs its own metric priorities

What the research says: small delays, large business effects

Google and Deloitte: sub-second gains move the funnel

Yottaa 2025: seconds, bounce, and third-party tax

Core Web Vitals: what to watch in a shop

LCP (Largest Contentful Paint)

INP (Interaction to Next Paint)

CLS (Cumulative Layout Shift)

Supporting lab metrics (still useful)

Page-type playbook: what to optimise first

Synthetic monitoring, CrUX, and RUM: how they fit

Third parties: measure the tax explicitly

Practical checklist: what “good” e-commerce monitoring includes

FAQ

What is e-commerce performance monitoring?

Which metrics matter most for online stores?

Does improving page speed increase e-commerce conversion?

How often should we run performance tests on a store?

Should we monitor Shopify or WooCommerce differently?

Sources and further reading

Apogee Watcher vs PostHog Web Vitals: Synthetic PageSpeed Monitoring and Product Analytics Compared

What PostHog Web Vitals actually is

Budgets and email alerts: how much setup each tool expects

What Apogee Watcher optimises for

Side-by-side: where the overlap ends

When PostHog is the better primary choice

When Apogee Watcher is the better primary choice

The complementary stack (layer, do not replace)

If you already use PostHog, what does Watcher add?

Limitations we will not sugar-coat

Bottom line

FAQs

Understanding INP: The Newest Core Web Vital and Why It Matters

What INP measures (in plain terms)

Where INP sits next to LCP and CLS

Why FID was not enough

Why INP matters for SEO and for users

How to see INP in practice

What usually hurts INP

Minimal `lighthouserc` (assertions + collect)

Resource limits: `budgetsFile` vs assertions

Use `srcset` and `sizes` so the browser picks a sane file