What Is a Good Google PageSpeed Insights Score?
Understand PageSpeed Insights scores, why mobile and desktop results differ, and which improvements matter most for your existing business website.
A good Google PageSpeed Insights Performance score is 90–100. A score of 50–89 needs improvement, while 0–49 is poor. These are Google’s official bands for the lab score shown in the report. However, a green score alone does not prove that every visitor has a fast experience. Google’s PageSpeed Insights guidance explains this distinction.
If you own a business website, the useful question is what your result means for customers. Can they read about your services quickly? Does the menu respond when they tap it? Can they request a quote without the page jumping around?
This guide explains how to interpret your score, what targets to use and how to decide whether your existing website needs a few improvements or a more substantial upgrade.
For the broader search impact, see our guide to how website speed affects Google rankings.
What do PageSpeed Insights scores mean?
The Performance score summarises a simulated test of the page you enter. Use the following bands as a starting point for investigation.
| Performance score | Google’s classification | Suggested next step |
|---|---|---|
| 90–100 | Good | Check real visitor data and maintain performance. |
| 50–89 | Needs improvement | Identify the main delays and prioritise useful fixes. |
| 0–49 | Poor | Investigate promptly, especially on important landing pages. |
The classifications come from Google’s PageSpeed Insights documentation. The next steps are our practical recommendations.
A score of 80 does not mean your website is 80% optimised. Nor does a score of 40 mean that 60% of customers will leave. The number is a diagnostic indicator, not a measurement of lost sales.
Treat it like a warning light on a dashboard: it helps you know where to investigate, but it does not explain the whole problem.
Which PageSpeed score should you look at?
PageSpeed Insights displays several categories. They answer different questions:
- Performance: how the page performs during the simulated test.
- Accessibility: results from automated accessibility checks.
- Best Practices: results from selected technical checks.
- SEO: results from selected search optimisation checks.
These categories appear in the Lighthouse diagnostics within PageSpeed Insights.
When someone asks for your website’s speed score, they normally mean Performance.
Keep the categories separate when reviewing a developer’s report. Ask for the category name, tested URL and device setting alongside each result. A screenshot with a green circle is much less useful without that context.
Also ask what was checked manually. An automated report cannot tell you whether your service description is persuasive, your pricing makes sense or a customer can confidently choose the right product.
What is a good mobile PageSpeed Insights score?
The good-score target is still 90 or above on mobile. There is no separate official amber-to-green boundary for mobile websites.
However, you should compare mobile results with mobile results. A mobile test and a desktop test represent different conditions. Processing power, network conditions and the way a page is displayed can all affect the experience. Google’s guide to differences between lab and field data explains why test results and visitor experiences vary.
For a small business, we recommend this order of attention:
- Resolve problems that prevent visitors from using the website.
- Address poor real-user performance where reliable data exists.
- Aim for a consistently green mobile Performance score.
- Check that desktop visitors also receive a good experience.
This is a prioritisation method, not an additional Google scoring system.
If your desktop score is 97 and mobile score is 58, report both. Showing only the desktop result can hide an important weakness in the customer journey.
Lab data and real-user data: what is the difference?
PageSpeed Insights contains two kinds of evidence.
Lab data comes from a controlled test. It is useful for investigating a particular page and checking changes.
Field data comes from eligible real Chrome users. In PageSpeed Insights, it covers a trailing 28-day period. If there are too few samples for one URL, the tool may show broader origin-level data, or no field data at all. See Google’s explanation of PageSpeed data.
That distinction matters when evaluating a redesign. A new version can perform better in a fresh test while historical visitor measurements still include the old website.
What if the lab score and visitor data disagree?
Investigate the difference before choosing which screenshot to trust.
A lab run represents a particular set of conditions. Real customers use different devices and connections, and interact with pages in ways that a loading test may not reproduce. A layout problem could appear only after someone scrolls or opens a feature. Google’s lab and field comparison discusses these differences.
Ask your developer to explain both sets of results. A useful report should describe the cause of any disagreement and the evidence needed to resolve it.
What are good Core Web Vitals results?
Core Web Vitals measure loading, responsiveness and visual stability.
| Metric | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint, or LCP | When the largest visible image or text block appears | 2.5 seconds or less |
| Interaction to Next Paint, or INP | How quickly the page responds visually to interactions | 200 milliseconds or less |
| Cumulative Layout Shift, or CLS | Unexpected movement of content | 0.1 or less |
Google recommends meeting these thresholds at the 75th percentile, assessed separately for mobile and desktop. Put simply, at least three-quarters of recorded experiences should meet each target. These thresholds are documented in Google’s Web Vitals guide.
For a business owner, the practical questions are straightforward:
- Can visitors see the main content promptly?
- Do buttons and menus respond?
- Does the page stay steady while people read or interact?
A performance conversation becomes much easier when each technical metric is connected to one of these customer experiences.
Is Total Blocking Time the same as INP?
No. Total Blocking Time, or TBT, is a lab metric that helps identify periods when the browser is too busy to respond promptly.
A standard Lighthouse loading test does not measure INP because it does not reproduce actual user interactions. TBT can help diagnose potential responsiveness problems, but it is not a substitute for field INP. Google’s Web Vitals documentation explains this relationship.
Does a high PageSpeed score improve Google rankings?
Google says its ranking systems use Core Web Vitals, but good results do not guarantee top rankings. Page experience is part of a much wider assessment. See Google Search Central’s page experience guidance.
The headline Performance score should therefore not be treated as a direct ranking target. Moving from 84 to 94 does not translate into a predictable number of extra positions or visitors.
For your business, assess performance alongside search intent, useful content and the ability to turn visits into enquiries.
Imagine a local electrician with a fast website that never explains which areas they cover. Improving the speed further will not answer that missing customer question. Equally, excellent service information is harder to use if the page freezes whenever someone opens the menu.
Your SEO plan should address both content and usability.
Do you need a PageSpeed Insights score of 100?
Usually, 100 should be an optional ambition rather than the sole acceptance criterion for a business website.
Lighthouse calculates its Performance score from weighted metrics. The relationship between a timing improvement and a score improvement is not linear, so the final few points can require disproportionate effort. Google’s Lighthouse scoring guide explains how the calculation works.
Before paying for further optimisation, ask:
- What specific delay will this work remove?
- Which customers or pages will benefit?
- Will it improve an important task, such as booking or requesting a quote?
- Could the change break useful functionality?
- How will the improvement be demonstrated?
For example, removing a booking tool might raise the score while making the website less useful. A better brief would be to investigate when the tool loads and whether it can run more efficiently.
How to test your website properly
You do not need to audit every URL before finding useful starting points. Choose a small, representative set.
1. Test pages that matter to your business
Start with your homepage, a main service page, a popular article and your contact or booking page.
If you sell products, include a category page and a product page. Different layouts may have different problems, so a strong homepage result should not close the investigation.
2. Record mobile and desktop results separately
Create a simple record of the URL, date, device setting, Performance score and the main reported issues.
Include the Core Web Vitals assessment where available, and note whether it applies to the URL or the wider origin. This prevents an aggregate result being mistaken for evidence about one particular page.
3. Repeat the lab test
Run several tests under the same device setting and look for a consistent pattern. We suggest using the middle result from three runs for an initial comparison.
Lighthouse scores can fluctuate because of the conditions surrounding the test. Its performance scoring documentation describes this variability.
Keep all the results. Selecting only the highest score makes it harder to judge whether an improvement is reliable.
4. Try the customer journey yourself
On a phone, open the menu, read a service page and complete a test enquiry.
Check that form validation, confirmation messages and telephone links work. If your site has consent controls, test the experience before and after making a choice.
Record the points where you hesitate or something feels unresponsive. Those observations give the developer a concrete journey to reproduce.
How can you improve a low PageSpeed score?
Start with the bottleneck identified in the report. Avoid buying a plugin or changing hosting before you understand the cause.
Improve delivery of the main content
A slow LCP can involve several stages: the initial server response, discovery of the main image, downloading it and finally displaying it.
Possible improvements include reducing the image’s file size, supplying suitable image dimensions and ensuring the browser discovers the important resource early. Avoid lazy-loading the image responsible for LCP. Faster hosting alone may not solve a delay caused later in the loading process. Google’s LCP optimisation guide explains how to diagnose these stages.
For your developer, a useful brief is: identify the largest visible element, explain what delays it and propose the smallest effective change.
Reduce work that blocks interaction
Long JavaScript tasks can keep the browser busy when a visitor wants to interact. Breaking up lengthy tasks and reducing unnecessary processing can help responsiveness. See Google’s INP optimisation guidance.
Ask for an inventory of scripts and embedded services. Does the website still use every chat widget, advertising tag and tracking integration?
Have the developer investigate redundant tools, then test essential features after any changes. Removing code without checking dependencies can create a faster page with a broken form.
Stop content moving unexpectedly
Images without reserved space, dynamically inserted content and font changes can contribute to layout shifts. Setting dimensions or an appropriate aspect ratio, reserving room for embeds and reviewing font behaviour are common remedies. Google’s CLS optimisation guide covers these causes.
As a practical check, watch your page while it loads. If the enquiry button moves just as you try to tap it, describe that exact behaviour in the work request.
Set a clear scope for the work
Ask for an estimate covering the diagnosis, changes and verification.
A helpful proposal should identify the affected pages, explain the expected benefit and state how success will be measured. Avoid an open-ended instruction to “make everything green” without agreement on the business priorities.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Should you repair your existing website or replace it?
A low score alone is not a reason to rebuild.
Repairs may be the sensible choice when your content, design and editing process already work well, and the main delays have identifiable causes.
Consider a broader upgrade when performance problems sit alongside confusing navigation, difficult maintenance, unreliable forms or a structure that no longer matches your services.
Compare the options using the same questions:
- What will be fixed?
- What useful functionality will be retained?
- How will existing URLs and search visibility be protected?
- Who will update the content afterwards?
- What ongoing maintenance will be needed?
Ask for the repair cost and replacement cost against a written scope. That gives you a decision based on the whole website, rather than one coloured number.
Can an Astro website help?
Astro’s islands architecture lets developers deliver mostly static HTML and add client-side JavaScript to selected interactive components. This can provide a useful foundation for content-led business websites. See the Astro islands documentation.
It still needs careful implementation. Large images and unnecessary third-party tools can undermine a lightweight starting point.
At Afterworks, we use your existing website as the starting point for an improved version, so you can see what a replacement could look like. The comparison should explain the changes, show performance evidence and make clear how the new site supports your customers.
Frequently asked questions
Is a PageSpeed score of 70 good?
It falls in the needs-improvement band. Use it as a prompt to investigate the main delays, especially on pages that generate enquiries. The number alone does not tell you how urgently a rebuild is needed.
Why is my desktop score better than my mobile score?
The tests use different conditions. A page may cope well with desktop resources while revealing delays under mobile constraints. Review both results and test the actual mobile customer journey.
Can a website score 100 and still have problems?
Yes. A Performance score cannot establish that a website’s information is accurate, its enquiry process is clear or its offer is compelling. Keep manual customer-journey checks in your review.
Does missing real-user data mean my website has failed?
No. Insufficient data is not a failed assessment. Use lab results and hands-on testing while considering whether additional visitor monitoring would be useful.
How often should I check PageSpeed Insights?
For a small business, we suggest checking after significant changes and reviewing important pages monthly. Test sooner if customers report delays or an update adds substantial functionality.
What should your business aim for?
Aim for a mobile and desktop Performance score of 90 or above, supported by good Core Web Vitals where field data is available.
Then judge the website by the tasks it needs to support. Visitors should be able to understand your offer, move between pages and contact you without unnecessary waiting or confusion.
If your existing site is falling short, start with a measured comparison. Ask Afterworks to review your current website and show how an upgrade could improve its speed, clarity and technical SEO foundations.
