PageSpeed Insights (PSI) is a free Google tool for web testing that analyzes the performance of a public URL and reports two kinds of evidence side by side: field data from real Chrome users and lab data from a Lighthouse audit run on Google’s servers. It evaluates mobile and desktop separately and adds scores for accessibility, best practices and SEO.
PSI is often the first tool teams use to check Core Web Vitals, because it shows whether a page passes the assessment that Google uses as a page experience signal. Its value lies in combining what actual visitors experienced over the past four weeks with a reproducible diagnostic run that explains why.
How PageSpeed Insights produces its report
When a URL is submitted, PageSpeed Insights performs two independent steps. It looks up the page and its origin in the Chrome User Experience Report (CrUX), a public dataset of anonymized measurements from opted-in Chrome users. In parallel it runs Lighthouse against the URL in a controlled environment and returns the audit.
The two halves answer different questions, which the table below separates.
| Property | Field data (CrUX) | Lab data (Lighthouse) |
|---|---|---|
| Source | Real Chrome users | One simulated page load |
| Time window | Rolling 28 days | The moment of the test |
| Statistic shown | 75th percentile | Single run values |
| Interaction metric | Interaction to Next Paint | Total Blocking Time as a proxy |
| Availability | Only with enough traffic | Always, if the page loads |
| Best used for | Judging real experience | Debugging and verifying fixes |
If a URL lacks enough CrUX samples, PSI may fall back to origin-level data for the whole site, or show no field data at all. Low-traffic and new pages therefore often have lab data only.
Core Web Vitals thresholds in PageSpeed Insights
The field section shows a pass or fail for the Core Web Vitals assessment. A page passes when the 75th percentile of each of the three metrics falls into the good range.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading of the main content | 2.5 s or less | Over 4.0 s |
| Interaction to Next Paint (INP) | Responsiveness to input | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | Over 0.25 |
Values between the two limits are rated needs improvement. PSI also displays First Contentful Paint and Time to First Byte from CrUX as diagnostic metrics, but they do not decide the assessment.
How the performance score is calculated
The performance score from 0 to 100 comes only from lab data. Lighthouse converts each metric into a sub-score using a log-normal curve derived from real website data, then combines them with fixed weights. Scores of 90 and above are shown green, 50 to 89 orange, and below 50 red.
| Lab metric | Weight | Main influence |
|---|---|---|
| Total Blocking Time | 30% | Long JavaScript tasks on the main thread |
| Largest Contentful Paint | 25% | Server response, render-blocking resources, hero image |
| Cumulative Layout Shift | 25% | Images without dimensions, injected content, web fonts |
| First Contentful Paint | 10% | Render-blocking CSS and scripts |
| Speed Index | 10% | How quickly visible content fills in |
The mobile test emulates a mid-range phone on a slow 4G connection with a CPU slowdown of about four times, which is why mobile scores are typically much lower than desktop scores for the same page. Network conditions are simulated rather than applied live, so results are an estimate.
PageSpeed Insights compared with other testing tools
PSI is a convenient front end to Lighthouse and CrUX, not a replacement for deeper tooling. Each neighboring tool fills a different gap.
| Tool | Data type | Strength | Limitation |
|---|---|---|---|
| PageSpeed Insights | Field and lab | Quick public check with real-user data | Public URLs only, fixed test settings |
| Lighthouse in DevTools | Lab | Runs locally, including on staging pages | Results depend on the local machine |
| Browser DevTools performance panel | Lab trace | Detailed main-thread analysis | Requires expertise to read |
| Real-user monitoring | Field | All browsers, every page, custom segments | Needs a script on the site |
| Search Console Core Web Vitals report | Field | Groups many URLs by status | Aggregated, delayed by days |
For automation, the PageSpeed Insights API returns the same results as JSON, which teams use in dashboards or scheduled checks. Its quota suits monitoring a set of key pages rather than crawling an entire site.
Interpreting results and common pitfalls
The most frequent misreading is to treat the lab score as the goal. Search ranking and user experience depend on field data, so a page with a score of 60 can still pass Core Web Vitals, while a page scoring 95 can fail for real users on slow devices.
- Run-to-run variance: lab scores can shift by several points between runs because of server load and network noise; compare medians of several runs.
- Field data lags behind fixes: the 28-day window means an improvement appears gradually over about four weeks.
- Only one URL is tested: a fast home page says little about product or search pages built from other templates.
- Opportunities are estimates: the projected savings in the audit are indicative and do not add up linearly.
- Logged-in states are invisible: PSI cannot test pages behind authentication.
In simple terms
PageSpeed Insights gives a web page two kinds of report card. One is based on how fast the page really felt for actual visitors over the last month. The other is a test drive done right now on a simulated, modest phone.
The visitor report tells you whether people have a good experience. The test drive tells you what slows the page down and what to fix first.
A practical example
An online furniture retailer checks its product page template in PageSpeed Insights. The field data shows an LCP of 3.8 seconds at the 75th percentile on mobile, so the page fails Core Web Vitals, while desktop passes. The lab audit identifies a large hero image loaded late through a script-driven carousel and a 1.2 MB JavaScript bundle.
The team serves the first product image directly in the HTML with a responsive WebP version and high fetch priority, and defers the carousel script. The mobile lab LCP drops from about 5 seconds to under 2.5 seconds immediately. Four weeks later the field LCP reaches 2.3 seconds and the template passes the assessment on mobile.