Coder Legion - Recent posts tagged corewebvitals

Changelog #12: Domain Report Summary, Lead Page Classification, and Classification Rules

Sat, 05 Sep 2026 07:19:00 +0000

August focused on making domain reports easier to triage before you open every mobile and desktop tab, and on extending the same page-type labels from monitored sites to prospecting leads. We also shipped a public help centre, tightened how we measure outreach engagement, and published agent-readiness improvements on the marketing site so automated visitors can find contact paths and structured metadata without guessing.

Changelog #11 (1 Aug 2026) covered paid plans, the multi-organisation dashboard, newsletter preferences, and first-pass page classification on customer sites. This release builds on that classification work for leads and adds a Summary-first view on shared domain reports.

Domain report Summary tab

Shared domain reports at https://apogeewatcher.com/reports/domain/{token} now open on a Summary tab by default (#summary). Mobile, Desktop, and Tested pages remain on their own tabs when you need the full score cards or per-page tables, so you can triage from one screen before drilling into strategy-specific detail.

The Summary is built for triage. It uses three terms consistently: Pages are URLs you selected; Tests are Lighthouse runs (each page tested on mobile and desktop counts as separate tests); Metrics are the measurements inside a test (LCP, CLS, INP, category scores, and so on). We dropped vague “sample” wording so agency copy matches what you see in the report header.

The attention-free score is the percentage of completed tests that pass every lab gate we track on that report: Performance ≥90, Accessibility, Best Practices, and SEO ≥80, LCP ≤2.5s, CLS ≤0.1, and INP ≤0.2s (with Total Blocking Time as the fallback when INP is missing). 100% means no test on either strategy still needs attention. The headline states how many tests need work, for example “12 of 38 tests need attention”, beside a site status badge and the top gap label when we can infer one.

Below the headline you get a fails-only scoreboard (averages for metrics that are still failing), a short “What we found” narrative, the top five pages that need attention with a Why column that names the failing metric and value (for example Perf (88%) or LCP (3.45s)), attention grouped by page type, and merged opportunity rows that count affected pages on mobile and desktop together with links into both strategy tabs. A coverage line closes the section: how many pages were selected, how many have completed tests, and how many tests finished in total.

PDF exports follow the same order: Summary first, then stacked mobile, desktop, and tested-pages sections. For a deeper walkthrough of the score and how we use Summary links in outreach, see our companion post on attention-free scoring on domain reports, or open any recent report and jump straight to #summary.

Richer domain reports with how-to links

Grouped Lighthouse opportunities link to clearer Chrome documentation where the audit text was ambiguous, and each actionable opportunity can surface up to two related Apogee Watcher how-to posts when we have a published article that matches the audit theme. The same opportunity does not repeat the same blog link twice within a strategy block, so the sidebar stays readable on large scans.

Lead page classification

Prospecting leads in the app now classify discovered URLs with the same page-type taxonomy you already use on monitored sites: homepage, category, product, cart, checkout, content, legal, and the rest of the standard set, plus Unclassified when rules do not match. Classification runs when a lead page is created or when its URL changes. Global URL rules apply first; keyword heuristics fill gaps. Each row stores a type label, a source (global rule, heuristic, manual, or unknown), and a confidence score you can inspect on the lead page detail view. Manual overrides stick until you clear them, matching the behaviour on customer site pages from Changelog #11.

On domain reports generated from leads (including free-check funnels and prospecting runs you start from a lead record), the Tested pages tables group rows by page type so you can see whether product URLs or blog posts dominate the failures. Late August also expanded locale and home-with-query matching in the global rules so common agency prospect URLs classify more reliably on first discovery.

Faster page discovery with DataForSEO

We integrated DataForSEO into the shared page-discovery pipeline. When a sitemap is thin or the origin blocks automated crawls, Watcher can pull likely public URLs from ranking and backlink datasets instead of waiting on a long on-site crawl. That shortens the page-pick step before tests start on monitored sites and on lead prospecting runs that feed domain reports.

Lead outreach and engagement tracking

For seller outreach we added a controlled send path from curated prospect drafts: plain-text templates, reply routing to your normal inbox, and delivery through our Mailgun integration so opens can be recorded without treating internal BCC copies as prospect engagement. In the Messages area, open counts for outreach mail now ignore opens from our own monitoring addresses and campaign BCC recipients, so “opened” reflects the prospect inbox more honestly. The Leads list can filter and sort by whether a domain report exists for the lead and by how many times a shared report link was viewed, which helps you prioritise follow-up after a cold email goes out.

Public help centre at /docs

We shipped a markdown-backed help centre at apogeewatcher.com/docs with fifteen P0 guides organised into Getting started, Testing and results, Reports and sharing, Budgets and alerts, Plans and billing, and Team and access. Articles cover account setup, first organisation and site, discovery, reading lab results, mobile versus desktop strategies, lab versus field data, sharing test links, organisation PDF exports, budgets, alert digests, plan limits, roles, invitations, and what each role can do.

Agent readiness on the public site

We continued the agent-readiness work we showed in We Scored 58/100 on Agent Readiness. The marketing site now publishes llms.txt, a dedicated contact page, richer JSON-LD on home and pricing (WebSite, Service, BreadcrumbList), and recovery links on common 404 paths so automated crawlers and humans land on a useful next step instead of a dead end. Markdown error responses for missing agent-oriented paths include explicit recovery links, and pricing checkout copy aligns with the public pricing template while the footer points to the on-domain contact page. We added an honest planned API stub: a public status endpoint and JSON-shaped 404 responses for guessed API paths, labelled as forthcoming rather than pretending full API coverage already exists.

Permissions and dashboard polish

Manual Run test actions now respect organisation role: only members who can run tests in the current organisation see the control, which stops Viewers from starting quota-consuming runs by accident. Authenticated users who open the sign-up page while already logged in are redirected into the app instead of seeing an empty registration form.

What to try

Open a recent domain report from a free scan or a lead in the app and start at #summary. Note the attention-free percentage, the failing scoreboard, and whether failures cluster in one page type. Switch to Mobile or Desktop only when you need the full opportunity list.

On a lead with many discovered URLs, re-run classification from the page list and confirm product or content URLs pick up sensible types before you generate a report for outreach.

Browse apogeewatcher.com/docs for onboarding a new teammate without exporting internal wiki notes, and send a test outreach message if you run seller campaigns so opens and report views show up on the lead record.

References

Cross-Origin YouTube Embeds and CLS: What Publishers Can Actually Fix

Fri, 04 Sep 2026 06:29:48 +0000

YouTube embed CLS is usually two separate failures that look like one video player. On the parent page, Cumulative Layout Shift often comes from a zero-height or late-sized embed box: the article injects an iframe, the box grows, and bylines, related stories, and forms jump. Inside the player, captions, related-video rails, and controls can still move, but that document loads from youtube.com or youtube-nocookie.com, so the hosting site cannot style or pin it. Teams that chase player UI inside the iframe waste weeks. Teams that reserve a stable 16:9 box, load the real iframe only after a click or consent gate, and watch CLS on the article URL usually recover the metric.

We covered the general CLS failure modes in CLS deep-dive: common causes and fixes for layout shift and the wider third-party load problem in third-party scripts and performance. Those posts map the shared causes (missing dimensions, injected widgets, fonts). What follows is the publisher checklist for YouTube: fixes on your origin, limits of cross-origin attribution, and how to prove the change with scheduled lab runs and field Core Web Vitals.

Why YouTube iframes drive CLS on publisher pages

Cumulative Layout Shift scores unexpected movement of visible content. When an article template injects a YouTube iframe without a reserved box, the iframe often starts at zero height (or a tiny stub) and expands when the embed document paints. Everything below the player (byline, related stories, newsletter forms) jumps. Readers notice. Field CLS moves. Lab Lighthouse flags the same pattern when the embed is in the viewport during the run.

Default oEmbed markup from many CMSs still pastes a bare iframe with width and height attributes that CSS then overrides to width: 100% without a matching height plan. The browser no longer knows the final box until the iframe layout settles. That is classic iframe layout shift: the parent document lacked a stable aspect ratio before the third party arrived.

YouTube is not uniquely broken. Maps, social posts, and ad slots fail the same way. YouTube is simply the most common video embed on publisher sites, so it shows up first in CrUX and PageSpeed Insights tickets. Treat it as a template problem first, not a “YouTube is slow” narrative.

What cross-origin changes for attribution and fixes

A YouTube embed loads from youtube.com or youtube-nocookie.com. Your page and the player document have different origins. Layout Instrumentation and debugging tools can show shifts that originate in the parent document (your slot collapsing or expanding). They cannot give you the same control over layout inside the iframe: you do not set the player’s internal CSS, thumbnail swap timing, or related-video rail.

Practical consequences for agency reports:

Symptom	Likely owner	Useful fix on your origin?
Content below the player jumps when the embed appears	Parent page (missing reserved space or late DOM injection)	Yes: aspect-ratio wrapper, facade, inject only into a sized box
Player UI rearranges inside the black box after click	YouTube document	No: you cannot style or pin internal player layout
Consent banner pushes the player and the article	Parent page + CMP	Yes: reserve banner space or place embeds after consent settles
Field CLS amber, lab green on a URL without the embed	Journey mix / other templates	Yes: align monitored URLs with embed-heavy templates

Say this plainly to clients: fix CLS video embed work on your stack means fixing the slot, not rewriting YouTube. If the reserved video box is stable and content below it does not jump, you have done the job the Core Web Vitals programme asks of the hosting page. Anything still moving inside the player is a different conversation, and usually out of scope for parent-page CLS tickets.

Reserve space: aspect-ratio wrappers that stop iframe layout shift

Google’s guidance on optimising Cumulative Layout Shift calls out embeds and iframes without dimensions as a primary cause. The durable pattern is a wrapper that always occupies the final video footprint before any iframe exists. That single habit removes most parent-page jumps caused by YouTube on article templates.

For standard landscape YouTube:

.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  max-width: 100%;
  background: #000;
  position: relative;
}

.video-embed iframe {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  border: 0;
}

The wrapper owns the height. The iframe fills the wrapper. When the third-party document paints late, the parent layout does not expand. Use youtube-nocookie.com when privacy and consent policy prefer cookies only after playback; CLS behaviour is the same either way.

Vertical Shorts and non-16:9 assets need their own ratio (9 / 16 or the true asset ratio). Mixing a 16:9 box with a vertical video still causes letterboxing or crop, which can look like a shift even when CLS maths stay calm. Match the ratio to the asset you ship.

Older “padding-bottom: 56.25%” hacks still work on browsers that lack reliable aspect-ratio support in your target set. Prefer aspect-ratio in modern templates: fewer magic numbers, clearer intent for the next developer who edits the component, and less fragile markup when nested flex layouts change. Keep the padding-bottom pattern only where you must support a documented legacy browser matrix.

CMS and oEmbed pitfalls

WordPress, Drupal, and many headless CMS pipelines replace a YouTube URL with iframe markup that ignores your design system. Audit the filter or block that runs oEmbed. Force the output through one shared component that always wraps the iframe. One component beats twenty article-specific fixes after each redesign.

If editors paste full iframe HTML into the body, teach a shortcode or block instead. Reserved space only helps when the wrapper is present in the initial HTML for above-the-fold embeds, or present before the lazy iframe is inserted for below-the-fold ones. Editorial training matters as much as CSS when freelancers paste oEmbed HTML from YouTube’s share dialog.

Facade and lite-youtube patterns for heavy embeds

A reserved iframe still downloads YouTube’s player shell when the iframe src is set. On article pages with several videos, that cost hits LCP, INP, and main-thread time even after CLS is fixed. The facade pattern shows a static thumbnail (with known dimensions) and a play control, then creates the iframe on user intent (click or keyboard activation).

web.dev’s guidance on efficiently loading third-party JavaScript points teams at facades for embeds that are not required for first paint. For YouTube specifically, Paul Irish’s lite-youtube-embed is the production-ready lite youtube embed component many teams adopt. It ships a thumbnail, play button, responsive sizing, and youtube-nocookie.com by default, with far less upfront JavaScript than a cold iframe. Use it when you want a maintained component rather than a one-off click handler.

Minimal facade sketch (illustrative; prefer a maintained component in production):

Keep the facade on the same aspect-ratio box you would use for the iframe. Swap inner content on activation; do not replace a sized box with an unsized iframe. Keyboard users need a real button (or equivalent) and a visible focus state. Screen reader labels must name the video, not “play button” alone.

Consent: if your CMP blocks YouTube until opt-in, the facade must respect the same gate. Loading the thumbnail from i.ytimg.com may still be a network call to Google infrastructure; align with legal and CMP configuration for your jurisdictions. After consent, inject the iframe into the already-sized box so CLS does not spike when the banner dismisses.

Lazy-load the embed without a late jump

loading="lazy" on iframes reduces early network work for below-the-fold videos. It does not reserve layout space by itself. Lazy without a wrapper is a common way to fix CLS video embed tickets that still fail: the iframe arrives later, then expands.

Rules we use on publisher templates:

Always pair lazy iframes with an aspect-ratio (or fixed-height) wrapper in the initial layout.
Prefer facades for multiple embeds; lazy alone still ships player JS when the iframe enters the viewport.
Do not inject the embed above existing content after first paint unless the slot was already reserved. Late injection near the top of the viewport is expensive for CLS.
If a cookie banner or newsletter bar inserts above the fold after load, treat that as a separate late-CLS problem. Diagnose early versus late shift patterns with the causes list in the CLS deep-dive; the calendar follow-up on late versus early CLS (post 77, due 8 September 2026) expands the field diagnosis workflow once it is live.

IntersectionObserver-based “warm” loading (create the iframe slightly before the slot scrolls into view) can help playback feel instant. Warm load into a reserved box only. Warm load into a zero-height node recreates the original shift.

Publisher CLS often blends three clocks: font and image shifts at load (early CLS), CMP and promo bars after hydration, and embeds that activate on scroll or consent. A YouTube facade that appears only after “Accept” will still shift the page if the accepted state inserts a full player into an unsized region under a newly taller banner. Separating those clocks in the ticket description keeps engineering from rebuilding the player when the banner is the real mover.

Checklist for CMP + embed pages:

Reserve space for the consent UI, or accept that field CLS includes banner shift and report it honestly.
Keep the video slot height stable across consent states (placeholder equals final player box).
Avoid moving the entire article column when the banner collapses; collapsing a tall banner into a thin bar is a classic late shift.
Reproduce in lab with consent granted and denied; field mixes both populations.

Agencies should label these as template + CMP issues in client decks, not as “YouTube broke Core Web Vitals” alone. That framing keeps engineering on the wrappers and consent layout you control. It also sets honest expectations when field CLS still moves slightly after the slot is fixed.

What you cannot fix inside the YouTube iframe

Be explicit in tickets and retainer reports so scope stays honest:

Internal player layout, control bar animations, and end-screen cards.
Related-video rails and annotation UI Google chooses to show.
Thumbnail-to-first-frame timing inside the player after the user presses play (interaction may still affect INP on the parent if your facade handler is heavy).
Third-party A/B tests YouTube runs inside the embed document.

You can choose privacy-enhanced hosts, modest query parameters the embed API documents, facade-vs-iframe trade-offs, and whether autoplay is allowed under your consent regime. You cannot promise a CLS of zero from pixels painted only inside YouTube’s origin. When field CLS remains slightly elevated on video-heavy URLs after slot fixes, check remaining parent-page causes (ads, fonts, injected related modules) before blaming the player.

How to verify YouTube embed CLS fixes in lab and field

Fixes without verification return as regressions after the next theme update. Use both lab and field instruments, then keep a scheduled check on the templates that actually embed video. A one-off Lighthouse screenshot in Slack is not a substitute for a budget that fires when oEmbed markup regresses.

Lab (PageSpeed Insights / Lighthouse / scheduled synthetic). Open the article URL with the embed in or near the viewport. Confirm the Performance trace no longer shows large layout shifts tied to the video node. Compare before/after on the same device class. Facades should show the thumbnail image as a normal LCP or contentful candidate rather than a cold iframe on first load.

Field (CrUX / RUM). Watch URL-level or template-level CLS over the rolling window after deploy. Embed-heavy article templates need their own monitored URLs; homepage-only schedules miss the regression. Pair CLS budgets with the thresholds in our performance budget thresholds template and schedule priority URLs with test frequency and portfolio priority.

Apogee Watcher. Schedule lab checks on the templates that carry YouTube blocks, set CLS budgets, and alert when a theme or CMS change reintroduces bare iframes. Layer Watcher beside any first-party RUM you already use. Do not rip out existing tooling to prove one embed fix; add a schedule on the URLs that matter.

Publisher checklist: ship the slot, then the player

One shared embed component with aspect-ratio (or true asset ratio) wrapping every YouTube instance.
Facade or lite-youtube for pages with more than one video, or any above-the-fold video that is not required for first paint.
Lazy or warm-load only into reserved boxes; never into zero-height stubs.
CMP and promo bars sized so consent state changes do not shove the player through the article.
Lab proof on embed URLs + field CLS on those URLs in the next CrUX window.
Document “cannot fix inside iframe” for client expectations.

FAQ

Does width and height on the iframe alone fix YouTube embed CLS?
Attributes help when CSS does not override them into an unknown height. Responsive CSS that sets width: 100% without a height plan still shifts. Prefer a wrapper with aspect-ratio and an absolutely positioned iframe that fills it.

Is lite-youtube-embed required?
No. Any facade that keeps a stable box and loads the iframe on intent can work. lite-youtube-embed is a maintained shortcut with accessibility defaults. Build in-house only if you will own focus states, labels, and consent hooks.

Will loading="lazy" on the iframe reduce CLS?
It reduces early work; it does not reserve space. Without a sized wrapper, lazy iframes often increase late CLS when they finally layout.

Why is lab CLS green but field CLS still amber on video articles?
Field traffic includes consent variants, slower devices, and templates your lab URL skipped. Align monitored URLs with real article templates and re-check after the CrUX window includes post-fix days.

Can I fix CLS caused by YouTube’s related videos inside the player?
Not from the parent page. Stabilise your slot; treat internal player UI as out of scope for parent-page CLS work.

Publishers who treat YouTube as a sized component, not a magic paste, recover CLS without arguing with a cross-origin player. Reserve the box, load the heavy iframe only after click or consent, keep consent layout honest, and monitor the URLs that actually embed video. If you want scheduled lab checks and CLS budgets across a portfolio of publisher sites, start a Watcher trial or run a free domain check.

References

Optimize Cumulative Layout Shift (web.dev)
Efficiently load third-party JavaScript (web.dev)
lite-youtube-embed (Paul Irish)
<a href="https://apog

When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Wed, 02 Sep 2026 22:12:54 +0000

Field Largest Contentful Paint in PageSpeed Insights can move while your release calendar stays empty. Chrome User Experience Report (CrUX) data is always a 28-day rolling average of real Chrome sessions. From Chrome 153 Stable on 8 September 2026, Chrome also moves to a two-week release cycle, so that same window can include more than one browser major with different paint and interaction behaviour. An amber field band after a quiet week is often population mix (who updated Chrome, which channel they use, how fast auto-update spreads), not proof that engineering shipped a regression on Tuesday.

We already separated pipeline lag from rolling-window lag in CrUX pipeline delays and late field data and explained why a verified fix can sit inside a green lab run and an amber field band in why your Core Web Vitals fix is not in CrUX yet. The gap here is the third clock agencies rarely label: browser release cadence inside the field window. When nobody deployed but field LCP drifts, you need release annotations on the same calendar as app, CDN, tag manager, and RUM changes, sample thresholds before you slice by exact Chrome major, and scheduled lab runs as same-week proof that the origin did not change.

Why field LCP can move when nobody deployed

CrUX and PageSpeed Insights field sections describe what real Chrome users experienced over roughly the past 28 days, not what your staging build measured yesterday. If the mix of Chrome versions, devices, networks, and journeys inside that window changes, the published p75 can move even when your HTML, CSS, and JavaScript bundles are byte-identical to last month.

Three non-deploy causes show up often in agency tickets:

Browser updates. A new Stable or Extended Stable channel release changes paint timing, image decoding, lazy-loading heuristics, or interaction scheduling for the same page. Users who auto-update mid-window contribute post-update sessions beside pre-update sessions in one aggregate.
Channel skew. Beta, Dev, and Canary users are a thin slice for most retail sites, but enterprise Extended Stable cohorts can lag Stable by weeks. A retail origin and a locked-down corporate audience can read different field bands on the same URL template.
Traffic mix. Campaign traffic, geography shifts, or seasonality change which templates dominate Chrome sessions. Origin-level field LCP can move when the homepage share of traffic falls while a slower category listing gains share, with no code change on either template.

Lab runs on a fixed URL answer whether your deploy changed the critical path. Field CrUX answers what Chrome users actually experienced across versions and journeys. Treating a field move as a deploy regression without checking browser and traffic mix sends engineering on a hunt for a commit that does not exist.

Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153

Google announced in March 2026 that Chrome will move from a four-week Stable cadence to a two-week cycle, starting with Chrome 153 Stable on 8 September 2026 (Chrome two-week release blog). Beta and Stable promotions arrive every two weeks on Desktop, Android, and iOS. Extended Stable keeps an eight-week cycle for enterprises that need longer validation windows (Chrome Enterprise Extended Stable).

The schedule compresses milestones quickly. Under the new table in Google's post, Chrome 153 Stable cuts on 25 August 2026 with public Stable on 8 September, while Chrome 154 Stable follows on 22 September. Firefox is running a similar experiment around Firefox 155 from 1 September 2026 (see community coverage linked from CSS Wizardry Web-Perf Wednesday 006). Performance teams that only annotated application releases in 2025 will need browser rows on the same calendar in 2026.

Release	Old four-week Stable (illustrative)	New two-week Stable (from Google table)
Chrome 153	Tue 22 Sep 2026	Tue 8 Sep 2026
Chrome 154	Tue 20 Oct 2026	Tue 22 Sep 2026

Smaller, more frequent browser releases are good for security and platform velocity. For field reporting they mean more opportunities for a 28-day CrUX window to span two majors with different Web Vitals behaviour, without any change on your origin.

How a 28-day CrUX window can span multiple browser majors

CrUX aggregates opted-in Chrome sessions into a rolling 28-day window. At any query, PageSpeed Insights and the CrUX API return a collectionPeriod with firstDate and endDate covering that blend (CrUX API documentation). The window advances daily: oldest day drops, newest day enters. There is no switch that flips the entire population to "only Chrome 153 sessions" on Stable release day.

Under a four-week browser cadence, one 28-day field window often covered one new Stable major plus tail versions. Under a two-week cadence, the same window can include two adjacent majors (for example 152 and 153) while auto-update propagates. Each major can shift LCP, INP, or CLS for the same URL because the browser pipeline changed, not because your LCP element or server timing changed.

Clock	What moves	Typical agency mistake
28-day CrUX window	Rolling average of Chrome sessions	Treating field p75 as "yesterday's score"
Chrome Stable cadence	Browser majors entering the window	Ignoring browser rows on the release calendar
App / CDN deploy	Origin HTML, assets, cache rules	Blaming deploys for browser-driven field drift
Lab schedule	Controlled PageSpeed Insights / Lighthouse runs	Expecting lab to explain field without dates

For metric definitions and why field percentiles behave differently from lab medians, start with our practical Core Web Vitals guide. For why lab and field are different instruments on the same URL, see synthetic versus real user monitoring.

Browser version in RUM: population mix vs a site regression

First-party Real User Monitoring (RUM) and CrUX answer different questions. CrUX is a public, privacy-thresholded view of Chrome traffic Google already collected. RUM is yours: you choose segments, retention, and alert rules. When practitioners search browser version RUM, they usually need to know whether a field shift is segment noise before they open a regression ticket.

Population mix means the aggregate changed because the audience composition changed: more sessions on Chrome 153, fewer on 152, a higher share of mobile on a slower network, or a campaign that sent traffic to a heavier template. Site regression means the same browser version and similar journey on the same URL got worse after your change (or after a third-party or CDN change you control).

Before you slice field data by exact Chrome major, set sample thresholds. Thin segments produce volatile p75 lines that look like regressions every week. Rules we use in client work:

Do not report URL-level p75 for a single Chrome major until you have enough sessions to trust the segment (exact cut-offs depend on traffic; treat very small counts as directional only).
Prefer unsegmented LCP, INP, and CLS as the headline series in retainer reports; use browser-major slices in appendix slides for engineers.
Compare like with like: same form factor, same URL or origin scope, same collection period dates.
Pair every segmented chart with an unsegmented line so leadership sees whether the whole population moved or only one slice.

Harry Roberts framed the risk clearly in Web-Perf Wednesday 006: faster browser releases change the RUM population you are averaging, not just the code on your server. Agencies that report "Chrome 152 LCP" and "Chrome 153 LCP" without sample sizes invite false escalations every Stable Tuesday.

Put Chrome Stable on the same calendar as deploys and CDN changes

Performance regressions are easier to debug when every graph annotation uses the same calendar. Most teams already mark application deploys, CDN cache rule changes, tag manager publishes, and major marketing releases. Browser Stable and Beta dates belong on that same timeline from September 2026 onward.

Checklist we ask account and engineering leads to maintain:

Chrome Stable and Early Stable dates for Desktop and Android (at minimum) through the next two milestones.
Extended Stable notes for clients with locked-down browser policies.
Firefox milestone dates when the site has meaningful non-Chrome share in RUM.
RUM or CrUX instrumentation changes (new snippet, different sampling, new soft-navigation handler).
Named owner who updates the calendar within one business day of a release (not "the platform team" in the abstract).

When field LCP moves in the weekly report, the first question is not "what did we ship?" but "what changed in the window: browser, traffic, CDN, tags, or code?" A single annotated timeline prevents the "nobody deployed" argument from turning into a trust fight. The ops checklist (release owner, browser rows beside deploy rows) is the agency ritual; the sections above carry the CrUX math and monitoring split.

Sample thresholds before you slice field data by Chrome major

Segmentation is useful after thresholds, not before. If Chrome 153 represents 4% of sessions in a 28-day URL-level slice, its p75 is not a client-ready KPI. Use thresholds to decide when a segment earns its own row in the report.

Segment type	When to show in client body	When to keep internal
Unsegmented origin or URL field p75	Always, with `collectionPeriod` dates	n/a
Mobile vs desktop field	When both pass eligibility	Thin desktop slice on mobile-heavy sites
Chrome major (e.g. M152 vs M153)	When each major has stable sample counts	Single-digit session majors
Beta / Dev channel	Rarely	Almost always appendix only

In first-party RUM, configure minimum session counts per segment before alerts fire. In CrUX-only workflows, respect Google's eligibility and popularity rules (CrUX methodology): missing URL-level data is often "not enough Chrome sessions," not a tooling failure. Say that explicitly in the report footnote.

Use scheduled lab runs as same-week proof when field CrUX drifts

Unsegmented field series are the executive headline. They answer "how are our users doing in aggregate?" without opening a statistics debate on Chrome 152.3 versus 153.0. Browser-major slices are diagnostic tools for engineers checking whether a shift correlates with a Stable release line on the calendar.

Scheduled lab runs provide same-week proof that the origin did not change:

Run PageSpeed Insights or Lighthouse on priority URLs on a fixed schedule (how to schedule PageSpeed monitoring across a portfolio).
Store run timestamps beside field collectionPeriod dates in the client-ready Core Web Vitals report outline.
If lab LCP and INP stay inside budget while field p75 drifts, investigate population mix and browser cadence before you roll back a deploy.
If lab and field move together after a deploy, treat it as a site change regardless of browser week.

Spot checks fail this test because Tuesday's paste and Thursday's paste are not a history. PageSpeed Insights versus automated monitoring is where we unpacked why portfolios need schedules, not heroic manual runs. Apogee Watcher holds that lab clock for multi-tenant teams: scheduled tests, budgets, alerts, and CrUX field numbers when Google returns them beside the same URL row. We do not replace first-party RUM segmentation. We keep lab verification repeatable while you interpret field drift.

Browser mix vs fix lag and CrUX pipeline delay: three lag types

Agencies confuse three lag types. Each needs a different sentence in the client deck.

Lag type	Cause	What the client sees	Primary doc
Rolling-window fix lag	Pre-fix sessions still inside 28 days after a deploy	Slow field improvement after a verified lab win	[Why your fix is not in CrUX yet](https://apogeewatcher.com/blog/why-core-web-vitals-fix-not-in-crux-yet-28-day-window)
Pipeline / publication lag	CrUX API, History, or BigQuery publish late	Same field values two days straight; missing weekly point	[CrUX pipeline delays](https://apogeewatcher.com/blog/crux-pipeline-delays-late-field-data-client-reports)
Browser population mix	New Chrome majors enter the window without a site deploy	Field moves while lab flat; shift aligns with Stable calendar	This post

Fix lag is about your sessions aging out. Pipeline lag is about Google's publish schedule. Browser mix is about whose Chrome sits inside an already-published window. A field LCP move with no deploy and flat lab budgets is often the third row, especially from September 2026 when two-week Stable releases overlap the 28-day average more often.

How agencies should monitor and report while browser mix shifts

From August through October 2026, expect more "false regression" tickets. Build the monitoring plan around dated clocks, not vibes.

Weekly field read with firstDate and endDate on every table row. No naked p75 without collection period.
Daily or thrice-weekly lab on money URLs through the Chrome 153 and 154 Stable window.
Release calendar with browser Stable rows visible to SEO and engineering, not only infra.
Executive one-liner in the retainer PDF: "Field CrUX is a 28-day rolling average of real Chrome users; browser Stable releases can move field bands without a site deploy; lab trends below are same-week origin verification."
Escalation rule: open a code regression when lab budgets break or when unsegmented field and lab move together after a deploy; investigate population mix when lab is flat and field drifts across a Stable line.

Portfolio teams scale this with per-client organisations, shared budget templates, and alerts that fire on lab thresholds even when field data lags. That is the layer Apogee Watcher adds on top of Search Console and whatever RUM vendor the client already pays for.

FAQ

Can Core Web Vitals change without a website update?

Yes. CrUX field metrics reflect real Chrome sessions over a rolling 28-day window. Browser updates, traffic mix shifts, and eligibility changes can move field p75 without any deploy on your origin. Lab runs on fixed URLs help prove whether the site changed.

How does Chrome's two-week release cycle affect CrUX data?

More frequent Stable releases mean a 28-day field window can include two browser majors with different performance behaviour. Field LCP or INP can shift as auto-update spreads, even when your code is unchanged. Annotate Chrome Stable dates on your release calendar from Chrome 153 onward.

Should I segment RUM by browser version after Chrome 153?

Segment when sample sizes support it, and keep an unsegmented headline series for clients. Thin Chrome-major slices produce noisy charts. Set minimum session thresholds before alerts or report rows use a single major.

Is a field LCP move a

Attention-Free Score: How Domain Reports Show Which Pages Need Work

Tue, 01 Sep 2026 08:56:00 +0000

We have updated how our domain-level reports work. A lot of users gave us feedback that the multi-page domain reports can list forty Lighthouse runs across mobile and desktop before they can track down the URL that actually needs work. Opening every strategy tab, scanning colour chips, and mentally counting failures does not scale when you run prospect scans, free-check funnels, or portfolio roll-ups for several clients in one week.

Apogee Watcher domain reports now open on a Summary tab by default. The headline answer is an attention-free score: the percentage of completed tests that pass every lab gate we track on that report. 100% means no test on either strategy still needs attention. Everything else on Summary is designed to show where to start before you drill into Mobile, Desktop, or Tested pages.

Why shared domain reports needed a Summary-first view

Domain reports roll up PageSpeed Insights / Lighthouse results from many URLs into one shareable link. That is the right format for agency prospecting, client readouts, and the public free domain scan. It is also easy to overwhelm: two strategies per page, four category scores, lab metrics, and grouped opportunities multiply quickly.

Single-URL PageSpeed Insights answers “how does this URL look right now?” Domain reports answer “which URLs on this host matter most after a batch run?” Those questions need different layouts. We kept the full Mobile and Desktop tabs for auditors who want every score card and opportunity list. We added Summary so you can answer “does anything need work, and where?” without tab hopping.

Summary is lab data only. It reflects the tests that finished on the report, not Chrome UX Report field history. Pair it with CrUX and field-data guidance when you explain trends to clients; use Summary when you need a fast lab triage pass after a scan or scheduled run.

Live example: apogeewatcher.com domain report Summary — 68% attention-free, with LCP as the top gap on blog and category URLs on mobile.

What the attention-free score measures

The attention-free score is the share of completed page tests (mobile and desktop runs counted separately) that pass all of the following gates on that test:

Gate	Threshold
Lighthouse Performance	≥ 90
Accessibility	≥ 80
Best Practices	≥ 80
SEO	≥ 80
Largest Contentful Paint (LCP)	≤ 2.5s
Cumulative Layout Shift (CLS)	≤ 0.1
Interaction to Next Paint (INP)	≤ 0.2s when present
Total Blocking Time (TBT)	≤ 200ms when INP is missing (lab fallback)

A test that fails any gate counts toward “needs attention.” A test that passes every gate counts as attention-free. The percentage is not an average of performance scores across pages. It is a strict pass rate across the full gate set, so a single weak CLS value on a product URL keeps that test out of the attention-free bucket even when Performance looks fine.

The headline beside the score states the same idea in plain numbers, for example “12 of 38 tests need attention.” Site status and top gap labels give a one-line severity read when the data supports it. Average Lighthouse Performance for mobile and desktop may appear under the score when those aggregates are available.

Pages, tests, and metrics on domain reports

Summary uses three terms consistently across the report header and coverage line:

Pages — URLs you selected for the run (or that discovery suggested).
Tests — Lighthouse runs. Each page tested on mobile and desktop counts as two tests when both strategies complete.
Metrics — measurements inside a test: LCP, CLS, INP, category scores, and supporting lab values.

We removed vague “sample” wording so report copy matches what agencies paste into emails and slide decks. The coverage line at the bottom of Summary reads like “19 pages selected · 17 pages with completed tests · 34 tests completed” so you can see whether failures come from missing runs or from real gate breaches.

What you see on the Summary tab

Open any shared domain report at https://apogeewatcher.com/reports/domain/{token} and you land on Summary (#summary). The tab bar still lists Mobile, Desktop, and Tested pages when you need the full strategy view.

On Summary you typically see:

Site status badge (pass, watch, or needs attention) and optional top gap label.
Attention-free score (percentage) with the headline count of tests that need work.
Dimensions needing attention — a fails-only scoreboard with mobile and desktop averages for metrics that are still outside good thresholds, plus how many tests fail each dimension.
What we found — short bullet findings and an optional recommended first action when the builder can infer one.
Top pages requiring attention — up to five rows with a Why column that names the failing metric and value (for example Perf (88%) or LCP (3.45s)), not a generic “poor” label.
Attention by page type — counts grouped by classification (product, content, checkout, and so on) so you can see whether failures cluster on templates.
Top opportunities merged across mobile and desktop — one row per Lighthouse theme with counts like “5 pages on mobile and 7 pages on desktop affected,” linking into both strategy tabs.
Coverage — pages selected, pages with completed tests, and tests completed.

PDF exports follow the same order: Summary first, then stacked mobile, desktop, and tested-pages sections. Tested pages tables use colour coding (red / orange / green) for quick scanning when you do open the full per-URL grids.

How lab gates relate to Core Web Vitals and Lighthouse categories

The gates mirror what many agencies already treat as “good enough for lab” on client reports, aligned with Core Web Vitals thresholds for LCP, CLS, and INP and with Lighthouse category scoring bands readers already see in PageSpeed Insights.

Performance ≥ 90 is deliberately stricter than “green” on some dashboards because domain reports are often used before a sales call or a sprint planning meeting. Accessibility, Best Practices, and SEO at ≥ 80 catch regressions that pure Performance scores hide, especially on content-heavy templates.

INP is evaluated when the lab run records it. When INP is absent (common on some URLs or tool versions), Total Blocking Time ≤ 200ms acts as the interaction proxy so mobile tests still have an input-responsiveness gate. That matches how teams read lab data when field INP is not yet available for a URL.

Summary does not replace performance budgets you configure inside Watcher for monitored sites. Budgets can fire alerts on your schedule. Summary gates are fixed on the report so every shared link speaks the same language.

Page-type breakdown and merged opportunities

When page classification is available, Summary groups attention counts by page type. On a commerce scan you might see product URLs failing LCP while blog posts pass Performance but fail SEO category gates. That pattern is hard to spot when URLs are sorted only by path.

Merged opportunity rows address another multi-tab pain point. The same Lighthouse audit (render-blocking resources, image delivery, unused JavaScript) often appears on both Mobile and Desktop tabs with different affected URL counts. Summary merges those into one theme row and links to both tabs so you do not double-count work when writing a fix brief.

Opportunity lists on Mobile and Desktop still show the full audit text, Chrome documentation links, and related Apogee Watcher how-to posts where we have a match. Summary is the map; the strategy tabs remain the detailed evidence.

Summary links for agency outreach and client reports

Agencies told us they wanted a single link that answers “what should we fix first?” without pasting four screenshots. Summary is built for that workflow.

Share https://apogeewatcher.com/reports/domain/{token}#summary in prospect email, Slack, or a client-ready report outline. Lead with the headline count and top gap, point to the top five pages table for specifics, and mention page-type concentration if the prospect runs a large catalogue site.

For monitored portfolios, generate domain reports from the site Reports tab after scheduled runs, then use Summary to decide whether this week’s deploy needs a full Mobile/Desktop review or can wait until the next scheduled test pass. The same Summary layout appears on free-check reports, lead prospecting runs, and customer site snapshots so your team does not relearn a different report shape per entry point.

We document the full August release in Changelog #12 (domain report Summary, lead classification, and discovery updates).

Where Summary appears in Apogee Watcher

Summary is on every public domain report served at /reports/domain/{token}:

Free domain scan — after /check completes, the emailed link opens on Summary.
Lead prospecting — domain reports you generate from a lead record use the same tab layout and page-type grouping on Tested pages.
Monitored sites — organisation members can generate customer domain reports from the site view; org members and sysadmin users can open expired share links when policy allows.

CrUX and field-history charts are not on Summary today. Phase B work may add field context beside lab gates later. For now, treat Summary as the lab triage layer and pull field series from PageSpeed Insights, CrUX Vis, or your scheduled monitoring history when the client conversation requires both clocks.

FAQ

What counts as one test in the attention-free score?

One completed Lighthouse run for one URL on one strategy (mobile or desktop). Ten pages with both strategies complete count as twenty tests.

Does 100% attention-free mean the site is perfect for users?

It means every completed test on the report passed all lab gates listed above. Lab scores can still differ from field Core Web Vitals on high-traffic URLs. Use field data for search and UX claims; use Summary for fast lab triage after a batch run.

Why might INP use Total Blocking Time instead?

Some lab runs do not emit INP for the tested URL. When INP is missing, we apply the TBT gate so interaction cost is not ignored on mobile tests.

Can I link directly to Summary?

Yes. Append #summary to the report URL. Mobile, Desktop, and Tested pages use #mobile, #desktop, and #pages.

How is this different from a single PageSpeed Insights URL check?

PageSpeed Insights focuses on one URL at a time. Domain reports aggregate many URLs and strategies, and Summary compresses that batch into one attention-free percentage and a short priority list.

Try Summary on your next domain report

Run a free domain scan on a client host, open the live apogeewatcher.com Summary example, or start any recent prospect report at #summary. Note the attention-free percentage, scan the fails-only scoreboard, and check whether failures cluster in one page type. Switch to Mobile or Desktop only when you need the full opportunity text.

If you already monitor sites in Watcher, generate a domain report from the site Reports tab after your next scheduled run and compare Summary against your performance budgets. Sign up free to save scans, schedule tests, and share reports without rebuilding the URL list each time.

References

CrUX Pipeline Delays: What Late Field Data Means for Client Reports

Thu, 27 Aug 2026 08:14:00 +0000

CrUX field numbers in a client report carry two dates most teams never write on the slide: when Google published the aggregate, and which 28 days of Chrome sessions sit inside it. PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, and BigQuery each refresh on a different schedule. Field Largest Contentful Paint and Interaction to Next Paint are always a rolling 28-day average on top of that schedule. Lab scores from a scheduled PageSpeed Insights run can turn green the morning after a deploy while the field band beside them stays amber for weeks. None of those contradictions mean the fix failed. They mean engineering, SEO, and the client are reading different clocks without labelling them.

Agencies lose retainer hours when those clocks get treated as one bug. Engineering trusts the lab trend; SEO trusts Search Console; the client trusts whichever PageSpeed Insights paste arrived in email first. Without a shared "field data as of" line, a routine CrUX pipeline delay reads like negligence. What follows separates pipeline lag (when Google publishes CrUX) from the 28-day rolling window (what CrUX averages once published), maps the Chrome UX Report update schedule across API, History, and BigQuery, and gives copy-ready footnotes for client-ready Core Web Vitals reports. For why a shipped fix can still sit inside a green lab run and an amber field band for weeks, see why your Core Web Vitals fix is not in CrUX yet. For where to read field history after the CrUX Dashboard retirement, see where to get TTFB, INP, and field history.

What CrUX data delay means for agency client reports

"CrUX data delay" shows up in two conversations that get mixed together in client Slack. The first is publication lag: Chrome User Experience Report (CrUX) data moves through Google's pipeline before it appears in PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, or BigQuery. The second is rolling-window lag: even when publication is on time, field percentiles describe roughly the past 28 days of real Chrome sessions, so a Tuesday deploy cannot rewrite Friday's field screenshot.

Client reports go wrong when those two lags are treated as one bug. A PageSpeed Insights field section that still shows last week's collectionPeriod end date is often a short pipeline or API refresh issue, not proof that users are still suffering pre-fix timings. A field band that barely moves for three weeks after a large fix is usually the rolling window doing its job, not a broken pipeline. Your report should name which lag you are discussing before you paste a number.

Lag type	What the client sees	Typical duration	What to cite in the report
Pipeline / publication lag	Same field values two days in a row; History weekly point missing	Hours to a few days; rare multi-day slips on weekly/monthly surfaces	CrUX release notes; `collectionPeriod` dates in PageSpeed Insights or API
Rolling-window lag	Field LCP or INP improves slowly after a verified lab win	Days to ~28 days depending on traffic and fix size	[28-day CrUX window](https://apogeewatcher.com/blog/why-core-web-vitals-fix-not-in-crux-yet-28-day-window); lab trend for same-week proof
Monthly BigQuery lag	SQL dashboards feel a month behind PageSpeed Insights	~5 weeks from collection month to second-Tuesday release	BigQuery `YYYYMM` table label; do not use for weekly client scorecards

Account managers do not need the full pipeline diagram. They need one sentence in the executive summary: field metrics are a rolling average of real-user Chrome data, refreshed on Google's schedule; lab metrics below are our same-week verification. That single line prevents most "your report is wrong" threads when CrUX is merely late, not wrong.

Chrome UX Report update schedule: daily API, weekly History, monthly BigQuery

Google publishes CrUX through several surfaces that update on different cadences. Teams that check only one surface often assume the whole ecosystem is broken. PageSpeed Insights field data and the daily CrUX API answer "what does field say this week?" CrUX History API and CrUX Vis answer "how has the trend moved over the past months?" BigQuery answers "what did the origin look like in March?" for analysts who accept monthly grain and query cost. Pick the surface that matches the question before you paste a number into a client deck.

According to Chrome's CrUX API documentation, the public dataset refreshes daily around 04:00 UTC on a best-effort basis with no fixed service-level agreement. Responses include a collectionPeriod with firstDate and endDate so you can see whether today's query returned a new aggregation window or the same window as yesterday. Chrome's docs also note that the API is typically about two days behind "today" in Pacific time, which is normal processing lag rather than a stalled deploy on your site.

The CrUX History API publishes weekly series: each point covers a 28-day window whose end dates are spaced seven days apart, with up to about 40 historical points. Weekly publication is aimed at trend charts in CrUX Vis and custom dashboards, not same-day deploy proof. CrUX on BigQuery releases on the second Tuesday of the month following each collection period, which is why BigQuery-only workflows feel like a month-long CrUX data delay even when PageSpeed Insights has already moved.

Surface	Update cadence	Best for client reports	Delay clients often misread
PageSpeed Insights field section	Daily (~04:00 UTC refresh)	Current origin/URL field p75 with collection dates	Rolling 28-day average, not yesterday's deploy
CrUX API (`queryRecord`)	Daily	Automated field snapshots; same `collectionPeriod` as PSI	~2-day processing lag behind calendar "today"
CrUX History API / CrUX Vis	Weekly (Mondays typical)	Trend slides in QBR decks	New weekly point missing after a holiday Monday
Search Console CWV report	Aligned with CrUX field base	SEO status badges clients already recognise	Same rolling window as PSI; not lab-on-demand
BigQuery `chrome-ux-report`	Monthly (second Tuesday)	Long-range origin analysis, custom SQL	Entire month feels "late" vs daily PSI

When you build a client-ready Core Web Vitals report outline, put daily or weekly field numbers in the scorecard and relegate BigQuery charts to appendix slides for analysts. Mixing monthly SQL exports into a weekly status email is how agencies accidentally tell a client their site regressed when PageSpeed Insights field data had already turned green.

Why CrUX pipeline delays happen beyond the rolling window

The 28-day rolling average is predictable. CrUX pipeline delays are the extra slips: processing backlog, holiday staffing, connector outages on legacy Looker paths, or incidents that delay a weekly History release while the daily API still updates. Google's CrUX release notes are the authoritative place to check whether a missing weekly point is your origin or the whole dataset. The May 2026 notes, for example, mention a slight delay to the weekly CrUX History API and CrUX Vis release that was resolved separately from the monthly BigQuery publish.

Pipeline incidents are not the same as "my fix did not work." During a History API slip, CrUX Vis may show a flat line for one week while PageSpeed Insights field sections still advance their collectionPeriod end date on schedule. During heavy monthly release weeks, teams that relied on the retired CrUX Dashboard connector sometimes saw monthly bars pause even though the API moved. After the CrUX Dashboard retirement, those connector failures are less common, but weekly and monthly surfaces still batch work differently than the daily API. A report that mixes a Monday lab run with a weekly History chart and no dates on either axis will look inconsistent even when Google published everything correctly.

Low-traffic URLs add a different kind of delay that looks like a pipeline fault. CrUX omits URL-level field data when sample sizes are too thin, and PageSpeed Insights may show origin-level field bands while the URL you changed stays empty. That "no data" state can persist across daily refreshes until enough Chrome sessions accumulate. It is eligibility and popularity filtering, not a stuck ETL job. Google's CrUX methodology documents discoverability and popularity rules. Your footnote should say URL-level field data not available; origin-level field shown when that is what the tool returned. Holiday weeks add the same confusion: a report drafted on the Tuesday after a long weekend may pair a fresh lab run with a History chart whose endDate still ends on the previous Saturday because the weekly job has not published yet.

In our experience, the CrUX Google Group threads that age badly inside agencies are the ones where nobody wrote down which surface was checked. Standardise on PageSpeed Insights or the daily API for current field and CrUX Vis for trend. When a weekly point is missing globally, link the release notes in the report caption so the client sees you checked for a pipeline slip rather than ignoring a regression.

How late CrUX field data affects client Core Web Vitals reports

Late field data changes the story in client reports even when engineering already closed the ticket. Checkout field Interaction to Next Paint can stay amber while the rolling window is only halfway through shedding pre-fix sessions. Origin field Largest Contentful Paint can look green while the product listing URL the client cares about never earns URL-level CrUX. A weekly trend chart can sit flat for one publication cycle because History API ran late, so leadership assumes performance work stalled. Each pattern needs its own sentence in the report, not a generic "CrUX is slow" disclaimer.

Search Console status badges trail the same CrUX base as PageSpeed Insights field data. A Needs improvement label in week one after a deploy is expected when the rolling window still contains mostly pre-fix traffic. Clients who treat Search Console as a real-time monitor will forward screenshots that contradict your lab appendix unless you date both artefacts and explain that Search Console updates on CrUX's schedule, not on deploy day.

Executive summaries that only cite field numbers make pipeline delays look like negligence. If the headline says mobile LCP is still 3.1s without field data through 9 Aug and lab homepage 2.3s on 12 Aug runs, the client will compare your PDF to their own PageSpeed Insights paste from a different collectionPeriod. Trust breaks fast. One dated footnote fixes most of that.

Trend slides built only from BigQuery or weekly History can miss a step change that daily PageSpeed Insights already shows in the collectionPeriod end date. Daily API checks without History miss slow drifts that only become obvious across six weekly points. Multi-site portfolios amplify the noise: one client's field data updates on schedule while another's URL never earns CrUX eligibility, and a portfolio table without per-row collection dates looks like you ignored a site when the pipeline returned no data legitimately.

The operational fix is to treat field metrics as dated lagging indicators in every client-facing table and lab metrics as scheduled verification with run timestamps. That split matches how we described lab versus field clocks in synthetic versus real user monitoring and in PageSpeed Insights versus automated monitoring. Field answers what Google will eventually show in search tooling. Lab answers whether your release is healthy on the URLs you monitor.

How to annotate client reports with field data collection dates

Every field number in a client report needs a collection window beside it. PageSpeed Insights has displayed collectionPeriod dates since late 2024; the CrUX API has exposed firstDate and endDate since 2022. If your report omits them, the client will supply their own assumed "as of today" date when they re-test.

Add these elements to the scorecard and executive summary from our client report template:

Executive summary footnote (copy-ready):

Field Core Web Vitals below are 75th-percentile values from Google's Chrome UX Report, averaged over a rolling 28-day window. Collection period: {firstDate} to {endDate} (source: PageSpeed Insights / CrUX API). Lab scores are scheduled PageSpeed Insights Lighthouse runs on {run dates} on the URLs listed in the appendix.

Scorecard column headers:

Metric	Mobile field (CrUX p75)	Mobile lab (scheduled)	Collection period (field)	Last lab run
LCP	2.8s	2.1s	15 Jul to 11 Aug 2026	12 Aug 2026

Trend chart caption:

Weekly points: CrUX History API (28-day windows ending Saturdays). If the latest weekly point is missing, check CrUX release notes for pipeline delays before interpreting a flat line.

When field and lab disagree, use a single explanatory line rather than a paragraph of theory:

Field LCP remains amber because CrUX still includes sessions from before the 4 Aug image fix. Lab LCP on the same URL has been below 2.5s on daily scheduled runs since 5 Aug. We expect field to follow as older sessions roll out of the window.

When CrUX returns no URL-level field data, state what you showed instead:

URL-level CrUX data is not available for /checkout (insufficient Chrome traffic). Origin-level mobile LCP is shown below; lab monitoring covers /checkout directly.

Account managers can paste those lines without opening the CrUX API. Technical leads should store firstDate, endDate, and lab run timestamps in the same spreadsheet or monitoring export you already use for multi-site portfolios, so the dates are not retyped by hand each month.

Use synthetic monitoring while CrUX field data is late

Pipeline lag and rolling-window lag both create a gap between deploy and field proof. Synthetic monitoring fills that gap with scheduled lab runs on the URLs you choose, on a clock you control. It does not replace CrUX for Search Console or PageSpeed Insights field reporting. It gives the client something credible to read while Google's publication schedule and 28-day average catch up.

A practical agency workflow during a CrUX delay week:

Baseline before change. Capture mobile and desktop lab LCP, INP, and CLS on priority URLs, with run dates stored alongside any field collectionPeriod you quote.
Increase schedule frequency on touched URLs for two weeks after deploy (daily or every two days on checkout and homepage, weekly on long tail), matching the priority model in how to schedule PageSpeed monitoring.
Set lab budgets and alerts so a regression during the wait still notifies someone, using thresholds from a shared performance budget template.
Check field once per week, not every morning. Note whether endDate moved and whether release notes mention a global History API delay.
Ship the client report with both clocks labelled. Lab trend proves the release; field dates prove you are not hiding behind a stale screenshot.

Apogee Watcher runs that split for multi-tenant teams: scheduled PageSpeed Insights-backed lab tests across many client sites, CrUX field numbers when Google returns them beside the same run, budgets and alerts while field data lags, and organisation-level views so agencies are not pasting PageSpeed Insights links into separate spreadsheets per client. We do not shorten Google's pipeline or replace first-party real-user monitoring. We give you a repeatable lab clock next to the field clock Google publishes, layered onto the SEO and observability tools you already use.

<a href="https://

Changelog #11: Paid plans, multi-org dashboard, and page classification

Tue, 25 Aug 2026 08:37:00 +0000

In July, we delivered self-serve billing, rebuilt the customer dashboard for agencies that juggle several client organisations, and added two workflows that had been stuck behind support tickets: newsletter opt-in on My Account and email invitations for new team members. We also started classifying discovered URLs by page type so large site inventories are easier to filter before you set budgets or alerts.

Changelog #10 capped how many organisations a plan can hold; this release connects those limits to checkout, team invites, and a dashboard that shows usage across every organisation you belong to. This release covers the following areas for customers.

Paid plans now generally available

We have opened subscriptions beyond our beta testers. Organisation admins can start checkout from the pricing page or from My Account > Subscriptions. Guests on the pricing page still see Sign up with the same message as before: start on Free without a credit card, upgrade when you are ready. Secure payments and invoicing go through Dodo Payments, so expect to see their branding in our checkout and invoices.

For users on a subscription plan, the pricing page allows both upgrading and downgrading your plan. Managers and Viewers who start checkout without an admin workspace get a new organisation provisioned for them automatically so billing has somewhere to attach; they become Admin of that workspace before payment completes.

Past-due subscriptions keep access while billing is unresolved, but My Account shows a Fix billing action that opens a payment-method update flow at Dodo without creating a duplicate subscription row. Only organisation admins see upgrade and fix-billing actions; other roles use the plans page for reference only.

The Plan & Usage widget on the dashboard shows the target plan name with a confirming message instead of reverting to the old tier. Both views poll every few seconds until the change clears. If processing stalls, stale pending state clears after 15 minutes so the UI does not show a phantom upgrade indefinitely.

Subscription cards on My Account list plan name, status (active, past due, cancelled, or ended), primary organisation, and the limits you care about day to day: organisations, sites, team members, and tests per month, with start and end dates where they apply.

Multi-organisation dashboard

In the dashboard, the older single-organisation summary cards are replaced by three quick-summary widgets, each with one row per organisation you can access:

Sites & pages — organisation name, site count, and active page count.
PageSpeed — tests in the last 30 days, failed tests, average score (colour-coded), and open alerts.
Team — organisation name, your role in that organisation, and active member count.

On wider screens each widget uses a scrollable mini-table so a long client list does not stretch the page. On mobile the same numbers appear as stacked cards. If you have no organisations, the widgets show a plain empty state.

Plan & Usage and API Usage still aggregate at account level across every organisation you admin, because subscription and API quotas apply to the billing account, not a single client organisation. That matches organisation limits from Changelog #10: you see per-organisation delivery stats in the quick summaries and account-wide caps in plan usage.

Latest test results and System updates remain on the dashboard below the PageSpeed widget.

We will soon start sending product updates and selected blog posts by email. Until July you could opt in at sign-up, but changing your mind meant a support message. My Account now has a Newsletter section on the read view with a Subscribed or Not subscribed badge and a pointer to Edit Profile.

On Edit Profile, the Newsletter block explains what you are signing up for and offers a single checkbox: subscribe to product updates and tips, unsubscribe at any time. If your account is in read-only mode because billing is past due, newsletter preferences are locked until the subscription is renewed. The footer on the public site still states that email is used for registration and opted-in updates only.

Page type classification for site pages

Discovery can add hundreds of URLs to a commerce or publisher site. Reporting and alerts are easier when you can separate product pages from blog posts without exporting to a spreadsheet. Discovered URLs can now be classified into page types such as homepage, category or listing, product detail, cart, checkout, account, search, content or blog, FAQ or help, contact, about, legal, landing or campaign, and a catch-all Other.

Classification runs when a page is first created or when its URL changes. Global URL rules are checked first; if none match, keyword heuristics fill in. Each page stores a type label, a source (global rule, heuristic, manual, or unknown), and a confidence score you can inspect on the page detail view. If you set a type manually, automatic re-classification skips that row until you clear the override.

On the site Pages list, a Page type column shows a badge or Unclassified. The default view groups rows by type so you can collapse whole sections. Filters cover page type, classification source, and whether the row is still unclassified. From a row action you can Re-classify to queue a fresh pass (hidden when the page was classified manually). The edit form lets you pick a type from a dropdown with helper text: leave empty for auto-detect, or choose a value to override.

The point is operational: an agency monitoring a shop can filter to product URLs before setting a performance budget, or exclude checkout and cart paths from a bulk test run. Labels are a starting point; you can correct odd matches per URL without turning off auto-classification for the rest of the site.

Email team invitations

Adding a colleague used to mean sharing credentials or asking us to provision an account. Organisation Admins can now invite by email from Team Members. Managers can invite Viewers only. Viewers cannot send invites. Free plans cannot add team members; paid plans enforce the team member cap across all your organisations, the same way organisation caps work on the subscription.

The invite form asks for email and role (Admin, Manager, or Viewer). Watcher sends an email with an accept link that expires after 30 days. No membership row is created until the invitee accepts. Admin invites to a new organisation also respect the organisation cap from Changelog #10.

What to try

On the pricing page, open a plan above Free and walk through checkout as an organisation admin. On My Account and the dashboard Plan & Usage widget, watch how pending checkout state behaves before limits update.

On a site with many discovered pages, group by page type, filter to Unclassified, and re-classify a few URLs to see how rules and heuristics label them. Override one product URL manually and confirm Re-classify disappears for that row.

From Team Members, invite a colleague as Admin or Viewer (depending on your role) and accept the email on a fresh or existing account to verify the cap and verification checks.

August work continues on help-centre docs and broader billing rollout.

References

Treo vs Apogee Watcher: CrUX Scale, Competitor Benchmarks, and Agency Portfolios

Mon, 24 Aug 2026 09:02:00 +0000

After the CrUX Dashboard and Looker Studio report retired, many teams rebuilt their field-data workflow from PageSpeed Insights, Search Console, and third-party CrUX explorers. Treo is one of the products agencies shortlist when they want CrUX at portfolio scale without writing BigQuery jobs. Apogee Watcher addresses a related but different bottleneck: keeping scheduled lab checks, budgets, and alerts aligned across many client sites when URL lists change every sprint.

Both products show lab and field context. Both matter to agencies. The decision is usually workflow fit, not which logo wins a feature grid. Below we compare Treo and Watcher on CrUX depth, competitor views, multi-site operations, and price bands. Figures change; verify limits on Treo pricing and Apogee Watcher pricing before you buy.

What Treo is built for: CrUX scale and competitor benchmarks

Treo markets itself around the Chrome User Experience Report: raw field data, historical trends, connection and country breakdowns, and competitor comparisons without standing up your own BigQuery pipeline. Public materials emphasise large CrUX URL budgets (from dozens on the free tier to five figures on Scale and Enterprise), multi-year retention, and views that go beyond the p75 snapshots many free tools show.

That positioning matters when your brief is field exploration at scale:

You need hundreds or thousands of URLs in CrUX with history, not just origin-level Search Console summaries.
You want to chart competitors beside your client on LCP, INP, or CLS using the same CrUX source.
You export or API-pull field series into your own reporting stack (paid tiers).

Treo also adds scheduled Lighthouse monitoring on paid plans, with tiered page counts and frequency trade-offs (for example, hourly checks consume more capacity than eight-hour cadences). The free tier is CrUX-only: useful for evaluation, not for lab regression alerts across a retainer.

The screenshot above is from Treo’s public product pages: connection mix by geography on a world map, one of the views teams use when they explain field data to stakeholders who will never open BigQuery. If your job is “show me five years of CrUX for this URL set and my competitors,” Treo is aimed at that job.

For where CrUX still lives inside Google’s own surfaces after dashboard retirement, see CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History.

What Apogee Watcher is built for: a web performance monitoring tool for agency portfolios

Apogee Watcher is a multi-tenant pagespeed monitoring platform built for agencies. We run scheduled tests through Google’s PageSpeed Insights API, which returns Lighthouse lab metrics plus CrUX field slices where Google publishes them for the tested URL. We emphasise organisations, sites, roles (Admin, Manager, Viewer), automated page discovery from sitemaps and crawl paths, performance budgets, and email alerts when thresholds breach.

We do not offer Treo-scale CrUX URL inventories or built-in competitor benchmarking boards. We do not replace a CrUX explorer when your primary question is “how does this competitor’s field INP trend over three years on five hundred URLs?”

We are strong when:

You manage many client properties and need scheduled lab coverage without maintaining separate spreadsheets per site.
Discovery must catch new templates and campaign landers before someone remembers to add URLs manually.
Account managers need read-only access without touching API quotas.
Entry price and predictable tiers matter for monitoring as its own retainer line.

Setup patterns and discovery behaviour are in Getting Started with Apogee Watcher: A Step-by-Step Setup Guide. For how synthetic schedules relate to field proof, pair with When to Use Synthetic vs Real User Monitoring for Performance.

Treo vs Apogee Watcher: CrUX monitoring tools compared

Use this table as a decision grid, not a scorecard. Confirm numbers on each vendor site.

Topic	Treo (typical positioning)	Apogee Watcher
Primary strength	CrUX URL scale, history, competitor benchmarks	Multi-site scheduled PSI monitoring, discovery, agency RBAC
Test engine	CrUX-native; Lighthouse on paid tiers	PageSpeed Insights API (Lighthouse lab + CrUX where available)
CrUX URL budgets	50 free; 1K–20K+ on Vital–Scale; 50K+ Enterprise	Per-URL CrUX via each PSI result; no competitor boards
Competitor benchmarking	Built into product narrative	Not a core feature
Data retention (public FAQ)	Unlimited historical access via UI/API	30–365 days by plan (confirm on pricing)
Team members	5–50 on paid tiers	Unlimited on published tiers
Entry paid pricing	Vital from $75/mo (CrUX + Lighthouse)	From $9/mo Personal through $199/mo Agency
Free tier	50 CrUX pages; no Lighthouse	Free tier available (confirm current limits)
API	Pro tier and above	Product API focus differs; confirm live features
Best day-one use	Field exploration, competitive charts, large CrUX lists	Portfolio lab monitoring without per-client instrumentation

Treo’s paid entry at $75/mo reflects CrUX infrastructure and history, not a stripped-down lab runner. Watcher’s lower entry reflects a different scope: scheduled synthetic monitoring and agency workflow, not five-figure CrUX URL catalogs.

Broader tool taxonomy (where Treo sits beside GTmetrix, DebugBear, and PSI) lives in Comparing PageSpeed Monitoring Tools: Features Agencies Need. For another premium synthetic comparison with optional RUM, see DebugBear vs Apogee Watcher: Synthetic Monitoring for Multi-Site Teams.

When Treo is the better primary choice

Favour Treo when CrUX is the product, not a sidebar on lab reports:

Competitive narratives: Monthly reviews that compare your client to named competitors on Core Web Vitals using the same CrUX source.
Large URL lists in field data: Category or marketplace sites where you must monitor hundreds of URLs in CrUX, not ten hero routes in lab only.
Long historical arcs: Multi-year trends for leadership decks; Treo’s marketing emphasises five-year history and unlimited retention in FAQ materials.
Export and API: Pro/Scale customers pulling JSON series into BI tools without maintaining BigQuery pipelines.

If first-party RUM on the client origin is also non-negotiable, Treo still is not a RUM vendor; you would add analytics or a RUM product separately. PageVitals vs Apogee Watcher covers a different RUM-first angle for WordPress-heavy stacks.

When Apogee Watcher is the better primary choice

Favour Watcher when the retainer is “keep these URLs inside budget and tell us when a deploy regresses”:

Many sites, modest field ambition: You need lab schedules and CrUX context on priority URLs, not a five-thousand-row CrUX inventory on day one.
URL churn: Marketing publishes routes faster than spreadsheets update; discovery reduces stale monitor lists.
Role separation: Managers tune budgets; viewers read dashboards; admins own billing without sharing one login.
Cost at scale: Monitoring line items must survive procurement at ten to thirty sites; entry tiers matter.

Watcher does not try to win on competitor benchmarking charts. We try to win on operational coverage: the same URLs tested on a cadence, with alerts that reach a human. Manual PSI rituals stop scaling long before CrUX URL math becomes the bottleneck; that case is in PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

Layer Treo and Watcher instead of forcing one vendor

Many agencies split roles:

Treo for field exploration, competitor slides, and CrUX-heavy discovery when a client asks “how do we compare in the market?”
Watcher for scheduled lab monitoring, budgets, and regression alerts across the whole portfolio.

That is the same layer-don’t-replace principle we use elsewhere: add CrUX exploration beside synthetic monitoring; do not pretend one subscription replaces both jobs. A team can run Treo on strategic URL sets and Watcher on every retainer property’s priority routes without duplicating work if roles are explicit in the SOW.

Neither tool replaces Search Console’s CWV report or one-off PSI checks before a sponsor call. Keep those; assign each tool a named owner in the runbook.

FAQ

Can Apogee Watcher replace Treo for large-scale CrUX work?

They overlap on “performance monitoring” but optimise for different questions. Treo is the stronger fit for large CrUX exploration and competitor benchmarking. Watcher is the stronger fit for multi-tenant scheduled PageSpeed monitoring with discovery and agency roles. Many teams use both.

Does Apogee Watcher replace Treo’s CrUX history?

No. Watcher shows CrUX where PSI returns field data for each tested URL and stores lab history for trends and alerts. It does not replicate Treo-scale CrUX URL budgets or competitor boards.

Can I start on Treo’s free tier and add Watcher later?

Yes. Treo’s free plan (50 CrUX pages, no Lighthouse) suits evaluation of field views. When you need scheduled lab checks across many client sites, add Watcher rather than stretching Treo’s Lighthouse limits alone.

Which tool is cheaper for an agency with twenty sites?

Compare total cost with your URL counts and roles, not headline price alone. Watcher’s published tiers start lower; Treo’s Vital plan at $75/mo includes CrUX and Lighthouse capacity you may not need on every retainer. Run the maths for CrUX pages, Lighthouse pages, seats, and retention you actually use.

Do either tool replace BigQuery CrUX exports?

Treo abstracts BigQuery for dashboard and API users. Watcher does not. If you need custom SQL across the public dataset, you still use BigQuery or a vendor built for that scale; see our CrUX replacement guide linked above.

If you want scheduled PageSpeed checks across client sites with budgets and discovery, start from pricing or run a free domain check. If your brief is CrUX competitor charts at thousands of URLs, evaluate Treo on its own terms and layer monitoring where lab cadence still matters.

References

TTFB Won't Go Down? Server-Side Culprits Beyond the Theme

Sun, 23 Aug 2026 10:02:00 +0000

You moved the site behind a CDN, trimmed the theme, deferred scripts, and ran a caching plugin. PageSpeed Insights still flags a high Time to First Byte on the homepage, and the waterfall shows most of the wait in Waiting (TTFB) rather than DNS or TLS. The next ticket proposes a bigger hosting plan; in our experience that upgrade often treats the symptom while the origin keeps doing too much work per request, or background jobs steal capacity when real visitors arrive.

What follows is a server-side checklist for WordPress and PHP stacks when you need to reduce TTFB after delivery-layer fixes. We focus on origin compute and scheduling: cron, workers, cache, database, and maintenance plugins. For DNS, TLS, HTTP, and CDN cache rules, start with Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. For cases where application code beats infrastructure, see Why Your WordPress Site Is Slow (It Is Not Always Hosting).

When slow server response time is not a theme or CDN problem

Lighthouse and PageSpeed Insights label high first-byte time as Reduce initial server response time. The diagnostic measures how long the browser waits after the request leaves the client until the first byte of the HTML response arrives. When DNS, connect, and TLS are already short, the remaining delay is almost always origin processing: PHP execution, database queries, remote API calls inside the page build, or contention from other jobs on the same machine.

That pattern is common on WordPress sites that look optimised in the front end but still regenerate HTML on every uncached hit. A page cache can hide the problem until a cache miss, a logged-in session, a cart cookie, or a query-string variant bypasses the edge, so your lab test shows a high TTFB while marketing reports “the CDN is on.” Treat those misses as the path that matters, not the cached marketing homepage.

Symptom in lab or RUM	Likely layer	First place to look
High Waiting, low DNS/TLS	Origin PHP / app	Object cache, query count, cold workers
Spikes at the top of each hour	Scheduled tasks	WP-Cron, backup, search indexers
Slow only when editors are logged in	Uncached admin bar / personalised HTML	Page cache exclusions, admin-ajax
Slow on `/?` and `?nocache=1` only	Full page cache working elsewhere	Origin path above
Slow after deploy, fine after warm-up	Cold opcode / PHP workers	OPcache, worker count, warm scripts

If your waterfall still shows long DNS or TLS phases, fix the network stack first; the sections below assume those hops are already reasonable.

How WordPress WP-Cron inflates time to first byte

WordPress schedules many tasks through WP-Cron, which is not a system daemon. On default setups, wp-cron.php runs on page requests: a visitor or bot triggers due jobs before WordPress serves the page they asked for. Heavy plugins add hooks for imports, sitemap builds, newsletter sends, and housekeeping that can run for seconds on shared hosting, which is why support threads about WordPress TTFB and cron keep resurfacing. A backup finishing at 09:00, a search indexer at :15 past the hour, and a security scan at :30 can stack into the same traffic window, so editors notice the site feels slow while cron owns the CPU.

Practical fixes, in order of leverage:

Disable request-driven WP-Cron in wp-config.php (define('DISABLE_WP_CRON', true);) and trigger wp cron event run --due-now from system cron on a fixed interval (every five or fifteen minutes, not on every page view).
Audit scheduled events with wp cron event list (WP-CLI) or a cron inspector plugin in staging. Remove or reschedule plugins that register hourly full-table scans on production.
Stagger plugin schedules so backup, analytics aggregation, and link checkers do not share the same minute.
Run long jobs off-peak in the site’s traffic timezone, not the agency’s office hours.

After changes, compare TTFB on the same URL at :05 and :55 past the hour; if the spread collapses, cron was the culprit rather than the theme or CDN.

PHP workers, opcode cache, and origin saturation

Even with clean cron, each uncached HTML request needs a PHP worker to execute WordPress. On FPM pools with few children, a burst of concurrent visitors queues behind a small worker count, and cold workers (first request after idle, or after deploy) pay bootstrap cost: loading WordPress core, autoloaded options, and dozens of plugin files before your theme renders one line. The checklist below covers the worker and opcode issues we see most often on agency WordPress stacks.

Checklist for worker and opcode issues:

OPcache enabled with enough memory and validate_timestamps tuned for your deploy flow (revalidate in dev; stable in prod).
Realpath cache and sensible pm.max_children for traffic (too low queues; too high can exhaust RAM and swap).
Separate pools for admin, AJAX, and front-end when the host allows it, so admin-ajax.php storms do not starve public pages.
Warm critical URLs after deploy (homepage, top landing pages, cart) before announcing release.

Origin saturation also appears when the same server runs mail, staging sync, or backup restores alongside production. Slow server response time in that case is capacity planning, not a tweak to a single plugin, but right-sizing workers and separating batch work often beats doubling CPU without touching cron or object cache.

Database load, object cache, and N+1 queries on uncached requests

WordPress without a persistent object cache hits the database for autoloaded options, post meta, and taxonomy on nearly every request. Plugins that add large autoload rows or run wide queries on init multiply that cost, and page builders with dynamic blocks can trigger N+1 query patterns when a single template loads dozens of posts or meta keys per view. Those queries run before the first byte leaves the server, so they show up directly in Waiting time rather than as a front-end script problem.

Signs the database is dominating TTFB:

Query Monitor (staging) shows hundreds of queries on the homepage.
wp_options autoload size is megabytes (transients and plugin settings that never clean up).
Slow query log spikes on wp_postmeta, wp_options, or custom tables from analytics plugins.

Mitigations that actually move first byte:

Issue	Fix
No object cache	Redis or Memcached with a drop-in (`object-cache.php`)
Fat autoload	Audit `autoload=yes` options; remove stale plugin rows
N+1 in theme or plugin	Batch queries, lazy load blocks, or cache fragment output
Missing indexes on custom tables	Add indexes in staging; measure before prod
Remote HTTP inside `the_content` filters	Remove or cache API responses with short TTL

Object cache does not replace a full-page cache, but it cuts origin work on partial misses and logged-in routes, so pair database wins with Performance Budget Thresholds Template on templates that must stay dynamic (checkout, account, enrolment).

admin-ajax storms, backup plugins, and maintenance during peak

Two other WordPress-specific patterns keep server response time high without touching the theme CSS. admin-ajax.php handles heartbeat, cart fragments, live search, and page-builder autosaves; a misconfigured plugin polling every few seconds from the front end can keep workers busy and add latency to unrelated pages on small pools. In staging, watch access logs for admin-ajax.php volume during a normal editor session, disable heartbeat on the front end where safe, fix plugins that hammer AJAX on public pages, and rate-limit bots that target wp-login.php and AJAX endpoints.

Backup and migration plugins (UpdraftPlus, Duplicator, All-in-One WP Migration, and host scheduled snapshot tools) can lock tables or saturate disk I/O during business hours. Schedule backups when analytics show the lowest concurrent users, not at local midnight on the server if that is peak in the site’s country, and test restore windows separately from performance testing because a backup run is not a deploy. Security scanners and link-checker plugins that crawl the whole site on cron belong in the same bucket: if TTFB spikes line up with their schedule in the cron list, move or throttle them before buying hardware.

How to verify TTFB fixes without guessing

Use the same priority URL and device profile before and after each change. In WebPageTest or Chrome DevTools, confirm Waiting shrank while DNS and SSL stayed flat, and run at least twice: once during a quiet minute and once when cron used to fire. For WooCommerce and membership sites, repeat on cart and checkout URLs, not only the homepage.

Scheduled PageSpeed monitoring catches regressions when a plugin update re-enables request-driven cron or adds autoload bloat. PageSpeed Insights versus automated monitoring explains why one-off lab pastes miss hour-of-day effects, while field TTFB in CrUX moves on a 28-day window and lab TTFB on your uncached path tells you whether today’s origin fix worked. Document what you changed (cron mode, object cache, backup window) in the client runbook so the next agency does not optimise the theme again while the server still runs fifty due cron events at noon.

FAQ

What is a good TTFB for WordPress?

There is no single magic number. Google’s optimize TTFB guidance treats sub-800 ms as a reasonable target for the HTML document on the network path you control, and stricter shops aim lower on cached marketing pages. Compare your origin miss path, not only the CDN hit, because a fast edge response on a cached homepage can hide a slow uncached checkout.

Does a CDN always reduce TTFB?

No. A CDN lowers TTFB on cache hits, but on misses HTML still builds at origin. Fix origin compute first if misses are common or if personalised cookies bypass cache, because a green Lighthouse score on the cached homepage will not help checkout.

Should I disable WP-Cron on every site?

For production sites with real traffic, system cron plus DISABLE_WP_CRON is the usual best practice. Keep request-driven cron only where you cannot schedule CLI (some locked-down hosts), and even then reduce due events rather than accepting page-triggered jobs on every visit.

Is high TTFB a Core Web Vital?

TTFB is not one of the three Core Web Vitals (LCP, INP, CLS), but it still affects LCP because the main content cannot paint until HTML arrives. See LCP, INP, and CLS explained for how first byte fits the wider picture.

When is upgrading hosting the right fix?

When profiling shows sustained CPU or memory limits after cron, cache, and query fixes, or when traffic outgrew the plan honestly. If doubling RAM fixes TTFB without code changes, you probably skipped object cache or cron discipline first, so rerun the checklist above before signing a larger contract.

When CDN, TLS, and theme tickets are closed and TTFB is still high, walk this server-side list before the next hosting invoice. Apogee Watcher schedules PageSpeed runs on the URLs that bypass cache so you see origin truth, not only the fast cached homepage.

Start monitoring your client sites or run a free performance check on an uncached priority URL.

References

Optimize Time to First Byte (web.dev)
Time to First Byte (TTFB) (web.dev)
Reduce server response times (Chrome for Developers)
Improve Server Response Time (Google PageSpeed Insights documentation)
Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules
Why Your WordPress Site Is Slow (It Is Not Always Hosting)
WooCommerce Performance Tuning (2026 Guide)
A Quick Way to Fix LCP: Four Changes That Cut Time to Paint
Performance Budget Thresholds Template
PageSpeed Insights versus automated monitoring
LCP, INP, and CLS explained

How Lighthouse Performance Scores Are Recorded and Calculated

Tue, 18 Aug 2026 09:44:00 +0000

A client forwards a PageSpeed Insights screenshot with a big green 94 and asks whether the site is “fast enough for Google.” Another week the same URL shows 81 on mobile after a tag manager change, and the account thread fills with theories. Both reactions treat the Lighthouse Performance score as a single truth. It is not. It is a lab construct: metrics recorded under controlled conditions, then calculated into a 0–100 number with curves and weights that Google documents and occasionally revises.

Chrome’s Lighthouse performance scoring guide is the source of truth for that math. What follows translates it for agency reporting: what gets recorded in a run, how the score is calculated, which weights apply in current Lighthouse 10 documentation, why the number is not the same as field Core Web Vitals, and how Apogee Watcher stores category scores from scheduled runs without pretending they are CrUX. Keep the calculator open while you read if you want to poke individual metrics.

What a Lighthouse Performance score actually is

The Performance score is a single 0–100 summary for one lab run of one URL under one device strategy (mobile or desktop). It is not a ranking factor by itself. It is not a rolling average of real visitors. Opportunities and Diagnostics in the report do not add points directly; they explain ways the underlying metrics might improve, which can raise the score indirectly when those metrics move.

Colour bands in the docs are simple: 0–49 poor (red), 50–89 needs improvement (orange), 90–100 good (green). A perfect 100 is unusually hard. Moving from 99 to 100 can need as much metric improvement as moving from 90 to 94. For client language, “good” means a lab run that cleared 90 under that profile, not that every user on every network had a green experience.

PageSpeed Insights uses Lighthouse for the lab block. When people say “the PageSpeed Insights score,” they usually mean that lab Performance category, sometimes while looking at a CrUX field panel on the same screen. Keep those two stories separate in every deck.

How Lighthouse records lab metrics in a controlled run

Recording comes first. Lighthouse (and PageSpeed Insights lab mode) loads the URL in a controlled environment: a chosen form factor, simulated network and CPU throttling for typical mobile profiles, and a single navigation. During that load it measures timings and layout behaviour. Common Performance metrics include First Contentful Paint (FCP), Speed Index (SI), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Diagnostics such as Time to First Byte (TTFB) may appear as supporting detail. None of those values are taken from real visitors in that run.

The lab profile matters. Mobile and desktop use different throttling and, since Lighthouse 6, different scoring curves so desktop is not scored on mobile HTTP Archive distributions. Running on a quiet office machine with extensions disabled still differs from a busy shared CI worker. Chrome documents common causes of score fluctuation: ads and A/B tests, routing changes, device power, extensions, antivirus. Treat a single paste as a sample from a distribution, not as the only possible score for that URL.

Scheduled monitoring reduces the “two screenshots, no baseline” problem. You still measure lab conditions, but you compare like with like over time. That is the operational gap we described in PageSpeed Insights versus automated monitoring.

How Lighthouse calculates the 0–100 Performance score

Calculation is a second step. Lighthouse does not average raw milliseconds into one number. For each metric it maps the recorded value onto a 0–100 metric score using a log-normal scoring curve calibrated from HTTP Archive site data. Those metric scores stay under the hood in the usual report UI. The visible Performance score is then a weighted average of the metric scores.

Chrome describes the curve control points clearly. The 25th percentile of HTTP Archive data for a metric maps to a metric score of 50. The 8th percentile maps to 90 (the “good” control point). Between roughly 0.50 and 0.92 the relationship is nearly linear; near 0.96 returns diminish and further metric gains buy less score. Exploring a metric in the Lighthouse scoring calculator is the fastest way to see how a raw LCP or TBT value becomes a metric score before weights apply.

Because the curves come from real-site distributions, “good” is relative to the web as captured in HTTP Archive, not to an arbitrary round number your client invented in a brand guideline. When Lighthouse major versions change weights or curves, historical scores need a footnote. Always cite the Lighthouse version your tool used when you compare quarters.

Lighthouse scoring weights (Lighthouse 10)

Chrome’s documented Lighthouse 10 weights for the Performance score are:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

TBT carries the largest single weight. LCP and CLS share 25% each. FCP and Speed Index are lighter. Earlier majors differed; Lighthouse 8 still weighted Time to Interactive and used a different CLS weight. Verify the table for the version you ship in CI or see in PageSpeed Insights, and re-check the calculator when Google publishes a new major.

INP may appear in field tooling and in some report contexts, but the lab Performance blend documented for Lighthouse 10 emphasises TBT as the interactivity proxy inside the score. Do not tell a client that “INP is 30% of the Lighthouse score.” Point them at TBT for lab scoring and at field INP for CrUX and Search Console when samples exist. Metric definitions live in LCP, INP, and CLS explained; field interactivity detail is in our INP guide.

Why the Performance score is not the same as Core Web Vitals field data

Field Core Web Vitals come from real Chrome users in the Chrome User Experience Report (CrUX), with Search Console and the PageSpeed Insights field section as common surfaces. Lab Performance scores come from one synthetic navigation. Both can mention LCP and CLS; only the lab score folds in Speed Index and TBT with the weights above. Field INP has no twin inside that Lighthouse 10 weight table.

Question	Lab Performance score	Field Core Web Vitals (CrUX)
Who was measured?	Controlled lab profile	Real Chrome users (sample)
What number?	Weighted 0–100 from metric scores	Percentiles for LCP, INP, CLS (and related)
Interactivity in the blend?	TBT (lab)	INP (field)
Good enough for SEO field status?	No, not by itself	Search Console / CrUX when eligible
Useful after a deploy?	Yes, fast regression signal	Yes, after the rolling window catches up

Agencies need both clocks. Lab catches “we broke the template today.” Field answers “Chrome users over ~28 days still feel it.” We covered the field lag in Why your Core Web Vitals fix is not in CrUX yet and the synthetic versus RUM split in When to use synthetic versus real user monitoring. Missing field rows are a sampling problem, not proof the lab score is wrong; see When PageSpeed Insights shows no CLS or INP.

Why Lighthouse scores fluctuate between runs

Variability is normal. The same URL can move several points between back-to-back runs when ads, consent banners, third-party scripts, or CPU contention differ. Chrome’s variability documentation exists for a reason. For retainers, prefer medians or repeated scheduled runs over a single heroic screenshot. Agree the device strategy (mobile versus desktop) before you argue about a five-point swing.

CI and local DevTools can also disagree because of Lighthouse version, throttling presets, and whether the environment matches PageSpeed Insights. When you automate audits with coding agents or DevTools workflows, still treat the Performance number as lab math under a stated version. Our note on Lighthouse audits with AI agents covers the agency gap between one-off agent runs and portfolio schedules. Separate audits such as Baseline Features change Best Practices diagnostics without rewriting the Performance weight table; see Lighthouse’s Baseline Features audit.

How agencies should report Lighthouse scores to clients

Name the artefact: “Lighthouse / PageSpeed Insights lab Performance score,” not “Google’s speed ranking.”
State device and version: mobile or desktop, and Lighthouse major when known.
Show the drivers: LCP, TBT, and CLS usually explain most of the blend under current weights.
Separate field status: CrUX / Search Console on their own slide or paragraph.
Use trends: three or more scheduled runs beat one paste after a deploy.
Open the calculator when a stakeholder wants to know how many milliseconds buy the next ten points.
Avoid score chasing at 99–100 unless the contract truly requires vanity greens; spend engineering time on user-visible LCP and TBT first.

Budgets work better on metric thresholds than on a single Performance integer, because the integer hides which metric moved. Pair score trends with LCP and TBT budgets on money URLs so engineering knows what to fix. A five-point score drop that is all TBT is a different ticket from one that is all CLS.

Where Apogee Watcher stores Performance scores

Apogee Watcher schedules PageSpeed Insights tests across multi-tenant portfolios and stores the lab category scores and metric payloads from those runs for trends, budgets, and alerts. That history is lab data under Google’s PSI/Lighthouse pipeline. It is not a substitute for CrUX percentiles, and it does not claim to weight INP inside the Performance blend.

Use Watcher when you need the same URLs retested on a cadence after deploys, with mobile and desktop strategies and client-ready charts. Use CrUX and Search Console for field Core Web Vitals when samples exist. Use the scoring calculator when someone asks how the 0–100 number is built. Layer the tools; do not collapse them into one green circle in a slide.

Start a free trial to schedule PageSpeed tests and keep Performance score trends beside metric budgets. Or run a free PageSpeed check on a priority URL and open the Lighthouse scoring calculator beside the result.

FAQ

Does Google use the Lighthouse Performance score as a ranking factor?
Google’s ranking systems use page experience signals tied to real-user Core Web Vitals concepts, not your lab Performance integer as a published ranking weight. Treat the score as an engineering and reporting aid. Use CrUX and Search Console for field status when data exists.

Why is Total Blocking Time in the score if INP is the Core Web Vital?
Lab runs need a synthetic interactivity signal during a single load. TBT fills that role inside the documented Lighthouse 10 Performance weights. INP is a field metric built from real interactions over a page life. Report both without merging them into one sentence.

Do Opportunities change the Performance score directly?
No. Only metric scores feed the weighted average. Opportunities and Diagnostics guide fixes that may improve those metrics on the next run.

Why did desktop scores change a lot after older Lighthouse versions?
Before Lighthouse 6, desktop runs could be scored against mobile-derived curves and look artificially strong. From v6 onward, desktop has its own scoring. Compare desktop history carefully across that boundary.

Can Apogee Watcher show how each metric score was weighted for a run?
Watcher stores the PageSpeed Insights / Lighthouse results from scheduled tests for trends and budgets. For interactive weight exploration, use Google’s scoring calculator and Chrome’s scoring documentation alongside your Watcher history.

References

Lighthouse performance scoring (Chrome for Developers)
Lighthouse scoring calculator (Chrome)
HTTP Archive (scoring curve source data)
Lighthouse variability (Lighthouse project)
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
Understanding INP: The Newest Core Web Vital and Why It Matters
PageSpeed Insights vs Automated Monitoring
When to Use Synthetic vs Real User Monitoring for Performance
Why Your Core Web Vitals Fix Isn't in CrUX Yet (28-Day Window)
When PageSpeed Insights Shows No CLS or INP for Your URL
Automate Lighthouse Audits with AI Agents
Lighthouse’s New Baseline Features Audit

How to measure LCP and INP in Safari 26.2 (and what still only Chrome reports)

Mon, 17 Aug 2026 12:44:00 +0000

For years, many agency Core Web Vitals programmes had a quiet blind spot. Chrome users filled CrUX, Search Console, and PageSpeed Insights field panels. Safari users on iPhone and Mac still felt slow pages, yet your JavaScript often never saw largest-contentful-paint or Event Timing entries in WebKit. That gap mattered whenever a client’s traffic mix was heavy on iOS, education, or consumer brands with strong Apple share.

Safari 26.2, released 12 December 2025, adds the Largest Contentful Paint API and the Event Timing API in WebKit. You can finally collect Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) from real Safari sessions through the Performance API, your own analytics, or a real user monitoring (RUM) tool. What follows is a practical measurement guide: how to observe the new entries, how to use Google’s web-vitals library, what still only Chrome reports in public Google tools, and where scheduled PageSpeed monitoring still fits beside Safari RUM.

What Safari 26.2 changed for LCP and INP measurement

Apple’s WebKit Features for Safari 26.2 post states that Safari 26.2 adds support for Event Timing and Largest Contentful Paint. Event Timing follows an interaction from input through event handlers and DOM updates until the next paint, which is the raw material for INP. Largest Contentful Paint reports when the largest visible element in the viewport finished painting during load. Web Inspector also shows LCP entries in the Timelines tab, which is useful for verifying a hero image or text block before you trust a production pipeline.

Google’s web.dev note on Baseline marks LCP and INP measurement APIs as Baseline Newly available after Safari 26.2 completed the major-browser set (Chromium already had them; Firefox added the INP pieces earlier). Newly available does not mean every visitor has upgraded. Users on older iOS builds, managed devices, or delayed OS updates still will not emit these entries until they move to a supporting Safari. Plan for mixed support for months, not for a single overnight switch.

Metric definitions have not changed. LCP still describes load feel for the main content. INP still describes responsiveness across interactions on the page. CLS still measures layout stability and remains Chromium-led in many RUM stacks. If you need a refresher before you change reporting templates, start with LCP, INP, and CLS explained and our INP guide.

How to measure LCP in Safari with PerformanceObserver

Once Safari exposes largest-contentful-paint entries, you can observe them the same way you do in Chromium. Register a PerformanceObserver with buffered: true so candidates that fired before your script loaded still appear. Log or beacon each candidate, and treat the last candidate before the page is hidden as the LCP you report for that navigation.

const lcpObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    // Candidates update as larger elements paint; keep the latest.
    console.log('LCP candidate', entry.startTime, entry.element, entry.url);
  }
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

Finalise on visibilitychange or pagehide when the document becomes hidden, then disconnect the observer. That pattern matches how production RUM libraries avoid reporting a mid-load candidate as the permanent LCP. Feature-detect with PerformanceObserver.supportedEntryTypes.includes('largest-contentful-paint') so older Safari builds stay quiet instead of throwing.

Use Web Inspector’s Layout and Rendering timeline to confirm the element you think is LCP is the one Safari records. Agencies often discover that a cookie banner, carousels, or a late web font swap changes the LCP element on iOS even when Chrome’s lab run pointed at the hero image. Fix the template once you see the Safari element; do not argue from a single Chrome Lighthouse screenshot alone.

How to measure INP in Safari with the Event Timing API

INP is not a single Event Timing entry. You observe event entries (with interactionId where available), keep the interaction latencies that matter, and apply the INP selection rules across the page lifetime. Safari 26.2’s Event Timing support is what makes that pipeline possible in WebKit. A minimal observer looks like this:

const eventObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.interactionId) continue;
    console.log('Interaction', {
      name: entry.name,
      duration: entry.duration,
      startTime: entry.startTime,
      interactionId: entry.interactionId,
    });
  }
});
eventObserver.observe({ type: 'event', buffered: true, durationThreshold: 16 });

Lower durationThreshold (for example 1) if you are debugging and need more events. Production pipelines usually keep a higher threshold and let a library compute INP so you do not re-implement selection logic incorrectly. Finalise INP when the page is hidden, because the metric can improve or worsen as the user keeps interacting.

Treat early Safari INP numbers with care. DebugBear notes that Safari’s INP implementation has had cases of unreasonably high scores while the engine settles. Segment by browser family before you tell a client that “INP exploded on iPhone.” Confirm the Safari version share in your analytics, re-check on a physical device, and compare against Chrome INP for the same URL template.

How to collect Safari LCP and INP with web-vitals.js

For most sites, Google’s web-vitals library is the safer path than hand-rolled observers. It handles buffering, attribution helpers, and finalisation when the page is hidden. After Safari gained the underlying APIs, the same onLCP and onINP callbacks can receive Safari sessions once those users are on 26.2 or later.

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  navigator.sendBeacon('/rum', JSON.stringify(metric));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Ask your RUM vendor whether Safari LCP and INP are already flowing, or whether you need a library upgrade. Shopify’s performance team warned store owners that dashboards can shift once Safari data arrives, and that prior “Safari” LCP or INP rows in some tools were not true Safari field samples. Establish browser-family baselines before you treat a combined p75 as gospel.

Keep CLS in the pipeline where your stack supports it, and label browser coverage in client decks. CLS support is still uneven compared with LCP and INP across engines. A Safari-heavy site can look healthy on LCP while layout shift problems remain visible mainly in Chromium field data.

What still only Chrome reports (CrUX, Search Console, PageSpeed Insights field)

Safari RUM and Google’s public field panels are not the same system. CrUX, the Chrome User Experience Report, remains a Chrome-user sample. Search Console’s Core Web Vitals report and the field block in PageSpeed Insights draw on that CrUX world. Turning on Safari observers does not fill those Google UIs with iPhone percentiles.

Source	What you get after Safari 26.2	Still Chrome-skewed?
First-party RUM / `web-vitals` / vendor RUM	LCP and INP from Safari 26.2+ users when instrumented	No, if you segment by browser
CrUX (origin or URL)	Real-user Chrome percentiles	Yes
Search Console CWV report	Field issues from CrUX	Yes
PageSpeed Insights field section	CrUX slices beside lab	Yes for field; lab is synthetic
Scheduled Lighthouse / PageSpeed Insights lab	Controlled lab run on a listed URL	Lab is not Safari field

That split is why agencies still need both layers. Safari RUM answers “how do our iOS users experience this template?” Chrome field tools answer “what does Google’s Chrome-based field sample say for ranking and Search Console?” Scheduled lab runs answer “did yesterday’s deploy regress the URL we listed?” Confusing any two of those produces the same failure mode as treating a missing CrUX row as proof the page has no CLS. We covered missing field rows in When PageSpeed Insights shows no CLS or INP.

Why Safari and Chrome LCP timings can differ slightly

Even when both browsers expose LCP, the clocks are not identical down to the millisecond. web.dev explains that Chrome has historically included a later presentationTime in LCP, while Firefox and Safari stop at an earlier paintTime. The difference is usually small, but it is enough to create noisy comparisons if you merge browser families into one percentile without labelling the engine. Chrome has been exposing more comparable paint timing for cross-browser work; still segment reports by browser until your tooling documents like-for-like fields.

Expect distribution shifts when Safari volume turns on in RUM. Some teams see slower Safari LCP than Chrome on the same URL; others see the opposite. Image decoding, font loading, and main-thread contention differ by engine and device. Use the new visibility to find Safari-specific issues (lazy-loaded LCP images, large hero assets on cellular, third-party scripts that hurt INP on iOS). Do not panic-rewrite the entire stack because a combined dashboard moved after Safari data landed.

Agency checklist: segment Safari RUM beside Chrome lab and CrUX

Confirm Safari version share in analytics for priority clients (especially education, consumer, and US mobile-heavy brands).
Upgrade or verify RUM so web-vitals or your vendor actually receives Safari LCP and INP.
Baseline by browser family for two to four weeks before rewriting client SLAs.
Keep CrUX and Search Console as the Chrome field story for SEO conversations.
Keep scheduled lab tests on money URLs for deploy regression, independent of Safari RUM noise.
Document the stack in the monthly deck: Safari RUM for iOS experience, CrUX for Google field, lab for release confidence.
Re-test INP outliers on device before escalating Safari INP spikes to engineering as production incidents.

For journey-heavy products (enrolment, lessons, checkout), map which steps matter on iPhone first. Our EdTech performance monitoring guide is a useful pattern even outside education: measure the stages users feel, not only the marketing homepage. The same habit applies to SaaS onboarding and ecommerce checkout when Safari share is material.

Where Apogee Watcher fits after Safari starts reporting LCP and INP

Apogee Watcher runs scheduled PageSpeed Insights tests across multi-tenant portfolios: discovery, mobile and desktop strategies, budgets, alerts, and client-ready trends. Those runs give you lab metrics plus CrUX field slices when Google has enough Chrome sample for the URL or origin. Watcher does not inject a Safari RUM snippet, and it does not claim Safari LCP or INP inside the product UI.

That boundary is deliberate. Safari field collection belongs in your RUM or first-party web-vitals pipeline. Watcher stays on the deploy and portfolio side: catch regressions on listed URLs after theme, tag, or CDN changes, while Safari RUM tells you whether iOS users improved after the fix. Layer the two. Do not rip out Chrome field reporting, and do not pretend a lab score is a Safari percentile.

If you need the wider lab versus field decision tree, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring. Soft navigations and SPA route measurement remain a separate Chromium-led topic. Scheduled PageSpeed Insights still measures full document loads of the URLs you list, as we described for Chrome 151 soft navigations.

Start a free trial to schedule PageSpeed tests and budgets across client sites while you instrument Safari RUM for iOS-heavy accounts. Or run a free PageSpeed check on a priority URL before you change reporting templates.

FAQ

Does Safari 26.2 mean CrUX now includes iPhone users?
No. CrUX remains a Chrome user experience sample. Safari 26.2 lets your own RUM or analytics read LCP and INP from Safari sessions. It does not rewrite Search Console or PageSpeed Insights field panels into multi-engine field data.

Is CLS now available in Safari the same way as LCP and INP?
Do not assume parity. This release is about Largest Contentful Paint and Event Timing for INP. Check your RUM vendor’s browser support table for CLS before you promise Safari layout-shift percentiles in a retainer report.

Should we stop using PageSpeed Insights lab scores?
No. Lab scores remain useful for controlled comparisons after deploys. Pair them with Chrome field data where CrUX exists, and with Safari RUM where iOS traffic matters. Each layer answers a different question.

Why did our RUM LCP get worse after Safari data appeared?
Combined percentiles often move when a new browser family joins the sample. Segment by Safari versus Chrome, confirm users are on 26.2+, and inspect the LCP element on a real iPhone before you treat the shift as a pure regression from your last release.

Can Apogee Watcher show Safari LCP and INP today?
No. Watcher stores scheduled PageSpeed Insights lab results and available CrUX field slices for the URLs you monitor. Use RUM or web-vitals for Safari field collection, and Watcher for portfolio lab cadence and alerts.

References

When PageSpeed Insights Shows No CLS or INP for Your URL

Tue, 11 Aug 2026 10:52:00 +0000

You paste a client URL into PageSpeed Insights and the lab block looks fine: Largest Contentful Paint, Total Blocking Time, even a Cumulative Layout Shift score from Lighthouse. Scroll to the field section and Interaction to Next Paint (INP) or CLS is simply absent. Not red, not amber, just missing. The account manager asks whether the page fails Core Web Vitals. You are not looking at a broken test. You are looking at a Chrome User Experience Report (CrUX) eligibility gap, and it is one of the most common sources of confusion in agency reporting.

PageSpeed Insights merges two data sources on one screen. Lab numbers are synthetic: Lighthouse runs on demand with a fixed device profile. Field numbers come from CrUX, a 28-day rolling sample of real Chrome users. Google only publishes a field metric when enough opted-in sessions meet privacy and quality thresholds for that origin, URL, device class, and metric. When the sample is too thin, PSI shows no data for that metric even though lab CLS or INP is right there. That split is normal on low-traffic pages, new launches, long-tail templates, and some desktop-only views. The fix is not to rerun the test until a number appears. The fix is to know which layer you are reading, follow a short decision tree, and fall back to scheduled lab monitoring where field data cannot exist yet.

Why PageSpeed Insights sometimes shows no CLS or INP field data

CrUX is not a census of every visit. Google aggregates performance from a subset of Chrome users who have opted in to sharing statistics. Before a metric appears in PageSpeed Insights field data, the URL or origin needs enough recent sessions in that collection period. If the count falls below Google's threshold, the metric is withheld rather than shown with misleading precision.

Several situations trigger a missing field row:

Insufficient sample size for the specific URL, especially on blog posts, campaign landers, and localised paths that get far fewer sessions than the homepage.
Origin-level data only, where CrUX has enough traffic for example.com but not for example.com/pricing/enterprise.
Metric-specific gaps, where LCP field data exists but CLS or INP does not, because each metric has its own eligibility within the same report.
Form factor splits, where mobile field INP is published but desktop INP is not, or the reverse, because phone and desktop traffic are reported separately.
New or recently changed URLs that have not yet accumulated four weeks of blended field history in the rolling window described in why your Core Web Vitals fix is not in CrUX yet.

None of these mean the page is fast or slow in the eyes of Google Search. They mean Google does not have enough field evidence to print a percentile for that slice. Search Console may still group the URL with origin-level status when URL-level field data is missing, which is another reason teams misread a single PageSpeed Insights screenshot as the full story.

Lab CLS and INP vs missing CrUX field data on the same URL

The most confusing PSI screen is lab green beside an empty field row. Lighthouse always calculates lab CLS from the layout shifts it observes during the synthetic load. Lab interactivity is proxied through Total Blocking Time and related audits; INP itself is a field metric, so PSI does not show a field INP value when CrUX has no sample, even if lab TBT looks acceptable.

Lab (Lighthouse in PageSpeed Insights)	Field (CrUX in PageSpeed Insights)
Source	One controlled run you triggered	Opted-in Chrome users, 28-day window
CLS	Always calculated for that run	Shown only when CrUX sample is large enough
INP	Not a lab Core Web Vital; use TBT as a lab signal	Shown only when enough real interactions were captured
Best for	Template QA, deploy checks, before/after on priority URLs	SEO and client field status when eligible
Missing data meaning	N/A (rerun always produces lab output)	Usually low traffic or URL-level ineligibility, not a PSI bug

Treat the two blocks as complementary. Lab answers whether today's build looks clean on a representative device profile. Field answers whether enough real users experienced that quality over the past month. A missing field CLS or INP row does not invalidate lab work; it limits what you can claim about population-level Core Web Vitals for that exact URL. For the wider lab versus field programme, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring.

When CrUX shows origin-level data but not URL-level CLS or INP

CrUX publishes at two granularities when sample size allows: origin (scheme plus registrable domain, for example https://www.example.com) and URL (the exact page tested). High-traffic homepages and top category routes often qualify for URL-level field data. Long-tail URLs frequently inherit only origin-level aggregates in PageSpeed Insights, or show no URL row at all.

If origin field CLS looks healthy but the product detail URL you care about has no field INP, you are not necessarily looking at a product-page regression. You may be looking at a page that does not meet URL-level thresholds. Google's PageSpeed Insights and CrUX guide documents how origin and URL slices appear in the UI. Practical workflow for agencies:

Run PageSpeed Insights on the origin (homepage or canonical host) and note which metrics appear at origin level.
Run the specific client URL and compare which metrics disappear.
If origin field data exists but URL data does not, report origin status for SEO conversations and use lab monitoring on the priority template until URL-level field history builds.
Query the CrUX History API or CrUX Vis for origin trends when you need charts; see CrUX Dashboard retired: where to get TTFB, INP, and field history for the replacement stack.

URL-level CrUX is valuable when you have it. It is not guaranteed for every page in the sitemap, and missing URL-level CLS or INP is often a traffic maths problem rather than a measurement error.

Desktop vs mobile splits when only one form factor has field data

PageSpeed Insights field data is split by phone and desktop form factors. Each combination of origin or URL, metric, and form factor has its own eligibility. That is why community threads describe CLS on desktop in one tool and no CLS on mobile in PageSpeed Insights, or INP on mobile with no desktop INP row.

Mobile traffic usually dominates retail and publisher sites, so mobile field Core Web Vitals are what Search Console emphasises for many properties. B2B sites with heavy desktop usage during business hours can still lack desktop INP in CrUX while mobile INP passes. Always note which strategy you selected in PageSpeed Insights before screenshotting a report. Switching between mobile and desktop lab profiles does not change field eligibility, but it changes which field column you are looking at.

For portfolio programmes, monitor both form factors on priority templates even when only one has field data today. Mobile versus desktop Core Web Vitals monitoring covers schedules and budgets; the reporting rule here is simple: never merge mobile and desktop field percentiles into a single averaged number for client decks.

Decision tree: what to check when PageSpeed Insights has no data

Use this sequence before you tell a client their CLS or INP "does not exist."

1. Confirm the exact URL (scheme, host, trailing slash) matches the live page
        |
        v
2. Check ORIGIN field data in PageSpeed Insights (same host, homepage if needed)
        |
        +-- Origin also missing --> likely low traffic or new site; skip to step 5
        |
        v
3. Check URL-level field data for the same metric on MOBILE and DESKTOP
        |
        +-- One form factor missing --> report the eligible one; lab-monitor the other
        |
        v
4. Compare LCP vs CLS vs INP availability (metric-specific gaps are common)
        |
        +-- Only INP/CLS missing --> interactions or shifts rare vs LCP paint; still fix in lab
        |
        v
5. Run lab Lighthouse on the template; store scheduled lab trends for proof
        |
        v
6. Set performance budgets and alerts on lab CLS/TBT (and field when it appears)

Step 4 matters for triage. A URL with field LCP but no field CLS often still has layout shift risk; Lighthouse lab CLS on that template is your honest diagnostic until CrUX accumulates enough sessions. A URL with no field INP may still have interaction pain visible as lab TBT or as INP in Chrome DevTools performance recordings on a real device.

If origin and URL both lack all field metrics, read Google's public guidance on discovering what your real users experience and treat the property as field-ineligible for now. SEO impact is evaluated at the origin level where data exists; product impact on a thin URL still warrants lab budgets because your users feel the page even when CrUX does not publish a percentile.

How agencies should monitor low-traffic URLs without CrUX samples

When PageSpeed Insights returns no field CLS or INP, your operating model shifts from field percentiles to template-level lab cadence plus origin field context.

Pick representative URLs, not every long-tail path. Monitor checkout, pricing, primary landing templates, and top blog layouts on a schedule. One good template lab series beats fifty one-off PSI pastes that all show "no data."

Store lab CLS and TBT (INP proxy) over time. Field INP may appear later if traffic grows; until then, regression alerts on lab metrics catch script and font changes that would hurt real users. Tie thresholds to performance budget templates and explain in client reports that field slices are pending, not ignored.

Use origin field data for executive summaries. When URL-level INP is missing, origin mobile INP still informs whether the domain broadly passes interactivity expectations. Pair that with lab evidence on the specific template you shipped last Tuesday.

Document device splits in every report. Note "mobile field INP: 142 ms p75; desktop field INP: not available (insufficient CrUX sample)" so stakeholders do not assume desktop is fine because mobile is green.

Re-test after traffic events. Product launches, paid campaigns, and seasonal enrolment can push a URL over CrUX URL thresholds. Schedule a quarterly eligibility check on pages that matter commercially.

Apogee Watcher is built for that layered model: scheduled PageSpeed Insights and Lighthouse runs across many client sites, budgets on lab metrics, and alerts when a priority URL regresses, while you still read field slices where Google publishes them. It does not manufacture CrUX samples for pages Chrome users rarely visit. It keeps lab proof continuous until field data catches up.

When field CLS or INP returns, compare it to the lab trend you stored. If they diverge, you are usually looking at cache mix, device diversity, or third-party behaviour that lab did not emulate. That is when CLS deep-dive fixes and LCP, INP, and CLS explained move from reference reading to sprint work.

FAQ

Why does PageSpeed Insights show lab CLS but no field CLS?

Lab CLS comes from Lighthouse on every run. Field CLS requires enough real Chrome sessions on that origin or URL in CrUX. Low traffic, URL-level ineligibility, or a form factor with too few sessions are the usual causes.

Does missing INP in PageSpeed Insights mean the page passes interactivity?

No. It means CrUX does not have enough interaction data to publish field INP for that slice. Use lab TBT, manual device testing, and scheduled lab monitoring until field INP appears or you confirm the URL is intentionally low priority.

Can I force URL-level CrUX data to appear?

You cannot opt in a single URL. Eligibility follows Chrome traffic volume and Google's privacy thresholds. Growing organic and paid traffic to the URL, fixing canonical and redirect issues, and waiting through the 28-day rolling window are the levers you actually have.

Should I report origin data when the client asked about one URL?

Yes, with a clear label. Origin field Core Web Vitals describe the domain's eligible traffic pool. Pair origin field status with lab results on the specific template so the client sees both the SEO-wide picture and the page they shipped.

Is "no data" the same as a failing Core Web Vital?

No. Missing field data is not a pass or fail badge. Search Console may use origin-level grouping for URLs without their own field row. Treat missing data as "not enough field evidence," then use lab monitoring and origin context until URL-level metrics qualify.

When should I use the CrUX API instead of PageSpeed Insights?

Use PageSpeed Insights for a quick human-readable check. Use the CrUX API or History API when you need to store daily or weekly field percentiles in your own database across many origins. Eligibility rules are the same; the API does not bypass sample limits.

Missing CLS or INP in PageSpeed Insights is a data availability problem, not a mystery bug. Read origin before URL, mobile before you assume desktop, lab before you declare victory, and keep scheduled synthetic monitoring on the templates that drive revenue while CrUX catches up.

Start a free trial to schedule PageSpeed tests, set lab budgets on priority URLs, and track regressions across client portfolios when field data is thin or absent.

References

CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History

Mon, 10 Aug 2026 17:57:00 +0000

For years the CrUX Dashboard was the bookmark agencies opened when a client asked whether field Largest Contentful Paint had moved since the last deploy. It was a Looker Studio report on monthly Chrome User Experience Report (CrUX) data: stacked bars for origin-level distributions, a familiar place to screenshot TTFB, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) without writing SQL. Google retired it at the end of November 2025 and shut down the shared CrUX Connector that fed it. If your team still has a saved link, the chart either fails to load or stops at the last month the connector received.

The Chrome UX Report itself did not go away. What you need now is a replacement stack: CrUX Vis and the CrUX History API for TTFB, INP, and CLS trends, PageSpeed Insights and Search Console for the latest field slice, BigQuery if you want years of origin history on your own billing project, and scheduled lab monitoring so deploy proof does not wait on CrUX's 28-day rolling window. No single free dashboard copies every old Looker view, but the migration path is straightforward once you match each tool to the question you are actually asking.

Why Google retired the CrUX Dashboard and Looker Studio connector

Google announced the deprecation in September 2025. The CrUX Dashboard was a Chrome team-maintained Looker Studio template on monthly CrUX tables. Usage grew after Core Web Vitals became a ranking signal in 2020, but the connector behind it struggled with outages, especially around monthly data releases. Google pointed teams at the CrUX History API (weekly series, up to about 40 points) and CrUX Vis (first-party charts on that API) as more reliable paths.

By November 2025 the connector stopped receiving new months. Dashboards that depended on Google's shared BigQuery bridge stopped updating; CrUX release notes treated that as the final reminder. You can still run the old Looker template against your own chrome-ux-report BigQuery project if you accept query cost and setup work, but the free one-click version most teams used is not coming back. CrUX Vis now carries much of the same job with weekly points instead of monthly bars, and PageSpeed Insights still shows the latest rolling 28-day field slice when Google has enough Chrome traffic for the origin or URL.

PageSpeed Insights field data and Search Console: current Chrome UX Report numbers

When someone asks "what does CrUX say right now?", they usually want the latest rolling field percentiles, not six months of history. Three surfaces answer that question most often, and they share the same underlying dataset with different filters and presentation. PageSpeed Insights, Search Console, and the daily CrUX API each emphasise a different workflow, but the numbers trace back to the same Chrome User Experience Report collection rules.

PageSpeed Insights field data for one origin or URL

PageSpeed Insights is still the default check for a single origin or URL. Open PageSpeed Insights, run the test, and read the field section when CrUX has eligible traffic. You get origin-level and, when sample size allows, URL-level p75 values for Core Web Vitals and supporting metrics, including experimental field Time to First Byte (TTFB) where Google publishes it. Lab Lighthouse numbers on the same screen are synthetic; field numbers are the 28-day rolling average described in why your Core Web Vitals fix is not in CrUX yet.

PageSpeed Insights lab data versus field data on the same URL

PageSpeed Insights shows lab and field on one page, which is convenient and easy to misread. Lab data is a controlled Lighthouse run on demand: fixed device profile, emulated network, one load you triggered. Field data is CrUX: real Chrome users over roughly the past 28 days, blended across devices, cache states, and journeys. A green lab Performance score beside an amber field INP band is normal after a deploy, on a low-traffic URL, or when third-party scripts behave differently for real users than in the lab.

	Lab (Lighthouse in PageSpeed Insights)	Field (CrUX in PageSpeed Insights)
Source	Synthetic test you run	Opted-in Chrome sessions
Clock	Same day, every run	28-day rolling average
Best for	Deploy verification, before/after on priority URLs	SEO reporting, client field status
Replaces CrUX Dashboard history?	No (point-in-time unless you store runs)	No (latest period only; use CrUX Vis or History API for trends)

Treat the two blocks as complementary, not competing scores. Lab answers whether the change shipped cleanly; field answers whether enough real users have lived with it for the aggregate to move. For a fuller split between synthetic schedules and real-user monitoring, see synthetic versus real user monitoring. The CrUX Dashboard retirement does not remove that distinction; it removes one place that charted field history without opening PageSpeed Insights, CrUX Vis, or an API client.

Search Console Core Web Vitals report for SEO workflows

Search Console's Core Web Vitals report groups URLs by status (Good, Needs improvement, Poor) at origin granularity for SEO workflows. It is slower to navigate than PageSpeed Insights for one URL, but account managers already live there for indexing and query data. Field metrics inherit the same CrUX eligibility rules: low-traffic pages may show origin-only data or gaps, which we will unpack further in a later post on missing CLS and INP in PageSpeed Insights.

Daily CrUX API for the latest field collection period

The daily CrUX API (queryRecord endpoint) returns the same latest collection period programmatically. Use it when you want to store today's field p75 beside yesterday's in your own database, or when a script needs TTFB, INP, or CLS without opening a browser. It refreshes roughly daily with a short processing lag; it does not return the long weekly history that the History API exposes.

Need	Tool	Granularity	History
Quick check on one URL	PageSpeed Insights	Origin + URL when eligible	Latest 28-day period only
SEO reporting by URL group	Search Console CWV report	Origin / URL groups	Status trends, not full metric export
Automation for "today's field"	CrUX API `queryRecord`	Origin or URL	One collection period per call
Metric definitions and thresholds	[Core Web Vitals guide](https://apogeewatcher.com/blog/what-are-core-web-vitals-a-practical-guide-for-2026)	Reference	N/A

CrUX Vis and the CrUX History API: TTFB, INP, and CLS field history

The old CrUX Dashboard's real value was trend lines: did INP drift after the tag manager change, did TTFB step up when the CDN rule shipped, did CLS calm down after the font fix? Current field snapshots in PageSpeed Insights answer "where are we this week?" History answers "when did it start moving?" Those are different tools now, and most teams need both answers on retainer accounts.

CrUX Vis for weekly field trend charts

CrUX Vis is Google's direct replacement UI. Point it at an origin or URL and open the Core Web Vitals, Loading Performance, Interactivity, or Visual Stability pages. Each chart shows weekly distributions built from the CrUX History API, with each point covering the previous 28 days of Chrome experiences. Data updates on Mondays; you can see up to about 40 weeks where Google has samples. TTFB sits with loading metrics; INP with interactivity; CLS with visual stability. CrUX Vis is free, fast compared with the old Looker report, and enough for a quarterly business review on one domain. It still queries one origin or URL at a time, so it does not replace a spreadsheet of fifty client homepages.

Query the CrUX History API for programmatic field history

The CrUX History API (queryHistoryRecord) powers CrUX Vis and any custom chart you build. With a Google Cloud API key you can pull weekly time series for origins and, critically, for URLs that qualify, which monthly BigQuery alone did not make easy for page-level history. Set collectionPeriodCount up to 40 to match the Vis window. Pair History API calls with daily queryRecord calls when you want both "what happened over the last six months" and "what changed since Tuesday's deploy." Google's History API guide documents form factors, histogram densities, and collection period dates; put those dates on client slides so nobody mistakes a four-week blend for a live score.

BigQuery for long-archive Chrome UX Report analysis

BigQuery (chrome-ux-report public dataset) remains the long-archive option. Monthly tables still publish for deep analysis, competitive research, and custom Looker Studio reports on your own billing account. Load times are slower and the data is less current than the APIs, but you can join CrUX to analytics exports, slice by country or device tables, and keep years of origin history that exceed the History API window. Expect to pay for queries after the free tier unless you cache results. Some newer sub-metrics appear in APIs before every BigQuery table catches up; check CrUX release notes when you standardise a metric set for client reports.

CrUX Vis, CrUX History API, or BigQuery: which fits your question?

Teams often ask for one replacement tool. In practice you pick by question, budget, and who needs to open the chart. Use CrUX Vis when a technical lead or SEO owner needs a trustworthy trend for one priority origin or URL and nobody wants to maintain a script. It is the fastest honest answer to "show me INP over the last few months" in a client call. Use the History API when you need the same series inside your own dashboard, a weekly email, or a database next to deploy tags. Use BigQuery when the question needs custom SQL, long horizons, or joins that Google's UI will never ship. Use PageSpeed Insights or the daily API when the question is simply whether today's field p75 cleared the budget.

None of these options shorten the 28-day rolling window. A fix shipped yesterday still ages into field aggregates gradually, which is why scheduled lab monitoring matters during the lag. PageSpeed Insights versus automated monitoring covers that split for teams who outgrew manual checks; the CrUX retirement does not remove the need for a lab clock beside the field clock.

Third-party Chrome UX Report tools for agency portfolios

Google is not the only place to chart CrUX. Several products wrap the History API or BigQuery with alerts, competitor views, and multi-URL boards. Treo is a common example for agencies that want CrUX-heavy field exploration and large URL lists without building pipes themselves. Field explorers and scheduled PageSpeed monitoring solve different jobs, and many teams use both. For how agencies shortlist monitoring tools on features and workflow fit, see comparing PageSpeed monitoring tools.

Apogee Watcher sits on the scheduled lab side of that split. We run PageSpeed Insights-backed tests across many sites on a cadence you set, store LCP, INP, CLS, FCP, and Total Blocking Time from lab runs, and show CrUX field numbers beside those results when Google returns them for the URL. We do not replace CrUX Vis for a six-month INP line chart on one domain, and we do not replicate BigQuery. We do give agency portfolios a repeatable before-and-after history on priority pages, budgets, and alerts while field data catches up, layered onto Search Console and the explorers you already use.

Field pipelines also slip. Collection delays, eligibility changes, and processing lag still show up in client inboxes as "why is Search Console still amber?" The same 28-day rolling window explains part of that lag after a deploy; see why your Core Web Vitals fix is not in CrUX yet for how to phrase timelines in client reports without blaming the wrong team.

What no free Chrome UX Report dashboard replaces after retirement

Being precise about gaps prevents another bookmark rot cycle. No free Google UI reproduces every old CrUX Dashboard view in one place. CrUX Vis does not list forty client origins on one screen. PageSpeed Insights does not chart six months of TTFB without you opening each URL. Search Console does not export weekly p75 series for every template. BigQuery is powerful but not free at scale and not friendly for account managers. The History API is accurate but requires engineering time.

Third-party tools close some of those holes with paid seats, URL limits, and their own refresh schedules. None of them remove CrUX eligibility rules: low-traffic pages still lack URL-level field data, desktop and phone still split, and rolling averages still trail deploys. The workable agency pattern we see is a small stack: CrUX Vis or a field explorer for deep history on hero URLs, Search Console for SEO status, scheduled lab monitoring for portfolio regression detection, and one sentence in the report that explains collection period dates. If nobody owns the threshold on a metric and nobody acts when it breaks, it should not be on the daily list, whether the chart came from Google or a vendor.

How agencies monitor Chrome UX Report field metrics across client sites

A practical Monday workflow after the dashboard retirement:

List priority origins and money URLs per client (home, pricing, signup, checkout, main templates). Match the list to URLs that actually receive Chrome traffic, not only the page engineering fixed in staging.
Pin one field history view per key domain. CrUX Vis or a History API-backed explorer for quarterly reviews; note the collection period on the screenshot.
Schedule lab tests on the same URLs. Use budgets so a deploy regression triggers before field data moves. Frequency guidance lives in how to schedule PageSpeed monitoring if you are standardising cadence across accounts.
Pull Search Console CWV status monthly for SEO owners. Treat it as a lagging group report, not a deploy gate.
Reserve BigQuery or custom API jobs for investigations (country regressions, device splits, before/after studies), not for every account manager every week.

Apogee Watcher automates steps two and three for multi-site organisations: discovery, scheduled tests, field slices when available, alerts, and client-ready exports without maintaining fifty PageSpeed Insights bookmarks. Start with a free domain check on one money URL if you want to see lab and field side by side before you add the portfolio, then expand the same URL list into budgets once the cadence feels right.

FAQ

Is the CrUX Dashboard still available?

Google deprecated the shared CrUX Dashboard and turned off the CrUX Connector at the end of November 2025. You can copy the Looker Studio template and point it at your own BigQuery project, but the hosted connector most teams used no longer updates. CrUX Vis is Google's recommended first-party replacement for historical charts.

Where do I get field TTFB now that the dashboard is gone?

Check PageSpeed Insights field data for the latest rolling TTFB when Google publishes it for your origin or URL. For history, use CrUX Vis Loading Performance charts or query the CrUX History API for weekly TTFB series. BigQuery monthly tables remain available fo

Core Web Vitals in 2026: What the Data Actually Says (And What to Fix First)

Sat, 18 Jul 2026 09:03:27 +0000

Core Web Vitals in 2026: What the Data Actually Says (And What to Fix First)

Originally published on www.devndespro.com, canonical: https://www.devndespro.com/blog/core-web-vitals-2026

Every year someone declares Core Web Vitals dead, replaced by AI search, replaced by content quality, replaced by whatever the trend of the month is. The data says otherwise. As of early 2026, Core Web Vitals remain a real, confirmed ranking signal, and most sites are still failing them. This isn't a "best practices" reminder, it's a look at what the numbers actually show and where the fastest wins are.

More than half the web is still failing

According to CrUX data from January 2026, roughly 55.7% of web origins globally pass all three Core Web Vitals thresholds at once, up from about 50% in early 2024 and 36% in 2022. That's real progress, but it also means close to half the web is still failing a test that's been public and documented for years.

Break it down by device and the gap widens: mobile origins pass at meaningfully lower rates than desktop, roughly 48% versus 56% based on 2025 Web Almanac figures, an 8-point gap that hasn't closed much despite years of "mobile-first" messaging.

INP is where sites actually die

If you're failing Core Web Vitals in 2026, INP (Interaction to Next Paint) is very likely the reason, or close to it. INP replaced the old FID metric in March 2024, and it's a much harder bar to clear: instead of just measuring the delay before the first interaction, it measures every interaction on the page and reports the worst one. Roughly 43% of websites still fail the 200ms INP threshold this year, and it's now widely regarded as the hardest of the three metrics to pass consistently.

LCP (loading speed) is the other weak point. Only around 62% of mobile pages hit a good LCP score, making it the single most common individual failure point, with image loading and rendering priority as the usual root causes.

CLS (visual stability), by contrast, is the easy one. About 81% of origins already pass it globally, mostly because the fixes (image dimensions, reserved space for ads, avoiding late-loading fonts) are well understood at this point.

The part most guides skip: it's field data, not a lab score

A number of technical audits still lean on Lighthouse scores as the source of truth. That's a mistake. Google's actual Core Web Vitals assessment comes from the Chrome User Experience Report (CrUX), real user sessions, measured at the 75th percentile over a rolling 28-day window. Lighthouse is a useful diagnostic tool for finding problems, but it doesn't even measure INP directly, it uses Total Blocking Time as an approximation. If you want to know your real standing, you need CrUX data or your own real-user monitoring, not just a PageSpeed Insights run on one machine in one location.

Why this still matters for revenue, not just rankings

Core Web Vitals function mainly as a tiebreaker: when two pages are otherwise similarly relevant, the faster and more stable one tends to win. That sounds modest until you look at real business outcomes. In an A/B test Vodafone Italy ran on two functionally identical pages, a 31% improvement in LCP alone was enough to drive an 8% increase in sales. That's not a developer metric anymore, it's a conversion metric with a dollar figure attached.

Where to actually start

Given the data, the priority order for most sites in 2026 looks like this:

Check your real field data first. Use CrUX or Search Console's Core Web Vitals report, not just a single Lighthouse run, to see what your actual visitors experience.
Fix LCP before anything else. It's statistically the most common individual failure, and the highest-leverage fixes (preloading your largest image with fetchpriority="high", cutting render-blocking resources) tend to be well-scoped engineering tasks.
Treat INP as the harder, ongoing problem. This usually means auditing JavaScript execution, breaking up long tasks, and reducing main-thread work rather than a single quick fix.
Don't ignore mobile. With an 8-point pass-rate gap versus desktop, mobile is where most of the missed opportunity is sitting.

If you want a quick read on where your own site currently stands, run it through seo.devndespro.com, it's a free audit tool I built that covers this alongside the broader technical SEO picture.

I'm a DevOps engineer and web developer running DevnDespro, a small web development, UI/UX, and SEO agency.

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

Sun, 14 Jun 2026 07:40:00 +0000

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

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

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

What are Core Mobile Vitals?

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

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

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

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

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

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

Why Core Web Vitals gave web teams a shared language

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

CWV fixed the vocabulary problem for public web content:

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

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

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

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

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

Why native mobile apps still lack an equivalent framework

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

Platforms and runtimes differ

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

Session shape differs

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

Distribution and measurement differ

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

Ownership differs on mixed portfolios

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

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

Embrace's four experience pillars for native apps

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

Screen Load

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

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

Smoothness

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

Responsiveness

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

Stability

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

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

Core Web Vitals on mobile web: what to monitor today

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

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

Practical checks we see in agency portfolios:

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

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

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

How web performance teams should combine web monitoring and native RUM

Think in three layers rather than one blended score:

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

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

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

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

What agencies should document in retainers

Until CMV thresholds exist, write contracts in plain terms:

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

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

FAQ

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

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

Does Google rank native apps on Core Mobile Vitals?

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

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

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

Should we monitor mobile and desktop Core Web Vitals separately?

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

Can Apogee Watcher monitor Core Mobile Vitals in native apps?

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

Where can we read more about Core Mobile Vitals?

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

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

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

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

FCP and TBT: Supporting Metrics Beyond Core Web Vitals

Sat, 13 Jun 2026 07:40:00 +0000

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

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

Are FCP and TBT Core Web Vitals?

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

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

What First Contentful Paint measures

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

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

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

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

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

What Total Blocking Time measures

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

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

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

Lab thresholds (same source as the budget template):

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

How FCP relates to LCP in diagnosis

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

Typical patterns we see in agency audits:

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

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

How TBT relates to INP in diagnosis

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

Use TBT when:

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

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

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

When agencies should track FCP and TBT in monitoring

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

Practical cases:

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

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

Common causes of poor FCP and TBT

FCP regressions

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

TBT regressions

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

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

Lab vs field: what to tell stakeholders

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

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

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

FAQ

Is First Contentful Paint a Core Web Vital?

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

Is Total Blocking Time the same as INP?

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

What is a good FCP score?

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

What is a good TBT score?

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

Should we add FCP and TBT to client reports?

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

Does CrUX show FCP and TBT?

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

Can we set performance budgets on FCP and TBT?

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

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

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

PSI on Tuesday, panic on Thursday: when spot checks break

Tue, 26 May 2026 10:28:09 +0000

You run PageSpeed Insights on Tuesday. Mobile performance looks acceptable. INP is not perfect, but nothing looks urgent, so you paste the link in Slack (maybe attach a screenshot) and move on.

By Thursday the account manager forwards a client message: checkout feels slow, organic traffic dipped, or a campaign page went live without web in the loop. You open PSI again. The score moved, sometimes by a lot. You are comparing two runs with nothing saved in between: no deploy note, no list of URLs, no record of which device profile you used.

That gap shows up on most agency rosters. It usually means spot checks are standing in for repeat testing and stored results.

What one Tuesday run actually tells you

A single PSI run answers a narrow question: what did Lighthouse report for this URL, on this device profile, at this moment?

That is useful. It is not a baseline for the rest of the week.

Between Tuesday and Thursday you might have:

A deployment that added one script to the global header.
A marketing tag that started firing on product pages only.
A CDN cache change that improved LCP in the lab while field data was still updating.
A traffic mix shift (more mobile, more logged-in users) that CrUX will reflect later than your manual run.

None of that appears in a tab you closed two days ago. Unless someone stored the run, named the build, and tested the same template the same way, Tuesday's green score is easy to misread on Thursday.

Thursday stress is often missing records, not a new crisis

When a spot check surprises the team on Thursday, the first move is often blind optimisation: defer scripts, shrink images, toggle a feature flag. Sometimes that helps. Often it happens because the timeline between runs was never written down.

Questions that usually settle Thursday faster:

Which URL or template regressed (not only the homepage you always test)?
Did lab and field move together, or did only one move?
Was there a deployment, content publish, or third-party change between runs?
Is the issue on one device strategy or both?

PageSpeed Insights can start that investigation. It cannot answer (3) or keep (1) comparable across many sites unless you add discipline or automation.

For a clear split between when manual PSI is enough and when it is not, see the longer comparison on the Watcher blog:

- PageSpeed Insights vs automated monitoring: when manual checks are not enough

Weekly PSI without storage

Some agencies run PSI once a week to show the client they are paying attention. The client sees activity. The team feels responsible. What is missing is evidence: stored runs, thresholds, and a named owner.

Weekly spot checks without storage tend to produce two outcomes:

Looks fine on Tuesday: Thursday's complaint gets treated as noise until someone reruns the same URL and finds a real regression.
Looks worse on Thursday: nobody can tell whether the drop is a one-off lab flake, a cold cache, or a trend across several runs.

Both waste time. What you need is the same routes tested the same way, with scores kept so you can compare this week to last.

Lab moves fast; field data updates later

PSI can show CrUX when the origin has enough traffic. Field metrics still lag lab. A deployment on Wednesday may not show clearly in field summaries for days, while lab can move on the next run.

That timing gap drives a lot of Thursday arguments. "PSI was green" and "Search Console looks rough" can both be true for a few days if you only spot-check lab scores.

If your team needs shared definitions for LCP, INP, and CLS before you argue about tools, start with the primer, then return to scheduling:

- What are Core Web Vitals? A practical guide for 2026

Changes that reduced repeat Tuesday/Thursday gaps

We still open PSI for a single URL in a hurry. We stopped treating that habit as portfolio governance.

Concrete habits that helped:

Same routes every time: homepage plus two revenue templates, not whichever URL someone remembers.
Paired mobile and desktop: one bad strategy is easy to miss if you only run mobile because it is quicker.
Named builds: paste the deploy tag or git SHA beside the score, even in a spreadsheet, so Thursday has a short list of suspects.
Thresholds written down: agree what triggers action on LCP and INP before the client email arrives.

That is still manual work. It is also visible work: you can see when the spreadsheet stops scaling and scheduled monitoring is worth the setup time.

Thursday triage (about fifteen minutes)

When a client pings and your last PSI run is stale, run this before you change code:

Re-run PSI on the reported URL and on the template you usually skip (category, checkout, logged-in home).
Compare mobile and desktop; screenshot both if you need to share upward.
Note whether the regression is lab-only, field-only, or both (use PSI's field section when available).
List deployments and tag-manager changes in the last 72 hours; ask one person to own the answer.
Decide: hotfix now, scheduled fix, or monitor for 48 hours with a stored re-run.

If step 5 is always "monitor" but nobody saves the follow-up run, you are back to comparing two isolated scores.

Closing

PSI on Tuesday is accurate for that moment. On Thursday, the issue is often that nobody stored Tuesday's run, named the deployment, or agreed which URLs and thresholds count.

Keep manual PSI for one URL and one urgent decision. For a client portfolio, add repeat routes, stored results, and thresholds the team agreed before the week filled up. The comparison and CWV primer linked above go deeper on when manual checks stop being enough and how to read the metrics before you choose tools.

WordPress Performance Monitoring: A Complete Guide

Mon, 18 May 2026 10:12:19 +0000

WordPress powers a large share of the sites agencies maintain, yet performance work on WordPress rarely looks like performance work on a static marketing site or a headless stack. The CMS is not slow by default; the combination of themes, plugins, hosting, and caching often is. And because every client stack is different, a one-off PageSpeed Insights run after a deploy tells you almost nothing about whether Tuesday’s plugin update quietly pushed LCP over budget on the homepage.

This guide is for teams who need WordPress performance monitoring that survives real operations: multiple client sites, frequent plugin changes, and stakeholders who only care when rankings or conversions move. We cover what to measure, which pages to include, how caching skews results, and how to choose between manual checks, WordPress plugins, and external monitoring that sits alongside your existing stack.

Why WordPress needs its own monitoring playbook

WordPress sites share a common platform, but not a common configuration. Two sites on the same host can differ by:

Page builders (Elementor, Divi, WPBakery) that add CSS and JavaScript on every template
Plugin stacks (SEO, forms, chat, reviews, consent, analytics) that load on routes where they are not needed
Caching (full-page cache, object cache, CDN) that makes synthetic tests look fast while logged-in or cart flows stay slow
WooCommerce (or other commerce plugins) with cart fragments, checkout, and account areas that bypass cache

That variability is why “we run Lighthouse once a month” fails. Regressions usually arrive from a small change: a slider plugin update, a new marketing pixel, a theme setting that disables lazy loading, or a cache rule that no longer excludes the shop checkout.

Monitoring should answer three questions on a schedule you can defend to clients:

Are Core Web Vitals still within budget on the URLs that matter for revenue and SEO?
Did a deploy or plugin change move lab metrics before field data (CrUX) catches up?
When something breaks, can you name the URL and the metric without re-running ten manual tests?

If you manage more than a handful of sites, the answer to the third question is almost always automation. PageSpeed Insights vs automated monitoring spells out the split: PSI is excellent for diagnosis; it is a poor system of record for a portfolio.

What to monitor on a WordPress site

Core Web Vitals and lab metrics

Core Web Vitals remain the public scorecard Google uses for page experience signals: LCP, INP, and CLS. For ongoing monitoring, track both:

Lab data (Lighthouse via PageSpeed Insights or equivalent) so you can compare runs consistently and catch regressions within hours of a deploy
Field data (Chrome UX Report / CrUX where available) so you know what real users see, not only what a cold lab run reports

Lab and field will disagree. That is normal on WordPress when full-page caching serves a fast HTML shell to anonymous visitors while logged-in editors or shoppers hit uncached PHP. Your monitoring scope should include both cached public URLs and at least one uncached or semi-cached path if conversions depend on it.

URLs that belong in every WordPress monitoring set

Do not monitor only the homepage. For a typical client site, start with:

URL type	Why it matters
Homepage	Brand, often heaviest builder layout
Primary conversion page	Contact, quote, demo, or lead form
Top blog or resource landing page	SEO traffic, often ad-heavy
WooCommerce shop / single product / cart / checkout	Commerce flows; cache exclusions
Site search results (optional)	Expensive queries on some stacks

Use your sitemap and analytics “landing pages” report to add two or three more high-traffic templates. Automated page discovery (sitemap plus crawl) reduces the manual URL list work when you onboard many domains.

Mobile and desktop

WordPress themes and plugins often treat mobile as an afterthought: different image sizes, deferred scripts that still block input, or desktop-only hero videos. Run both mobile and desktop strategies on priority URLs. Mobile vs desktop Core Web Vitals explains why a green desktop score can still hide a failing mobile experience.

Beyond the performance score

A single Lighthouse performance score is easy to report and easy to misread. Pair it with:

LCP element (hero image, slider, or web font?)
INP and Total Blocking Time proxies when third-party scripts compete with the main thread (third-party script audits help here)
CLS on pages with ads, embeds, or dynamic cart badges
Server response time (TTFB) when object cache or hosting is the bottleneck

WordPress-specific audits in Lighthouse (unused CSS, document request latency, render-blocking resources) point at theme and plugin debt; use them to prioritise fixes, not as a substitute for CWV thresholds.

WordPress-specific pitfalls that break monitoring

Full-page cache makes everyone look fast

When Kinsta, WP Engine, Cloudflare APO, or a generic reverse proxy serves cached HTML, synthetic tests often hit the cached response. That is useful (it matches what most anonymous visitors see) but dangerous if you never test checkout, /wp-admin, or personalised routes.

Monitor cached public URLs on a schedule, and run a separate check on one cache-bypass path after major plugin or theme changes. Document which URLs are cached in your client onboarding notes; our site audit checklist for onboarding includes stack and scope fields for exactly this.

Plugin and theme updates are the main regression source

WordPress maintenance is continuous. A security patch for a form plugin can add a synchronous script on every page. Monitoring without history means you argue about whether the site “was always this slow.”

Store time-series results (score and CWV metrics per URL, per strategy) so you can answer what changed between Monday and Wednesday. Performance budgets turn that history into alerts instead of quarterly surprises.

Staging is not production

Staging copies often disable analytics, use smaller images, or run without the production CDN. Use staging for before/after comparisons of a specific change; use production monitoring for client-facing SLAs and SEO impact.

Page builders and “global” assets

Builders enqueue shared CSS and JavaScript across templates. Fixing LCP on the homepage often needs builder-level settings, not a single compressed hero file. When monitoring flags LCP regressions, note the template (Elementor single, archive, WooCommerce product) in your ticket so developers do not chase the wrong URL.

Three ways to monitor WordPress performance

1. Manual PageSpeed Insights (fine for one site, weak for many)

Best for ad-hoc audits, verifying a fix, or client demos. Limits: no history, no alerts, no multi-site view, easy to forget after launch. Fine for five URLs; painful for fifty sites × five URLs × two strategies.

2. WordPress plugins and connected services

Several products live inside wp-admin or connect WordPress to an external account:

GTmetrix for WordPress connects the site to GTmetrix; you still manage GTmetrix accounts and quotas per client in many setups.
PageVitals and similar WordPress-focused tools combine Lighthouse with RUM and theme-oriented insights; pricing and multi-site workflows vary.

Convenient for site owners who never log into a central agency dashboard. Downside: per-site configuration, API keys in WordPress, uneven multi-tenant reporting for agencies managing dozens of domains. Plugins also add their own overhead if not kept lean.

A WordPress plugin is coming soon for teams who want monitoring tied to the CMS. Today you add the public URL in Watcher like any other site, which avoids installing yet another plugin on fragile client stacks.

3. External monitoring platform (recommended for agencies)

For agencies and consultants, what usually works is monitoring outside WordPress:

Add the domain once in a multi-site dashboard
Discover URLs from sitemap/crawl
Schedule PSI/Lighthouse runs and store CrUX field data where available
Set performance budgets and email alerts per site
Layer on your existing hosting, CDN, and optimisation plugins without rip-and-replace

Apogee Watcher follows this model: you add each domain once, scheduled tests run without your team managing Google API keys, each result includes lab metrics plus CrUX where available, and you review every client from one dashboard. It complements WordPress optimisation plugins; it does not replace caching, image optimisation, or code fixes.

If you are comparing vendors, GTmetrix vs Apogee Watcher and DebugBear vs Apogee Watcher spell out trade-offs for multi-site teams (pricing shape, RUM depth, agency reporting).

Step-by-step: set up WordPress performance monitoring

Step 1: Inventory sites and critical URLs

For each WordPress property, list domain, hosting, cache plugin, builder, and the five to ten URLs from the table above. If you onboard clients regularly, start from the site audit checklist so scope and owners are agreed before tools run.

Step 2: Set budgets by site type

Use realistic thresholds, not “everything green”:

Marketing / brochure WordPress: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.10 (tighten for lead-gen homepages)
WooCommerce: stricter LCP/INP on product and checkout; expect more third-party weight on cart
Publisher / ad-supported: CLS and INP often suffer from ads; budget accordingly

The performance budget thresholds template gives copy-paste starting points; adjust per client contract.

Step 3: Configure scheduled tests

Daily tests are enough for most marketing sites; twice daily for high-revenue stores during campaigns or migration windows. Match schedule to risk: a brochure site updated monthly does not need the same frequency as a WooCommerce store running weekly plugin updates.

In Watcher, add the site, run discovery, set budgets, and enable email alerts for violations. Detailed setup steps are in How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Step 4: Tie monitoring to your change process

WordPress performance is a process problem as much as a tooling problem:

Before major plugin or theme updates: note baseline metrics for affected URLs
After deploy: wait for the next scheduled run (or trigger a manual test) and compare to budget
Monthly: review trends with the client using a consistent report outline (client-ready CWV report outline)

When a regression fires, split work: hosting/TTFB, theme/builder assets, plugin scripts, and third-party tags. Image optimisation for LCP covers the most common WordPress hero image mistakes.

Step 5: Do not optimise in isolation from SEO

CWV and rankings are related but not identical. If the client cares about search visibility, connect monitoring to your SEO review rhythm (how Core Web Vitals impact SEO) and Search Console’s experience reports for field validation.

When to fix in WordPress vs when to fix upstream

Symptom	Often fixed in WordPress	Often fixed outside WordPress
Huge LCP image	Smarter image sizes, WebP, priority hints, builder settings	CDN image optimisation, origin compression
High TTFB	Object cache, query reduction, lean plugins	Hosting tier, PHP version, database tuning
Poor INP	Defer or remove plugins, reduce main-thread JS	Tag manager governance, fewer third parties
CLS from ads/embeds	Reserved space, lazy load rules	Ad network configuration, consent banner placement

Monitoring tells you which URL and metric failed; the table helps route tickets to the right owner so developers are not asked to “fix CLS” when marketing added a new chat widget globally.

FAQ

How often should I run WordPress performance tests?

For stable brochure sites, daily lab monitoring is usually enough. For WooCommerce or sites with frequent plugin changes, daily plus alerts on budget violations is safer. Field data (CrUX) updates on a slower cadence; do not wait for CrUX alone to catch a bad deploy.

Should I monitor the WordPress admin area (/wp-admin)?

Rarely for client reporting. The wp-admin area is uncached and unrepresentative of visitor experience. Monitor public and commerce URLs instead. Slow wp-admin can point to hosting or database issues; treat it as an ops signal, not a Core Web Vitals KPI.

Do I need a WordPress plugin to monitor performance?

No. URL-based monitoring from outside WordPress avoids extra plugin weight and works across all hosts. Plugins can help site owners who want scores inside wp-admin; agencies usually prefer one dashboard for all clients.

What is the difference between a speed optimisation plugin and monitoring?

Optimisation plugins (caching, minify, image compression) change behaviour. Monitoring measures behaviour over time and alerts when metrics cross thresholds. You need both roles clear; optimisers without monitoring leave you blind after the next update.

Does Apogee Watcher replace my caching or image plugins?

No. Watcher layers on top of your stack: scheduled tests, budgets, alerts, and reports you can share with clients. You onboard WordPress sites in the app the same way as any other domain today; a dedicated WordPress plugin is coming soon for teams who want tighter CMS integration.

Next steps

Pick five to ten URLs per WordPress client (homepage, conversion, commerce if applicable).
Set mobile and desktop budgets using your site type.
Turn on scheduled monitoring and email alerts so regressions surface before the client’s inbox does.
Plug the workflow into onboarding and monthly reviews so numbers become decisions.

If you manage multiple WordPress sites today, start a free trial and add your first domains, or follow the automated PageSpeed monitoring setup guide to configure discovery, budgets, and alerts in one pass.

How Google's Latest Algorithm Update Affects Core Web Vitals

Mon, 18 May 2026 10:11:43 +0000

Your client saw a ranking drop the same week SEO Twitter posted about a "Google update." They want to know whether Core Web Vitals thresholds changed, whether their PageSpeed report is now obsolete, and whether you should drop everything to chase a new green score.

Short answer: the recent core updates did not reset how Google measures LCP, INP, or CLS. Google re-evaluated which pages best satisfy search intent across the whole index. Page experience, including Core Web Vitals, still matters. It is not the headline of these updates, and it is not a separate "CWV algorithm" you can fix in isolation.

Below: which official updates matter for page experience work, what stayed the same for Google page experience and CWV, and what to do when traffic moves after a core update.

Google core updates in 2025–2026: official timeline

When someone says "Google's latest algorithm update," they might mean different releases. For page experience and CWV work, these are the ones that matter:

Update	Official timing	What it affects	Relation to CWV
December 2025 core update	Rolled out from 11 Dec 2025 (~18 days)	Broad search quality and relevance	Indirect: competitive pages may shift; CWV thresholds unchanged
March 2026 core update	Rolled out from 27 Mar 2026 (~12 days)	Broad search quality and relevance	Same as above
March 2026 spam update	From 24 Mar 2026	Spam policy enforcement	Not a CWV or page experience change
February 2026 Discover core update	From 5 Feb 2026	Google Discover feed	Separate surface; do not confuse with web ranking CWV

Google lists confirmed ranking updates on the Search Status Dashboard. Check there before you rewrite a performance roadmap.

Core updates are broad. Google's own guidance compares them to refreshing a list of restaurant recommendations: some move up, some move down, and a drop does not automatically mean the site is "bad." The systems are reassessing helpful, reliable content at scale, not announcing new LCP cut-offs.

Did Google change Core Web Vitals or page experience thresholds?

If your brief is only "react to the algorithm update," start here. Google's published guidance for page experience in 2026 still says the same thing on thresholds and signals.

CWV "Good" bands are unchanged: LCP at or below 2.5 seconds, INP below 200 ms, CLS below 0.1 (Understanding Core Web Vitals). There is no single page experience score used for ranking; the page experience FAQ states that core ranking systems look at a variety of signals, and CWV are among them.

Field data from CrUX is what matters for ranking context, not a one-off Lighthouse run. Lab scores help you debug; real-user data is what Search Console's CWV report reflects. INP is the interaction metric (FID was replaced in March 2024). If a stakeholder still asks about First Input Delay, point them to LCP, INP, CLS explained.

None of the December 2025 or March 2026 core updates on the status dashboard were labelled as page experience updates. The last named page experience rollout in the dashboard history is the June 2021 mobile page experience update. Since then, CWV have remained part of ongoing ranking systems without a repeat of that launch-style announcement.

So when a client asks "Did Google change the Core Web Vitals rules?" the honest answer is: not in these core updates. The rules in Search Central are the same. What changed is which pages Google prefers for a given query after a broad quality reassessment.

What changed in core updates that still affects your CWV work

Core updates do not rewrite CWV maths. They can still change how much CWV matter for a specific site in practice.

Competitive context shifted

A core update can promote pages that were already fast and demote pages that were borderline on content quality and slow. When many competitors in a niche improve experience, your "Good" CWV stop being a differentiator and become baseline. That feels like "Google got stricter on CWV" even when the thresholds did not move.

For how CWV interact with rankings in general (tiebreaker, not trump card), see How Core Web Vitals Impact SEO Rankings.

Google clarified how often rankings refresh

In December 2025, Google updated core update documentation to explain that smaller core updates happen continually, not only during named releases. Improvements to helpful content can show up between major updates; recovery also may not wait for the next named event.

For performance teams, that means measuring CWV on a schedule, not only when a core update hits the news cycle.

Documentation and crawling guidance moved (not CWV thresholds)

Search Central's changelog in late 2025 added JavaScript canonicalisation notes, noindex handling clarifications, and migrated crawling docs to Google's crawling infrastructure site. Those changes affect how you ship and index fixes, not the 2.5s / 200ms / 0.1 thresholds.

For a full map of which Search Central pages mean what for delivery, use Google Search Central Core Web Vitals and Page Experience Docs (2026). That post is the doc companion; this one is the update-timeline companion.

Discover is a different product surface

The February 2026 Discover update changed what surfaces in Discover, not how web Search scores LCP on a product page. Agencies reporting "traffic is down" should split Discover vs Web in Search Console before blaming CWV.

Does Google page experience still affect rankings after a core update?

Yes, but not as a separate "page experience update" headline. Google still uses CWV and related signals as part of broader page quality. Content relevance and helpfulness carry more weight when Google is choosing between pages.

A useful mental model has three layers:

Relevance and helpful content: does the page answer the query better than alternatives?
Trust and experience signals: CWV, mobile usability, HTTPS, intrusive interstitial avoidance.
Competitive set: who Google compares you to for that query after the update.

Google states that it still aims to show the most relevant result even when page experience is weak. In crowded SERPs, experience often tips close calls. That is why page experience is worth maintaining even when a core update headline is about content quality or E-E-A-T, not performance.

It also explains a pattern agencies see after every core update: a client with red CWV in Search Console and thin or outdated content loses twice. Fixing only scripts without content review rarely recovers large drops. Fixing only blog posts while LCP sits at 5s leaves money on the table for competitive queries.

Why rankings can drop when Core Web Vitals still look fine

Three mechanics create false blame:

Template deploys move CWV and rankings together

If your blog template regressed (new ad slot, heavier hero image), CWV and rankings can fall in the same week. The update did not change CLS limits; the deploy changed CLS.

CrUX field data lags behind your lab fixes

CrUX updates on a rolling 28-day window. You might analyse a core update in week one while Search Console still shows pre-fix field data. Lab scores improved Tuesday; Google's field view has not caught up yet.

Third-party visibility reports are not new CWV rules

Industry analyses (for example visibility studies after the March 2026 core update) describe who won or lost visibility, not new CWV thresholds. Use them for competitive context, not as proof that Google raised LCP requirements.

Before you promise "we will recover rankings by fixing INP," separate:

URLs with large position loss on high-value queries
Whether those URLs are Poor vs Good in the CWV report
Whether content quality, not performance, is the more likely driver

What to do after a Google core update (agency checklist)

Confirm timing on the Search Status Dashboard

Match the traffic change to the Search Status Dashboard window. Wait until the update is finished before deep analysis. Google recommends comparing at least a full week after rollout ends.

Split Discover, Web, and spam in Search Console

Use search types and filters. A Discover drop is not fixed by CLS work on checkout.

Triage dropped URLs, not the whole site

For URLs with large drops:

Run the helpful content self-assessment honestly.
Check CWV status for those URL groups (mobile first).
Check recent deploys, tag managers, and third-party scripts on those templates.

If a template-wide regression is suspected, read third-party scripts and performance.

Keep PageSpeed monitoring on a schedule

Manual PageSpeed runs after bad news produce screenshots, not a trend. PageSpeed Insights vs automated monitoring covers why one-off tests fail agencies at portfolio scale.

Use the agency CWV monitoring checklist to keep lab and field views on a schedule, not tied to SEO news cycles. For setup detail, see automated PageSpeed monitoring for multiple sites.

Report what you can prove to clients

Client updates should separate:

Google ran a broad core update; thresholds for CWV did not change.
These URLs lost visibility; here is content vs performance evidence.
Here is what we are fixing first and when field data should reflect it.

That framing reduces the weekly "did Google change the algorithm again?" loop.

Mistakes to avoid after a Google core update

Do not renegotiate CWV targets because of a core update headline unless Search Central actually changes thresholds (rare).

Do not delete useful content because rankings dipped. Google warns that mass deletion often signals search-first pages, not user-first pages.

Do not chase a perfect Lighthouse score for SEO alone. Google explicitly notes that perfect lab scores are not the goal of page experience work.

Do not treat AI Overviews traffic loss as a CWV problem by default. Click mix is changing for other reasons; see AI Overviews and CTR for that parallel track. Fast, crawlable pages still help both traditional and AI-mediated discovery.

FAQ

Did Google's March 2026 core update change Core Web Vitals thresholds?

No. Google did not announce new LCP, INP, or CLS "Good" thresholds with that update. It was a broad core update listed on the Search Status Dashboard, not a page experience launch.

Is Google page experience still a ranking factor in 2026?

Yes. CWV remain part of page experience signals Google uses. They work alongside content quality and relevance; they do not replace them.

Should we pause content projects and only fix CWV after a core update?

Usually no. Assess whether the drop is content-led, experience-led, or both. Strong teams continue content improvements while keeping CWV from regressing on important templates.

How long until CWV fixes show in rankings?

Field data needs roughly a 28-day CrUX window, then Google needs time to incorporate changes. Many teams see meaningful movement over weeks to a few months, not overnight. See the timelines in How Core Web Vitals Impact SEO Rankings.

Where does Apogee Watcher fit?

Watcher does not replace Search Console or Search Central docs. It helps agencies run scheduled PSI/Lighthouse checks and track lab plus CrUX field data across many client sites, so you spot regressions between core updates instead of discovering them when a client forwards an SEO newsletter.

What you can do next

Google's latest core updates reshuffle which pages win on quality and relevance. They do not redefine Core Web Vitals. Confirm the update on the official dashboard, triage dropped URLs by content and CWV evidence, keep monitoring on a schedule, and tell clients that page experience is still baseline work in competitive SERPs even when the news cycle is about something else.

If you manage multiple client sites, pair this timeline with the Search Central documentation guide and implement monitoring from the agency checklist. Start with a free Apogee Watcher account to automate tests and catch regressions before the next core update fills your inbox.

Lighthouse Agentic Browsing: How to rank in chatbots

Sat, 16 May 2026 02:57:23 +0000

Google’s Lighthouse has long been the reference lab engine behind PageSpeed Insights and countless CI pipelines. Most teams know its headline categories (Performance, Accessibility, Best Practices, SEO) and the familiar 0–100 style scores on several of them. Chrome’s documentation now adds an experimental Agentic Browsing lane: how a page behaves when agents programmatically discover and use the interface. That is a different question from whether the same page feels fast and smooth when a human scrolls and taps.

This post summarises what that category measures, how scoring works (and why it is not another weighted 0–100 average), and what it means for teams who already run Lighthouse on a schedule. Official detail lives in Chrome’s guide: Lighthouse agentic browsing scoring.

What is Lighthouse Agentic Browsing?

Agentic here means software agents (assistants, automation, or test harnesses) that need to discover, understand, and interact with your UI programmatically. That is a different job from “did the hero image paint quickly?” Agents lean heavily on structured signals: a stable layout, a coherent accessibility tree, explicit affordances for tools, and machine-readable hints about what the site offers.

Lighthouse’s Agentic Browsing category is experimental and tied to proposed standards (including WebMCP). Treat it as an early signal you can watch in lab runs: not a finished ranking factor, and not a replacement for Core Web Vitals field data.

Lighthouse Agentic Browsing scoring vs Performance 0–100

For Performance, Lighthouse maps raw metrics to scores and blends them into a headline number readers recognise. The Agentic Browsing category does not use that pattern. According to Google’s documentation, because standards are still emerging the emphasis is on specific per-audit signals rather than a definitive rank.

In practice the report shows:

A fractional score: a ratio of how many agentic readiness checks passed, not a single weighted 0–100 grade.
Pass or fail (and warnings) on specific audits when technical requirements are not met (for example WebMCP schema validity).
Informational counts in the category header, such as a pass ratio, so you can see overall progress at a glance.

That framing matters for dashboards and alerts. A small movement in a fractional ratio is not automatically comparable to “we gained three Performance points.” You interpret it as coverage of checks, not a universal quality score.

What the Lighthouse Agentic Browsing audits check

The documentation groups work into a few themes. Wording below stays high level; when you implement, follow the live audit names and criteria in your Lighthouse version.

WebMCP and tool registration

Lighthouse uses the Chrome DevTools Protocol WebMCP domain to observe tool registration. It is meant to cover both declarative tools (declared in HTML) and imperative tools (registered from JavaScript). If your site exposes actions or forms for agents through WebMCP, when and how those tools register can determine whether a given run “sees” them.

Accessibility tree checks for agents

Agents are described as relying on the accessibility tree as a primary data model. Lighthouse therefore pulls a subset of accessibility audits that matter most for machine interaction. Examples cited include names and labels, tree integrity (roles and parent-child relationships), and visibility (interactive content not hidden from the tree while still usable). That is not a replacement for a full manual accessibility review; it is a machine-navigation lens on top of familiar a11y themes.

CLS and llms.txt discoverability

Two items stand out for general web performance readers:

Cumulative Layout Shift (CLS): layout stability matters because agents may target an element’s coordinates. If ads, late images, or injected content move the layout between identification and interaction, actions fail. That connects directly to CLS work you may already be doing for Core Web Vitals. For a deeper field and lab angle on causes and fixes, see our CLS deep-dive.
llms.txt: the category checks for a machine-readable summary at the domain root, as a discoverability signal for agents. Whether or not you adopt it, it is a reminder that routing agents to documentation and boundaries is showing up in tooling conversations, alongside crawlability topics we covered in why AI crawlers need fast, crawlable pages.

Why Lighthouse Agentic Browsing scores change between runs

The documentation calls out causes even when audits themselves are deterministic:

Dynamic tool registration: imperative WebMCP registration from JavaScript can land before or after the snapshot Lighthouse captures, so the same page might register tools differently across runs or timings.
Accessibility tree complexity: large or highly dynamic DOMs can change how the tree is built; that can shift which issues surface for agent-centric checks.
CLS during the run: late-loading content that shifts layout can move targets between agent planning and interaction.

For teams, the practical move is to pair occasional spot checks with repeatable environments: fixed throttling, consistent navigation scripts, pinned Lighthouse versions in CI. Where business risk is high, keep continuous monitoring on the metrics that already predict user pain (for example CLS trends from the field) in parallel with whatever you learn from this category.

Lighthouse Agentic Browsing readiness: what to prioritise first

Google’s own “what can developers do” list boils down to three practical directions:

Adopt WebMCP where it fits: expose site logic and forms in a way agents can consume safely and predictably, following current specs and examples in Chrome’s Agentic Browsing audit docs.
Keep the accessibility tree honest: semantic HTML, correct roles, and visible labels help humans and automation; fixing fundamentals rarely conflicts with other goals.
Reduce layout shift: treat CLS as a stability requirement for agentic flows as well as for Core Web Vitals and user trust.

None of that replaces your existing performance programme. Lab Performance scores and field CrUX data still answer different questions from “is this page constructed for machine interaction?” If you are deciding how often to run Lighthouse in CI versus on-demand tools like PageSpeed Insights, our PageSpeed Insights vs automated monitoring piece still applies: cadence, history, and alerts matter once the novelty of a single audit wears off.

Scheduled Lighthouse runs and Agentic Browsing at Apogee Watcher

Apogee Watcher is built around scheduled PageSpeed and Lighthouse-style lab data and Core Web Vitals visibility across many sites. A new Lighthouse category, even an experimental one, is still useful input for roadmaps: which audit names appear in exports, how scores are represented in JSON, and whether customers want pass ratios or binary gates in reports alongside traditional category scores.

Until the ecosystem stabilises, we expect teams to use Agentic Browsing audits as R&D and hygiene, not as the primary KPI they show a client’s marketing lead. Fractional scoring is a feature, not a bug: it matches an immature standard where a single “87” would imply false precision.

Lighthouse Agentic Browsing FAQ

Is Lighthouse Agentic Browsing a Google ranking signal?

The documentation positions the category as experimental and focused on readiness signals, not as a replacement for Search ranking systems. Do not treat fractional pass ratios as an SEO ranking lever without independent confirmation from Search-specific guidance.

Should you drop Performance budgets for Agentic Browsing?

No. Performance budgets (bundle size, LCP guardrails, and similar) answer delivery and UX risk. Agentic readiness answers automation and tool exposure risk. Keep the two separate in how you report and prioritise.

Does every Lighthouse run include Agentic Browsing audits?

Visibility depends on Lighthouse version, channel (Chrome stable vs Canary), and feature availability. Pin versions in CI and read release notes when upgrading, especially if you snapshot audit lists for regression testing.

Do you need llms.txt for Lighthouse Agentic Browsing to pass?

It is one discoverability check in an experimental category. Useful for some architectures; not a universal requirement for a fast, usable product. Treat it as optional unless your organisation standardises on it.

Lighthouse Agentic Browsing: summary

Lighthouse’s Agentic Browsing category is experimental and evaluates machine interaction readiness through deterministic audits.
Scoring is not a 0–100 weighted average like Performance; expect fractional pass ratios, pass or fail (and warnings) per audit, and informational counts in the header.
WebMCP, agent-centric accessibility, CLS, and llms.txt discoverability are central themes. For the current list and behaviour, see Chrome’s official page: Lighthouse agentic browsing scoring.
Fluctuation can come from tool registration timing, DOM and a11y tree shape, and layout shift during the run, so design tests and monitoring accordingly.
Practical next steps: improve real accessibility and stability, evaluate WebMCP deliberately, and keep continuous PageSpeed and CWV monitoring on the metrics that already matter day to day.

If Chrome promotes this category beyond experiment, the habits that pay off will be the same ones that help now: pinned Lighthouse builds, stable lab conditions, and field-backed CLS so you are not optimising noise. Fractional pass ratios are easier to explain to a client than a headline “87” when the underlying rules are still changing. If you run scheduled lab checks across many sites, log Agentic Browsing results as another time series alongside Performance and CWV, not as the first number you chase in a sprint.

CLS Deep-Dive: Common Causes and Fixes for Layout Shift

Fri, 15 May 2026 19:54:00 +0000

Cumulative Layout Shift (CLS) is the Core Web Vital that measures visual stability: whether the page jumps under the user while they are trying to read or tap. A bad CLS score rarely means “CSS is slow” in the abstract. It usually means something changed size or position after the browser first painted, without the user doing something that should move the layout.

Google’s own guidance defines CLS as a score that combines how much unstable content shifts and how far it moves, with good experiences targeting 0.1 or lower at the 75th percentile of page loads in the field (Cumulative Layout Shift (CLS), Optimize CLS). What matters is that you are optimising for real navigations, not a single Lighthouse run.

We go deeper here than the CLS section inside LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. That piece sets thresholds and a short fix list. This article unpacks causes you see on real client builds, how to show which one fired, and what to standardise so the same bug does not reopen on the next template change.

If you need the wider CWV picture first, read What Are Core Web Vitals? A Practical Guide for 2026.

What CLS is measuring (and what it ignores)

CLS aggregates unexpected layout shifts: movement that was not clearly tied to a user gesture in the same interaction window. Images that load without reserved height, fonts that swap metrics, consent banners that push the hero down, and carousels that resize the track all show up here.

It does not penalise every animation. Transforms and opacity changes that do not trigger layout sit outside the problem class we are fixing. The painful shifts are almost always layout-affecting: width, height, margin, padding, or DOM insertions that reflow siblings.

Thresholds for field and lab alignment

Rating	Score
Good	≤ 0.1
Needs improvement	above 0.1 up to 0.25
Poor	above 0.25

Lab CLS from Lighthouse or PageSpeed Insights can read higher or lower than CrUX on the same URL. Use lab traces to see which elements moved; use CrUX (where available) to see whether Chrome users actually experienced instability on navigations you care about.

Why lab CLS and field CLS diverge

Lighthouse-style lab runs focus heavily on initial load. Field CLS can include shifts that happen seconds later: personalised modules, consent flows, chat widgets, and infinite scroll batches. Google’s CLS documentation calls out that gap explicitly when comparing lab tooling with real-user data (Optimize CLS). If your CrUX line is red but Lighthouse is green, do not assume the tooling is wrong. Assume your post-load behaviour is shifting the layout.

Session windows and “bursts” of movement

CLS in the field uses session windows: clusters of layout shifts that occur close together in time count as a single worst burst rather than punishing every micro-jitter twice. The metric evolved to better match how people perceive instability (Evolving the CLS metric). You do not need to memorise the algorithm to ship fixes, but you should know why a single giant banner insertion can dominate the score for a visit even if the rest of the page is calm.

The six causes we see most often on production sites

1. Images, video posters, and iframes without reserved space

The classic failure mode: a hero or card image has no width and height (or no stable aspect-ratio), so when bytes arrive the box grows and everything below it jumps.

Fix: set intrinsic dimensions on the element, or lock an aspect-ratio in CSS that matches the asset. For responsive sets, pair width and height with CSS that scales (max-width: 100%; height: auto is a common pattern when the attributes match the true aspect ratio). For embeds, reserve the iframe box up front.

2. Web fonts that change glyph metrics after swap

When a fallback font and the web font differ in line height or glyph width, text blocks reflow the moment the custom font activates. That is a layout shift even if the user only sees “the text twitch”.

Fix: subset fonts, reduce weight variants you do not need, prefer font-display: optional when a flash of wrong metrics is worse than a short wait, and use size-adjust and fallback tuning where your stack supports it. Preload only the few files that above-the-fold text truly needs.

3. Ad slots, recommendations, and third-party embeds

Empty div placeholders that expand when the network returns an ad size, or “smart” widgets that inject height late, are a major CLS source on media and e-commerce templates.

Fix: give the slot a minimum height that matches your default creative size, negotiate fixed sizes with your ad stack where possible, and avoid collapsing the slot to zero before fill. For non-ad embeds, treat them like images: reserve space and fail closed to a fixed-height error state.

4. Client-side inserted UI above the fold

Cookie banners, promo ribbons, A/B test headers, and “install our app” bars often mount after first paint. If they push main content down, CLS goes up.

Fix: render the shell (or a non-interactive placeholder with the same height) in the initial HTML, or keep the banner in an overlay that does not reflow the document flow. Legal and marketing need wireframes that show reserved space, not only mock-ups at final load.

5. Dynamic content lists and infinite scroll

New cards appended above existing content (for example “new since your last visit”) shift everything the user is reading. Even append-below patterns can shift if heights were guessed wrong.

Fix: prefer append-below with stable card heights, skeleton rows that match final layout, and content-visibility only where you understand its effect on measurement. If you must prepend, animate within a reserved strip rather than reflowing the whole column.

6. Hydration and client-rendered headers in SPAs

Server HTML shows a compact header; the hydrated app mounts a taller nav or adds icons, so the first paint and the “settled” UI disagree.

Fix: match server and client markup for above-the-fold chrome, defer non-critical chrome below the fold, and split shell CSS so the first paint already includes the final header height.

How to prove which cause fired

Work in this order so you do not optimise the wrong layer:

Reproduce in lab. Run PageSpeed Insights on mobile and desktop for the URL and template you care about. Open the “avoid large layout shifts” style diagnostics and note the DOM nodes Lighthouse names.
Use Chrome DevTools. Performance recording with the Layout Shift track, or the Experience section in the Layout pane, ties shifts to frames. The Layout Shift Regions overlay makes jumps obvious on a screen recording. Chrome’s performance docs describe layout shift culprits as a structured way to name unstable elements (Layout shift culprits).
Compare with field. If CrUX shows CLS pain but lab is clean, suspect logged-in routes, personalised headers, slow devices, or interaction-heavy pages where shifts happen after idle. Lab is still useful for element lists; field tells you whether the pain is widespread.

For third-party-heavy pages, cross-check with Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders. The worst CLS offenders are often the same tags that compete with LCP for bytes and main-thread time.

Layout Instability API and `PerformanceObserver`

When you need telemetry in staging (or a one-off console script on a client clone), the Layout Instability API surfaces individual shift events: impacted nodes, scores, and timing. Pair it with a PerformanceObserver so you can log shifts during scripted flows or synthetic monitoring. Google documents the pattern under Debug layout shifts. Chromium-only support is the trade-off, so keep PSI and CrUX as your cross-browser story.

Fix order that matches how agencies ship work

When time is limited, we use this stack rank on client sites:

Intrinsic sizing for all above-the-fold media and embeds. One pass through the template often drops CLS more than any single JS tweak.
Font strategy for the first screen. Lock text blocks that marketing edits often (headlines, promos).
Consent and promo bars. Move to overlay or reserve height in the base layout.
Ad and recommendation slots. Minimum heights and explicit collapse rules.
Framework hydration mismatches. Pair with whoever owns the design system.

CLS, conversion, and why stakeholders should care

Layout shift is not only a Core Web Vital checkbox. It shows up as mis-clicks on primary buttons, lost reading position on long articles, and distrust when the UI feels like it is fighting the user. We do not quote a single universal “CLS costs X percent revenue” figure here because those studies vary by vertical and methodology. We do treat checkout, lead forms, and sticky CTAs as high-risk surfaces: if the button moves between pointer-down and click, you lose conversions even when the metric still looks acceptable on a marketing homepage.

That is why we prefer template-level budgets (PDP, PLP, article, checkout) over one site-wide number. A homepage can absorb a small consent-banner shift; a three-field payment flow cannot.

Stopping CLS from coming back

CLS regressions are layout regression tests. Treat them like accessibility or SEO regressions: add checks rather than hoping QA spots a one-pixel jump.

Performance budgets on LCP and CLS for key templates catch small layout changes that still hurt users. See Performance Budget Thresholds Template and the wider guide to performance budgets.
Scheduled lab runs on the URLs that actually earn revenue or leads flag third-party or CMS drift before CrUX turns red. If you run many properties, How to Set Up Automated PageSpeed Monitoring for Multiple Sites describes the operational shape we build Apogee Watcher around.

Your team keeps the design system; we need stable URLs under test and thresholds that match what your stakeholders agreed. CLS is a good candidate for a hard ceiling (for example, lab CLS below 0.1 on checkout and PDP templates) because shifts there map directly to mis-taps and abandoned reads.

Does fixing CLS help SEO?

Google treats Core Web Vitals as part of the wider page experience signal set; CLS is one leg. Fixing CLS alone does not replace good content or links, but severe instability can correlate with poor engagement metrics that search systems already react to. Treat CLS as user trust and conversion hygiene, not a magic ranking switch.

Why does my Lighthouse CLS differ from Search Console?

Different populations and sessions. Lighthouse uses a controlled load; CrUX aggregates real Chrome navigations. Personalisation, auth, slower hardware, and different viewport sizes change which elements move. Use both: lab for cause lists, field for whether the pain is widespread.

Should I use `transform` for every animation?

transform and opacity are safe for many micro-interactions because they often skip layout when used alone. They do not fix a missing image box or a late-inserted banner. Use transforms for motion; use dimensions and slot contracts for stability.

CLS is one of the few vitals you can improve with mostly HTML and CSS discipline. Start by sizing what the user sees first, then tighten fonts and third parties, then add checks to your release path so the next small marketing change does not undo the work.

When you are ready to monitor CLS and the rest on a schedule across sites, open pricing and pick a plan that matches your portfolio.

Google Search Central Core Web Vitals and Page Experience Docs (2026): What Actually Matters

Tue, 12 May 2026 13:28:33 +0000

Every quarter, agencies get the same brief in different wording: "Can we align with Google's latest Core Web Vitals and Page Experience documentation?" Finding documentation is easy. Converting scattered docs into clear delivery decisions is the hard part.

Most teams over-correct in one of two ways. Some treat every page quality recommendation as a direct ranking lever. Others assume Core Web Vitals are old news and stop monitoring them properly. Both positions create avoidable churn in roadmaps and client expectations.

This article is a practical read of the Search Central documentation landscape in 2026, built around one question: what should agencies prioritise for search outcomes and user outcomes? We focus on official Google documentation wording, not forum folklore. For metric definitions, use What Are Core Web Vitals? A Practical Guide for 2026. For implementation workflows, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Which Google docs influence ranking decisions vs implementation decisions

Google's documentation is not one page. It is a set of documents with different intent:

Search Central pages that describe how systems evaluate pages in search contexts
tooling docs that explain measurement and diagnostics
implementation resources for engineering workflows

When teams blend these layers, planning gets noisy. Measurement recommendations get mistaken for ranking rules. UX best practices get sold as SEO guarantees. Search Central language is careful for a reason. Your roadmap should be careful too.

Core Web Vitals in 2026: what still matters for rankings

Search Central documentation continues to position Core Web Vitals as part of Google's broader work on page experience and helpful results. That does not mean "hit green and rank first." It means CWV remain quality signals, while relevance and content quality still carry primary weight.

In practice, agencies should treat CWV as:

a baseline quality requirement for competitive SERPs
a risk-control system for regressions
a trust signal in client reporting

That framing is more accurate than promising ranking jumps from isolated metric gains. It also protects account teams from overpromising to non-technical stakeholders.

Page Experience in 2026: how to interpret it in agency delivery

Many teams still reference "Page Experience" like it is a single score gate. It is not. The useful 2026 interpretation is operational:

remove obvious friction that hurts real users
keep performance and usability signals stable over time
avoid technical debt that quietly degrades mobile experience

The mistake is treating Page Experience as either everything or nothing. A better view is weighted contribution. Page quality supports search outcomes when content quality and intent alignment are already strong.

Which signals to treat as ranking-sensitive vs workflow-sensitive

A practical way to plan work is to separate two groups.

Ranking-sensitive signals (where search impact is likely)

sustained CWV degradation on important templates
mobile experience regressions on high-intent pages
repeated instability that affects crawlability or interaction

Workflow-sensitive signals (critical for delivery, indirect for rankings)

alert policies
reporting cadence
diagnostic depth in lab tooling
documentation quality in handovers

Both groups matter. Only one should be sold as direct ranking mechanics. This distinction makes client communication cleaner and keeps teams honest.

Why reading docs alone fails without scheduled monitoring

Reading docs is not a system. Teams need recurring measurement if they want documentation guidance to become outcomes.

Without scheduled monitoring, agencies usually discover regressions too late:

after a redesign rollout
after third-party script additions
after CMS content changes that alter template weight

That delay weakens both performance and SEO narratives. If you run only manual checks, you can explain what happened. You cannot prove you were in control of it.

For a concrete comparison of this gap, see Automated vs Manual PageSpeed Testing: A Time and Cost Comparison.

Common myths agencies repeat about Core Web Vitals and Page Experience

Myth 1: "If all URLs are green, rankings will rise automatically"

Green CWV status reduces risk and improves user conditions. It does not replace relevance, authority, or search intent match.

Myth 2: "Page Experience updates mean we should pause content work"

False trade-off. Content quality and technical quality are not alternatives. Strong teams ship both, with clear sequencing.

Myth 3: "Search Console warnings mean the whole site is broken"

Warnings usually indicate segment-level problems (template, device class, or URL set). Treat them as prioritisation input, not panic alarms.

Myth 4: "One Lighthouse run is enough to prove page quality"

Lab diagnostics are useful snapshots. They are not a monitoring programme. Use them with history, not as one-off proof.

How agencies should operationalise Search Central guidance in 2026

If your goal is to align with Search Central documentation while keeping client delivery efficient, this sequence works well.

Step 1: Define baseline metrics per page template

Set baselines for homepage, key landing templates, product/service pages, and conversion paths. Avoid sitewide averages as your only control layer.

Step 2: Set thresholds by business context and page type

Different page types justify different sensitivity. A campaign page with heavy media may need different guardrails than a lean documentation page.

Use Performance Budget Thresholds Template to formalise thresholds instead of negotiating from scratch every month.

Step 3: Schedule monitoring on cadence, not by memory

Run scheduled checks across the pages that matter. The value is consistency. You need trendlines and alertable changes, not isolated screenshots.

Step 4: Report decisions, not just metric snapshots

Client reports should answer:

what changed
why it changed
whether it affects business-critical flows
what action is next

If your reports only list numbers, teams still argue about interpretation each month. Use Client-Ready Core Web Vitals Report Outline for a decision-first structure.

Step 5: Reconcile Search Central docs with field reality each quarter

Documentation interpretation drifts over time in organisations. A quarterly review keeps your internal guidance aligned with current Search Central wording and your field data.

How to triage Search Central updates without backlog churn

The "what's new" pages are useful, but not every update should trigger backlog churn. A simple triage model helps:

Clarification update: adjust internal docs, no immediate engineering work
Measurement interpretation update: review reporting language and thresholds
System-level relevance update: reassess roadmap priority

This keeps teams from swinging between "ignore it" and "rewrite everything."

Where Apogee Watcher fits in a documentation-led workflow

Apogee Watcher does not replace Search Central documentation. It helps agencies operationalise that guidance across multiple sites by keeping monitoring, trend visibility, and reporting in one place.

That matters most when teams manage portfolios, not single projects. Documentation tells you what to care about. Monitoring tells you when implementation drifts. Reporting tells clients what changed and what comes next.

If your agency is trying to reduce manual monitoring overhead while keeping documentation-aligned delivery, start with Core Web Vitals Monitoring Checklist for Agencies and map it to your current client review cycle.

FAQ

Do Core Web Vitals still matter for SEO in 2026?

Yes, they still matter as part of broader page quality and user experience systems. They should be managed as ongoing quality controls, not as one-time ranking hacks.

Is Page Experience a single ranking score?

No. Treat it as a set of quality dimensions and signals. Do not reduce it to one pass/fail narrative in client communication.

Should agencies prioritise CWV work over content strategy?

No. They are complementary. Weak content cannot be rescued by perfect metrics, and strong content is undermined by unstable experience.

Can we rely on Search Console alone?

Search Console is essential, but agencies managing multiple sites should pair it with scheduled monitoring and operational reporting.

What is the biggest implementation mistake agencies make?

Manual-only monitoring with inconsistent reporting. Teams detect issues late, then spend more time explaining regressions than preventing them.

Summary

The strongest interpretation of Search Central Core Web Vitals and Page Experience documentation in 2026 is practical, not dramatic. Keep CWV and page quality as stable operating standards. Avoid treating every guideline as a direct ranking switch. Build a monitoring and reporting process that turns documentation into repeatable execution.

If your team still relies on manual checks and ad hoc monthly decks, move to a cadence where measurement is continuous and analysis stays human. Start with Performance Budget Thresholds Template, then implement automated monitoring across key templates. That is how you stay aligned with documentation without turning SEO planning into noise.

Your client read the performance PDF. Then nothing happened.

Mon, 11 May 2026 07:40:33 +0000

You sent the report on Friday, and the client replied on Monday: "Looks good, thanks." Then nothing moved.

If you work in an agency, this is familiar. The report was not wrong. The metrics were there. You probably even explained LCP, INP, and CLS clearly. Still, no owner picked up the work, no ticket landed in sprint, and the same issues appeared again next month.

The problem is usually not the PDF itself. The problem is the operating model around it. For templates you can reuse directly, start with:

This post is the practical layer between those templates and day-to-day delivery.

Why reports stall after "looks good"

In our experience, one of these four gaps is present:

No clear decision The report presents data, but not the decision required this week.
No named owner "Dev team" is not an owner. One person needs the task in a board with a due date.
No business impact wording Numbers are shown, but business impact is not translated into lost leads, paid traffic waste, or checkout risk.
No review rhythm The report is delivered ad hoc, so teams treat it as commentary instead of an operating input.

Until those gaps close, performance reporting becomes a polite monthly ritual.

A report should produce three outputs, every time

Before a report leaves your team, check that it will produce:

One decision (what gets prioritised now)
One owner (who ships it)
One date (when it will be reviewed or completed)

If any of those are missing, the document is not done yet.

The agenda we use in client review calls

You do not need a long meeting. Thirty minutes is enough when the agenda is strict.

1) Baseline in one minute

Open with trend, not raw noise:

What changed since last cycle
Which template or route worsened
Which metric crossed agreed threshold

Keep it short. The point is alignment, not narration.

2) Top three regressions only

Do not bring ten issues to a team that can ship three.

For each item, include:

affected URL group (not only a single page)
likely root cause class (image payload, third-party script, render-blocking path, etc.)
size estimate (small, medium, large)

This reduces the common "we need more analysis first" loop.

3) One decision per regression

For each of the top three:

fix this sprint
defer with reason
monitor for one more cycle

Write the decision live during the call.

4) Confirm owner and due date before closing

No owner means no outcome, and no date means no accountability.

End the call only after each accepted action has:

owner name
board/ticket reference
expected review date

Turn metrics into client language

Most clients do not need another lecture on how Lighthouse works. They need to know what changes if they fund or delay the fix.

Instead of:
"INP p75 moved from 180ms to 270ms."

Use:
"Checkout interaction delay moved into a zone where users feel lag on mobile. If paid traffic keeps scaling, this increases drop-off risk during high-intent clicks."

Same data, different consequence.

Build a monthly cadence teams can trust

A reliable rhythm beats heroic one-off audits.

We suggest:

Week 1: collect baseline and annotate anomalies
Week 2: client review call and decisions
Week 3: implementation check-in with owners
Week 4: verify shipped fixes and update next cycle backlog

When this cadence runs for 2-3 months, reporting stops being "extra work" and starts functioning like a delivery control loop.

Where agencies lose margin (quietly)

Many agencies absorb performance analysis time without noticing:

repeated explanation of the same issue each month
rescue debugging before stakeholder calls
context switching because ownership was unclear

A tighter report-to-decision workflow protects margin because teams stop re-diagnosing issues that were already known.

A simple scorecard to track report quality

Add this to your internal QA before sending any client report:

Did we state one clear decision?
Did each accepted action get one owner and one date?
Did we translate at least one technical metric into business risk?
Did we limit priorities to what can ship this cycle?
Did we schedule the next review before ending the call?

If three or fewer are true, expect "thanks, looks good" and little follow-through.

What to do next

Use your next client report as a test:

Limit it to top three decisions.
Assign one owner per accepted action during the call.
Book a verification checkpoint before the meeting ends.

Then compare completion rate against your previous cycle.

Better reporting is not about prettier PDFs. It is about whether work gets shipped after the PDF lands.

Performance Monitoring for EdTech: What to Measure Across Enrolment, Learning, and Checkout

Tue, 28 Apr 2026 20:08:46 +0000

EdTech teams often inherit a monitoring setup built for generic SaaS dashboards, not learning workflows. That mismatch causes two problems: you miss issues that hurt students, and you spend hours chasing alerts that do not affect outcomes.

In education products, performance has to serve three groups at once: learners, educators, and administrators. Each group uses different pages, on different devices, at different times. A home page score can look healthy while quiz submission pages fail on school networks. A checkout flow can be fast while live-class pages feel sticky when students open chat and polls.

This post breaks performance monitoring for EdTech into practical parts: what to measure, where to measure it, and how to build an alerting policy that helps your team act quickly.

If you are new to the metrics themselves, start with 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. This guide assumes you know the basics and want an EdTech-specific operating model.

Why EdTech needs a different monitoring approach

Most EdTech products mix content, interaction, media, and transactions in one platform. That creates a wider performance surface than many B2B apps.

Typical patterns include:

Public marketing pages for course discovery and trust building.
Logged-in learner dashboards with heavy personalisation.
Interactive lesson pages with video, chat, quizzes, and progress tracking.
Assignment upload and grading workflows with file processing.
Payment and enrolment flows for courses, subscriptions, or certifications.

Each area has different failure modes. Slow image loading on a brochure page is not the same issue as delayed quiz feedback in a timed assessment. If you treat both as one blended score, you lose the signal that helps prioritisation.

EdTech also has sharp traffic peaks around class start times, assignment deadlines, and exam periods. These predictable surges stress front-end rendering, backend APIs, and third-party services at the same time. Monitoring has to reflect those windows instead of daily averages only.

Map metrics to the learner journey

A useful EdTech monitoring plan starts with journey stages, not tools.

1) Discovery and enrolment

This stage includes landing pages, course catalogues, search/filter pages, course detail pages, and signup or checkout.

Speed here is not a cosmetic KPI. In the Google-commissioned Deloitte and 55 study, a 0.1 second performance improvement across key speed metrics was linked to stronger funnel progression and conversion outcomes across large consumer journeys (web.dev summary). EdTech funnels differ from retail, but the operational lesson is the same: small delays at step transitions compound into measurable business loss.

What usually matters most:

LCP on landing, catalogue, and course detail pages.
INP for search filters, date pickers, and plan selection.
CLS in pricing sections, promo banners, and checkout forms.
Conversion step timing for account creation and payment completion.

If course imagery and promo embeds are heavy, LCP often degrades first. If payment pages load multiple scripts, INP and CLS often degrade during form interaction.

2) First learning session

The first minutes after signup decide activation for many education products.

Key surfaces:

Onboarding checklist.
First lesson page.
Video player load and first playable frame.
First quiz or exercise interaction.

Useful signals:

Time to first meaningful lesson interaction.
INP on first quiz answer and submit actions.
Error rate for lesson-content API calls.
Video startup delay and buffering events.

This stage is where technical performance and product activation overlap directly.

3) Ongoing study and assessment

Returning learners use calendar views, progress dashboards, lesson modules, discussion threads, and assignment forms.

Watch for:

INP on high-frequency actions (next lesson, mark complete, submit answer).
API latency percentiles for progress save and assessment endpoints.
Front-end error rates tied to specific lesson templates.
Long-task frequency during interactive sessions.

A page can load fast and still feel broken if each click takes 400-600ms to respond. INP and interaction-level traces reveal this faster than load metrics alone.

4) Educator and admin workflows

In many EdTech products, instructors and admins perform heavy actions:

Uploading content packs.
Bulk enrolment.
Grade export.
Attendance sync.
Reporting dashboard filters.

These screens are operationally critical. If they slow down, support tickets rise and delivery teams lose trust in the platform. Include role-based dashboards and admin actions in your monitoring scope, even if public pages are the top SEO focus.

Core metrics for EdTech teams

Core Web Vitals remain the baseline, but EdTech needs a wider set around interactions and reliability.

Core Web Vitals

LCP: loading quality for first content and lesson entry points.
INP: responsiveness for quiz, navigation, discussion, and form actions.
CLS: visual stability for pages with embeds, dynamic modules, and notices.

Use separate thresholds by template. A marketing home page and a lesson player page should not share one budget by default.

Supporting technical metrics

API latency at p50, p95, and p99 for key learning actions.
Front-end JavaScript error rate by route.
Failed requests by endpoint group (content, progress, auth, payment).
Video startup time and rebuffer ratio where video is core.
Queue or processing time for assignment upload and grading jobs.

This set helps connect front-end symptoms to backend causes.

Outcome-linked product metrics

Pair technical monitoring with product outcomes:

Signup completion rate.
First lesson started rate.
Lesson completion rate.
Quiz submission success rate.
Payment completion rate.
Support tickets tagged with speed or loading issues.

When these are tracked side by side, performance work is easier to prioritise in roadmap discussions.

Device and network realities in education

EdTech audiences are often more mixed than other SaaS categories:

Students on older phones.
Shared household devices.
School-managed laptops with strict browser policies.
Variable Wi-Fi and mobile data conditions.

This is why desktop-only checks can create false confidence. Run both mobile and desktop, and set your default review lens to mobile where student traffic is high. Our guide on Mobile vs Desktop Core Web Vitals Monitoring: Why You Need Both covers this pattern in detail.

Global access data also supports this approach. UNESCO's GEM report notes that connectivity and device access remain uneven across education systems, and during pandemic-era remote learning at least 500 million students were not reached by remote provision (GEM 2023). If your monitoring assumes modern devices and stable broadband, you can miss the exact populations most likely to struggle.

In addition, test representative geographies if your platform serves multiple regions. International cohorts can face latency patterns that a single-region test misses.

Synthetic monitoring, field data, and in-app telemetry

For EdTech operations, each source answers a different question:

Synthetic tests: "Did this route regress after deploy?"
Field data: "What are learners and educators actually experiencing?"
In-app telemetry: "Which user action failed, and at which step?"

Synthetic monitoring gives repeatability across your key URLs and user journeys. It is excellent for regressions, budget checks, and release confidence.

Field data (for example via CrUX where coverage exists) adds real-user outcomes but can be delayed and sparse on low-traffic routes.

In-app telemetry gives event-level visibility for core actions like submit quiz, upload assignment, or complete checkout.

The strongest setup combines all three:

Scheduled synthetic checks for route coverage and trend history.
Field signals for user reality and long-term quality.
Product instrumentation for action-level failures and drop-offs.

Alerting policy that avoids fatigue

A common EdTech issue is alert fatigue during release weeks. Teams receive many warnings and ignore most of them.

Use a tiered policy:

Tier 1: learner-critical alerts (immediate)

Trigger immediately for:

Large INP regression on lesson or quiz pages.
Elevated error rate on progress save or submission endpoints.
Checkout failures above baseline.
Major LCP degradation on login and first lesson routes.

These alerts should page the owning team during core operating hours.

Tier 2: quality drift alerts (daily review)

Trigger for:

Smaller but persistent LCP or CLS drift.
Elevated third-party script cost on discovery pages.
Slow admin report routes outside incident thresholds.

Route these to a daily triage queue rather than instant paging.

Tier 3: planning signals (weekly)

Track trends like:

Device class degradation over time.
Seasonal spikes around exam windows.
Performance budget breaches by template over 2-4 weeks.

Use these for sprint planning and technical debt prioritisation.

Cooldowns and deduplication matter as much as thresholds. One incident should not create twenty notifications across channels.

Third-party dependencies in learning platforms

EdTech products often depend on many external services:

Analytics and product analytics.
Video and interactive media.
Classroom engagement widgets.
Proctoring or identity checks.
Payment processors.
Support chat.

Each script can add latency or thread blocking. During audits, measure not only total page load but script-level contribution on critical routes.

A practical process:

Inventory third-party scripts by route group.
Run before/after synthetic tests when adding a vendor.
Set per-route budgets for third-party weight and request count.
Review quarterly and remove low-value scripts.

For many teams, this single discipline creates immediate gains on learning and checkout pages.

A practical 30-day rollout plan

If your current setup is ad hoc, use a phased rollout:

Week 1: define route groups and success metrics

List your top learner, educator, and admin routes.
Tag routes by journey stage (discovery, first session, ongoing study, admin).
Agree on critical outcomes to protect (activation, completion, checkout).

This route-first discipline prevents "dashboard theatre". The same UNESCO GEM evidence base reports substantial underuse of paid education software licences in practice, including US data showing high non-use rates across procured tools (GEM 2023 chapter). Monitoring tied to real, high-frequency workflows protects you from buying observability that teams rarely use when it matters.

Week 2: instrument baseline monitoring

Configure scheduled synthetic tests for each route group.
Record baseline LCP, INP, CLS, error rate, and API latency.
Confirm dashboards are segmented by role and device.

Week 3: add alert tiers and ownership

Define Tier 1/2/3 thresholds.
Assign route owners and on-call expectations.
Configure cooldowns to reduce noise.

Week 4: connect performance to product review

Add a weekly performance review to product and engineering rituals.
Include outcome metrics in the same dashboard or report.
Prioritise top regressions by learner impact and business effect.

This plan is small enough to run without a full platform overhaul.

Where Apogee Watcher fits for EdTech teams

Apogee Watcher helps teams monitor multiple routes and sites on a schedule, with historical trends and threshold alerts. That is useful when you manage several programme sites, white-label properties, or many route templates across one learning platform.

For teams supporting education clients, it also reduces manual reporting overhead. Instead of collecting one-off snapshots, you get trend visibility and a repeatable view of route health.

If you are currently in a manual workflow, compare your existing process with Automated vs Manual PageSpeed Testing: A Time and Cost Comparison. For setup guidance, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

FAQ

What should EdTech teams monitor first?

Start with a small set of learner-critical routes: login, first lesson, one quiz page, and checkout or enrolment. Track LCP, INP, CLS, error rate, and API latency for those routes before expanding coverage.

Is Core Web Vitals enough for education products?

Core Web Vitals are necessary but not sufficient. Add interaction and reliability metrics such as request failures, endpoint latency, and action success rates for submissions and payments.

How often should we run synthetic tests?

For learner-critical routes, daily is a practical default. During high-risk periods such as launch week or exam season, increase frequency on key pages. For lower-risk admin pages, weekly can be enough.

How do we avoid alert fatigue?

Use tiered thresholds, cooldown windows, and clear ownership. Page only on learner-critical incidents. Move smaller drifts into daily or weekly review workflows.

Can agencies use the same framework for multiple education clients?

Yes. Keep a shared monitoring blueprint, then customise route lists and thresholds per client. Standard process with client-specific budgets is usually easier to scale than fully custom monitoring from scratch.

Summary

Performance monitoring for EdTech works best when it mirrors real learning journeys, not generic page groups. Monitor discovery, first session, ongoing study, and admin operations as separate surfaces. Pair Core Web Vitals with interaction and reliability signals, then connect those signals to activation, completion, and checkout outcomes.

Teams that do this well usually share three habits: route-based budgets, tiered alerting, and weekly review tied to product decisions. Start small, make ownership clear, and expand once your team trusts the signal.

Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders

Mon, 27 Apr 2026 09:12:45 +0000

Most “performance projects” start with images and fonts. Fair enough. But the pages that still feel bad after a hero image is optimised, preloaded, and served from a CDN are often suffering from a different problem: third-party JavaScript. Tag managers, chat widgets, A/B tests, and social embeds do not have to be evil. Left unmanaged, they absolutely compete with your first paint, your LCP, and the interactions that INP measures. This guide is a practical way to name the worst offenders, decide what to cut or delay, and prove the win before the marketing team files a ticket because “the numbers look wrong”.

What “third party” really means in performance work

A third-party script is any JavaScript, iframe, or stylesheet you did not write that loads from another origin: analytics, ads, reviews, personalisation, consent platforms, and the tag manager that wires them together. Browsers do not care whether a script is “small business friendly”. They still parse it, sometimes execute it in the hot path, and every long task on the main thread delays input handling and the next paint.

Core Web Vitals are the clearest public scorecard, but the mechanism underneath is the same in smaller shops and enterprise:

LCP can move if a late-loading script or font pushes your hero, or if third-party work delays rendering.
INP gets worse when the main thread is busy; third-party long tasks and heavy event listeners sit in front of your own code.
Total Blocking Time (TBT) in lab tools like Lighthouse measures main-thread blocking after First Contentful Paint; it often correlates with poor INP in the field, but TBT is not a substitute for INP: it can miss slow interactions that happen after load (where a lot of third-party widgets do their work).

So the job is not “remove all third parties”. The job is to order them, time them, and measure so you are not optimising in the dark.

Step 1: Get a defensible list of what actually loads

You cannot fix what you cannot see. Start with a cold, hard inventory:

View source and search for and src=.** Note every external host. Do the same for link rel="preconnect" and import() chains if you use a modern bundler.
Open DevTools, Network, disable cache, hard reload. Sort by “Initiator” or group by “Domain” so you see which product pulled in which chain. A single GTM or Segment container often fans out to twenty requests.
Use your tag manager’s preview mode to log which tags fire on which page templates. A homepage does not have to carry the same load as a logged-in account area, but in practice one container often rules them all until someone audits it.

Read the Initiator column and the waterfall to see which script pulled in which chain. Use Group by options in the table header if you want rows collapsed by Domain (wording varies by Chrome version).

For clients, this inventory belongs in the same place as your design system: a short internal doc, not a one-off email. When a new pixel appears, you can ask “which tag added this?” and roll back a single change instead of re-running a mystery hunt every quarter.

Step 2: Use Lighthouse to rank third-party cost (not just bytes)

Lighthouse in Chrome (or the PageSpeed Insights “Diagnose performance issues” section) surfaces third-party impact in a dedicated audit (title: Reduce the impact of third-party code). It lists transfer size, CPU time, and main-thread blocking time by origin. Under the documented rules, Lighthouse fails this check when third-party code blocks the main thread for more than 250ms in total during the load it measures. Treat that as a first “who is expensive?” table before you dig into traces.

Depending on Lighthouse version, you may see the same idea under newer Performance insights (for example third-party coverage in Lighthouse 13’s insight model); the underlying job is unchanged: quantify cost per provider.

Pair it with:

“Reduce JavaScript execution time”, “Reduce the impact of third-party code” (above), and “Minimize main-thread work” where those audits appear (Lighthouse UI uses US spelling). The exact labels move between releases; the intent does not: find scripts that add long tasks and network overhead. For a walkthrough, see Identify slow third-party JavaScript.
A lab run on the slowest realistic conditions (mobile, throttled) so the ranking matches how your users experience the page, not a developer laptop on Wi-Fi.

The same audit appears in PageSpeed Insights under performance diagnostics; use it as your first sorted table of “who costs what” before DevTools deep dives.

Lab data is not field data, but for third-party work it is often more actionable: you can block a host in DevTools, reload, and see the same page without the tag.

Step 3: Use DevTools to find the moment a script hurts

Lighthouse points at winners and losers. DevTools shows when they run:

Performance panel: record a page load, then look for long yellow blocks (Scripting) and the Main flame chart. The Long Tasks API uses a 50ms threshold for a “long task”; tasks longer than that contribute to how “busy” the main thread feels. Heavy ads or frameworks often show 50–200ms+ slices.
Bottom-up / Call tree on the same recording, filtered by a third-party domain, tells you if time is in parse, compile, or your own app code after a third party schedules work.
Coverage tab: load a page, then record which portions of a third-party file actually run. A 400KB file that was fully downloaded but only 5% “used” is a candidate for lazy loading or removal, not a pat on the back for gzip.

Record a load (and, for INP, a real click or menu open). Long Scripting slices on the main thread are what make interactions feel delayed.

Coverage answers “did we even execute this?” High unused percentage means you may be shipping JS you never needed on that route.

If you are chasing INP, repeat the recording with a real interaction: open the menu, add to cart, open chat. The worst third-party work often appears after first load, when the widget initialises on scroll or on first click.

Step 4: Map findings to CWV and business impact

Not every big script is worth a fight. Sort candidates like this:

Question	If “yes”
Does it sit on the critical path before first meaningful paint?	Push it later or to a worker pattern (see below).
Does it add long main-thread work during typical interactions?	It is a prime INP target.
Is it on every page but only used on checkout?	Load it on checkout routes only.
Is it duplicated (same vendor, two tags)?	Merge at the source; duplicate pixels are a classic agency waste.
Does the marketing team need it for attribution this quarter?	Optimise the delivery first; removal is a product decision, not a dev-only one.

In multi-site and agency work, the same “standard” GTM install often ships to every property. A template fix in the container is cheaper than renegotiating a vendor contract, so fix the shared layer before you re-architect a single site.

Step 5: Fix patterns that work in production

Defer what you can. Non-critical script tags should not sit synchronously in . Your framework or CMS may be injecting them; override at the template level where possible. For scripts you truly need early, you are trading against LCP: keep the list as short as your analytics owner allows.

Load on interaction, not on paint. Chat widgets, non-critical A/B tools, and “nice to have” personalisation can wait until scroll, a tab click, or a 2–3 second idle timeout. requestIdleCallback is not supported everywhere, but a small setTimeout after load is still a step up from “block first paint”.

Facade heavy embeds where it makes sense for your content. A static placeholder that loads the real YouTube, map, or social widget on click (or on entering the viewport) cuts initial JavaScript and often improves LCP on content-heavy pages. See Efficiently load third-party JavaScript and implement facades in a way that does not break keyboard users or your consent flow.

Move work off the main thread for eligible scripts. Partytown and similar patterns run particular scripts in a web worker. They are not a free lunch (serialisation, compatibility), but for analytics and support scripts that can cooperate, they reduce main-thread contention. Fit them into your performance budget as an experiment, not a silent default, until you have tested INP and edge cases.

Server-side and edge tagging. If your use case is “send a conversion to ad platforms”, a server GTM on Cloud Run, or API-based server events, can remove a client tag entirely. The implementation cost is higher; the client-side win is real on interaction-heavy pages.

Govern the tag manager. One owner, naming conventions, a rule that new tags do not go live in “All Pages” without review, and a quarterly cull of unused tags will save more CPU than another round of webpack tweaks.

Step 6: Prove the change and set a floor so it sticks

Re-run the same Lighthouse and DevTools profile after the change. Keep a one-page before/after note: third-party main-thread ms, LCP, INP (if you have field data in Search Console’s Core Web Vitals report or RUM), and a screenshot of the GTM version number. If someone re-imports a container without your fixes, you have an audit trail.

For portfolios, that proof is the difference between “we sped you up” and “we keep you fast when the next tag ships”. Tying the numbers to a monitoring or budget alert means a regression is an email, not a surprise in a QBR. Apogee Watcher is built for that loop: schedule PageSpeed runs, set budgets per site or template, and get alerts when lab metrics drift. We do not replace your tag manager; we give you a steady signal that the work you just shipped (or the tag someone added at 5 p.m. Friday) is still within the thresholds you and the client agreed.

If you are still building a governance story for your team, the Core Web Vitals monitoring checklist for agencies is a good companion: it includes a third-party pass as part of ongoing ops, not a one-off launch audit.

FAQ

Are third-party scripts the main cause of bad Core Web Vitals?

Not always, but they are a common cause of high INP and TBT, and they keep turning up in audits for LCP and CLS when they shift layout or delay rendering. TBT in the lab and INP in the field are related but not the same (post-load interactions matter for INP). Your own images and font strategy still matter. Treat third parties as a parallel track you measure with the same rigour as first-party code.

Should I use only field data to prioritise?

Field data (CrUX, RUM) tells you who suffers in the real world. Lab data and DevTools help you attribute that pain to a specific script before you change contracts or tags. Use both. For more on the split, read PageSpeed Insights vs automated monitoring: when manual checks are not enough and Understanding INP: the newest Core Web Vital.

What is the fastest win?

In our experience, the fastest win is cutting duplicate tags and loading chat and secondary widgets after load or on interaction, before you touch your core bundle. The slowest is migrating to full server-side tagging, which pays off for large programmes but is not a Friday afternoon change.

Will delaying analytics break reporting?

It can change “session” definitions if you delay too aggressively or if your vendor counts page views before a delayed tag fires. Align with whoever owns the data model. Often you can still send one lightweight pageview early and load heavier remarketing and enrichment after idle.

How do I explain this to a non-technical stakeholder?

Framed the right way, it is a cost conversation: every script has a time cost on the user’s device. The table from Lighthouse, plus one before/after number for LCP or INP, is usually enough to get approval for a staged rollout.

Image Optimisation Strategies for Better LCP Scores

Sat, 25 Apr 2026 06:55:16 +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 , 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 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:

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 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 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 or 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.

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

Thu, 23 Apr 2026 22:56:03 +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.

State of Small Business Websites (2026 Study): We Audited 292 Sites. 96.9% Fail Core Web Vitals

Thu, 23 Apr 2026 20:02:01 +0000

Most performance articles repeat the same three stats everyone has already read. "Amazon found a 100ms delay costs 1% revenue." "53% of mobile users leave if a page takes over 3 seconds." You have seen them. They are old.

Last month we ran a different experiment. We took a real-world list of 292 North American B2B prospects, pointed our headless browser audit tool at every site, and measured what actually ships to production in 2026.

The short version: 96.9% of the sites we audited fail at least one Core Web Vital on mobile. Only 3.1% pass all three. And 100% of 191 sites with valid accessibility data failed the Link Labels check. Not most. Not 95%. Every single one.

The full report, dataset, and methodology are open source. This post is the developer-angle on what is breaking and why.

Report: axiondeepdigital.com/research/state-of-small-business-websites-2026

Key stats (copy-paste friendly)

Metric	Sample	Result
Fail at least one Core Web Vital (mobile)	n=191	96.9%
Pass all three Core Web Vitals (mobile)	n=191	3.1%
Fail axe-core Link Labels rule	n=191	100%
Post "poor" mobile LCP (>4.0s)	n=191	86.4%
Post "poor" mobile FCP (>3.0s)	n=191	72.4%
Pass mobile CLS (<0.1)	n=191	85.5%
Total domains scanned	n=292	—

Source: State of Small Business Websites 2026, Axion Deep Digital Research. April 2026.

How we measured

This study runs on our production audit infrastructure. DeepAudit AI is the same pipeline we run against client sites daily. The dataset below is 292 consecutive scans pulled from a single week in April 2026. Because the pipeline runs continuously, future snapshots will replicate this analysis against a larger and eventually randomized sample, and the methodology stays frozen so the comparisons hold.

Each scan runs a real Chromium instance inside a Lambda (Puppeteer plus @sparticuz/chromium), renders the page the way Googlebot would, waits for hydration, and then measures against:

Lighthouse mobile Core Web Vitals (LCP, FCP, CLS) using Google's published thresholds
axe-core accessibility evaluations
60+ technical SEO checks (meta, headings, schema, canonicals, alt text)
Open PageRank for domain authority

191 of the 292 sites returned valid Lighthouse mobile data. 191 returned valid axe-core data. 260 had valid Open PageRank. Every finding below is gated on the subset of sites where the relevant measurement succeeded, not averaged over missing data.

What this study does and does not prove

Before the numbers, the honest scope:

This is a purposive sample, not a random one. The 292 domains came from a North American B2B prospect list, which skews toward construction, trades, and small professional services. It is not representative of the web as a whole.
What it does represent is the category of business that small digital agencies actually get hired to fix. If you pitch to this market, the sites you convert will look like this sample.
One snapshot per site. Results reflect the state of each site on the day it was scanned. A site could have shipped a perf fix the next morning.
Lighthouse mobile scores vary. Google's Lighthouse CI documentation acknowledges a ±5 point variance across runs. None of the findings below hinge on a difference smaller than that. The 96.9% failure rate and the 100% Link Labels failure are robust to that noise.

The full dataset is open. Every row, every score, every axe-core violation is downloadable from the methodology page. If you disagree with a finding, you can reproduce it or refute it.

Finding 1: LCP is the silent killer

86.4% of sites post poor mobile LCP. Only 5.2% are good.

Largest Contentful Paint over 4.0 seconds is Google's "poor" threshold. Most of the sites we measured clock in between 4 and 8 seconds on mobile. Some over 10.

What is causing it, in order of frequency:

1. Hero images served as full-resolution PNG

One site we looked at ships a 2400x1600 PNG as its hero, served at 3.2 MB. Mobile user on 4G? That is 6 seconds of transfer on a good connection. The image renders last, so LCP measures the whole download.

The fix is trivial if you are on Next.js:

import Image from 'next/image';

<Image
  src="/hero.jpg"
  alt="..."
  width={1200}
  height={600}
  priority
  sizes="(max-width: 768px) 100vw, 1200px"
  quality={75}
/>

priority injects a preload hint. sizes tells the browser to pick the right srcset variant for the viewport. quality=75 on JPEG looks identical to 90 in blind testing. Next.js serves WebP or AVIF automatically based on the Accept header.

If you are not on Next.js, the same rules apply. <link rel="preload" as="image">, <picture> with AVIF first, and a srcset + sizes combo.

2. Render-blocking JavaScript in the head

Tag Manager. Hotjar. Intercom. Drift. One of every four sites we audited had three or more synchronous third-party scripts in the head. Each one blocks HTML parsing until it is fetched, parsed, and executed.

The defer attribute is older than most React developers. Use it:

<script src="/vendor/gtm.js" defer></script>

Or on Next.js:

import Script from 'next/script';

<Script src="https://www.googletagmanager.com/gtm.js" strategy="afterInteractive" />
<Script src="https://widget.intercom.io/widget.js" strategy="lazyOnload" />

afterInteractive loads after hydration. lazyOnload waits until the browser is idle. Neither blocks the LCP element.

3. Custom fonts with no `font-display` directive

Default font-loading behavior blocks text rendering for up to 3 seconds. If your LCP element contains text, it cannot paint until the font loads.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

swap tells the browser to render with a system fallback immediately, then swap to the custom font once it arrives. On Next.js, next/font does this automatically. On anything else, you write it in three lines.

Finding 2: First Contentful Paint is worse than LCP, and nobody talks about it

72.4% of sites post poor mobile FCP.

FCP is the time to the first pixel of anything meaningful. It is the metric that correlates most directly with user perception of speed. If it takes 4 seconds to paint a single headline, the user has already decided the site is broken, regardless of how fast the rest of the page loads.

The causes overlap with LCP but there is one specific pattern we saw repeatedly: a client-side routing framework rehydrating the whole page before rendering anything.

Here is the anti-pattern. A site ships a React SPA that serves an empty shell HTML, boots up, fetches the route data, then renders. The browser sees nothing visible until JavaScript finishes executing. The fix is either:

Server-side render the first paint (Next.js App Router, Remix, SvelteKit — pick one)
Ship static HTML for the first paint, hydrate on demand (Astro model)

If you are shipping a React SPA as the entire site in 2026, you are fighting gravity. The frameworks that win on FCP are the ones that put real HTML on the first GET.

Finding 3: 100% of sites failed Link Labels

This is the number that should bother you most.

axe-core's Link Labels rule checks that every <a> element has a discernible accessible name. Every single one of the 191 sites we evaluated had at least one link that failed this rule. Every one.

What does a failing link look like? It looks like this:

<a href="/products">
  <svg>...</svg>
</a>

A screen reader reads "link" and stops. There is no text content and no aria-label. The user has no idea where the link goes.

The fix is one attribute:

<a href="/products" aria-label="Our products">
  <svg aria-hidden="true">...</svg>
</a>

Social icon sets are the most common offender. Every Twitter, LinkedIn, and Instagram icon in every footer. Almost every one of them was an unlabeled link. Across 191 sites, we did not find a single site that had labeled every one of its icon-only links.

This is not an edge case. This is the baseline.

The broader pattern is: developers ship components library icons without reading the a11y docs. React-icons, Font Awesome, Lucide, Heroicons — all of them render SVGs inside anchors by default, and unless you explicitly add an aria-label or sibling text, the resulting link is unreadable.

If you ship a component with an icon-only link, wrap it:

export function SocialLink({ href, label, children }: SocialLinkProps) {
  return (
    <a href={href} aria-label={label}>
      <span aria-hidden="true">{children}</span>
    </a>
  );
}

Three lines. You now pass axe-core.

Finding 4: CLS is the one metric most sites get right

85.5% of sites pass mobile CLS.

Cumulative Layout Shift is the one Core Web Vital developers have actually internalized. It helps that every modern framework bakes in width and height on images by default, and that font-display: swap cuts down on font-swap shifts. The sites that fail CLS are doing something unusual: late-loading ads, position: sticky headers without reserving space, or hero carousels that resize after the first slide loads.

If your site passes everything else but fails CLS, the cause is almost always one of those three.

The takeaways for developers

If you read nothing else from this, read this:

Priority-load one image and one font. Your LCP element and your primary typeface. Everything else lazy-loads. This single change moves most sites from "poor" LCP to "good."
Defer or lazy-load every third-party script. If Tag Manager is synchronous in your <head>, you are paying for it on every paint. Move it.
Run axe-core on every PR. A CI check that runs @axe-core/cli against your built site will catch unlabeled links before they ship. It takes 10 minutes to configure and it will save you from the baseline failure.
Test on mobile, not desktop. Every site we audited looked fine on desktop. 96.9% of them fail on mobile. Chrome DevTools has a "Mobile" preset in the Performance tab. Use it on every build.

The dataset

The full 292-site dataset, methodology, and reproducibility notes are open. If you want to cite any of these findings in a post, article, or conference talk, you can pull the raw scan JSON and reproduce every chart.

Report: State of Small Business Websites 2026

Suggested citation (BibTeX friendly):

Gutierrez, J.R. (2026). State of Small Business Websites 2026.
Axion Deep Digital Research, n=292.
axiondeepdigital.com/research/state-of-small-business-websites-2026

If you find an error, contact us and we will update the public methodology page with the correction and the reporter credit.

The takeaway, in one sentence

The small business web is not sophisticated enough to be slow. It is slow because nothing is prioritized, nothing is deferred, and nothing is labeled. Every one of the findings above is fixable in a single afternoon by a developer who knows the four keywords: priority, defer, font-display: swap, and aria-label.

That is what the 3.1% do.

Further reading

Performance Monitoring for E-Commerce: What Metrics Matter Most

Wed, 22 Apr 2026 21:12:38 +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

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

Sun, 19 Apr 2026 03:08:09 +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.

Mobile vs Desktop Core Web Vitals: Why You Need to Monitor Both

Mon, 13 Apr 2026 23:52:33 +0000

Most teams treat Core Web Vitals like one scoreboard. They run a quick test, pick a single set of scores, and move on. The problem is that Core Web Vitals are defined per page load; device shows up in how you measure—mobile versus desktop in lab emulation, or in field data grouped by form factor. The same URL can therefore produce different LCP, INP, and CLS results across those contexts. Mobile and desktop travel different routes through your UI, assets, network conditions, and interaction patterns. If you monitor only one side, you will miss regressions that matter—and you will struggle to justify prioritisation when clients ask, “Why did this change?”

The trap: one device, one story

It’s easy to fall into a workflow like this:

Mobile is “important”, so you track mobile CWV only.
Desktop is “nice to have”, so you leave it until later.
When something breaks, you re-run tests and pick the latest scores to explain the incident.

This approach has two predictable failure modes:

Hidden regressions — A fix that improves desktop experience can still leave mobile failing (or vice versa).
Unclear communication — You end up explaining different symptoms with one set of numbers. Clients rightly lose confidence.

If you want monitoring that supports real delivery and client-ready reporting, you need a repeatable paired view: mobile + desktop for the same pages, the same cadence, and the same triage rules.

If you need a quick primer on the metrics themselves, start with What Are Core Web Vitals?.

Why mobile vs desktop Core Web Vitals diverge

Core Web Vitals can look “similar” at a headline level, but the underlying causes often differ. The most common reasons:

Different rendering and loading conditions

Mobile is constrained: less CPU headroom, different caching patterns, and more aggressive resource variation. That shows up strongly in:

LCP (Largest Contentful Paint): often driven by large images, fonts, or other heavy elements on the critical path (the LCP element can also be a text block or a video poster, depending on the page). If those pieces behave differently across breakpoints, LCP will diverge.

Different interaction patterns (INP)

INP captures interaction responsiveness, which often behaves differently by device due to:

Touch vs pointer interactions
Different event targets and UI density
Varying execution cost on lower-end hardware

If you only look at one device’s INP, you can miss “works on desktop” but “feels slow on phones” issues.

Different layout stability (CLS)

CLS is highly sensitive to responsive layout, late-loading elements, and dynamic components that appear only under certain breakpoints (ads, banners, late injected UI, etc.). A page can be stable on desktop and still shift on mobile.

For a deeper explanation of what each metric actually means, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

What to monitor in practice (beyond the total score)

Monitoring both devices is necessary, but it’s not sufficient by itself.

You also need to monitor the right dimensions:

1. Treat each device as its own budget

Instead of one “CWV target” for the page, define device-specific thresholds for the metrics you care about. A pass on desktop should not automatically compensate for a fail on mobile.

This keeps decisions defensible when you propose fixes to stakeholders.

If you want a structured way to set thresholds, use our Performance Budget Thresholds Template.

2. Compare by change, not by absolute numbers alone

Absolute CWV numbers can vary slightly run-to-run. What should drive action is:

What changed since the last known good period
Which metric moved first (LCP vs INP vs CLS)
Which device changed (mobile-first incidents vs desktop-only issues)

3. Triage using “worst metric per device”

A practical triage rule:

For mobile: focus on the single worst metric (LCP/INP/CLS) and the reason it is failing.
For desktop: do the same.

Then decide whether you have a shared root cause (both devices fail similarly) or breakpoint/device-specific problems.

A practical monitoring workflow for agencies

If you want this to work across clients and pages, keep it repeatable. Here’s a workflow you can run every week:

Choose pages that reflect real funnel risk
- Homepage (first impression)
- Key category or service pages (high intent)
- Conversion pages (where UX pain becomes business cost)
Run paired analysis for the same pages
- Mobile + desktop tests on the same cadence
- Stable analysis conditions (avoid mixing “random checks” with planned ones)
Record findings in the same order
- Mobile: LCP → INP → CLS (and a quick “what it likely affects” note)
- Desktop: LCP → INP → CLS
Assign device-specific priority
- If mobile fails and desktop passes, your “first fix” should usually start mobile unless you have a desktop-only user segment.
Set alerts that match the story
- Budget breaches on a device should trigger the device’s reporting, not just the overall page score.
Deliver client-ready reporting
- Give clients a paired narrative: “what you saw” and “what you changed next”.

For the setup side of automated monitoring across multiple sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

And if you’re turning this into deliverables, the Client-Ready Core Web Vitals Report Outline helps you package the evidence into something stakeholders actually read.

Interpreting results: three common scenarios

When you review mobile vs desktop CWV together, you’ll usually fall into one of these buckets:

Scenario	What it often means	How you should respond
Mobile failing, desktop ok	Mobile critical path or interactive cost is the bottleneck	Prioritise mobile-first fixes (hero/LCP and interaction latency)
Desktop failing, mobile ok	Desktop-only layout or heavy JS path	Focus on desktop breakpoints, scripts, and layout stability
Both failing consistently	Shared design debt or performance regressions	Treat it as a system-level problem, then verify with paired reruns

The important part is that you avoid the “one score explains everything” habit. Paired monitoring turns CWV from a vanity chart into a decision system.

What your client update should say (example wording)

When clients ask “why are there two scores?”, they usually want a single paragraph that explains what changed and what you will do next.

Here’s a simple template you can reuse:

Mobile-first incident (mobile fails, desktop ok):

“Mobile performance is out of budget right now (LCP/INP/CLS), while desktop is within budget. This pattern usually points to a mobile-specific bottleneck: hero rendering timing, touch interaction cost, or a late-loading component that behaves differently on smaller breakpoints.”
“Next step: we’ll apply a targeted first-fix on the affected mobile path, then re-run the same paired checks to confirm both the device budget and the user-story are improving.”

Shared incident (both devices failing in a similar way):

“Both mobile and desktop are currently out of budget for the same metric area. That usually means a shared component, shared asset, or shared build/deploy change rather than a single device quirk.”
“Next step: we’ll verify what changed in the release window, then test the fix with paired checks to ensure the improvement holds across devices.”

If you include field data (for example, when you do CrUX-aware reporting), keep the wording consistent: explain what your lab checks caught, and how the field view supports the same story. The goal is less debate and more action.

A quick consistency check for every report

Before you send your update, run this quick self-check:

Are you using the same page set for both devices (so the comparison is fair)?
Did you name the first metric to fail on each device (so the triage is clear)?
Does your next step match the device that is failing (or explain why you’re fixing something shared first)?
Did you state how you will verify after changes (re-run paired checks, not “we’ll look later”)?

Client-ready reporting: avoid confusion with one sentence

Clients often ask why you’re reporting two device scores.

Your answer should be simple:

“Mobile and desktop measure different experiences. We monitor both so we catch issues that only appear on one device and so our fixes stay prioritised and verifiable.”

When you present this in a consistent report format, it is easier for stakeholders to focus on the next actions instead of arguing over a single headline score.

Operational checklist for your next report

Pick the same set of pages every reporting cycle
Confirm mobile + desktop are both included in the schedule
Use device-specific thresholds for LCP/INP/CLS
Triage by worst metric per device, then explain likely root cause
Reference a repeatable next step (fix + verify, not just “we will look into it”)
Share a paired narrative that stakeholders can understand in under two minutes

FAQ

Do I need to monitor both mobile and desktop if mobile gets most traffic?
Yes. Even if mobile dominates, desktop still represents business risk for a portion of your audience. More importantly, fixes can improve one device while leaving the other failing. Paired monitoring prevents blind spots.

Which metric should I start with: LCP, INP, or CLS?
Start with the worst metric on each device (mobile and desktop separately). In many audits, improving LCP is the fastest high-impact win, while INP usually surfaces interaction pain and CLS highlights layout instability—but the right first lever depends on what is actually failing.

How often should we review paired CWV?
For most agency workflows, weekly review is a good starting point. For active releases or client campaigns, you may need tighter cadence to verify that fixes actually hold.

What if a page behaves differently by device (e.g. different layout/components)?
That’s exactly why paired monitoring helps. Explain the difference in your report: the breakpoint experience is part of the user journey, and device-specific findings lead to device-specific fixes.

Will paired monitoring slow down the workflow?
It shouldn’t. The operational cost should live in automation, not manual re-checks. If your monitoring is scheduled and your reporting is templated, you get more reliable evidence without extra churn.

If you want a repeatable way to monitor mobile and desktop Core Web Vitals across client portfolios (with paired evidence, budgets, and client-ready reporting), Apogee Watcher is built for that workflow.

Coder Legion - Recent posts tagged corewebvitals

Changelog #12: Domain Report Summary, Lead Page Classification, and Classification Rules

Domain report Summary tab

Richer domain reports with how-to links

Lead page classification

Faster page discovery with DataForSEO

Lead outreach and engagement tracking

Public help centre at /docs

Agent readiness on the public site

Permissions and dashboard polish

What to try

References

Cross-Origin YouTube Embeds and CLS: What Publishers Can Actually Fix

Why YouTube iframes drive CLS on publisher pages

What cross-origin changes for attribution and fixes

Reserve space: aspect-ratio wrappers that stop iframe layout shift

CMS and oEmbed pitfalls

Facade and lite-youtube patterns for heavy embeds

Lazy-load the embed without a late jump

Consent banners, late CLS, and YouTube slots

What you cannot fix inside the YouTube iframe

How to verify YouTube embed CLS fixes in lab and field

Publisher checklist: ship the slot, then the player

FAQ

References

When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Why field LCP can move when nobody deployed

Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153

How a 28-day CrUX window can span multiple browser majors

Browser version in RUM: population mix vs a site regression

Put Chrome Stable on the same calendar as deploys and CDN changes

Sample thresholds before you slice field data by Chrome major

Use scheduled lab runs as same-week proof when field CrUX drifts

Browser mix vs fix lag and CrUX pipeline delay: three lag types

How agencies should monitor and report while browser mix shifts

FAQ

Attention-Free Score: How Domain Reports Show Which Pages Need Work

Why shared domain reports needed a Summary-first view

What the attention-free score measures

Pages, tests, and metrics on domain reports

What you see on the Summary tab

How lab gates relate to Core Web Vitals and Lighthouse categories

Page-type breakdown and merged opportunities

Summary links for agency outreach and client reports

Where Summary appears in Apogee Watcher

FAQ

Try Summary on your next domain report

References

CrUX Pipeline Delays: What Late Field Data Means for Client Reports

What CrUX data delay means for agency client reports

Chrome UX Report update schedule: daily API, weekly History, monthly BigQuery

Why CrUX pipeline delays happen beyond the rolling window

How late CrUX field data affects client Core Web Vitals reports

How to annotate client reports with field data collection dates

Use synthetic monitoring while CrUX field data is late

Changelog #11: Paid plans, multi-org dashboard, and page classification

Paid plans now generally available

Multi-organisation dashboard

Newsletter preferences on My Account

Page type classification for site pages

Email team invitations

What to try

References

Treo vs Apogee Watcher: CrUX Scale, Competitor Benchmarks, and Agency Portfolios

What Treo is built for: CrUX scale and competitor benchmarks

What Apogee Watcher is built for: a web performance monitoring tool for agency portfolios

Treo vs Apogee Watcher: CrUX monitoring tools compared

When Treo is the better primary choice

When Apogee Watcher is the better primary choice

Layer Treo and Watcher instead of forcing one vendor

FAQ

References

TTFB Won't Go Down? Server-Side Culprits Beyond the Theme

When slow server response time is not a theme or CDN problem

How WordPress WP-Cron inflates time to first byte

PHP workers, opcode cache, and origin saturation

Database load, object cache, and N+1 queries on uncached requests

admin-ajax storms, backup plugins, and maintenance during peak

How to verify TTFB fixes without guessing

FAQ