Google PageSpeed Insights is the free tool most small business owners get pointed at when someone says your site is slow. It is also the tool most often misread.
Two things people get wrong about it. The score at the top is not a grade Google uses to rank you. And the long list of recommendations is not a to-do list ranked by impact.
Reading the report correctly matters more than improving the number at the top.
This guide explains what PageSpeed Insights actually measures, which numbers matter for SEO, and which fixes move the needle most. Full disclosure: Stackra runs PageSpeed Insights on every audit and translates the output into platform-specific recommendations, which is why this guide is opinionated about which sections to act on and which to ignore.
What is a good page speed score?
On the PageSpeed Insights lab score, 90 to 100 is good, 50 to 89 needs improvement, and 0 to 49 is poor. That is the number at the top of the report. The result Google actually uses is a separate one: whether real visitors' pages pass Core Web Vitals. A good page speed score, in the sense that matters, is a pass on that assessment. Most US business sites get there: 65% of those with enough Chrome traffic to measure pass all three Core Web Vitals on phones, and the typical site's main content loads in 1.7 seconds, well inside Google's 2.5 second limit.
Chase the Core Web Vitals pass first. A lab score in the 70s with a pass is in better shape than a 95 that fails with real visitors.
What PageSpeed Insights actually measures
PageSpeed Insights reports two different kinds of data on the same page. Most of the confusion about the tool comes from not knowing which is which.
- •Field data (real users): collected from actual visits to your site over the previous 28 days through the Chrome User Experience Report. This is what Google uses when it evaluates your page for ranking. If your page does not have enough real-user traffic, this section is missing or incomplete.
- •Lab data (a single test in a controlled environment): a single Lighthouse test run from Google's servers. This is the score most people remember, but it is not what Google uses for ranking. It is useful for diagnosing specific problems and comparing before and after a change.
When SEO depends on speed, field data is the number that matters. The lab score is for debugging, not for grading.
The three Core Web Vitals: a quick reference
Core Web Vitals are the three real-user metrics Google uses to grade every website. A page passes when all three are in the good range across at least 75% of real visits. The thresholds:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | How fast your main content loads | Under 2.5s | 2.5 to 4s | Over 4s |
| INP | How fast the page responds to a tap or click | Under 200ms | 200 to 500ms | Over 500ms |
| CLS | How much the layout jumps while loading | Under 0.1 | 0.1 to 0.25 | Over 0.25 |
Source: Google Core Web Vitals documentation. Thresholds apply to the 75th percentile of real-user data.
Where most sites stand right now
We measured this across US business websites. Of 383,806 sites with enough Chrome traffic to measure, 65% pass all three Core Web Vitals on phones. The typical site's main content (its Largest Contentful Paint at the 75th percentile, the figure Google grades) loads in 1.7 seconds. Responsiveness is rarely the problem: the typical site answers a tap in 75 milliseconds against a 200 millisecond limit. Source: Stackra US corpus, 383,806 US business sites with Chrome UX Report data (mobile visits from the US, May 2026 snapshot), exported October 2026.
If your site is failing one Core Web Vital, it is probably LCP, and it is probably an uncompressed hero image.
Platform matters more than the per-site score implies
Different platforms start from different baselines because hosting, image handling and theme code differ. Hosted builders such as Wix, Duda, GoDaddy and Shopify put the typical site at 1 to 1.3 seconds, with about nine in ten passing. WordPress sits at 1.9 seconds with 62% passing. Sites hand-built on React or Next.js load about as fast as WordPress but pass less often, 41% and 45%. Their typical tap response is also slower, 150 and 125 milliseconds against 75 for most platforms. Weebly is the one platform whose typical site is past the 2.5 second line.
Table view
| Typical site's load time (LCP, 75th percentile) | Pass rate | |
|---|---|---|
| GoDaddy | 1.0s | 90% |
| Wix | 1.1s | 89% |
| Duda | 1.1s | 91% |
| Shopify | 1.3s | 90% |
| Webflow | 1.4s | 81% |
| Squarespace | 1.5s | 81% |
| Drupal | 1.5s | 80% |
| Custom, hosted | 1.5s | 70% |
| Custom Nuxt | 1.8s | 66% |
| WordPress | 1.9s | 62% |
| Custom single-page | 2.0s | 51% |
| Custom React | 2.0s | 41% |
| Custom Next.js | 2.1s | 45% |
| Weebly | 3.2s | 31% |
Pass rate is the share of each platform's sites passing all three Core Web Vitals. Fourteen common platforms, each with at least 4,000 measured sites. Source: Stackra US corpus, 383,806 US business sites with Chrome UX Report data (mobile visits from the US, May 2026 snapshot), exported October 2026.
- •Shopify: uncompressed product images on older themes
- •Wix: oversized hero images (Wix converts to WebP but does not shrink the file you uploaded)
- •Squarespace: theme JavaScript and image weight
- •WordPress: no automatic image compression, plugin overhead and slow shared hosting
By business category, the gap is in passing, not loading
Split the same sites by what the business does and typical load times barely move, from 1.3 to 2.1 seconds, all inside the limit. Pass rates swing from 76% to 35%, so typical load time explains little of the gap. Automotive is the clearest case: its typical page takes 175 milliseconds to respond to a tap, close to the 200 millisecond limit, where most categories sit at 75. Real estate and home services sites load in about 2 seconds and pass less than half the time.
Table view
| Sites passing all three Core Web Vitals | Load time | |
|---|---|---|
| Recreation | 76% | 1.4s |
| Funeral services | 74% | 1.7s |
| Restaurants | 74% | 1.3s |
| Retail | 73% | 1.5s |
| Religious groups | 73% | 1.7s |
| Entertainment | 72% | 1.6s |
| Nonprofits | 71% | 1.7s |
| Hospitality | 71% | 1.6s |
| Healthcare | 70% | 1.7s |
| Wellness and beauty | 70% | 1.5s |
| Government | 69% | 1.8s |
| B2B services | 62% | 1.9s |
| Professional services | 61% | 1.8s |
| Education | 61% | 1.9s |
| Content and media | 59% | 1.8s |
| Financial services | 56% | 2.0s |
| SaaS | 55% | 2.0s |
| Real estate | 49% | 2.0s |
| Home services | 47% | 2.1s |
| Automotive | 35% | 2.0s |
Load time is the typical site's Largest Contentful Paint at the 75th percentile. Twenty categories, each with at least 5,000 measured sites. Source: Stackra US corpus, 383,806 US business sites with Chrome UX Report data (mobile visits from the US, May 2026 snapshot), exported October 2026.
The most common LCP problem on small business sites
An uncompressed hero image. The pattern repeats across WordPress, Wix, Shopify, and Squarespace: a 4 to 8 megabyte JPEG uploaded as the homepage banner. What each platform does and does not do with that file:
- •Most platforms generate responsive image markup so browsers can pick an appropriate size for the viewport
- •Most platforms convert images to WebP or AVIF at delivery, which reduces transfer size for the browser format that loaded
- •None of them reduce the weight of your source file. An 8 MB upload is stored and served at 8 MB even after WebP conversion
Uncompressed hero images are the most common LCP failure mode Stackra flags on small business sites.
Three fixes that move the score, in order
If you only have time for three fixes, do these. They apply to every platform.
- •Compress every image above 200 KB before uploading. A typical 4 MB hero image compresses to 200 to 400 KB with no visible quality loss. This single change often moves LCP from failing to passing.
- •Add lazy loading to images below the fold. Most modern platforms do this automatically. For older custom themes, view source and confirm offscreen images carry the loading="lazy" attribute.
- •Remove or defer render-blocking third-party scripts. Chat widgets, analytics tags, ad pixels, and review widgets often load before your page can paint. Defer non-critical scripts to load after page interaction.
What to ignore in the recommendations list
PageSpeed Insights lists every detected issue, regardless of impact. Most lists are 20 to 40 items long. The vast majority of those items will not move your score noticeably. What to skip:
- •Recommendations under 50 ms estimated savings: too small to register in real-user data
- •Third-party script issues you cannot control: GDPR consent banners, ad networks, analytics tags
- •Properly size images warnings on responsive images that already have srcset (a parsing quirk, not a real problem)
- •Diagnostics labelled as informational rather than as opportunities
When the field data section is missing
If your page does not get enough real-user traffic, the field data section will be missing or partial. PageSpeed Insights falls back to lab data only. This is normal for new sites, low-traffic pages, and most internal pages on small business sites.
- •Focus on the lab-data Core Web Vitals (LCP and CLS) since those are still measurable in a lab test
- •Treat the lab score as a directional indicator, not a grade
- •As your traffic grows, field data starts to appear and eventually replaces lab data as the source of truth
No field data is not a problem to fix. It just means Google is not yet ranking the page on real-user performance, so use lab data as your guide until traffic catches up.
Frequently asked questions
Common questions about reading and acting on PageSpeed Insights results.
What is a good PageSpeed Insights score?
The lab score uses three bands: 90 to 100 (green) is good, 50 to 89 (orange) needs improvement, and 0 to 49 (red) is poor. For ranking, the result that counts is the Core Web Vitals pass or fail from real visitors, which 65% of measured US business sites pass.
But which score actually matters for SEO?
The lab score is not what Google uses for ranking. The number that matters is the field data Core Web Vitals assessment at the top of the report, which is either Pass or Fail based on real-user data over the previous 28 days. Aim to pass Core Web Vitals first. Improve the lab score as a secondary goal.
Why does my mobile score differ from my desktop score?
Mobile tests are run on a simulated mid-range Android device with a slow 4G connection, while desktop tests use a fast wired connection. Mobile is harder to score well on, and Google ranks mobile and desktop separately. Mobile-first indexing means Google primarily uses your mobile page to rank, so mobile is the score that matters most for SEO.
Does PageSpeed Insights affect my Google ranking?
Indirectly, yes. Google confirmed Core Web Vitals as an official ranking signal in 2021. The signal is used as a tiebreaker when pages are otherwise closely matched in relevance, not as a primary ranking factor. The lab score from PageSpeed Insights does not directly affect ranking; the field-data Core Web Vitals assessment does. Failing Core Web Vitals will not crater your ranking on its own. Passing them removes a tiebreaker disadvantage and signals to Google that the page provides a good user experience.
How often should I run PageSpeed Insights?
Run it after every change that affects layout, images, scripts, or hosting. Re-run it monthly to spot regressions caused by plugin updates, theme updates, or new third-party scripts added by marketing tags. One important detail about field data: the underlying Chrome UX Report data is updated daily but reflects a 28-day rolling window. A fix takes about a month to fully appear in the field score.
What about the older Lighthouse metrics like FCP and Speed Index?
First Contentful Paint (FCP), Speed Index, Total Blocking Time, and Time to Interactive still appear in PageSpeed Insights and contribute to the lab score, but they are not Core Web Vitals and are not what Google uses for ranking. Treat them as diagnostics for understanding why your LCP is slow. If your FCP is high, your server response or render-blocking resources are likely the cause. If Total Blocking Time is high, JavaScript execution is the bottleneck.