PageSpeed monitoring does not require CrUX data. You can measure a page with scheduled synthetic tests, save a baseline and investigate regressions even when Google has too few eligible visitor samples to report real-user performance. Choose a tool that produces useful lab results independently of its CrUX panel, and check whether it preserves history, exposes test conditions and supports the alerts your team needs.
What you cannot do is turn a good lab result into a verified real-user Core Web Vitals pass. Missing field data remains missing evidence.
For a new website, start with representative public pages and a repeatable test profile. Add your own real-user monitoring when you need evidence about interactions, devices or later page behavior. The tools below support different parts of that workflow. Their documented capabilities are compared alongside a worked example showing how to report a lab regression without overstating what it proves.
Why CrUX data is missing
First establish whether the missing report concerns the exact page or its whole origin. Those are different scopes. A product page can lack its own field measurements while the website has an origin-level report. An origin summary is useful context, but it is not a measurement of that product page alone.
Google's PageSpeed Insights documentation explains that PSI can fall back from page-level to origin-level data when the page lacks sufficient samples. If the origin also lacks sufficient data, the field panel cannot provide real-user results. The Lighthouse lab analysis is a separate measurement.
CrUX inclusion depends on eligible experiences, public discoverability and sufficient popularity. The CrUX methodology does not disclose an exact visitor threshold, and pages cannot be manually submitted for inclusion. Ordinary analytics visits are not interchangeable with eligible CrUX samples.
A recently launched site, a lightly visited landing page or a site whose audience produces few eligible samples may therefore have useful lab results and no CrUX report. Treat these as possible explanations, not a diagnosis made from an empty panel alone. Check the intended URL, the origin shown and whether the public page is served successfully without an unintended noindex directive.
Write the scope into your report: “No page-level CrUX data available; origin data available” or “No CrUX field data available for either scope.” Do not replace either statement with “Core Web Vitals passed,” “failed” or “Google cannot index the site.” None follows simply from missing samples.
Once that distinction is clear, choose monitoring for the evidence you can collect now. A dashboard that only republishes CrUX will remain empty for the same unavailable dataset. A tool that runs independent browser tests can still measure the page.
PageSpeed monitoring tools that do not need CrUX
Choose by the evidence you need to retain, rather than the number of metrics on a dashboard. Recurring checks, a historical comparison and an alert are separate capabilities. A tool may offer the first without the other two.
Screpy publishes this comparison and is included below. These are documented workflows checked on October 11, 2026, not results from a hands-on accuracy or speed benchmark. Confirm the relevant plan, test allowance, retention and notification options before committing to a monitoring setup.
| Tool | Useful workflow without CrUX | Best-fit need | Limit to check |
|---|---|---|---|
| Screpy PageSpeed Monitoring | Recurring lab checks of selected public URLs with available loading, blocking and layout metrics | Keep page measurements alongside existing SEO work | Current-result view has no multi-point history, performance alerts or immediate retest control; preserve your own baseline |
| DebugBear | Controlled synthetic tests with diagnostic reports; own RUM is separate | Investigate loading regressions and combine lab evidence with visitor measurements | Select test settings and ensure the data source is identified |
| Calibre | Test profiles, performance budgets, snapshot details and deployment context | Compare releases under saved profiles | Configure profiles and budgets for the pages you actually monitor |
| GTmetrix | Scheduled browser tests, historical graphs and configurable alerts | Maintain recurring page reports and investigate a changed run | Frequency, history and other options depend on the selected plan |
| SpeedCurve | Synthetic comparisons, detailed diagnostics, budgets and deployment integration; RUM is separate | A team workflow connecting releases and performance evidence | Lab and RUM results describe different populations and conditions |
| Sitespeed.io | Self-operated browser tests, scripted journeys, budgets, storage and alert integrations | Control and automate the testing environment | Your team must run, schedule and maintain the workflow |
In Screpy, eligible active URLs can become due for another check after one day; this is not a promise of a result at an exact clock time. Adding a URL does not trigger an instant measurement. The selected-URL table and homepage overview also have different scopes. Neither should be described as a visitor distribution or an automatic historical archive.
For a managed service, inspect the actual diagnostic report during a trial. Can your developer trace an unexpected value to a request waterfall, a render timeline or a browser trace? A summary score is easier to read, but may not supply the evidence needed to investigate.
For a self-operated workflow, include the work of maintaining test agents, report storage and notifications in the decision. Open-source software does not remove those responsibilities. Likewise, a managed dashboard does not remove the need to choose representative pages and check whether the runner reached the intended content.
If notifications are essential, validate their behavior instead of assuming every monitoring product sends them. For example, DebugBear documents separate lab alert conditions and performance budgets. Ask what triggers an alert, who receives it and whether repeated failures are suppressed. A recurring test with no reviewed output can quietly become an unused collection of numbers.
Build a comparable monitoring baseline
Start with pages that represent distinct business decisions: an organic entry page, an important product or service page, a campaign landing page and a template affected by frequent changes. You do not need to test every URL before establishing a useful baseline. Several copies of the same template may tell you less than a smaller set covering different loading behavior.
Create a measurement record before making a performance change:
| Record | Why it matters |
|---|---|
| Exact requested and final URL | Redirects or changed parameters can lead to different content |
| Test time and report identifier | Gives the comparison a reproducible reference |
| Device, viewport, network and location | Defines which controlled experience was measured |
| Browser/tool version and test configuration | A changed engine or profile can affect results |
| Cache, consent and authentication state | Changes which assets and content are loaded |
| Page version or release marker | Associates the run with a candidate change |
| Individual metrics and units | Prevents mixing seconds, milliseconds, scores and unitless CLS |
| Response and content validity | Excludes login pages, bot challenges and broken responses from successful page comparisons |
Use the same exposed settings for before and after tests. If your tool does not show or let you control a setting, record that limitation. Do not claim a precisely matched profile when all you have is a mobile label. A screenshot or saved report helps preserve what was actually available.
Keep mobile and desktop baselines separate. Keep cold-cache and repeat-visit scenarios separate where your tooling supports them. Do not compare a production page with ads against a staging page that blocks those scripts and call the difference an optimization result.
Monitor individual metrics as well as any score. LCP describes the main content milestone; CLS describes unexpected movement; TBT helps investigate blocking during the tested load. TTFB and FCP provide other useful delivery and rendering signals. They answer different questions.
Google's explanation of lab and field measurement differences describes why an ordinary lab navigation may miss real interactions and later layout changes. In particular, TBT is not INP. A low blocking value during startup cannot establish that a search box, filter or checkout control responds quickly later.
Finally, verify that the report shows your actual page. A fast 200 response containing a security challenge is not a fast product page. Resolve that measurement problem before comparing its numbers with a valid baseline.
Interpret a regression without a field-data claim
Consider a hypothetical product page with no CrUX report. Your team has saved a mobile lab baseline and wants to evaluate a release that adds a review widget. The following values are illustrative, not measurements of Screpy, a customer website or any listed tool.
| Run | Before-release LCP | After-release LCP |
|---|---|---|
| 1 | 1.9 seconds | 2.7 seconds |
| 2 | 2.0 seconds | 2.8 seconds |
| 3 | 2.1 seconds | 3.0 seconds |
| Median of these runs | 2.0 seconds | 2.8 seconds |
For this example, the median lab LCP increased by 0.8 seconds. The relative increase is (2.8 - 2.0) / 2.0 × 100 = 40%. Both statements describe these controlled runs. Neither is the 75th percentile of real visitor experiences.
The useful conclusion is that the tested page became slower under the recorded profile, and the changed release deserves investigation. Three runs make the arithmetic understandable; they do not establish statistical significance, explain the entire population or prove that the widget caused the difference.
Compare the available waterfall, render timeline or trace. Did a new request compete with the main image? Did an additional script delay rendering? Were the page content, cache state or third-party responses different? Write these as hypotheses until the relevant evidence identifies a cause.
An actionable issue could read: “Mobile lab LCP rose from a three-run median of 2.0 to 2.8 seconds after release R2, using the same saved profile. Review the new widget's loading behavior and repeat matched tests after a focused change. No CrUX field assessment is available.” Attach the individual reports, configuration and release references.
Choose budgets after observing the normal variability of your own setup. An absolute limit protects an experience target; a relative-change condition detects deterioration from a baseline. Neither should become an unexplained rule applied to every template, device and vendor. A single failed run may justify checking the page, but should not be silently presented as a persistent regression.
After a correction, compare the same scenario again and preserve the evidence. If the page improves in the lab, report that improvement in the lab. Leave visitor impact and Google's field assessment unverified until the corresponding data exists.
Add real-user monitoring when lab tests leave a gap
Use your own RUM when the unanswered question concerns actual visits: a filter that responds slowly, layout shifts after scrolling, differences between countries or the experience of returning customers. A controlled page-load test can help debug part of that behavior, but it is not a substitute for observing those visits.
The web.dev measurement guide describes collecting your own field measurements through a provider or the web-vitals library. Collection, delivery to a reporting system and meaningful aggregation are separate parts of the setup. Installing a script without checking the resulting events is not a completed monitoring workflow.
Define the question before collecting data. If visitors complain about an interactive filter, record the relevant interaction evidence and page context. If a template shifts after loading more content, examine the later experience rather than only the first screen. Keep the device, page group and sample period attached to any result you share.
RUM does not manufacture traffic. On a lightly visited site, your own dataset can also be sparse. A few measurements may reveal a useful debugging example while remaining too limited for a stable population summary. Show the sample size and missing dimensions; avoid turning an isolated visit into a site-wide conclusion.
Your RUM population also differs from CrUX's eligible Chrome population. An independently collected percentile is not automatically Google's reported percentile, even if both use the same metric names. Installing RUM does not submit your site to CrUX or guarantee inclusion.
Keep this distinction visible when reviewing Screpy's Core Web Vitals monitoring: its available lab measurements help direct investigation, while actual visitor responsiveness requires field evidence. Adding a separate RUM service does not convert those saved lab values into real-user measurements.
Choose and configure collection appropriately for your site, including data minimization and the relevant consent requirements. This is a measurement-design decision, not a reason to copy a tracking snippet into production without reviewing what it collects. Validate useful events first, then judge whether the resulting sample answers the original question.
Choose a workflow and report what is known
For a small public site, a recurring lab workflow with a saved baseline may be sufficient to detect a changed loading experience. For a team that needs release comparisons and notifications, history, budgets and diagnostic detail become selection requirements. For interaction problems, add appropriate field collection or a deliberately scripted investigation rather than relying on a navigation score.
Before choosing PageSpeed monitoring tools for a site without CrUX data, run a focused acceptance check:
- Confirm independent lab results. The tool should still provide a meaningful report when the CrUX panel is empty.
- Verify the target. Check the final URL, useful page content and test status before interpreting any metrics.
- Record the profile. Preserve available device, location, network, cache and version settings; flag anything unavailable.
- Test retention. Find the actual earlier report or establish how your team will save a baseline if the tool only shows current values.
- Check required alerts. Confirm supported conditions and notification delivery in a controlled trial where alerts are part of the chosen workflow.
- Make one comparison. Explain a changed individual metric using the saved inputs and supporting diagnostics, without asserting a real-user pass.
Include operating cost in the decision, beyond subscription price. Someone must select pages, inspect invalid runs, maintain self-operated agents where used and respond to findings. A detailed platform with nobody reviewing its output is less useful than a narrower workflow your team actually uses.
For a client report, separate three evidence states: current lab measurements, your own visitor measurements if collected, and available CrUX data at the identified scope. “Unavailable” is a valid result. It is more useful than filling the gap with a score from another source.
When field data becomes available, add it alongside the baseline instead of replacing or relabeling the lab history. It answers a different question and covers a different period. The guide to reading Google PageSpeed Insights explains how to interpret the two parts of that report.
The objective is a repeatable decision: identify a changed experience, preserve evidence, investigate a plausible cause and verify the relevant correction. You can do that without waiting for CrUX. You should still describe exactly which experience you measured and which conclusions remain unsupported.