Apogee Watcher

For years the CrUX Dashboard was the bookmark agencies opened when a client asked whether field INP had moved since the last deploy. Google retired the shared Looker Studio connector at the end of November 2025. Saved links either fail to load or freeze on the last month the connector received.

The Chrome UX Report did not disappear. You need a replacement stack instead of one screen: CrUX Vis and the History API for weekly TTFB, INP, and CLS trends; PageSpeed Insights and Search Console for the latest rolling slice; BigQuery when you want years of origin history on your own project; scheduled lab monitoring so deploy proof does not wait on the 28-day field window.

A practical Monday split after the dashboard retirement:

• One URL check: PageSpeed Insights field section (latest 28-day p75 when eligible)

• SEO status by URL group: Search Console Core Web Vitals report

• Quarterly trend screenshots: CrUX Vis (about 40 weeks from the History API)

• Automation: CrUX History API queryHistoryRecord with your Google Cloud key

• Portfolio regressions before field moves: scheduled PageSpeed lab tests with budgets on the same money URLs

We run scheduled lab tests across many client sites and show CrUX field slices beside results when Google returns them. CrUX Vis still owns the six-month INP line on one hero domain; we help when fifty URLs need the same row without fifty bookmarks.

Read more: where to get TTFB, INP, and field history after the CrUX Dashboard retired

Procurement wants a line item for "AI search." A vendor demo shows green citation bars for category prompts. Your team still has not confirmed whether GPTBot can fetch pricing or docs after last week's theme deploy.

We split AI search work into two layers. Prompt-level citations need GEO or visibility SaaS. Fetchability on named URLs does not: robots.txt policy, HTTP health, and lab Core Web Vitals on the routes buyers actually need.

Before you sign a visibility contract, you can still run a useful baseline:

• Fetch production robots.txt and note rules for GPTBot and other AI user-agents the client names.

• Build a ten-to-twenty URL list by intent (pricing, PDPs, docs, checkout where tests are allowed).

• Record status codes, redirect hops, and mobile plus desktop lab vitals on that list.

• Schedule recurring PageSpeed tests so theme and CDN changes do not erase the baseline overnight.

A green citation chart next to a checkout that times out for crawlers is still an incomplete story. We schedule lab tests and budgets across client sites; we do not score ChatGPT mentions.

Read more: AI search optimization without a GEO subscription

A client scrolls a product page on Android and the page hitches. They blame the phone, the network, or "Chrome is slow." In July 2026 Chromium published how they cut the frequency of janky scrolls in Chrome on Android by about 48% between 2023 and 2026. That pipeline work is real. It still does not remove your scroll handlers, long tasks, or layout that shifts while the finger is moving.

Scroll jank is a missed frame during scroll: the screen shows a stale offset for about 16.7 ms on a 60 Hz display. Chrome owns input-to-frame delivery inside the browser. Your site owns the work that runs while Chrome is trying to produce the next frame. After a Chrome release note, only two buckets belong on the sprint board: main-thread and style work during scroll, and layout that moves mid-gesture.

What we put in the checklist for web teams:

• List every scroll / touchmove / wheel listener on priority templates (homepage, PDP, article, category feed).

• Mark each as passive observe, must preventDefault, or removable; drop handlers that force layout on every event.

• Move scroll-linked visuals to CSS sticky / transform where you can.

• Reserve space for lazy images, embeds, and infinite-scroll rows before they load.

• Audit third-party tags for long tasks during the first scroll after load; re-run mobile lab and watch INP and CLS field bands for the following weeks.

One green Lighthouse paste after a Chrome update is not proof the portfolio is smooth. Spot checks miss the template you did not open.

Read more: Chrome Android scroll jank: what to check on your site

You ship a layout that looks clean in Chrome. A week later Safari users report a broken filter panel, or Firefox drops a CSS feature your design system assumed was safe. The Performance score on PageSpeed Insights still looks fine, because speed and interoperability are different questions.

Lighthouse now reports Baseline status for web platform features on a page, including many third-party scripts. Each feature shows Limited, Newly available, or Widely available, with a link to webstatus.dev and a source hint. Treat that list as an inventory with risk labels, not as a new Core Web Vitals threshold.

How we triage it on client sites:

• Collect every Limited row first on money URLs; name an owner and a fallback before go-live

• Treat Newly available as an audience check, not a silent ship in the theme pull request

• Escalate third-party Limited features to the vendor or tag owner instead of rewriting minified vendor code

• Keep Best Practices / Baseline on a separate slide from LCP, INP, and CLS budgets

Scheduled PageSpeed runs catch when a tag or theme change reintroduces Limited features after a quiet week. DevTools is still the place for deep triage of a single finding. Layer monitoring onto the stack you already have.

Read more: Lighthouse Baseline Features audit

Your React or Vue product site already updates the URL when someone clicks from pricing to checkout. The address bar looks like a new page. Search Console and PageSpeed Insights still treat most of that journey as one long document load, so LCP for the first paint stays on the initial hard navigation while later route changes never get their own Core Web Vitals story.

Chrome 151 ships soft-navigation and interaction-contentful-paint timeline entries unflagged. Soft navigations are Chrome's way to slice metrics on SPA-style route changes that update the URL and paint after a user action. Lab PageSpeed schedules still measure full document loads of the URLs you list. They do not walk your click path and invent soft-nav entries for every in-app route.

What to prepare and measure:

• Keep URL updates visible and history-friendly so heuristics can fire

• Paint after the interaction that starts the transition (skeletons count; invisible DOM swaps do not)

• Confirm soft-navigation markers on money routes in DevTools before you promise field soft-nav LCP

• Keep scheduled lab runs on public deep links for deploy regressions; put soft-nav observation in RUM or custom observers

Apogee Watcher stays on the scheduled lab and portfolio side across client hostnames. Soft-navigation and ICP observation belong in your RUM stack until field tooling catches up. Layer both; do not claim one replaces the other.

Read more: soft navigations in Chrome 151

You shipped the fix on Tuesday. Hero images are compressed, the heavy tag is gone, and Lighthouse on mobile looks healthier than Monday's run. On Thursday the account manager forwards a Search Console screenshot: the URL group is still Needs improvement. In most cases the change is real. CrUX has not finished rolling the old sessions out of its window yet.

CrUX is a 28-day rolling average of real Chrome sessions, not a lab run taken on ship day. Sessions collected before your fix stay inside the window until they age out, so a green lab run can sit next to amber field bands for days or weeks.

What to monitor while field data catches up:

• Baseline lab LCP, INP, and CLS on mobile and desktop before you change anything

• Scheduled lab runs after ship so before/after is stored, not remembered

• Budgets and alerts on lab vitals so regressions during the CrUX wait still notify someone

• Weekly field checks with collection period dates noted in the client report

Close the engineering ticket when lab verification passes. Keep a separate field-watch item until Search Console moves into the agreed band. One sentence in the retainer report saves a week-one reopening: field CrUX remains a 28-day rolling average; lab trends below are same-week verification.

Read more: why your Core Web Vitals fix is not in CrUX yet (28-day window)

Chrome now documents how coding agents can run Lighthouse inside DevTools while a developer still has the branch open. Instead of grepping the repo for clues, the agent loads the page you care about and measures accessibility, SEO, best practices, and agentic browsing against live runtime behaviour.

That loop earns its keep on local and staging hosts. It does not replace scheduled tests across forty client sites, budget thresholds, or alerts when a theme deploy regresses Largest Contentful Paint overnight.

What we keep separate in delivery:

• During build: use DevTools agent prompts for accessibility, technical SEO, and best practices on the URL under change

• At release: re-run the same priority templates on the staging hostname the client will accept

• After release: scheduled PageSpeed Insights runs across the portfolio, with budgets on revenue URLs

Layer, do not replace. Coding agents shorten the time from UI changed to measurable defect named. Monitoring shortens the time from production changed to someone on the account knows.

Read more: automate Lighthouse audits with AI agents in Chrome DevTools

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy.

TTFB is not a Core Web Vital, but it feeds Largest Contentful Paint. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero can paint. WebPageTest and similar waterfalls split that wait into DNS, TCP connect, TLS, and waiting. That split is what makes network work actionable.

Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay. Walk the request in order before another theme rewrite.

Checklist when you try to reduce TTFB:

• DNS: flatten long CNAME chains, raise TTL once cutovers are rare, test from more than one region

• TLS: enable TLS 1.3, staple OCSP, serve a complete chain, consolidate hosts for reuse

• HTTP and connections: confirm HTTP/2 or HTTP/3 at the edge; avoid spraying cold handshakes across origins

• CDN routing: separate CDN configured from HTML cacheable; inspect Age and cache-status headers

• Cache rules: short TTL or SWR for anonymous HTML; long TTL for hashed assets; purge by URL or tag, not blanket storms

If TLS is 40 ms and Waiting is 900 ms, move to CDN and cache rules instead of chasing another certificate setting. Prove each change with scheduled lab runs on the same priority URL.

Read more: Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules

The client forwards a screenshot from an AI visibility platform. Green bars. Category prompts answered. Leadership reads it as proof the site is ready for ChatGPT. Your server logs tell a different story: GPTBot requests on /checkout, long-tail product templates, and pricing routes that time out or return pages where the product copy is not in the first HTML response, while the homepage lab score still passes.

AI visibility tooling answers whether a model mentions your brand for a fixed prompt set. That is useful for citation trends. It does not tell you whether crawlers can fetch and parse the routes buyers actually need: product detail pages, comparison tables, pricing, and checkout paths where third-party scripts stack up.

We treat AI visibility and AI crawler performance as separate layers. Citation is probabilistic. Fetch speed and HTTP health on priority URLs are deterministic: either the response completes in time with parseable HTML, or it does not. Lab tests do not perfectly simulate GPTBot, but they flag the conditions that cause real crawler timeouts: multi-second responses, render-blocking bundles, and templates that defer product copy until after JavaScript runs.

Build a priority list by business intent, not homepage-only:

• Pricing and plan comparison pages where widgets change often

• Product detail and variant templates, including long-tail categories

• Checkout and cart routes where unauthenticated lab tests are allowed

• High-traffic campaign landers, not only the root domain

Schedule synthetic lab runs on that list with mobile and desktop strategies, then alert on regressions. A green prompt chart next to a failing checkout fetch is the failure mode agencies miss.

Read more: Monitor GPTBot performance on checkout, not AI visibility alone

When an enterprise WordPress site feels slow, the first meeting is almost always about infrastructure. Upgrade the server. Add a CDN. Move to a higher hosting tier. Those moves can help. Across hundreds of large WordPress projects, the limit is more often the code on the stack: plugins loading assets where they are not needed, redundant queries on every request, bloated autoloaded options, and third-party scripts before first paint.

PageSpeed Insights and Chrome DevTools still show whether time is spent waiting on the server (TTFB) or in render and script work on the client. If you skip that split, you risk funding a hosting upgrade that leaves LCP and INP unchanged because the homepage still loads twelve plugin stylesheets on a contact page.

Hosting is the right lever when TTFB stays high on simple pages after code cleanup, PHP-FPM queues spike under normal traffic, or Redis is unavailable and the database becomes the session store. A CDN helps distant static assets and image-heavy LCP. It does not shrink a two-megabyte autoload row.

Before you buy a new tier, audit in this order:

• Pick representative URLs (homepage, conversion path, heavy archive, one logged-in or commerce route).

• Split TTFB from LCP, INP, and CLS on mobile and desktop lab runs.

• Profile plugins and queries with Query Monitor; measure autoload size.

• Inventory third-party scripts on conversion URLs with marketing modules enabled.

Code-first fixes can move metrics hosting alone did not touch. Keep plugin policy and scheduled lab tests so the next update does not undo the audit quietly.

Read more: why your WordPress site is slow (it is not always hosting)