Apogee Watcher
Solving web performance for agencies and solopreneurs
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)
A retail client's homepage LCP looked fine in PageSpeed Insights. The same week the account lead forwarded a message: shoppers were dropping at checkout on mobile. The sitewide average had buried the cart and payment routes, which never got the same cache treatment as the brochure pages.
WooCommerce performance tuning in 2026 is still infrastructure, data structure, caching rules, media, and extensions, in that order. Hosting sets the ceiling. High-Performance Order Storage and Redis change how order writes and product lookups behave. Full-page cache helps anonymous shop and PDP shells only when cart, checkout, and my-account stay excluded.
Cart fragments are the quiet tax. The mini-cart AJAX refresh on every page load can hurt INP and TTFB even on templates that never show a basket icon. Product galleries still dominate LCP: WebP or AVIF, honest srcset, and do not lazy-load the primary paint candidate without measuring first.
Prioritise the URLs that carry revenue:
Product detail pages for gallery LCP and variant INP
Shop and category archives for thumbnail grids and filters
Cart for fragments, coupons, and layout shift
Checkout and account for payment scripts and uncached flows
Schedule synthetic lab runs on that list with separate mobile and desktop strategies. CrUX lags and often omits low-traffic checkout URLs; lab history catches plugin and theme regressions within hours.
Read more: WooCommerce performance tuning (2026 guide)
Largest Contentful Paint fails when the browser is still waiting on the server, fighting for bandwidth, or blocked on JavaScript before it can paint the biggest thing in the viewport. You do not need a six-week programme to move a red LCP. In delivery work, four changes cover most urgent regressions.
Start with Time to First Byte: cache queries, HTML at the edge, and generated code paths so the first byte arrives sooner. Then clear the path to the LCP element. Icons, third-party scripts, below-the-fold images, and non-critical fonts should enqueue after the LCP resource, not ahead of it.
Mark the single LCP candidate with fetchpriority="high" (and preload when the hero is known at build time but late in markup). Finally, schedule low-value JavaScript after the load event so the main thread can paint once the asset arrives.
Cut TTFB with object cache, CDN HTML cache, and opcode or template caches before you resize heroes.
Defer icons, analytics, lazy below-fold images, and secondary fonts until after the LCP request starts.
Set fetchpriority="high" on the one LCP element PSI reports; do not mark every image high.
Run heatmaps, chat, and secondary widgets after load (requestIdleCallback where supported).
Re-test the same URL after each change. Scheduled lab runs catch the next theme or tag deploy that puts competing work back on the critical path.
Read more: how to improve LCP with four paint fixes
Comment