Measure Your Website’s Page Experience with Google PageSpeed Insights

The test on this page audits the exact address you submit. That address is a Uniform Resource Locator (URL). PageSpeed Insights (PSI) asks Google to run Lighthouse on that address and returns the lab audit with two field blocks beside it. One block is the page you entered. The other is the origin, which is every eligible page on that host. When the page has enough eligible visits, the report shows both. When the page is short of Google’s sample, the page block drops away and the origin stands on its own.

Where Origin Mode Fits

Origin mode is a field-data scope, and it is not a switch on the lab audit. The PageSpeed Insights Application Programming Interface (API) accepts the URL, a strategy, and the categories you want scored. It has no parameter that tells Lighthouse to audit the whole host instead of the page. Google still attaches two field sections to that response. loadingExperience is the Chrome User Experience Report (CrUX) sample for the URL. originLoadingExperience is the sample for the origin. This report prints both. It keeps a single origin section when Google marks the URL sample as a fallback, or when the two histograms are the same sample under two labels.

A page gets its own sample only when it is publicly reachable and popular enough for Google to trust the distribution. The visitor minimum is real, and Google does not publish the number. Query strings and fragments are stripped before visits are grouped, so a campaign parameter does not split one article into a dozen thin samples. The lab audit still loads the URL you typed, including that query string. Chrome on iOS is outside the dataset, and the methodology lists the other gaps beside that.

An origin represents an entire website, addressable by a URL like https://www.example.com.

A page is determined to be sufficiently popular if it has a minimum number of visitors.

An exact number is not disclosed, but it has been chosen to ensure that we have enough samples to be confident in the statistical distributions for included pages.

Pages commonly have additional identifiers in their URL including query string parameters like ?utm_medium=email and fragments like #main.

These identifiers are stripped from the URL in the CrUX dataset so that all user experiences on the page are aggregated together.

Chrome on iOS.

Android apps using WebView.

Other Chromium browsers (for example Microsoft Edge).

Chrome for Developers, CrUX Methodology

The Parameters on Every Run

Each run is a small set of choices, and most of what people call origin mode is not one of them. The call that leaves this site carries the address, the strategy, and four categories. Everything else in the report is either read back from Lighthouse or measured by a separate request from our server.

• URL: The address you type. Lighthouse loads that address, path and query string included. CrUX later groups real visits after the query string and the fragment are removed, so the field row can be slightly broader than the lab URL.
• Strategy: Mobile is the default, and desktop is the other choice. Mobile uses Google’s phone profile, which this report labels Moto G Power, and the viewport on the current preset is 412 by 823. Desktop is labeled 1350 by 940. The strategy picks the lab device and the matching phone or desktop slice of the field data.
• Categories: Performance, accessibility, best practices, and Search Engine Optimization (SEO) are all requested on the same call. The retired Progressive Web Application (PWA) category is left off, because current Lighthouse rejects it. Each score runs from 0 to 100.
• Lab environment: Bandwidth and processor speed are not values we send. PageSpeed Insights runs Lighthouse with simulated throttling, and the report reads that method back from the result. The simulation loads the page on a fast connection, then estimates the same load on the slow preset.
• Field scope: The URL block is visits to that page. The origin block is visits to the whole host. Neither scope is a request parameter. Both arrive because the API response includes them. Locale, campaign tags, and a captcha token are also available on the API, and this test does not send them.
• Network timing: This is our own request, from the Martech Zone server, and it does not follow redirects. It times the Domain Name System (DNS) lookup, the Transmission Control Protocol (TCP) handshake, Transport Layer Security (TLS) negotiation, Time to First Byte (TTFB), and the full transfer, along with the HTTP status. It is not a Lighthouse score and it is not CrUX.

Change the URL or the strategy and you change the audit. The categories choose which scores come back. Origin shows up in the field section as the sitewide sample, or as the only sample when the page itself is too thin.

Lab Results Under a Tight Network

The lab result is one controlled load of that URL, built to be harsh. Lighthouse records the page on a fast connection, then simulates a slower phone and a tighter network so the largest delays show up when bandwidth and the processor are scarce. That is the useful part of a stress test. The opportunities and the diagnostics point at the work that still hurts when the connection is poor. Visitors on faster networks, with files already cached, usually come in ahead of that lab number.

The performance score rolls several lab timings into one figure: First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT), Cumulative Layout Shift (CLS), Speed Index (SI), and Time to Interactive (TTI). TBT is the lab stand-in for responsiveness. The field metric for that same idea is Interaction to Next Paint (INP), which only exists once real people have clicked and typed.

The mobile preset sits toward the slow end of fourth-generation (4G) service and the fast end of third-generation (3G) service. The throughput figures below are megabits per second (Mbps) and kilobits per second (Kbps). The processor slowdown is applied to the central processing unit (CPU).

Lighthouse applies network throttling to emulate the ~85th percentile mobile connection speed even when run on much faster fiber connections.

Latency: 150ms

Throughput: 1.6Mbps down / 750 Kbps up.

Packet loss: none.

They represent roughly the bottom 25% of 4G connections and top 25% of 3G connections (in Lighthouse this configuration is currently called Slow 4G but used to be labeled as Fast 3G).

By default, Lighthouse uses a constant 4x CPU multiplier which moves a typical run in the high-end desktop bracket somewhere into the mid-tier mobile bracket.

Lighthouse, Network Throttling

Field Results from Real Visits

Field data is what opted-in Chrome users actually waited through, on desktop and on Android, over a rolling 28 days. The methodology above is the gate. Chrome on phones that do not report into this dataset, in-app web views, and other Chromium browsers stay outside the sample. The origin row mixes every eligible page on the host. The URL row is that one page. People on ordinary connections usually look better here than they do in the lab, because the lab pushed the page toward a slow network and a slower processor on purpose. The field number is the one that describes the visit.

CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.

The percentiles shown for all metrics correspond to the 75th percentile.

On the other hand, PSI aggregates new data every day encompassing the previous 28 days.

If the URL you entered is not available in CrUX, PageSpeed Insights will attempt to fallback to origin-level data as shown in the next screenshot.

Chrome for Developers, How to View Chrome UX Report Data on PageSpeed Insights

The 75th Percentile

Google does not publish the average visit. It publishes the experience at the 75th percentile, so about three quarters of the measured visits were at least that fast and about a quarter were slower. A good result on Core Web Vitals (CWV) means that slower line still qualifies. LCP, INP, and CLS are the three that feed the assessment. FCP and TTFB sit beside them as diagnostics. Passing means all three Core Web Vitals are in the good range at that percentile, for the strategy you ran.

To provide a good user experience, strive to have LCP occur within the first 2.5 seconds of the page starting to load.

To provide a good user experience, strive to have an INP of less than 200 milliseconds.

To provide a good user experience, strive to have a CLS score of less than 0.1.

Google Search Central, Understanding Core Web Vitals and Google Search Results

Why the Field Number Waits

A fix you ship today is mixed with the previous 27 days of visits. The field figure refreshes daily: the oldest day drops off, and the newest day joins. You can see the number start to move as those new days accumulate. It represents the fixed site across the whole window only after the older visits have aged out, which takes the full 28 days. Search Console reads the same field Core Web Vitals, generally page by page, so a ranking movement that depends on them follows that field data. A greener lab score on the afternoon you deploy does not replace the visits already inside the window.

The monthly BigQuery release is a separate cut of CrUX, a calendar month aggregated at the origin, so it will read differently from the 28-day window on this page. Treat it as a monthly archive. Treat the figures in this report as the rolling window Google is refreshing every day.

Core Web Vitals are used by our ranking systems.

Our core ranking systems generally evaluate content on a page-specific basis, including when understanding aspects related to page experience.

Keep in mind that getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results; there’s more to great page experience than Core Web Vitals scores alone.

Google Search Central, Understanding Page Experience in Google Search Results

Why This Report Helps

The public PageSpeed Insights form runs one strategy at a time. This page calls the Lighthouse API, so a single response carries the lab scores, the failed checks, the opportunities, and both field scopes. The origin block is labeled as the whole site, including when it is present only because the URL lacked a sample of its own. The network probe then times the connection from our server without following a redirect, which shows whether the clock is burning on the handshake or on the page. Read the URL you submitted, set the lab stress test next to the 75th percentile, and use the origin row as the sitewide context for that same period.