DEV Community: Apogee Watcher

Why did PageSpeed Insights jump overnight? (Lighthouse 13.6, site unchanged)

Apogee Watcher — Wed, 04 Nov 2026 09:53:09 +0000

Lighthouse 13.6.0 shipped on 27 October 2026. Within about a week, PageSpeed Insights was running that build. The change is not a new weight table for the Performance score. It is a change to Lantern, the model that estimates how a fast capture would look under mobile throttling. Simulated First Contentful Paint and Largest Contentful Paint get closer to reality, and Barry Pollard noted that scores often come out higher, especially on JavaScript-heavy pages.

So a URL can show a different lab Performance score when the HTML, CSS, and scripts are the same as yesterday. That is awkward for anyone who keeps saved PageSpeed Insights screenshots for clients. The useful question is not “did Google make us faster?” It is “are we comparing two Lighthouse versions, or two states of the site?”

What follows is a short path through that question: what Lantern changed, where the Lighthouse version appears on the PageSpeed Insights card, why field CrUX will not move with the lab score, and what usually belongs in the client note. For the longer scoring guide on our monitoring blog, see Google Lighthouse Score Explained: How Scoring Works. For why one-off reports still sit poorly next to a schedule, see PageSpeed Insights vs Automated Monitoring.

What Lighthouse 13.6 changed in the lab simulation

PageSpeed Insights loads the page quickly, then Lantern estimates how that load would behave on a slower mobile profile. Until 13.6, that estimate relied heavily on fetch priority to decide what blocked rendering. Lantern now prefers Chrome’s own render-blocking label for each request, and only falls back to priority when that label is missing.

A second change affects pages whose Largest Contentful Paint is text in the same frame as first content. Lantern now estimates that LCP from the same request and task set it uses for FCP, instead of folding in a wider set of earlier work that could push simulated LCP later. Ivan Akulov’s Framer example showed how the old model could punish useful module and font preloads; the Lighthouse team closed that class of issue in the 13.6 Lantern upgrade.

None of that rewrites CrUX. It rewrites the lab timings that feed the weighted Performance score. When an overnight jump sits on a JavaScript-heavy template or a text-first above-the-fold block, the simulator is usually the first place to look before crediting a release.

How to tell a simulation jump from a real site change

The two PageSpeed Insights reports under discussion each name a Lighthouse version next to the emulated device. When one says 13.5.x and the other says 13.6.0, the runs are not on the same measurement. Part of the Performance difference may be Lantern, not a code change.

Three questions usually settle the case:

Did the site change? Same commit, same CDN purge window, same tag-manager container? If nothing moved, simulation is the more likely explanation.
Did FCP or LCP move more than Total Blocking Time or CLS? Lantern’s 13.6 notes centre on simulated paint. A swing that is mostly Total Blocking Time still points at main-thread work.
Does field data agree? The CrUX block on the same PageSpeed Insights page still covers a rolling window of real Chrome visits. It will not jump overnight because Lantern changed.

If modulepreloads or font preloads were removed earlier to improve a lab colour band, it is worth running the same URL again on 13.6 before leaving them out. A preload that helped real visits may no longer cost as much in the lab. Image LCP is a different story: work that finishes before the image paints can still stretch simulated LCP.

Lab scores and field CrUX after the update

Lab Performance is one controlled navigation under a fixed profile. Field Core Web Vitals are percentiles from eligible Chrome users. Both can mention LCP; only the lab score folds Speed Index and Total Blocking Time into a 0–100 blend with documented weights.

A higher lab Performance score after 13.6 does not mean Search Console’s Core Web Vitals report improved. Google’s field status still comes from CrUX, not from the Lighthouse Performance integer. Claiming “we gained twelve points overnight” without naming the Lighthouse version credits a lab change the field never showed.

Charts that track only the lab Performance score will show a step at the PageSpeed Insights roll-out, so that step belongs as a note on the monitoring board. Metric budgets (LCP, INP, CLS, and lab Total Blocking Time where you use them) on the same URLs still give engineering a clear ticket when the Performance score improves while visitor experience does not.

What to put in the client note

A short, honest note usually beats a celebration deck:

PageSpeed Insights now runs Lighthouse 13.6.0, which changed how simulated FCP and LCP are estimated.
Our lab Performance score moved on [URL] between [date A] and [date B]; versions were [x] then [y].
Field CrUX on the same report [moved / did not move] for LCP, INP, and CLS.
We keep the same URLs on a short schedule so the next comparison uses one Lighthouse minor and a dated trail.

That is enough for most account threads. When someone wants the weight table and calculator path, the Watcher scoring guide linked above already names the Lighthouse 10 weights and the version footnote, so a second methodology essay in Slack is rarely needed.

FAQ

Can PageSpeed Insights scores rise when the site has not changed?

Yes. When PageSpeed Insights upgrades the Lighthouse build (for example to 13.6.0), Lantern can change simulated FCP and LCP even if HTML and assets are identical. Matching the Lighthouse version on both reports and reading the field block usually comes before attributing the jump to a release.

Is a higher lab score better for SEO ranking?

Not by itself. Lab Performance is a diagnostic blend. Field Core Web Vitals (via CrUX and Search Console when eligible) are the experience signals Google documents for page experience. The Performance score stays useful as engineering context.

Why did my local DevTools Lighthouse disagree with PageSpeed Insights?

Version, throttling preset, and machine noise all differ. Matching Lighthouse versions before comparing, and preferring a short schedule of the same live URLs over two one-off screenshots, usually closes that gap. That is a monitoring problem as much as a scoring problem.

CTA

Before the next client email about an overnight PageSpeed Insights jump, it is usually enough to match the Lighthouse versions, read the field block, and keep the same live URLs on a short schedule so LCP, INP, and CLS still have dates beside the Performance score. The scoring walkthrough lives in Google Lighthouse Score Explained: How Scoring Works. The schedule argument is in PageSpeed Insights vs Automated Monitoring.

References

Lighthouse 13.6.0 release notes (Lighthouse project)
PageSpeed Insights Scores May Rise After Lighthouse Update (Search Engine Journal)
Lighthouse variability (Lighthouse project)
Lighthouse performance scoring (Chrome for Developers)
Google Lighthouse Score Explained: How Scoring Works (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring (Apogee Watcher)

Why does CrUX say no data for my client site?

Apogee Watcher — Tue, 03 Nov 2026 07:50:09 +0000

PageSpeed Insights finishes the Lighthouse half of the report and then leaves the “real users” block empty. The client Slack thread fills with “is CrUX broken?” and someone refreshes the same URL three times. Lab scores are there, but field percentiles are not. That pattern is usually eligibility, not a failed API call.

What follows is the engineer’s short path: which kind of “no data” you are looking at, whether the origin string matches the live host, how PageSpeed Insights falls back from URL to origin, and what still makes sense to monitor until Chrome UX Report rows exist. For the fuller eligibility walkthrough and client wording on our monitoring blog, see Why CrUX Has No Data for Your Site. When field data does exist but a fix still looks invisible, that is a different clock: Why Your Core Web Vitals Fix Is Not in CrUX Yet.

What “no data” means in PageSpeed Insights and the CrUX API

Chrome UX Report (CrUX) only publishes anonymised field distributions when enough eligible Chrome sessions clear privacy and quality rules for that origin or URL. PageSpeed Insights and Search Console inherit those gaps. A blank field section is not the same as an amber or red Core Web Vitals category. There is simply no percentile to colour yet.

In the UI you usually see one of three shapes. Origin absent: tools cannot show field data for the site at all. URL thin, origin present: PageSpeed Insights may disable “This URL” and fall back to origin-level field rows, or show origin while the URL field block stays empty. Metric missing: some field metrics appear and others do not. The third case is a sampling gap on a URL that already has other field rows, so it is a metric problem rather than “CrUX is offline.”

The CrUX API often answers the same situations with a not-found style response for the origin or URL you requested. That is still eligibility (or a wrong identifier), not proof that Lighthouse lied. Google’s CrUX methodology is clear that you cannot manually submit a site for inclusion; origins and pages appear and disappear as eligibility changes.

Debug the origin string before you blame traffic

Most “CrUX no data” conversations waste the first hour on the wrong host. http versus https, www versus apex, and every subdomain are different origins. https://shop.example.com does not inherit field rows from https://www.example.com. The reliable check is the final navigable URL after redirects, with the path stripped and scheme plus host kept in lowercase the way CrUX expects.

When the string is wrong, PageSpeed Insights and the CrUX API look empty even if the real public origin already has field data. Matching the published origin once is usually enough before anyone argues about sample size. Chrome’s own connector errors have long suggested trying www or the opposite scheme when an origin is missing from the large CrUX origin set; that advice is about matching the published origin, not about inventing traffic.

When the URL is empty but the origin still has field data

PageSpeed Insights tries URL-level CrUX first. If the URL is not popular enough, it falls back to origin-level data and explains that the URL button is unavailable. Official guidance is in How to view Chrome UX Report data on PageSpeed Insights. That fallback is useful for orientation, and risky in a client deck if origin percentiles are labelled as “this landing page.”

Reports stay honest when they say which level the numbers come from. Synthetic history on the thin URL still matters while URL-level samples catch up. An origin bar that looks fine is not the same as a Core Web Vitals pass for that URL. Homepage and high-traffic templates often qualify first; locale paths, checkout steps, and campaign URLs lag for a long time.

Eligibility gates engineers actually check

Once the origin string is correct, the gates Google documents are user, origin, and page. User eligibility means only opted-in Chrome sessions on supported platforms (Chrome on iOS does not contribute). Origin eligibility needs a publicly discoverable root and enough eligible experiences across the origin. Page eligibility adds enough samples for that specific URL.

Discoverability failures are easy to miss. A root that returns a non-200 after redirects, ships noindex, or redirects in a way indexing systems treat as undiscoverable can drop the whole origin even when inner URLs get visits. Chromium discussion threads have repeatedly pointed at locale redirects on / as a reason origin-level CrUX vanishes while a deeper URL still shows field data after PageSpeed Insights follows the redirect. A Lighthouse SEO pass on the root often surfaces those indexing or status problems before anyone promises that “more traffic next month” will create rows.

Popularity thresholds are not published. Small sites, brand-new launches, and niches with little opted-in Chrome traffic can stay empty indefinitely. Refreshing PageSpeed Insights does not create field eligibility. Growing real Chrome visits and keeping the root public does; there is no submit button.

What to monitor until field rows appear

A blank CrUX panel is not a reason to skip performance work. Scheduled lab tests on the homepage and the other URLs the retainer cares about, with budgets and a named owner when LCP, CLS, or related lab metrics move, give you dated history to show week to week while field percentiles are missing. When origin or URL field data appears, it sits beside that lab history rather than replacing it.

If the client already has field data and only the fix looks late, the useful link is the 28-day collection window article above. “No data” and “stale data” are different problems. Mixing them produces the wrong promise in Slack.

FAQ

Does CrUX “no data” mean the site is slow?

No. It means Google does not have enough eligible samples (or the origin fails discoverability) to publish field percentiles. Lab diagnostics can still guide template fixes while eligible Chrome traffic builds.

Can we force the client site into the Chrome UX Report?

No. Inclusion is automatic when eligibility is met. A public root plus real Chrome traffic, checked on a fixed schedule, is the path; refreshing PageSpeed Insights every hour is not.

Why do I still see Lighthouse scores?

Lighthouse runs on demand in the lab. CrUX needs eligible real-user samples. Both can sit on one PageSpeed Insights page, and either side can be empty on its own without proving the other is wrong.

Are subdomains covered by the apex origin?

No. Each scheme and host is its own origin. The useful query is the origin the product actually uses, including https and whether the live site sits on www or the apex.

CTA

When the field block is empty, the useful client note is eligibility rather than “CrUX is broken.” Naming the origin and confirming the root is public usually clears the first half of the conversation. Synthetic budgets on the priority URLs cover the weeks until field rows show up. The Watcher eligibility guide holds the longer agency script; the 28-day window guide fits lag after a fix, not an empty panel.

References

CrUX methodology (Chrome for Developers)
How to view Chrome UX Report data on PageSpeed Insights (Chrome for Developers)
About PageSpeed Insights (Google for Developers)
Overview of CrUX (Chrome for Developers)
Why CrUX Has No Data for Your Site (Apogee Watcher)
Why Your Core Web Vitals Fix Is Not in CrUX Yet (Apogee Watcher)

Core Web Vitals Benchmarks for WordPress Sites (2026 Data)

Apogee Watcher — Tue, 03 Nov 2026 07:46:01 +0000

Public Core Web Vitals numbers for WordPress usually arrive as origin pass rates: roughly half of WordPress origins clear all three vitals on mobile in large CrUX-based studies, and vendor how-tos still start from a single homepage PageSpeed Insights run. An agency with twenty WordPress retainers needs a different baseline. What do multi-page lab averages look like once home, templates, and conversion URLs sit in the same domain report?

Neither number replaces the other. Field pass rates describe eligible Chrome traffic at the origin; multi-page Lighthouse averages describe the templates you still have to budget and schedule. What follows publishes a reproducible Watcher sample from client-tagged WordPress sites, sets it beside public CrUX orientation, and points at the work that usually moves the needle first. The method matches our Shopify, Magento, and fashion benchmark posts. For WordPress monitoring practice after the numbers, see WordPress Performance Monitoring: The Complete Guide.

What counts as a reliable WordPress Core Web Vitals benchmark in 2026

For Core Web Vitals, the strongest public field source remains the Chrome UX Report (CrUX). Google’s methodology is clear about inclusion: pages and origins must be publicly discoverable and popular enough, data comes from eligible Chrome users, and thresholds are read at the 75th percentile over a rolling window. That is why Search Console and the field section of PageSpeed Insights matter for ranking and real-user claims, while a single Lighthouse run remains a diagnostic tool.

Google’s published thresholds are unchanged for the three metrics:

Metric	Good (p75)	Needs improvement	Poor
LCP	≤ 2.5 s	2.5 s – 4.0 s	> 4.0 s
INP	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS	≤ 0.1	0.1 – 0.25	> 0.25

An origin or URL group passes Core Web Vitals when all three sit in the good bucket at p75. A Lighthouse Performance score is a different artefact: it blends lab timings under a throttled environment and is useful for regression detection, not as a substitute for CrUX pass/fail. If you need a refresher on the three metrics themselves, start with What Are Core Web Vitals? A Practical Guide for 2026.

A useful WordPress benchmark therefore states four things up front: which clock (CrUX field versus Lighthouse lab), which URLs (homepage only versus archives, posts, and conversion paths), how scores are aggregated (single URL versus median or mean across pages), and the collection window. Plugin marketing and hosting dashboards often quote one green score without that scaffolding. Agencies managing a mixed WordPress book need the scaffolding more than another screenshot.

Sources:

Public CrUX context for WordPress in 2026

Independent researchers combine HTTP Archive technology detection with Chrome UX Report data and publish WordPress pass rates that orient a portfolio conversation. HostingStep’s June 2026 rebuild from the HTTP Archive CrUX crawl reports about 48.8% of WordPress mobile origins and 53.3% of desktop origins passing all Core Web Vitals in that sample (millions of origins). PageSpeed Matters’ CMS study places WordPress near the bottom of major general-purpose CMS mobile pass rates in its cut (about 38.4% all-three on mobile among measured WordPress sites). The spread is expected when samples, devices, and “complete metrics” filters differ.

What those studies agree on matters more than the exact percentage. WordPress INP and CLS pass rates are often healthier than LCP. Loading, and especially server response and Largest Contentful Paint, is where origins fail. That field pattern matches what agencies feel when a client’s Search Console “needs improvement” is almost always an LCP story, not an interactivity lecture.

Treat public CrUX tables as orientation for the platform, then measure the URL set you actually retain. A homepage that passes origin-level CrUX can still hide slow templates that never earn enough traffic to appear at URL level. Multi-page lab averages are how you catch that before the retainer review.

Sources:

Core Web Vitals Statistics 2026 (WordPress) (HostingStep / HTTP Archive)
CMS Core Web Vitals 2026 (PageSpeed Matters)

Multi-page lab sample from Watcher WordPress clients

We keep WordPress-tagged client sites in Watcher and run multi-page PageSpeed Insights analyses that store Lighthouse lab metrics per selected URL. For this snapshot we took the latest domain report for every site with platform_cms=WordPress, and an aggregated report payload (n = 381 sites). Reports were generated between 27 August and 2 November 2026.

Each report averages Lighthouse metrics across the URLs selected for that domain (median 21 analysed pages per site; 7,278 page runs in total). Values below are store-level averages of lab runs, not single-URL CrUX p75s. A site that looks healthy on one landing page can still drag the average when archives, templates, and form pages are included, which is the usual WordPress pattern once page builders, shared headers, and plugin scripts repeat across templates.

Mobile and desktop Lighthouse Performance

Slice	Mobile Performance (avg)	Desktop Performance (avg)
Minimum	17	30
25th percentile	51	69
Median	62	82
75th percentile	73	90
Maximum	99	100
Mean	63	79

Half of the sample sits at or below a mobile Performance average of 62. 296 / 381 sites clear a mobile average of 50, 117 / 381 clear 70, and 23 / 381 reach a mobile store average of 90. Desktop is kinder in the same runs (median 82), which matches what agencies see when a client forwards a desktop-only screenshot and assumes the WordPress site is fine. Compared with our Shopify Watcher sample (median mobile Performance about 51 on 64 stores) and Magento verified sample (median about 58 on 76 stores), this WordPress client set sits a little higher on the Performance dial. The shared pattern still matters more than the gap: multi-page lab averages remain a remediation queue, not proof that monitoring can stop.

Mobile lab Core Web Vitals timings (store averages)

Metric	Median	75th percentile	Notes in this sample
LCP (s)	7.48	10.5	18 / 381 store averages ≤ 2.5 s
INP (s)	0.154	0.229	251 / 381 store averages ≤ 0.20 s
CLS	0.023	0.066	328 / 381 store averages ≤ 0.1

CLS is the bright spot. INP at the median clears the “good” lab line for most of the cohort, though the upper quartile still needs work. LCP is the structural problem: fewer than one in twenty sites averages ≤ 2.5 s across the selected pages under lab throttling. That lines up with public CrUX stories that blame loading more than interactivity on WordPress origins, and with the retainer reality that hero images, render-blocking CSS, and plugin JavaScript dominate the first paint path.

Recurring mobile Lighthouse opportunities

Opportunity	Sites (of 381)
Reduce unused JavaScript	330
Reduce unused CSS	315
Avoid multiple page redirects	296
Minify JavaScript	103
Minify CSS	88
Initial server response time	30

Unused JavaScript and unused CSS appear on most of the book. Redirect chains are almost as common. Server response shows up less often as a named opportunity in this lab cut, which does not mean TTFB is fine in the field; it means the Lighthouse opportunities list is dominated by front-end weight once the document arrives. For the hosting-versus-theme argument agencies still have with clients, see WordPress Site Slow? It Is Not Always the Hosting. For speculation and prerender plugins that can help navigation and sometimes hurt LCP, see WordPress Speculation Rules and Prerender vs Core Web Vitals.

How to use these WordPress benchmarks on a retainer

A useful next step is to open one client domain report and compare its mobile Performance average and lab LCP to the medians above. Sites well above a mobile Performance of 62 with lab LCP near the good line are not the priority queue; sites below the median with unused JavaScript and redirects repeating across templates usually are. That single comparison is enough to decide whether the next sprint is LCP work or quiet monitoring.

Budgets stay clearer when they name the artefact: lab LCP and Performance on a fixed URL set, reviewed on a schedule, with field CrUX added when the origin has data. The Complete Guide to Performance Budgets for Web Teams covers threshold design, and PageSpeed Monitoring: How to Schedule Test Frequency and Priority Across Your Portfolio covers cadence across many WordPress clients. Homepage-only PageSpeed Insights understates template drag, so the cost of inaction is another quarter of retainers argued from screenshots instead of a shared baseline.

FAQ

Do these lab averages mean most WordPress sites fail Core Web Vitals in Search?

No. Lab store averages and CrUX origin pass rates are different clocks. Public CrUX studies still show a large share of WordPress origins passing all three vitals. The Watcher sample shows how multi-page lab averages look on client WordPress stacks under throttling.

Why is median lab LCP so far from 2.5 s?

Domain reports average many templates. Heroes, page-builder CSS, and plugin scripts that repeat on archives and conversion URLs pull the store average up even when one marketing URL looks acceptable.

Is WordPress worse than Shopify or Magento in Watcher’s samples?

On median mobile Performance, this WordPress client cohort (62) sits above our Shopify (51) and Magento verified (58) lab samples. LCP remains the shared failure mode across all three. Prefer same-method comparisons over mixing CrUX pass rates with lab averages.

Should we chase unused CSS before hosting?

In this opportunity list, unused JavaScript, unused CSS, and redirects dominate. Hosting still matters for TTFB in the field, but the lab queue on these client sites is mostly front-end weight and redirect hygiene.

CTA

If you manage WordPress clients, the useful move after these tables is to pull one domain report, mark where it sits versus the medians, and put lab LCP plus unused JavaScript on the next sprint board with a scheduled re-test. WordPress Performance Monitoring: The Complete Guide is the operational companion. Start a trial at sign-up when you want that multi-page lab baseline on a schedule rather than another one-off homepage PageSpeed Insights run.

References

CrUX methodology (Chrome for Developers)
Understanding Core Web Vitals and Google search results (Google Search Central)
Core Web Vitals Statistics 2026 (HostingStep)
CMS Core Web Vitals 2026 (PageSpeed Matters)
Core Web Vitals Benchmarks for Shopify Stores (2026 Data) (Apogee Watcher)
Core Web Vitals Benchmarks for Magento Stores (2026 Data) (Apogee Watcher)
Core Web Vitals Benchmarks for Fashion Stores (2026 Data) (Apogee Watcher)
WordPress Performance Monitoring: The Complete Guide (Apogee Watcher)
WordPress Site Slow? It Is Not Always the Hosting (Apogee Watcher)
WordPress Speculation Rules and Prerender vs Core Web Vitals (Apogee Watcher)
What Are Core Web Vitals? A Practical Guide for 2026 (Apogee Watcher)
The Complete Guide to Performance Budgets for Web Teams (Apogee Watcher)
PageSpeed Monitoring: How to Schedule Test Frequency and Priority Across Your Portfolio (Apogee Watcher)

Internal only - do not publish

Calendar: Watcher #101 / Sat 7 Nov 2026.

Cohort: 101-wordpress-benchmark-analysis.json (prod 2 Nov 2026); n=381 client WordPress + latest domain report; 7278 page runs.

Charts: CDN 101-wordpress-lighthouse-performance.webp, 101-wordpress-mobile-lab-cwv-medians.webp, 101-wordpress-lighthouse-opportunities.webp.

Pass 0 / 0.5: 101-serp-brief.md (agency_tech_lead, journey diagnose).

Passes: 1–4, 4b–4d complete (2 Nov 2026). Not imported.

Links: 41, 60, 89, 06, 11, 45, plus 80 / 83B / 85B.

Voice: British English; §2.21 descriptive how-to; lab ≠ CrUX clocks stated explicitly.

Changelog #14: AI Insights, Affiliate Programme, CSV/PDF Exports

Apogee Watcher — Sat, 31 Oct 2026 21:59:59 +0000

October closed with site-level AI actionable insights leaving beta, a clearer site workspace for tests and reports, and a public affiliate programme for partners who already recommend Watcher. Earlier in the month we made the free domain check easier to start, showed plan usage in the topbar, opened organisation report PDFs on Starter, and added CSV export for site test history. Changelog #13 (1 Oct 2026) covered weekly organisation reports, Cloudflare-aware PageSpeed runs, and Agency lead tools. This release covers product work from early October through the end of the month. For the long-form AI announcement, see Site-Level Guidance: AI Actionable Insights Leave Beta. For partner terms, see Watcher Affiliate Programme: 30% Commission for Agencies and Publishers.

AI actionable insights leave beta

Domain report Summary already gave agencies a fixed triage view: attention-free score, top pages needing attention, and merged opportunities. What was still missing was an optional step that turns a multi-page snapshot into a prioritised fix order a developer can ship without reopening every Lighthouse tab. That step is out of beta. From a domain report in the app, Managers and Admins can generate site-level AI insights from stored PageSpeed / Lighthouse evidence for the pages in that report. The output is a short narrative, a prioritised how-to-fix list, and evidence that points at shared templates or third parties when those patterns repeat. It does not re-score the site or invent metrics that were not in the stored runs.

Each generate or regenerate uses one AI credit for the organisation’s current monthly period. Caps and remaining usage appear in the topbar Plan & usage panel next to sites, organisations, and tests. Default paid tiers from Personal upward include the feature; Free does not. Public share links show the insight body only after someone with access has generated a completed insight, so client links stay free of an empty AI box until you choose to share it.

Summary stays free and does not spend AI credits. Generate when you want a prioritised written plan for the site; skip it when Summary already answers the call. Detail and screenshots: Site-Level Guidance: AI Actionable Insights Leave Beta. Docs: Domain performance reports and Understand plan limits. For Summary itself, see Attention-Free Score on domain reports.

Updated site view

Alongside AI insights leaving beta, we refreshed the site view so day-to-day monitoring work stays on one record instead of jumping between unrelated screens. From Setup → Sites, a property opens with pages and discovery for the URL pool, test history for what already ran, statistics for recent lab movement, and Reports for domain-report generation and AI actions. Insights are only as good as the evidence behind them, so discovery and page lists decide which URLs enter the report pool, scheduled tests fill that pool, and Reports turn the results into a shareable Summary and, when you choose, an AI insight. Keeping those steps on one site record lowers the chance that someone generates an insight from an incomplete page set.

Affiliate programme

Partners who already tell clients or readers to stop relying on a once-a-week PageSpeed Insights run now have a tracked commercial path when those people choose Watcher. The public Affiliate programme page states the live terms: one coupon per partner, 30% of attributed plan revenue in EUR for 12 months after trial→paid conversion, a 30-day hold, and a €50 PayPal minimum. Attribution uses the coupon system we already use for trials, so append the coupon query to any public Watcher page, track redemptions under Account → Affiliate, and request payout when available commission clears the hold and minimum. Free plans and pure trials do not generate commission. Full announcement: Watcher Affiliate Programme: 30% Commission for Agencies and Publishers.

Free domain check: email optional, live thanks, save later

Earlier in October we simplified the public free domain check funnel. An email address is no longer required before the scan starts. You can run discovery and tests first, then add contact details when you want the report link or a save path. The thanks page shows live scores and findings grouped by page type while the run finishes, instead of a static waiting screen.

When a shared domain report is ready, anonymous viewers can leave an email on the report page to create a Free account and import the scan. Signup links from free-check mail carry the email and report token so the save step keeps that context. Hero and form controls received a small design update so the funnel matches the rest of the public site.

Use /check when you want a multi-page lab snapshot before you commit to monitoring. For how free-check reports relate to saved sites, see the help centre and pricing.

Plan usage in the topbar and quota warning emails

Organisation admins can see Sites, Orgs, and Tests usage in the signed-in topbar without opening My Account. The detail panel shows period context and a short forecast for scheduled tests through the end of the billing period.

On the subscription anniversary window, Watcher sends a warning when successful tests reach 80% of the plan budget (with a scheduled-run forecast), and a second notice at 100% when new successful runs pause until renewal or an upgrade. Quotas still renew on the subscription anniversary day, not a fixed calendar month, unless the account has no start date.

Docs: Understand plan limits and Site API usage and quotas.

PDF reports on Starter; white-label stays Professional+

Starter now includes PDF reports for weekly organisation report downloads. That matches the client-export need for small teams without unlocking agency branding. White-label reports (logo, colour, curated PDF fonts) remain a Professional and above differentiator.

If you are on Starter, open Results → Reports after a weekly run (or Preview mid-week) and use Download when a PDF exists. Branding fields on the organisation do not change the PDF theme until the plan includes white-label. See Organisation reports and PDF and White-label reports.

CSV export for site test results

From Results → Site Test Results, or from a site’s Test results tab, select rows and use bulk Export to CSV. Columns include full page URL, site, device, performance score, LCP, INP, CLS, FCP, TBT, tested-at time, status, and a link back to the result in the panel. Viewers can export selected rows; they still cannot run tests or delete results.

The Test results table also supports a score-range filter. Alert and site-notice deep links into the site-filtered alerts table resolve correctly again. Guide: Run a test and read results.

What to try

On a monitored site with completed tests, create or open a domain report and generate AI insights when your plan includes the feature. Check that the topbar AI credit meter moves, then open the public report URL and confirm the insight appears only after generation. From Setup → Sites, open the same property and walk Pages, Test results, and Reports without leaving the site record.

Run /check without an email address, wait for the thanks page to fill with scores, then save the report from the public report CTA with an email. If you are a signed-up user, In the app, open the topbar Sites / Orgs / Tests meters and confirm they match My Account and dashboard plan usage. If you are near a test cap, check whether an 80% warning would fit your anniversary period.

On Starter, Preview or open the latest weekly organisation report and download the PDF. On Professional or above, confirm white-label still applies only when that feature is on. On a monitored site, open Test results, select several rows, and Export to CSV. Open a weekly report unsubscribe link in a private window and confirm the confirm step is required.

References

Launch checklist vs retainer checklist for AI-built websites

Apogee Watcher — Sat, 31 Oct 2026 09:23:07 +0000

A launch checklist answers one question: is this site safe to show a client today? A retainer checklist answers a different one: will we notice when it gets worse next month? Agencies that treat those as the same document keep shipping AI-built sites that look finished on Friday and feel slow after the next content prompt.

The launch pass is short, human, and often honest. Forms work. Mobile layout holds. Analytics fires once. Someone ran PageSpeed Insights on the homepage and pasted a green-ish score into Slack. The retainer pass is calendar-shaped: named URLs, dated lab runs, field context when CrUX exists, and a named owner when Largest Contentful Paint or Interaction to Next Paint moves. AI builders make the gap wider, because a successful afternoon QA does not survive an unsupervised redesign of the hero or a new chat widget.

What follows is a side-by-side for agency teams and freelancers who ship AI-assisted sites into retainers. For what automated monitoring means in plain terms, see What Is Automated Web Performance Monitoring?. For why agencies outgrow manual checks, see Why Agencies Need Automated Performance Monitoring in 2026.

What a launch checklist is for (and what it is not)

A launch checklist is a gate before the custom domain goes live. Typical rows cover critical journeys (home, contact, booking or checkout), forms and email delivery, broken links, mobile layout, basic accessibility, SEO tags, analytics, and a one-off Lighthouse or PageSpeed Insights pass on home and the conversion URL. The job is binary enough for a ship decision: ship, fix, or delay.

It is not a monitoring plan. Passing once does not create history, budgets, or alerts. It also does not prove field Core Web Vitals for real users; CrUX needs traffic and time. Launch QA can include a lab score, but that score is a photograph of one URL on one day, not a retainer obligation.

For AI-built sites the launch list still matters. Builder previews lie; the published origin is what clients open. Forms, redirects, and consent banners deserve a human pass even when the model wrote the templates. The mistake is stopping there and calling performance “done.”

What a retainer performance checklist covers

A retainer checklist assumes the site is already live and somebody will keep watching it. The useful rows look more like operations than launch day:

Named URL set (home, conversion path, one or two templates that change often)
Scheduled lab tests on a fixed cadence (weekly is enough for many small retainers; denser where deploys are frequent)
Field context when PageSpeed Insights or Search Console shows CrUX for the origin or URL
Budgets or plain thresholds on LCP, INP, and CLS that a human can explain
Alert or review ritual with a named owner (Slack channel, weekly standup line, or report pack)
Change log of what shipped since the last green period (theme edit, tag manager, AI prompt, plugin)

That list is the monitoring half of automated web performance work: schedules, history, thresholds, and a person who acts. It is deliberately boring. Boring is what survives a portfolio of AI-assisted client sites.

Side-by-side: launch afternoon vs weekly monitoring

Question	Launch checklist	Retainer checklist
When	Once before go-live (and after big launches)	On a calendar after go-live
Pass condition	Journeys work; no blockers; one lab sanity check	Trends hold; regressions get a ticket
Artefact	Checkbox list / QA notes	Dated runs, budgets, alerts, monthly proof
Owner	Launch engineer / PM	Account or performance owner on the retainer
AI risk it catches	Broken forms, missing tags, obvious layout	Hero swaps, new widgets, script creep after prompts
Stops when	Domain is live	Never; cadence continues

Both lists can share a few URLs. They should not share a single “done” checkbox. Launch says the site can open. Retainer says you will notice when it softens.

How AI-built sites break the gap between the two

AI builders and agent workflows accelerate the launch list. They also accelerate post-launch drift. A prompt that replaces the hero image, injects a booking iframe, or adds a chat script can clear launch QA and still move LCP, CLS, or INP within a week. Cookie banners and marketing tags often arrive after the padlock, which is after the launch checklist closed.

Teams that only re-run the launch list after every prompt waste time on binary gates that already passed. Teams that never leave launch mode miss the regressions that show up as “the site feels slower” emails. The retainer checklist is the cheaper habit: keep the same URLs on a schedule so the next prompt has a before-and-after, not a memory of Friday’s green score.

Agencies feel this first. One AI-built brochure site is manageable as a spot check. Ten clients with weekly content prompts are not. That is the same scaling story as any portfolio without schedules: manual honesty that does not fit the calendar.

How to hand off from launch QA to a monitoring loop

A practical handoff after go-live usually looks like this:

The launch checklist stays in the project folder as the ship record.
Three to five URLs move into the retainer set (home, conversion, one volatile template).
Those URLs sit on a weekly lab schedule, with mobile and desktop as separate series where both matter.
One budget line per Core Web Vital the client already understands (or score bands if that is the retainer language).
A named reader for the first amber week: account manager, developer, or shared channel.
After any AI builder session that touches layout, media, or third-party scripts, the next scheduled run is mandatory reading, not optional polish.

You do not need a heavy stack on day one. You need a calendar and a short URL list. Tools that already define schedules, budgets, and multi-site views fit when the portfolio grows; the definition of automated monitoring is still those jobs, not a one-off paste.

FAQ

Can the launch checklist include Core Web Vitals?

Yes, as a lab sanity check on key URLs. Treat it as evidence for ship day, not as proof that field vitals will stay green.

Is a monthly PageSpeed Insights paste a retainer checklist?

Only if you save dates, compare the same URLs, and act when numbers move. A lonely paste without history is still launch-style QA on a slower clock.

Do AI-built sites need different monitoring than hand-built ones?

The metrics are the same. The change rate is often higher, so the retainer cadence matters more after prompts that rewrite layout or inject scripts.

Where does a one-off “fix Core Web Vitals” agent prompt fit?

It can help diagnose a URL. It does not replace either checklist. Launch still needs human journeys; retainer still needs scheduled evidence.

Keep both lists, stop merging them

Launch QA gets the site live. Retainer monitoring keeps the story honest after the next edit. AI-built websites make that split sharper, not softer. Ship with a launch checklist, then put the same critical URLs on a dated loop before the first unsupervised prompt goes live in production.

If you want that loop across many client hosts without another Monday paste, try Apogee Watcher or run a free domain check on the URLs you just launched.

References

What Is Automated Web Performance Monitoring? (Apogee Watcher)
Why Agencies Need Automated Performance Monitoring in 2026 (Apogee Watcher)
AI-built sites: the Core Web Vitals regressions that show up after the padlock (Apogee Watcher DevLog)

We Sold PageSpeed Retainers for Years. Here Is Why We Productised Monitoring Instead of Another Audit PDF

Apogee Watcher — Fri, 30 Oct 2026 07:58:18 +0000

Apogee Information Systems has sold digital work since 2002. For a long stretch of that history, website speed showed up as a line on a statement of work: a PageSpeed Insights paste after a redesign, a Core Web Vitals fix sprint, a quarterly “we checked the homepage” slide. Clients paid for people and hours. The artefact they remembered was often a PDF.

When we built Apogee Watcher, we were not inventing a new category for its own sake. We were productising the part of the retainer that never scaled: keeping many client hosts on a dated lab and CrUX schedule without another Monday paste. What follows is that pivot story for founders who are deciding whether to turn an agency service into a product. It is not a revenue brag and it is not a feature dump. It is the decision path we wish we had written down earlier.

If you already run PageSpeed retainers and you are tempted to package “the report” as the product, start with the failure mode we rejected. If you are building tools for agencies, the same cut explains why multi-tenant monitoring and white-label PDFs are different jobs. Both audiences care about the same split: what software can keep honest on a calendar, and what still needs a named human on the retainer.

What a PageSpeed retainer looked like before the product

A typical performance retainer mixed three jobs that felt related and were not the same purchase.

First came discovery and fixes: theme, hosting, images, third parties, templates. That work still needs humans. Second came proof for the client: screenshots, scores, a narrative for the account lead. Third came continuity: the same URLs checked again after the next plugin update, campaign landing page, or template ship. Continuity was the piece that quietly failed. Nobody wanted to own the calendar. The SOW said “monitor,” and the delivery looked like sporadic PageSpeed Insights runs when someone remembered.

We could sell that as a service forever. Agencies already do. The labour cost sits inside the retainer margin until the portfolio grows past the capacity of one careful developer. At that point you either hire, raise prices, or stop promising continuity. Productising the service only helps if you productise the job that broke first.

For the buyer map of how agencies price portfolio monitoring once they leave DIY, see Affordable Multi-Tenant Performance Monitoring Under $100/Month. For the monthly report loop after tests exist, see From Scheduled Tests to White-Label CWV Reports: A Monthly Retainer Workflow. Those posts assume the product already exists. What follows is why we built it.

Why another branded audit PDF was the wrong product bet

The obvious productisation move for a PageSpeed agency is a prettier report. Put your logo on a Lighthouse export, sell a self-serve audit, charge per PDF. The market already has free and paid checkers. Agencies already send branded decks. Competing on “a nicer screenshot of a score you could get from Google” is a thin moat.

An audit PDF answers one question on one day: what does this URL look like right now? Retainers need a second question: did last month’s fix stick after the next content ship? A product that only sells the first question leaves the continuity problem inside the agency again. You have productised the commodity and kept the expensive habit unsolved.

We also rejected “AI that explains one PageSpeed Insights JSON” as the core product. Explaining a single run is useful. It is not multi-tenant monitoring. Site-level guidance that reads a domain-report snapshot is a later layer on stored evidence, not a substitute for the schedule. When that layer left beta, we documented the split between deterministic Summary and optional AI synthesis in Site-Level Guidance: AI Actionable Insights Leave Beta. The order mattered: evidence and schedules first, narrative second.

What we productised instead

Watcher productises the continuity job: organisations hold many sites, sites hold pages discovered from sitemaps and crawls, and scheduled PageSpeed Insights runs store lab metrics plus CrUX field context when Google returns it. Budgets and alerts fire when scores move. Team roles keep account managers in Viewer mode without buying a seat per reader on a premium RUM plan. Domain reports and weekly organisation packs turn stored runs into something you can send without rebuilding a slide deck from scratch each month.

That shape is multi-tenant by design. Agencies do not buy monitoring the way a product team buys continuous synthetic coverage on one storefront. They buy portfolio coverage without placing a first-party RUM script on every client origin and without managing a Google API key per client. We hold the PageSpeed Insights relationship so the agency does not. Field context comes from CrUX in the result when it exists; we do not claim to replace Calibre-style RUM on a flagship site you fully control.

The product boundary is deliberate. Fix work, theme work, and hosting decisions stay in the retainer. The product owns the calendar, the history, and the shareable scoreboard. If you want the definitional framing of that category, What Is Automated Web Performance Monitoring? stays the short reference. For how a one-off PageSpeed Insights paste fails the same continuity test, PageSpeed Insights vs Automated Monitoring is the companion argument.

Service hours, product seats, and premium RUM compared

Approach	What you sell	Scales with…	Breaks when…
Classic PageSpeed retainer	People + fixes + occasional PSI paste	Billable hours	Portfolio grows faster than staff
Branded audit PDF product	One-off lab report	Per-report or per-URL fees	Client asks “and next month?”
DIY scripts + Lighthouse CI	Engineering time + infra	Engineer capacity and API quota	Reporting and on-call stay manual
Multi-tenant PSI monitor (Watcher)	Scheduled lab + CrUX-in-PSI, orgs, alerts, reports	Org / site / test quotas	You need session-level RUM on one origin
Premium continuous + RUM (Calibre, DebugBear, SpeedCurve)	Deep synthetic + first-party RUM	Seats, synthetic packs, RUM sessions	Brochure long-tail burns the monitoring line item

Agencies often need both a portfolio layer and a flagship RUM tool. That is the layer, do not replace stance we take in stack posts: Calibre or DebugBear on one or two owned origins where continuous synthetic depth and RUM pay for themselves, Watcher across the long tail of client hosts. Productising monitoring did not mean claiming we replaced every incumbent. It meant owning the job that our retainers already promised and could not keep by hand. The side-by-side with continuous monitoring brands is also spelled out in Calibre vs Apogee Watcher.

Layer, do not replace: the stack honesty that kept the product shippable

Rip-and-replace pitches sound bold in a landing page. They fail in agency sales cycles. Clients already have hosting, CMS, tag managers, and sometimes a RUM vendor on the money site. A new monitor that demands migration of every tool loses the deal before the trial starts.

Watcher ships as a schedule and a history store on public URLs. No client-side script is required for the core path. That constraint limited what we could claim and clarified what we could ship. We do not attribute Interaction to Next Paint to a single button in a logged-in session. We do tell you whether mobile Largest Contentful Paint on the homepage moved after last week’s theme update, with a dated run you can open again.

Founders productising an agency service often underestimate how much of the service brand is “we will figure it out.” Products cannot figure it out indefinitely. They need a narrow job with measurable inputs. For us the inputs were URLs, strategies, schedules, and stored PageSpeed Insights payloads. The service brand kept the consulting relationship. The product kept the calendar honest.

What stays in the agency after the product ships

Productisation is not a funeral for retainers; it is a cleaner split between what software can store on a schedule and what still needs a human judgment call. Agencies still sell diagnosis and implementation. They still write the narrative for a quarterly business review. They still decide whether a template change or a third-party tag caused the regression. Watcher makes the evidence cheaper to gather and harder to lose. White-label and weekly organisation reporting help the presentation layer; they do not replace the consultant who interprets trade-offs for a specific client stack.

If you are mid-pivot, a practical test helps. List the last ten hours you billed under “performance,” then mark which of those hours were fixing versus re-running the same URLs and rebuilding the same slides. The second pile is usually the better first product. The first pile stays as services until you have a different product thesis with its own measurable inputs.

We still use Watcher on our own properties and for client portfolios. The affiliate programme exists for people who already recommend the category; it is not the founding product story. The product story remains the schedule.

FAQ

Should every agency turn a service into a SaaS product?

No. Many retainers stay healthier as services. Productisation pays when one job repeats across clients, the inputs are measurable, and the delivery fails at portfolio scale. PageSpeed continuity met that bar for us. Custom redesigns did not.

Is “agency to SaaS product” the same as building a tool for agencies?

Not always. Building SaaS for agencies is a customer segment. Turning your delivery into a product is an operations cut. Our cut was internal continuity pain that matched an external buyer: agencies managing many hosts who cannot fund premium RUM on every brochure site.

Did you stop selling performance services?

No. Implementation and advisory stay human. The product owns monitoring history and alerts so the retainer can spend hours on fixes instead of paste-and-screenshot theatre.

How is this different from selling a white-label audit PDF?

An audit PDF is a one-day artefact. Monitoring is a series of dated runs on the same URLs. We productised the series. Reports sit on top of that series; they are not the product by themselves.

Where should a founder start if they want to productise a similar service?

A useful first pass is to write down the recurring job that breaks when client count doubles, then name the artefacts you already produce (URL lists, scores, alerts, PDFs). The smallest credible product is usually the system that stores those artefacts on a schedule and sits beside the retainer. It is not a replacement for the trust that closes advisory work, and it should not pretend to be.

Measure the calendar, then sell the fix

We sold PageSpeed retainers for years because clients needed faster sites and clearer reports. We productised monitoring because the calendar was the part of that promise we could not keep with paste alone. Another audit PDF would have productised the commodity. A multi-tenant PageSpeed schedule productised the habit.

If you run a portfolio today and the continuity job is already failing, try a multi-page sample at apogeewatcher.com/check or start a free Watcher account and put your noisiest client URLs on a dated schedule before you invent another report template.

References

AI-built sites: the Core Web Vitals regressions that show up after the padlock

Apogee Watcher — Thu, 29 Oct 2026 08:27:25 +0000

The padlock in the address bar means the custom domain is live on HTTPS, but it does not mean Core Web Vitals stay healthy after the next edit. The certificate proves encryption. It says nothing about Largest Contentful Paint on the booking page next Tuesday.

AI-built sites often look fine on launch day: one homepage laboratory pass, images compressed, obvious red audits cleared. Then someone swaps the hero, pastes a booking widget, turns on a cookie banner, or asks the builder for a “fresh look.” Those are normal post-go-live moves, and they are also the usual path from a green afternoon score to an AI website that feels slow after launch.

What follows names the Core Web Vitals regressions we see after the padlock, why laboratory scores move, and how to catch the next change before a client forwards a complaint. For metric thresholds, keep LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It open. For why one PageSpeed Insights run in Slack is not a portfolio schedule, see PageSpeed Insights vs Automated Monitoring.

Why Core Web Vitals regress after go-live on AI-built sites

Launch checks answer a narrow question: is this build good enough to connect the domain? They rarely answer the after-launch question: will the same URLs still meet good thresholds after content and third parties change? Agencies that stop at the padlock usually learn the answer from a client screenshot, not from their own dated run.

AI builders make those changes cheap. A one-sentence prompt can replace the Largest Contentful Paint candidate, inject a chat script on every template, or regenerate layout that was stable last week. The builder did not fail, but the team stopped measuring after the padlock.

Website performance after go-live also depends on the live host, not the preview CDN. Once DNS points at production, image origins, caching headers, and third-party domains often differ from the builder preview. Public URLs after cutover are the fair baseline. The preview score is not.

Hero and image swaps that break Largest Contentful Paint

The most common post-launch Largest Contentful Paint regression on AI-built sites is a marketing edit, not a platform outage. Someone uploads a heavier hero, removes fetchpriority or preload hints the builder had set, or lazy-loads the above-the-fold image because a checklist said “lazy load everything.” That edit can go live without a deploy ticket, so nobody thinks to re-run PageSpeed Insights.

When the homepage suddenly feels slower, the useful artefacts are the previous hero dimensions and file weight, then a fresh mobile laboratory Largest Contentful Paint on the same URL. If the new image is the Largest Contentful Paint element, that asset is the first place to look. Unrelated script audits rarely explain the jump.

Booking, chat, and WhatsApp widgets that hurt Interaction to Next Paint

Conversion pages are where AI-built sites usually get slow after launch. Home stays tidy while the quote, booking, or contact URL loads calendars, maps, WhatsApp buttons, and chat bubbles. Those scripts compete for the main thread, so Interaction to Next Paint (or Total Blocking Time in older laboratory reports) is the metric that moves first.

Each new widget belongs on a laboratory pass for the conversion URL, not only for home. If the agent never saw the booking iframe when it “fixed Core Web Vitals,” it cannot be blamed for a widget added two weeks later. Non-critical scripts often work better deferred, and chat that waits for first interaction hurts Interaction to Next Paint less when the product allows it. One dated mobile run on the conversion URL in the client note is enough evidence for the next comparison.

Cookie banners and late embeds that raise Cumulative Layout Shift

Cookie consent, newsletter bars, and embeds that inject after first paint are common Cumulative Layout Shift sources. AI builders often ship a minimal banner on day one, then the legal or marketing team enables a heavier consent manager later. Layout that looked stable in the launch laboratory run starts shifting under real Chrome visits once field samples exist.

A useful reproduction is mobile, with the banner accepted and dismissed. Templates that reserve space for the banner, or load it without pushing the Largest Contentful Paint candidate, keep Cumulative Layout Shift lower. Late YouTube or map embeds need the same treatment: sized containers before the iframe paints.

Full redesign prompts that erase last week’s laboratory baseline

“Make it look more premium” is a legitimate client request. On an AI-built site it can rewrite templates, fonts, and image treatment in one pass, and the previous green laboratory screenshot becomes irrelevant because the DOM is no longer the same site.

Before a redesign prompt, the URL list, device strategy, and scores you will compare against are the baseline worth saving. After the redesign, that same list is the honest re-test. If nobody recorded the baseline, the account lead has no way to say whether Core Web Vitals got better or worse. That process gap looks like “the AI website got slow after launch” even when only the new design is slow.

How to catch the next regression before the client forwards a complaint

A practical loop for AI-built properties looks like this:

Keep a short URL list: home plus the conversion URL (booking, shop, or quote).
Record laboratory tool, strategy (mobile or desktop), and date for every “we are fine” claim.
Re-run the list after every material edit: hero, widget, banner, redesign, or tag manager change.
When PageSpeed Insights shows field data, read URL-level and origin-level rows separately. Do not claim Search Console health from a laboratory screenshot alone.
Put the next check on a calendar. Weekly is enough for most small sites; agencies running many AI-built clients need a portfolio schedule.

That loop is monitoring, not another launch prompt. Spot checks remain useful for debugging a single change, but they do not scale when five clients each ship Christmas banners the same week. Automated coverage exists so regressions show up before the complaint email.

FAQ

Does the padlock mean Core Web Vitals are fine?

No. HTTPS proves the connection is encrypted. Core Web Vitals still need laboratory checks on the live host, and field data when Chrome samples exist.

Why is my AI website slow after launch when the builder said it was green?

Usually a post-launch edit or a host difference, not a lying launch report. Public URLs after cutover are the fair comparison, then the same URL before and after the hero, widget, or redesign change.

Which pages should I re-test after go-live?

At minimum home and the conversion URL. Blog templates and category pages matter when those URLs carry ads, embeds, or shared scripts.

Can we still use AI website builders?

Yes. Keep them for speed of build. Keep a dated laboratory schedule (and field data when available) for the weeks after the padlock. Launch and retain are different jobs.

Keep the padlock. Watch the next edit.

An honest launch checklist is still the right gate for connecting the domain. After that, every hero swap, widget paste, cookie banner, and redesign prompt is a new Core Web Vitals event on a short URL list. That is how you keep “green on Friday” from becoming “slow after launch” with no dated evidence in between.

If you want that schedule across many client domains without running PageSpeed Insights by hand each time, try Apogee Watcher or run a free domain check for a multi-page laboratory baseline before the next edit ships.

References

Lab data vs field data (web.dev)
Optimize Largest Contentful Paint (web.dev)
Optimize Interaction to Next Paint (web.dev)
Optimize Cumulative Layout Shift (web.dev)
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring (Apogee Watcher)

Defer, Async, and Module Scripts: A Field Guide for INP and TBT

Apogee Watcher — Thu, 29 Oct 2026 08:23:49 +0000

A classic <script src="…"> with no attributes pauses HTML parsing while the file downloads and runs. An async script downloads in the background and runs as soon as it is ready, which can interrupt the parser mid-document. A defer script also downloads in the background, but it waits until parsing finishes, then runs in document order before DOMContentLoaded.

Those three timings are not interchangeable. Choosing wrong keeps Total Blocking Time high in the lab and Interaction to Next Paint red in the field, even after you have cleaned render-blocking CSS. Script loading is the other half of first-paint and responsiveness work. Critical CSS clears stylesheet wait; attributes on <script> decide when JavaScript claims the main thread.

What follows is a field guide for agency sites: how parser-blocking scripts feed TBT and INP, when defer versus async fits, what type="module" changes, and how to verify the change on the URLs you already monitor. Metric thresholds sit in LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It and FCP and TBT: Supporting Metrics Beyond Core Web Vitals. Third-party inventories belong with Third-Party Scripts and Performance: The Worst Offenders. Stylesheet extraction is covered in Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing.

What parser-blocking scripts do to Total Blocking Time and INP

Without async, defer, or type="module", an external classic script is parser-blocking. The browser stops building the DOM until that script has downloaded, parsed, and executed. Long tasks on the main thread after First Contentful Paint add to Total Blocking Time in Lighthouse: every task over 50 milliseconds contributes its duration minus 50 milliseconds to the TBT sum. High TBT is a lab signal that the page was hard to interact with during load.

Interaction to Next Paint is the field Core Web Vital for responsiveness. It measures how long the page takes to respond to clicks, taps, and key presses with the next paint. Heavy JavaScript during or soon after load is a common INP cause, but INP also captures later interactions when chat widgets, consent banners, or cart scripts wake up. TBT is a useful lab proxy for that risk; it is not a substitute for field INP. web.dev is explicit that a low TBT often correlates with a low INP, and that you still need field measurement for real user responsiveness.

For agencies, the practical split is simple. Lighthouse TBT and the Performance panel show which script files create long tasks on a cold load. CrUX in PageSpeed Insights or Search Console shows INP on the live origin. Changing script attributes moves both numbers only when those scripts were actually on the critical path.

Defer vs async scripts: when each attribute fits

Both async and defer let the browser continue parsing HTML while the script downloads. The difference is when execution starts, and whether order is preserved. MDN and web.dev describe the same contract:

Loading mode	Download	Execution	Order	Typical fit
Classic (no attribute)	Blocks parser	Immediately when ready	Document order	Rare; only when the page cannot paint without that script
`async`	Parallel	As soon as downloaded (can interrupt parser)	Not guaranteed	Independent tags: many analytics and pixels
`defer`	Parallel	After HTML parse, before `DOMContentLoaded`	Document order	Theme bundles, shared libraries, scripts that need the DOM
`type="module"`	Parallel	Deferred by default (like `defer`)	Module graph order	Modern app entry points and ES modules

<!-- Independent; order does not matter -->
<script src="https://example.com/analytics.js" async></script>

<!-- Needs DOM; must run after sibling libraries in order -->
<script src="/js/vendor.js" defer></script>
<script src="/js/theme.js" defer></script>

async fits when the script is self-contained and should run at the first opportunity after download. Analytics snippets often ship this way. Evaluation can still briefly block the parser when it starts, and two async tags may finish in either order.

defer fits when scripts depend on the full document or on each other. Theme JavaScript that handles forms, drawers, and navigation usually belongs here. defer scripts run in markup order after parsing completes, which keeps vendor-then-app sequences intact. Shopify’s theme guidance makes the same split: defer for theme scripts, async for independent third parties.

If both async and defer are present on a classic script, browsers treat the element as async. One deliberate attribute is clearer than both. Leaving both set usually means a copy-paste leftover, not a loading strategy.

How `type="module"` changes script loading

Module scripts (<script type="module" src="…">) are deferred by default. You do not need a separate defer attribute for that behaviour; MDN notes that defer has no effect on modules because deferral is already the default. Modules also fetch their dependency graph, so boot cost can still create long tasks even when parsing is not blocked.

Adding async to a module script changes the contract: the module and its dependencies fetch in parallel with parsing and evaluate as soon as they are available, without waiting for the full document parse the way classic defer does. That helps some independent module entry points. It is a poor default for a theme that expects DOM-ready order across several classic files.

For agency migrations, modules and classic tag-manager injects are usually separate pipelines. Converting one app bundle to type="module" does not fix a synchronous Google Tag Manager container still in the <head> without async or defer. Both pipelines need a check on the same URL before the JavaScript half is done.

How to choose attributes for theme, analytics, and tag-manager scripts

A practical decision pass on a client template looks like this:

List every external <script src> on home and on the conversion URL (view-source or the Network panel filtered to JS).
Mark each script as theme / first-party app, analytics or pixel, tag manager / consent, or embed (chat, maps, video).
defer usually fits first-party theme and app scripts that touch the DOM or depend on load order.
async usually fits independent third-party trackers that do not require sibling order.
Classic blocking is rarely justified; it belongs only when a script must run before first paint for a documented reason.
Tag managers should match the vendor’s current snippet. Many Google Tag Manager installs use async on the container loader; consent-mode and consent-banner scripts still need a check so they do not reintroduce a parser-blocking chain.
Coverage and the Performance panel confirm the change: long tasks should move off the early critical path, not merely rename themselves.

Third-party volume still matters after attributes are correct. A deferred chat widget that downloads two megabytes will hurt INP when it evaluates, even if it no longer blocks HTML parsing. Attribute choice is necessary; removing or delaying low-value tags remains the larger win on many portfolios. The worst-offenders guide covers that inventory work.

Mistakes that keep Total Blocking Time and INP high

Deferring nothing and hoping minify alone is enough. Minification shrinks transfer size. It does not change parser-blocking behaviour. A small synchronous script in the <head> can still stall DOM construction on a mid-range mobile CPU.

Putting interdependent libraries on async. If theme.js assumes vendor.js already ran, async on both creates race conditions that look like “flaky checkout” rather than a Lighthouse warning. Those scripts usually need defer (or a single bundled file) so order stays stable. The attribute change is cheaper than a sprint chasing intermittent null-reference bugs.

Treating async as “free.” Evaluation still runs on the main thread. An analytics file that executes a 200 millisecond task as soon as it downloads still adds blocking time. Attributes work better alongside code-splitting, fewer tags, and idle or interaction-based loading where the product allows it.

Ignoring dynamically injected scripts. Tag managers and consent tools often insert new <script> nodes at runtime. Attributes on the original loader do not automatically apply to every child inject. The Network and Performance panels after consent accept show more than a cold load with banners dismissed.

Fixing CSS and skipping JavaScript. Clearing render-blocking stylesheets improves First Contentful Paint and sometimes Largest Contentful Paint. Responsiveness still depends on when scripts run. The CSS pass and the script-attribute pass belong on the same URLs as related work items.

One homepage change for the whole portfolio. Booking, checkout, and account templates often load extra tags. Coverage and TBT on the conversion URL catch scripts the brochure home never requested. Checkout and booking templates need their own script inventory, not a copy of the home <head>.

How to verify script-loading changes in Lighthouse and monitoring

After attributes change, a useful verification loop looks like this:

Record the laboratory tool, URL, strategy (mobile or desktop), and date for a before baseline.
Re-run Lighthouse or PageSpeed Insights on the same URL and strategy. Total Blocking Time, the “Reduce JavaScript execution time” / bootup-time related audits, and any remaining render-blocking or unused-JavaScript opportunities belong in the same read.
In Chrome DevTools Performance, long tasks after FCP should shrink or move later; the Main track names the script URLs.
Interaction to Next Paint in the field section of PageSpeed Insights or Search Console, after enough traffic, is the check lab TBT cannot replace.
Critical journeys (add to cart, open booking form, accept cookies) confirm defer / async did not break order-dependent behaviour.
A follow-up lab run on other templates that share the same tag container catches container-wide regressions.

A green TBT row on one homepage is not a portfolio proof. Theme updates and marketing tag changes reintroduce synchronous injects. Budgets on TBT or field INP make that regression visible without waiting for a client complaint.

FAQ

Is defer always better than async?

No. defer preserves order and waits for HTML parse, which suits theme and library chains. async suits independent scripts that should run at the first opportunity after download. The wrong choice for the dependency graph is worse than either attribute used correctly.

Will changing script attributes always improve Interaction to Next Paint?

Not always. Attributes help when parser-blocking or early evaluation was creating long tasks around interaction. If INP is driven by a heavy click handler or a late third-party widget, that work still needs reducing. Lab TBT and field INP together after the change show which lever moved.

Do async and defer work on inline scripts?

For classic scripts, both attributes require a src. Inline classic scripts ignore them. Module scripts can be inline with type="module" and still follow module loading rules.

Should Google Tag Manager use defer or async?

The current Google snippet for your install is the source of truth. Many container loaders use async. After install, child tags and consent scripts in the Performance panel matter, because the container is only the first file in the chain.

How is this different from critical CSS work?

Critical CSS decides which styles travel with the first HTML response. Script attributes decide when JavaScript runs relative to parsing. Most agency sites need both: stylesheets for first paint, scripts for responsiveness. The critical CSS guide covers the stylesheet half; this guide covers the script half.

Measure the main thread, then pick the attribute

Defer versus async is a timing decision, not a slogan. Classic blocking scripts stall the parser; async races independent tags; defer keeps ordered theme work after parse; modules defer by default. Total Blocking Time shows whether load still floods the main thread in the lab, and Interaction to Next Paint shows whether real users feel that cost.

If those lab and field checks need to run on a schedule across many domains, try Apogee Watcher or run a free domain check before and after the script-attribute change.

References

<script>: The HTML Script element (MDN)
Efficiently load third-party JavaScript (web.dev)
Optimize resource loading (web.dev)
Total Blocking Time (TBT) (web.dev)
Total Blocking Time (Chrome for Developers / Lighthouse)
Use defer and async on non-critical scripts (Shopify)
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
FCP and TBT: Supporting Metrics Beyond Core Web Vitals
Third-Party Scripts and Performance: The Worst Offenders
Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing

Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing

Apogee Watcher — Wed, 28 Oct 2026 07:54:18 +0000

Lighthouse keeps recommending “Eliminate render-blocking resources,” and the usual response is to inline more CSS or defer everything in sight. That can help First Contentful Paint. It can also ship a Flash of Unstyled Content, bloat the HTML response, or leave Largest Contentful Paint worse than before.

Critical CSS is a narrower job: ship only the styles needed for the first viewport as soon as HTML arrives, then load the remainder without blocking that first paint. The method is measurable. Chrome’s Coverage tab shows what was used on load; guessing from a theme “optimise” toggle is not the same work.

The sections below walk through extraction and deferral for agency sites. For what First Contentful Paint and Total Blocking Time mean in lab reports, keep FCP and TBT: Supporting Metrics Beyond Core Web Vitals open. For Largest Contentful Paint thresholds and fixes, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Resource hints that pair with deferred CSS are covered in Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals. The full browser critical rendering path (DOM, CSSOM, layout, paint) is a separate map; here the focus stays on CSS extraction and render-blocking stylesheets.

What critical CSS is (and what it is not)

Critical CSS is the subset of rules required to render content that is visible in the initial viewport (sometimes called above the fold). Google’s performance guides describe it as styles needed so the browser can paint meaningful content without waiting for every stylesheet on the network. That definition is deliberately smaller than “the CSS file the theme already ships.”

It is not “all CSS for the homepage,” and it is not a substitute for removing unused CSS from the full bundle. It is also not the same as understanding every stage of the critical rendering path. Critical CSS answers a shipping question: which rules must travel with the first HTML response so first paint is not stuck behind a large link rel="stylesheet"?

When the critical set is too large, you pay HTML bytes on every document request, often with a short cache lifetime. When it is too small, users see unstyled or partially styled content until the deferred sheet arrives. The useful size is usually the Coverage-green set for the templates you care about on mobile, plus a margin for the Largest Contentful Paint element’s layout.

How render-blocking CSS delays First Contentful Paint and Largest Contentful Paint

By default, CSS is render-blocking. The browser builds the CSS Object Model before it paints, so it avoids a Flash of Unstyled Content. That behaviour is intentional. The cost appears when a large shared stylesheet must finish downloading and parsing before any text or hero layout appears.

In Lighthouse and PageSpeed Insights, that cost shows up as the Eliminate render-blocking resources opportunity: stylesheet (and script) URLs that sit on the critical path to first paint. First Contentful Paint moves when those bytes clear earlier. Largest Contentful Paint can improve when the LCP element’s styles and related layout rules are available sooner, but LCP still depends on the LCP resource itself (image, text block, or video poster). Fixing render-blocking CSS does not replace image optimisation for a heavy hero.

Scripts marked without async or defer can block parsing as well. Stylesheets are the subject here. Script deferral and Interaction to Next Paint belong on a separate main-thread checklist; not every render-blocking URL in the audit is a CSS problem.

How to find critical CSS with Chrome DevTools Coverage

Extraction works best from evidence, not from a plugin default. Theme toggles that claim to eliminate render-blocking resources rarely show which rules still matter for first paint. A practical Coverage pass looks like this:

Open the page on a representative mobile viewport (or device mode that matches your lab strategy).
Open DevTools → Command Menu → Show Coverage, then reload so the report captures the initial load.
Inspect each stylesheet URL. Green marks rules used for that load; red marks unused rules in that file for that load.
Treat green rules that style above-the-fold content (header, hero, primary text, navigation chrome) as candidates for the critical set. Red rules for below-the-fold accordion bodies, footers, and dormant components usually belong in the deferred sheet.

Coverage is a laboratory sample. A cookie banner that appears after consent, or a mega-menu that opens on hover, may need styles that were red on a cold load. Those rules still belong in the critical set when they affect first paint or first interaction on real client templates. For portfolio work, Coverage on home and on the conversion URL, then a careful merge of the two sets, beats inlining two full themes.

Automated extractors (for example the Critical tooling family referenced in Chrome’s render-blocking docs) can speed the cut when the architecture allows it. The output still needs a Coverage check and a visual pass. Automated critical CSS that omits font-face or hero layout rules is a common FOUC source, and that failure usually shows up on mobile first.

How to inline critical CSS and defer the rest

A common pattern, documented on web.dev, looks like this:

Place the critical rules in a <style> block in the document <head> (minified).
Load the full stylesheet asynchronously so it does not block first paint, for example with rel="preload" as style and an onload handler that switches it to a stylesheet, plus a <noscript> fallback for browsers without script.
Keep the inlined block small enough that the HTML response stays lean.

<head>
  <style>/* minified critical rules only */</style>
  <link
    rel="preload"
    href="/css/site.css"
    as="style"
    onload="this.onload=null;this.rel='stylesheet'"
  />
  <noscript><link rel="stylesheet" href="/css/site.css" /></noscript>
</head>

Production sites often wrap the preload pattern in a small helper (loadCSS-style) so Content Security Policy and older browsers behave predictably. The principle stays the same either way: critical styles travel with HTML, and the bulk of the CSS arrives without blocking the first paint. The helper exists for edge cases; the measurement still comes from Coverage and a dated lab run.

Deferred CSS pairs well with honest resource hints when the full sheet is still important soon after paint. A preload for the stylesheet is part of that story; preloading every font and hero image at once usually blows the budget. The decision table in the resource-hints guide keeps those choices from competing with each other.

Media-query stylesheets as a lighter alternative

Not every render-blocking sheet needs full critical-CSS extraction. Styles that only apply to print, or only above a large breakpoint, can stay in separate files with a media attribute. The browser still downloads them according to its rules, but it does not block first paint on media that do not match.

<link rel="stylesheet" href="/css/site.css" />
<link rel="stylesheet" href="/css/print.css" media="print" />
<link rel="stylesheet" href="/css/wide.css" media="(min-width: 64em)" />

This approach helps when print or desktop-only rules inflate a shared bundle. It does not replace critical CSS when the default (always-matching) sheet is still huge. Media splits suit conditional CSS; extraction suits the case where the main all stylesheet is the blocker Lighthouse names.

Mistakes that make “critical CSS” slower

Inlining the entire theme. Critical CSS that is “most of app.css” increases HTML weight on every navigation and often cannot be cached as aggressively as a hashed stylesheet. First paint may still improve on a cold cache, but TTFB and transfer size can suffer on repeat views and multi-page sessions.

Guessing without Coverage. Theme or page-builder toggles that claim to eliminate render-blocking resources often defer styles the first paint still needs. The result is FOUC, layout thrash, or a late Cumulative Layout Shift when the full sheet arrives.

Forgetting the Largest Contentful Paint element. If the LCP node is a text block or image whose dimensions depend on deferred rules, a generic render-blocking audit can go green while LCP stays red. LCP styles belong in the critical set, and the LCP resource itself still needs its own optimisation. Agency reports that celebrate a cleared opportunity while LCP stays amber lose credibility fast.

Skipping noscript or CSP-safe loading. Async CSS patterns that rely only on inline onload handlers can fail under strict Content Security Policy. A fallback matters when the client’s security headers are strict. Test the pattern under the same CSP the production site already ships.

Treating one homepage pass as the portfolio. Agency sites share templates. Critical CSS extracted only from a brochure home can miss booking or checkout chrome. Coverage on the conversion URL before you declare the set done catches that gap.

How to verify the change in Lighthouse and monitoring

After critical CSS ships, a useful verification loop looks like this:

Record the laboratory tool, URL, strategy (mobile or desktop), and date for a before baseline.
Re-run Lighthouse or PageSpeed Insights on the same URL and strategy. Check Eliminate render-blocking resources, First Contentful Paint, and Largest Contentful Paint together.
Visually confirm first paint on a throttled mobile profile: no long unstyled flash, hero and header readable early.
Watch Cumulative Layout Shift if late styles change dimensions after paint.
Put a follow-up lab run on the calendar, and on other templates that share the CSS pipeline.

A single green opportunity row is not a portfolio proof. Scheduled lab tests catch the next theme update that reintroduces a blocking sheet. Budgets on FCP or LCP make that regression visible without waiting for a client complaint.

FAQ

Is critical CSS the same as eliminating unused CSS?

No. Unused CSS removal shrinks the full stylesheet. Critical CSS chooses which rules travel with the first HTML response. Teams usually need both over a quarter: unused CSS for transfer size, critical CSS for first paint timing.

Will critical CSS always improve Largest Contentful Paint?

Not always. It helps when LCP is waiting on stylesheet work. If LCP is a large image or a slow server, those paths still need work. Reading FCP and LCP together after the change shows which lever moved.

Can we defer all CSS to the bottom of the body?

Moving the link lower can change priority, but the browser may still treat the stylesheet as high priority and you risk FOUC. An explicit critical set plus async load of the remainder, with a noscript fallback, is the more reliable pattern. Position alone rarely matches what Coverage would have selected for above-the-fold paint.

Do WordPress or Shopify “defer CSS” plugins replace Coverage?

They can automate a pattern, but they still need verification. Coverage plus a dated lab test on home and the conversion URL after enabling a plugin, with a rollback ready if FOUC appears, is the safer agency habit. Plugin defaults rarely know your booking or checkout chrome.

How does this relate to the critical rendering path?

Render-blocking CSS is one stage of the path from HTML to pixels. Extraction and deferral are the shipping half of that story. A deeper pass on DOM, CSSOM, layout, and paint belongs in a critical rendering path guide; web.dev’s Critical Rendering Path is the map when you need those stages named in order.

Measure first, then inline

Critical CSS works when the critical set is measured, small, and verified. Coverage decides what is above the fold; the inline block carries that set; an async pattern loads the rest. First Contentful Paint and Largest Contentful Paint on the same client URLs show whether the change stuck, and a follow-up lab run after the next theme update shows whether it stayed stuck.

If those lab checks need to run on a schedule across many domains, try Apogee Watcher or run a free domain check before and after the CSS change.

References

Eliminate render-blocking resources (Chrome for Developers)
Extract critical CSS (web.dev)
Defer non-critical CSS (web.dev)
Render-blocking CSS (web.dev)
Critical Rendering Path (web.dev)
Optimize resource loading (web.dev)
FCP and TBT: Supporting Metrics Beyond Core Web Vitals
LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It
Preload, Prefetch, and Preconnect: Resource Hints for Faster Core Web Vitals

Is PageSpeed Insights Reliable?

Apogee Watcher — Tue, 27 Oct 2026 07:49:23 +0000

Short answer: PageSpeed Insights is reliable for the job it was built for. It is unreliable as a once-a-week screenshot that proves “the site is fine.”

Most people who ask whether PageSpeed Insights is reliable have just watched the same URL swing ten or twenty points between two runs. Or they shipped a fix, pasted a green lab score into Slack, then watched Search Console stay amber. That feels like a broken tool. Usually it is a mismatch between what the report shows and what the team needed from it.

What follows is the agency view: what the report actually measures, when to trust it, when the process is the problem, and what to add when a single paste is not enough. For the longer monitoring-versus-manual comparison on our main blog, keep PageSpeed Insights vs Automated Monitoring open. For the definition of automated coverage itself, see What Is Automated Web Performance Monitoring?.

What PageSpeed Insights actually measures

A PageSpeed Insights report is two clocks on one page.

Lab data comes from Lighthouse: one controlled run, throttled network, a fixed device profile. It is good at catching template and third-party changes you just shipped. It is a single sample, not a week of traffic.

Field data comes from the Chrome UX Report when Google has enough samples for that URL or origin. Those percentiles describe real Chrome visits over a rolling window. They move slowly. They do not answer “what did last night’s release do?”

Google’s own lab versus field guidance treats those as different questions. Reliability starts when you stop asking one number to answer both.

When PageSpeed Insights is reliable

Treat PageSpeed Insights as reliable when you use it for:

A diagnostic pass on a specific URL after a release or theme change
Comparing mobile and desktop lab results on the same template
Reading CrUX field categories when samples exist, separate from the Lighthouse performance score
Pulling opportunity lists (LCP element, unused JavaScript, layout shifts) that engineers can reproduce

In those cases the tool is doing honest work. The lab score can still bounce a few points between identical runs. That variance is normal for Lighthouse. A median of three runs beats a single screenshot if you are about to argue with a client about a pass/fail line.

When PageSpeed Insights feels unreliable (and why)

One run treated as a baseline

You open PageSpeed Insights on Tuesday, paste the link, and close the tab. On Thursday the account manager forwards a client complaint. You run it again. The score moved. You have nothing stored between the two runs: no release note, no URL list, no record of which strategy you used. The tool did not lie. The process did. We wrote that failure mode up as PSI on Tuesday, panic on Thursday.

Lab green, field amber

Lighthouse can look healthy while CrUX still needs improvement. Mid-range phones, consent banners, campaign tags, and traffic mix show up in field data long before a single lab profile catches them. Trust CrUX (or Search Console URL groups) for “are real users fine?” Trust lab for “what should we change next?” Arguing which dashboard is “right” wastes a sprint.

Origin field data mistaken for URL truth

Low-traffic money pages often lack URL-level CrUX. PageSpeed Insights may show origin-level field data instead. That can flatter a weak checkout URL or hide a strong blog post behind a slow homepage. Label those rows. Do not sell a Core Web Vitals win from origin fallback alone.

Chasing 100 instead of the vitals

The Lighthouse performance score is a blended lab artefact. Google’s ranking story for page experience sits closer to Core Web Vitals field thresholds than to a perfect 100. A team that spends a week for five score points while Largest Contentful Paint stays over 4 seconds on mobile is using PageSpeed Insights as a game, not a diagnostic.

How agencies keep PageSpeed Insights honest

A reliable workflow looks boring on purpose.

Same URL set every time: homepage, primary landing templates, checkout or lead paths, mobile and desktop as separate rows.
Store every run. A green score with no history is not a monitoring system.
Read lab and field in the same report, then decide which clock owns the ticket.
Alert on regressions against a budget, not on vibes from a random re-run.
Tell clients which signal you used. “Lab LCP after release” and “CrUX p75 over 28 days” are different sentences.

That is the difference between “PageSpeed Insights is unreliable” and “we used a free checker as if it were a portfolio monitor.”

What to use when one-off PageSpeed Insights is not enough

If you manage more than a handful of client sites, the reliability problem is rarely the Google API. It is cadence, history, and who gets notified when a template regresses.

Automated monitoring is the layer that turns PageSpeed Insights into a schedule: repeated tests, stored results, budgets, and alerts. That definition is unpacked in What Is Automated Web Performance Monitoring?. The comparison of when manual checks stop scaling is in PageSpeed Insights vs Automated Monitoring.

You still open PageSpeed Insights when you need a deep single-URL dig. You stop using a lonely green score as proof the whole roster is fine.

FAQ

Is PageSpeed Insights reliable for SEO?

It is reliable as a diagnostic and as a window onto CrUX when samples exist. It is not a substitute for Search Console page-experience reporting or for a stored history of the same URLs. Treat lab and field as separate sentences in client decks.

Why does my PageSpeed Insights score change every time?

Lighthouse variance between identical runs is normal. Network noise, CPU contention, and third-party scripts move the lab sample. Median of three runs, same strategy, same URL, beats arguing over a one-point swing.

Is lab data or field data more accurate?

They answer different questions. Lab is a controlled sample after a change. Field is a rolling distribution of real Chrome visits. Neither is a lie when you label which clock you used.

Should agencies stop using PageSpeed Insights?

No. Stop using it as the only portfolio monitor. Keep it for deep digs and opportunity lists; add scheduled runs, history, and alerts for the roster.

So is PageSpeed Insights reliable?

Yes, when you treat lab as a diagnostic sample and field as a real-user distribution.

No, when you treat one Lighthouse performance score as a week-long service level for every client site.

The tool is fine. The question that matters is whether your process gives those two clocks a job each, and whether someone is looking when either one moves.

If you want that loop on a multi-tenant portfolio without rebuilding the schedule yourself, try Apogee Watcher or run a free domain check.

References

Lab data vs field data (web.dev)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)
What Is Automated Web Performance Monitoring? (Apogee Watcher)
PSI on Tuesday, panic on Thursday (Apogee Watcher on Hashnode)
PageSpeed Insights (Google)

Site-Level Guidance: AI Actionable Insights Leave Beta

Apogee Watcher — Tue, 27 Oct 2026 07:49:10 +0000

Agencies already know how to read a single PageSpeed Insights run. The harder job is turning twenty URLs on one host into a fix order a developer can ship without reopening every Lighthouse tab. Domain report Summary gave us a deterministic triage layer earlier this year: attention-free score, top pages, and merged opportunities. What was still missing was an optional synthesis step that names shared problems and ranks what to change first across the property.

That step is out of beta. AI actionable insights now generate from a domain-report snapshot in Apogee Watcher: one site-level evaluation grounded in stored PageSpeed / Lighthouse evidence, not a one-off chat about a single homepage run. We also refreshed the site view so tests, pages, discovery, and reports stay in one workspace when you prepare that snapshot.

What site-level AI insights do with PageSpeed evidence

AI insights answer a different question from a single-URL Lighthouse chat. Tools that paste one PageSpeed Insights JSON into a language model explain that URL. Watcher starts from a domain report: up to about twenty pages already tested on mobile and desktop, with scores and opportunities already grouped. The model sees a bounded summary of site problems built from that snapshot. It returns a short narrative, a prioritised how-to-fix list, and evidence that points at shared templates, third parties, or headers when those patterns repeat.

Lighthouse remains the source of truth for scores and audits. The insight does not re-score the site or invent metrics that were not in the stored runs. It synthesises what the deterministic report already shows, so an account lead can hand a developer an ordered checklist instead of a screenshot dump. That site-level default is deliberate: calling a model on every completed page test would use quota quickly and mostly rewrite audit text you already have.

Approach	Input	Typical output	Fit
Single-URL AI + Lighthouse	One page, one strategy	Explain this run	Spot check or homepage deep dive
Watcher AI insights	Domain-report snapshot (multi-page)	Prioritised site fix plan	Agency portfolio triage after scheduled tests

If you only need “what is red on this URL right now,” PageSpeed Insights or the Mobile / Desktop tabs on the domain report are enough. AI insights fit when the brief is “what should we change across this property first?” The distinction matters in client emails: one explains a spot check, the other briefs a template or third-party change that shows up across many URLs. Agencies usually need both over a quarter; they just should not confuse them on the same call.

How AI insights sit next to the domain report Summary

Attention-Free Score: How Domain Reports Show Which Pages Need Work remains the always-on layer. Summary is free with the report: attention-free percentage, dimensions needing attention, top pages, and merged opportunities. No language-model credit is spent to open it.

AI insights are the optional layer on the same snapshot. Generate when you want natural-language prioritisation and a fix checklist grounded in recurring audits. Skip generate when Summary already answers the client call. Public share links show the insight body only after someone with access has generated a completed insight; visitors never see an empty AI box or a Generate button on the public URL.

That split keeps lab triage honest. Deterministic Summary is the scoreboard. AI is the briefing note you write when the portfolio needs a narrative, not a replacement for budgets, alerts, or scheduled monitoring. For the broader monitoring loop, see What Is Automated Web Performance Monitoring? and PageSpeed Insights vs Automated Monitoring.

Where to generate AI insights in Watcher

Generation starts from evidence that already exists. After scheduled or manual tests finish, a Manager or Admin creates a domain report from the site Reports tab. In the app, the report’s AI insights tab shows either an empty state with Generate AI insights, or the stored insight with Regenerate and Copy markdown. The same generate action is available from the site Reports list.

Live example: apogeewatcher.com domain report AI insights — site-level summary, priority fixes, and quick wins on the public share URL.

On the public domain report URL, recipients see the insight only when a completed one exists. That keeps prospect and client links tidy: you decide when synthesis is ready to share, then send the same token you already use for Summary. Until you generate, the public page stays a clean lab readout without an empty AI placeholder.

AI insights quota and which plans include them

Default paid tiers from Personal upward include AI insights. Free does not. Pricing and My Account show whether the feature is on before you promise synthesis in a retainer scope. Monthly AI credit limits sit beside test volume on purpose: synthesis is meant for site evaluations, not one model call per scheduled page run.

When the meter is empty, Generate and Regenerate stay blocked until the period resets or the plan changes. Site-level evaluation is the default we ship; per-run AI deep dives remain a future path if customers ask for them. Portfolio roll-ups across many client sites are also later work. For weekly organisation PDFs and white-label branding already live, see Weekly Organisation Reports and White-Label Branding Options Are Live.

Updated site view: tests, pages, discovery, and reports together

Alongside AI insights leaving beta, we refreshed the site view in the app so day-to-day monitoring work does not scatter across unrelated screens. From Setup → Sites, a property opens as one record: pages and discovery for the URL pool, test history for what already ran, statistics for recent lab movement, and Reports for domain-report generation and AI actions. Fewer switches between “find URLs,” “see what ran,” and “share what it means” means fewer stale snapshots.

Insights are only as good as the evidence behind them. Discovery and page lists decide which URLs enter the report pool. Scheduled tests fill that pool. Reports turn the results into a shareable Summary and, when you choose, an AI briefing. Keeping those steps on one site record lowers the chance that someone generates synthesis from an incomplete page set.

Client-ready reporting habits still apply: budgets and schedules first, then shared links. Client-Ready Core Web Vitals Report Outline remains useful when Summary plus an insight becomes a retainer narrative. The insight works as the ordered checklist inside that outline, not as a substitute for the scoreboard.

What AI insights do not claim

We are explicit about scope so contracts stay clean:

Insights do not replace Lighthouse scores, audit lists, or Attention-Free gates.
Insights do not guarantee rankings, Core Web Vitals field improvements, or pass/fail after a deploy. You still re-test and compare stored runs.
Insights are not generated on every completed PageSpeed run by default.
Public visitors cannot spend your AI credits.
Free plans cannot generate insights.

The useful promise is narrower: faster time from multi-page red metrics to a concrete, evidence-backed checklist your team can implement and then verify with scheduled lab tests.

FAQ

Do I need AI insights to use domain reports?

No. Summary, Mobile, Desktop, and Tested pages work without generating an insight. AI is optional synthesis on Personal and higher plans that include the feature.

Can clients generate insights from a public share link?

No. The public URL shows a completed insight when one exists. Generate and Regenerate stay in the signed-in app for roles that can manage reports, so visitors cannot spend your monthly AI credits.

Is this the same as pasting PageSpeed Insights into ChatGPT?

No. Watcher builds a bounded site summary from a multi-page domain-report snapshot already stored for your organisation. Single-URL chat tools explain one run; they do not see your scheduled portfolio context or recurring audits across templates.

Will AI insights appear on weekly organisation PDFs?

Not in this release. Organisation weekly reports and white-label PDFs remain the portfolio pack described in the September ship note. Domain-report AI is site-level synthesis on the HTML report path first.

What should I do after I apply a recommended fix?

Re-run tests on the affected pages, regenerate the domain report when you want a fresh snapshot, and compare Attention-Free and opportunity lists. Treat the insight as guidance before the fix, not as a certificate after deploy. Pass or fail still comes from the next stored lab runs, the same way budgets and alerts already work.

If you want site-level guidance on top of the monitoring loop you already run, open a site with completed tests, generate a domain report, then use Generate AI insights when the plan includes the feature. A trial starts at sign-up; a free domain check shows Summary without AI first. Changelog #14 at the end of October will cover the wider product window.

References

Domain performance reports (Apogee Watcher docs)
Understand plan limits (Apogee Watcher docs)
Plan features by tier (Apogee Watcher docs)
Attention-Free Score: How Domain Reports Show Which Pages Need Work
What Is Automated Web Performance Monitoring?
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough
Weekly Organisation Reports and White-Label Branding Options Are Live
Client-Ready Core Web Vitals Report Outline
PageSpeed Insights API (Google for Developers)
Lighthouse in Chrome DevTools (Chrome for Developers)

Watcher Affiliate Programme: 30% Commission for Agencies and Publishers

Apogee Watcher — Mon, 26 Oct 2026 08:34:57 +0000

If you already tell clients or readers to stop relying on a once-a-week PageSpeed Insights paste, you have probably also heard the follow-up: “Fine — what should we actually run?” That conversation is useful for them, and until now it did not give you a tracked commercial path when they chose Apogee Watcher.

The Watcher affiliate programme closes that gap. Partners get one unique coupon tied to a Watcher account. Someone signs up with that code, runs a time-limited trial on a paid plan, and when they convert to a paying subscription, commission accrues in EUR. Redemptions and balances sit under Account → Affiliate. Public terms live on Affiliate programme.

We built the referral path on the coupon system we already use for trials, so partners and customers share the same product surface instead of a separate affiliate portal. What follows is a short product announcement, not a tour of every affiliate network. The rules match what is live on that page today. Confirm the page before you quote numbers to a client or publisher, because commercial terms can change.

How the Apogee Watcher affiliate programme works

One coupon per partner. The code is tied to a Watcher user account. Append ?coupon_code=YOUR-CODE (or ?coupon=YOUR-CODE) to any public Watcher page — sign-up, a blog post, features, pricing, or home. Redeemers get a time-limited trial on a paid plan when they complete sign-up; a short-lived cookie keeps the deal if they browse first.
Commission on conversion. Free plans and pure trials do not generate commission. When the referred account becomes a paying subscription, accrual starts.
Track in the app. Partners with an assigned coupon see redemptions, conversions, pending, and lifetime referral under Account → Affiliate.
PayPal payout. We pay manually to the email on the partner’s Apogee Watcher account when available commission clears the hold and reaches the minimum.

Attribution stays on the coupon for the life of that partner relationship. You do not need a separate “affiliate dashboard” product: redemptions and status sit next to the same account you would use if you also run Watcher for clients.

Commission terms

Rule	Value
Rate	30% of attributed plan revenue
Currency	EUR
Window	First 12 months after trial → paid conversion
Hold	30 days per accrual before payable (refund window)
Minimum payout	€50 available (cleared hold, not yet paid)
Ownership	One coupon per partner account

Cancelled or refunded subscriptions may void unpaid accruals that are still in hold or available. The live programme page remains the source of truth if anything here falls behind.

In practice that means: someone redeems your coupon, finishes the trial, and pays for a plan. You earn 30% of that plan’s EUR revenue for the first twelve months after conversion. Each accrual sits for thirty days before it becomes payable, which gives a simple refund window. When cleared commission reaches €50, we send a PayPal payout to the email on your Watcher account.

Who it is for

Agencies that already recommend monitoring to clients, consultants who publish PageSpeed or Core Web Vitals guides, newsletter writers, comparison sites, and educators. The fit is strongest when you already have an audience that needs scheduled multi-site checks, not a one-off PageSpeed Insights paste.

Typical partners include:

Agencies that mention Watcher (or a similar stack) in proposals and want a coupon for prospects who self-serve
Independent consultants who write about Lighthouse, CrUX, or PageSpeed Insights and want a tracked trial link
Newsletter and podcast hosts who cover web performance tooling
Comparison and “alternatives” publishers who list multi-tenant PageSpeed monitoring honestly

If you are still deciding whether automated monitoring belongs in the retainer at all, start with Why Agencies Need Automated Performance Monitoring in 2026 and What Is Automated Web Performance Monitoring?. Plans and limits are on pricing.

What you can share

Keep the story simple. Watcher is multi-tenant PageSpeed Insights and CrUX-in-PSI monitoring for agencies and portfolio owners: scheduled runs, history, alerts, and organisation-level reporting. Your coupon shortens the path from “interesting tool” to a dated trial on a real plan.

You do not have to send everyone straight to /sign-up. Append your code to any public Apogee Watcher URL so readers can land on the page that matches the conversation: a blog post, the features page, pricing, home, or the affiliate programme page itself. Examples:

https://apogeewatcher.com/sign-up?coupon_code=YOUR-CODE
https://apogeewatcher.com/blog/some-article?coupon_code=YOUR-CODE
https://apogeewatcher.com/features?coupon_code=YOUR-CODE

Visitors see an offer strip on public pages, and a 24-hour cookie keeps the coupon when they continue to sign-up. Place those Watcher links wherever your audience already reads you (your blog, a newsletter, a proposal). Do not invent commission rates or payout rules that are not on the live programme page. If a reader asks “what do I get?”, point them at pricing and the trial that your coupon unlocks.

How to join

Contact us with your site or audience, and we will create your coupon and share tracking details. Existing customers who become partners use the same login; the Affiliate panel appears once a coupon is assigned to your user.

You do not need a large media kit. A short note with who you write for, a sample post or client list, and where you plan to place the link is enough for us to assign a code. After that, the operational loop is: share the coupon URL, check Account → Affiliate when people redeem, and wait for available balance to clear the hold and the €50 threshold before payout.

Affiliate programme · Contact · Sign up

FAQ

Do free sign-ups pay commission?

No. Commission starts when a referred account converts to a paid subscription after the trial path tied to your coupon. Someone who never leaves free, or who never completes the coupon trial into paid, does not create an accrual.

Can I have more than one coupon?

No. The programme is one coupon per partner account so attribution stays clear. If you need a renamed code for branding, contact us; we still keep a single owner account behind it.

Must every referral go through /sign-up only?

No. Put ?coupon_code=YOUR-CODE on any public Watcher page — including our blog posts, features, pricing, or home. The cookie carries the offer to sign-up. You can still embed those Watcher links on your own site or in email; attribution follows the coupon, not a single landing path.

Where do I see redemptions?

Once a coupon is assigned to your user, open Account → Affiliate for redemptions, conversions, pending, and lifetime totals. Pending covers accruals still inside the 30-day hold. Available is what can go into the next PayPal payout once you clear €50.

How are payouts sent?

Manually via PayPal to the email on your Apogee Watcher account, after the 30-day hold and once available commission reaches €50. Keep that email current so we do not hold a payout for a bounced PayPal address.

Does the twelve-month window restart if the customer upgrades?

Commission tracks attributed plan revenue during the first twelve months after the trial-to-paid conversion. Check the live affiliate programme page for how upgrades and plan changes are treated before you promise a figure to a reader.

What happens if the customer cancels or gets a refund?

Unpaid accruals that are still in hold or available may be voided when a subscription is cancelled or refunded. That is why the hold exists. Paid history is not something this short post rewrites; the programme page and your Affiliate panel are the operational record.

References

Affiliate programme (Apogee Watcher)
Pricing (Apogee Watcher)
Why Agencies Need Automated Performance Monitoring in 2026 (Apogee Watcher)
What Is Automated Web Performance Monitoring? (Apogee Watcher)
Contact (Apogee Watcher)

DEV Community: Apogee Watcher

Why did PageSpeed Insights jump overnight? (Lighthouse 13.6, site unchanged)

What Lighthouse 13.6 changed in the lab simulation

How to tell a simulation jump from a real site change

Lab scores and field CrUX after the update

What to put in the client note

FAQ

CTA

References

Why does CrUX say no data for my client site?

What “no data” means in PageSpeed Insights and the CrUX API

Debug the origin string before you blame traffic

When the URL is empty but the origin still has field data

Eligibility gates engineers actually check

What to monitor until field rows appear

FAQ

CTA

References

Core Web Vitals Benchmarks for WordPress Sites (2026 Data)

What counts as a reliable WordPress Core Web Vitals benchmark in 2026

Public CrUX context for WordPress in 2026

Multi-page lab sample from Watcher WordPress clients

Mobile and desktop Lighthouse Performance

Mobile lab Core Web Vitals timings (store averages)

Recurring mobile Lighthouse opportunities

How to use these WordPress benchmarks on a retainer

FAQ

CTA

References

Internal only - do not publish

Changelog #14: AI Insights, Affiliate Programme, CSV/PDF Exports

AI actionable insights leave beta

Updated site view

Affiliate programme

Free domain check: email optional, live thanks, save later

Plan usage in the topbar and quota warning emails

PDF reports on Starter; white-label stays Professional+

CSV export for site test results

What to try

References

Launch checklist vs retainer checklist for AI-built websites

What a launch checklist is for (and what it is not)

What a retainer performance checklist covers

Side-by-side: launch afternoon vs weekly monitoring

How AI-built sites break the gap between the two

How to hand off from launch QA to a monitoring loop

FAQ

Keep both lists, stop merging them

References

We Sold PageSpeed Retainers for Years. Here Is Why We Productised Monitoring Instead of Another Audit PDF

What a PageSpeed retainer looked like before the product

Why another branded audit PDF was the wrong product bet

What we productised instead

Service hours, product seats, and premium RUM compared

Layer, do not replace: the stack honesty that kept the product shippable

What stays in the agency after the product ships

FAQ

Measure the calendar, then sell the fix

References

AI-built sites: the Core Web Vitals regressions that show up after the padlock

Why Core Web Vitals regress after go-live on AI-built sites

Hero and image swaps that break Largest Contentful Paint

Booking, chat, and WhatsApp widgets that hurt Interaction to Next Paint

Cookie banners and late embeds that raise Cumulative Layout Shift

Full redesign prompts that erase last week’s laboratory baseline

How to catch the next regression before the client forwards a complaint

FAQ

Keep the padlock. Watch the next edit.

References

Defer, Async, and Module Scripts: A Field Guide for INP and TBT

What parser-blocking scripts do to Total Blocking Time and INP

Defer vs async scripts: when each attribute fits

How type="module" changes script loading

How to choose attributes for theme, analytics, and tag-manager scripts

Mistakes that keep Total Blocking Time and INP high

How to verify script-loading changes in Lighthouse and monitoring

FAQ

Measure the main thread, then pick the attribute

References

Critical CSS and Render-Blocking Resources: Faster First Paint Without Guessing

How `type="module"` changes script loading