Docs / Page check
What runs when you ask the connector to check a page
Measures Core Web Vitals through PageSpeed Insights and reads a mobile screenshot against the conversion heuristics. Asynchronous: acknowledge, then poll.
Signature
cr_check_page_speedCore Web Vitals through Google PageSpeed Insights, joined to the property's own numbers for that page.cr_heuristic_checkSpeed plus a read of a mobile screenshot against the conversion heuristics. Asynchronous: it returns a request id.cr_get_heuristic_checkFetches the result of a heuristic check by request id. Returns pending until the background run finishes.
What you ask
Prompts land with the captured session, so that what is printed here is what actually worked rather than what should have.
What runs
What comes back
No session to show
The transcript and the screenshot for this instrument have not been captured yet. Everything else on this page is the real tool surface.
When to reach for this
Use this when you suspect the page itself
It measures Core Web Vitals through Google PageSpeed Insights and, separately, reads a mobile screenshot against the conversion heuristics. One call gives you the measured half and the observed half, which is usually what a page argument is missing.
Use it on a page you cannot connect analytics to
It works on any public URL, including a competitor's. Nothing about it requires the page to be yours or GA4 to be connected.
Not this one to find which page to check
It examines the URL you give it. Deciding which page deserves the attention is a job for funnel leak diagnosis or the landing-page rows of a full audit.
How to read it
Two halves of the answer, two different epistemics
Core Web Vitals are measurements: LCP, CLS and INP either exceeded a threshold or did not. The UX findings are readings of a screenshot, which are evidence-based hypotheses about conversion. Keep them apart. The first half is a fact you can act on directly; the second is a lead to verify.
Lab and field numbers disagree, and both are true
Lighthouse renders the page once on a defined machine. Field data is what real visitors experienced. A page that scores badly in the lab and fine in the field usually has an audience on better devices than the test profile, and the reverse is more alarming than a bad lab score.
Slow is only a problem where it costs something
A slow page nobody enters is not the priority. This is why the check joins the speed result to the property's own numbers where GA4 is connected: the useful sentence is not "LCP is 4.1s" but "LCP is 4.1s on the page that takes 8,000 sessions a month".
It is asynchronous, and the poll is part of the design
The tool returns a request id immediately and the client polls until the run finishes, because rendering a page in a real browser takes longer than a chat client will wait. A pause of a minute or more is the tool working, not hanging.
Limits
- It reads one URL per run. A whole-site crawl is not what this is.
- Runs are asynchronous and can take minutes. A capture or a check can also time out, and when the mobile pass fails the honest answer is that mobile was not verified rather than a guess from the desktop frame.
- Field data comes from Google's dataset and is unavailable for low-traffic pages. Only lab numbers will appear for those.
- It reads the page as an anonymous visitor sees it. Anything behind a login, a geo gate or a consent wall is invisible.
- The UX half describes and interprets what is visible. It does not prove the finding cost you a sale.
Related instruments
Go deeper
Try it on your own data
Every instrument runs on your own GA4, read-only, inside Claude or ChatGPT. One connector covers all of them.
Add the connector →Session captured 2026-08-03 against the ConvRadar demo property. Masked in the image: cropped to the conversation column, so the account sidebar and workspace name are out of frame, no connector URL is in frame, so no token can leak, no account email or avatar is in frame.