How to read your website performance test results
A jargon-free guide to every number in your speed test: what is good, what is bad and where to start improving.
Key takeaways
- The three numbers Google cares about most are LCP, INP and CLS (the Core Web Vitals).
- One number alone does not tell the whole story: always compare the same device, preferably mobile.
- Start with what weighs most: large images, a slow server and too many third-party scripts.
In this guide
You tested your site and got a score, a few acronyms and lots of colors. Relax: you can understand all of it without being a developer. This guide explains, item by item, what each number means, what a good value looks like and what usually fixes it.
First, the overall score
The 0 to 100 score is calculated by Lighthouse, Google's measurement tool. It summarizes how the page performed in that test, on a simulated device.
| Score | What it means |
|---|---|
| 90 to 100 | Fast. Your visitors barely wait. |
| 50 to 89 | Room to improve. There is already a noticeable wait. |
| 0 to 49 | Slow. Some people give up before seeing the page. |
Tip: the score varies a little from test to test, because of the network and server load at that moment. A difference of 3 or 4 points is normal. Watch trends, not a single test.
The three numbers Google values most
Since 2021, Google has used three measurements, called Core Web Vitals, as part of its page experience assessment. Think of them as three questions a visitor would ask.
LCP: "When can I see the content?"
Largest Contentful Paint measures how long it takes for the largest element on the screen to appear, usually the main photo or heading.
- Good: up to 2.5 seconds
- Needs improvement: up to 4 seconds
- Poor: over 4 seconds
What usually fixes it: shrinking the main image, using modern formats (WebP or AVIF) and having a server that responds quickly.
INP: "When I click, does the page respond?"
Interaction to Next Paint measures the delay between a tap or click and the page's reaction. It replaced the old FID metric in March 2024.
- Good: up to 200 milliseconds
- Needs improvement: up to 500 milliseconds
- Poor: over 500 milliseconds
What usually fixes it: cutting heavy scripts, especially chat widgets, pop-ups and third-party tools running at the same time.
CLS: "Do things jump around while I read?"
Cumulative Layout Shift measures how much elements move during loading. You know when you go to tap a button and it moves down because an ad appeared? That is it.
- Good: up to 0.1
- Needs improvement: up to 0.25
- Poor: over 0.25
What usually fixes it: setting width and height on images and reserving space for banners and ads before they load.
Other numbers in the report
Server response time (TTFB)
How long the server takes to start sending the page. If it is slow, everything else is delayed too.
- Good: up to 0.8 seconds
- Warning: over 1.8 seconds
When this number varies a lot between tests, the server is probably overloaded. The fix is usually a better hosting plan, turning on caching or using a CDN such as Cloudflare.
Speed Index
Shows how quickly the screen fills in. A page may finish loading slowly but feel fast if the top appears right away. Lower is better.
Total page size
The sum of everything the browser downloads: text, images, videos, fonts and scripts. There is no official limit, but on mobile every megabyte counts. As a reference, pages over 3 MB start to struggle on weaker mobile connections.
Number of requests
Each file on the page (image, font, script) is a separate request to a server. Many requests, especially to outside services, make loading take longer.
Where to start
If the report showed several problems, tackle them in this order, which usually brings the most results for the least effort:
- Images: compress them and convert to WebP. On many sites, this alone solves half the problem.
- Third-party scripts: remove what nobody uses anymore (old pixels, unused chat widgets, embeds).
- Caching and CDN: they make the server work less and deliver content closer to the visitor.
- Hosting: if TTFB is still high after that, the server is the bottleneck.
Test on mobile. Most visits come from phones, and Google uses the mobile version to evaluate your site. A page can do well on desktop and poorly on a phone.
After each change, run the test again and compare. Watching the score go up is the best proof the fix worked.
Originally published on January 4, 2019 and updated on October 24, 2026.