Who can use the page-speed beta?
Page speed is a staged beta for eligible paid workspaces and must be enabled for your workspace. A paid plan alone does not grant beta access. The setup screen reports availability and the reason when you cannot create a monitor; existing documentation is not a promise that the beta is enabled for your account.
When enabled, choose Add monitor, select Page speed, enter a public page URL and a name, review the schedule and budget, and create the monitor. Creation queues its first scheduled measurement. You do not need to write a browser script or install anything on the page.
Which pages and test conditions are supported?
The initial profile measures one public HTTP or HTTPS page in one desktop browser from the home region shown in setup. The viewport is 1365 × 768 with device pixel ratio 1, a fresh browser context and cache, and no artificial network throttling. These conditions describe a repeatable synthetic test, not every visitor connection.
Authenticated pages, private networks, custom browser scripts, mobile presets and additional regions are outside this beta. URLs cannot include embedded credentials or fragments. A bot challenge or blocked page is reported as a measurement problem; it does not establish that the website is down.
What do the measurements mean?
LCP, or Largest Contentful Paint, records when the largest visible content element is painted during the captured load. FCP records the first content paint, and navigation TTFB records the time to the first response byte. Run diagnostics also show available load milestones, transferred bytes, request counts and failed requests.
Layout movement is load-window CLS: it covers the bounded observation during this browser test, not layout changes throughout a visitor session. No real-user Core Web Vitals verdict, INP value, Lighthouse score or Google grade is produced.
Missing or invalid measurements appear as Not measured and remain null in the API and exports. Null is not zero or a healthy result. Partial captures may contain some useful diagnostics without a valid loading measurement. Trends compare matching profile, region, browser, collector and configuration conditions; gaps remain visible when a scheduled measurement cannot be made.
How often does it run, and what does it cost in allowance?
Choose every hour, every 6 hours, or every day. Every 6 hours is the default. One page-speed monitor uses one monitor slot and shares the rolling 30-day browser-minute allowance with Browser checks: 250 minutes on Starter, 1,000 on Team, and none on Free. The Usage page shows current use and reservations.
Usage follows browser execution time, including manual diagnostics. At the default schedule, about 120 runs in 30 days would use roughly 30–60 minutes if each takes 15–30 seconds. This is an estimate, not a runtime or capacity guarantee. Other Browser checks and manual runs reduce the same remaining allowance.
If the allowance is used or reserved, or no execution capacity is available, the run is recorded as skipped. No website failure or good measurement is invented. Previously measured performance can become stale while new measurements are unavailable.
When does a performance alert open or recover?
The default budget opens a performance alert after two consecutive valid scheduled measurements above 4.0 seconds LCP. It recovers after two consecutive valid scheduled measurements at or below 3.6 seconds. Both confirmations use two runs. You can set a loading threshold from 0.1 to 20 seconds and a lower recovery threshold; the recovery band helps avoid repeated alerts around one cutoff.
Only comparable, valid scheduled measurements confirm or recover the alert. Missing or invalid measurements do not prove a slowdown or recovery. At a 6-hour schedule, confirmation can take approximately 12 hours; choose an hourly schedule when that delay is too long and review the additional allowance use.
Performance state is separate from availability. Page speed does not change uptime percentages, create an availability-down verdict, or feed a public status page. Configure alert destinations through the existing integrations.
What does Run check do?
Run check queues an asynchronous manual measurement. The page shows its queued or measuring state and updates when the result arrives. Manual runs use the shared browser-minute allowance and appear in the run history.
A manual result does not confirm or recover an alert, reset scheduled freshness, or replace scheduled overview health. Open the manual run to inspect its measurements. If no scheduled result exists yet, any manual values are labelled as diagnostics while scheduled health remains unmeasured.
How do I investigate a slow or incomplete run?
Open a run from its history to see measured values, capture notes, test conditions, available screenshots, and the bounded request timeline. Filter the timeline by resource type, URL path or failed requests to inspect large or slow requests. Request timings can overlap; a slow resource is evidence to investigate, not proof of the cause.
Displayed request URLs omit credentials, query strings and fragments. Request and response bodies are not included in the timeline. Screenshots can contain the visible public page content, so only monitor pages you are authorized to capture.
The request timeline is retained diagnostic evidence, just like a screenshot, and is loaded when you open an individual run. It is not permanently embedded in the summary or run-history rows. Retained artifacts normally expire after the configured retention period, which defaults to 14 days. Capture failures, expired links or unavailable evidence are shown explicitly. Numeric history may remain after an artifact expires. Download needed evidence while it is available; do not treat an expired screenshot as a missing measurement.
What can I export?
Download trend CSV exports the selected time range and matching measurement series, using scheduled measurements and explicit gaps. The trend reports when returned history is capped; choose a shorter range when needed. Download loaded runs CSV exports the rows currently loaded in the run ledger, including manual diagnostics. Load older runs first when you need those rows in the ledger export. Run exports include the requested and actual regions, profile, configuration revision, comparison series, trigger, and metric-validity notes when available; missing metadata is left blank.
The API reference documents the PAGE_SPEED configuration, capability check, asynchronous manual-run endpoint and dedicated result endpoints. Generic HTTP latency and uptime exports are not page-speed measurements.