PageSpeed Insights explained: how to read the score and what score is enough

PageSpeed Insights is Google's free tool that reports a page's speed in two ways on one screen: data from real users over the previous 28 days, and a simulated Lighthouse test with a score from 0 to 100. The figure to read first is the Core Web Vitals assessment at the top of the report, because it comes from real visitors. The green, orange or red circle below it is the result of a single page load in a simulated environment.

This guide walks through the report section by section, explains why the two data sets disagree, shows where to fix LCP, INP and CLS when they fail, and answers the question site owners ask most: what score is enough.

What PageSpeed Insights is and what the report contains

After you paste a URL and press Analyze, PageSpeed Insights shows a Mobile tab and a Desktop tab. Each has two main parts.

• The top section, "Discover what your real users are experiencing", is field data from the Chrome User Experience Report (CrUX). It shows LCP, INP, CLS, FCP and TTFB, which Google still labels as experimental, along with a verdict on whether the page passes the Core Web Vitals assessment.
• The lower section, "Diagnose performance issues", is lab data from Lighthouse. It gives scores in four categories (Performance, Accessibility, Best Practices and SEO), followed by a list of things to fix such as oversized images, unused JavaScript or render-blocking resources.

The SEO category in this report is a basic technical check of one page: whether it has a title, whether links are crawlable and so on. It says nothing about how well the page will rank, so it is no substitute for a full site review.

How to read the PageSpeed Insights score

The Performance score falls into three bands: 90 to 100 is green, 50 to 89 is orange and 0 to 49 is red. The number is a weighted blend of five lab metrics and does not translate into seconds. From Lighthouse 10 onward the weights are:

• Total Blocking Time (TBT): 30%
• Largest Contentful Paint (LCP): 25%
• Cumulative Layout Shift (CLS): 25%
• First Contentful Paint (FCP): 10%
• Speed Index: 10%

The weights tell you where the points are. TBT, LCP and CLS together make up 80% of the score. If a page carries heavy JavaScript and TBT is high, another round of image compression will barely move the number. The recommendations listed under the score do not count toward it directly. Fixing them helps only when it improves one of the five metrics.

The score also changes from run to run, even when nothing on the page has changed. Causes include network conditions on the test machine, ads or A/B tests that serve differently each time, and third-party scripts that respond at different speeds. The safe way to read it is to run the test several times and look at the middle result.

What decides whether the Core Web Vitals assessment passes

PageSpeed Insights uses the 75th percentile of real-user visits, meaning at least 75% of visits have to land in the "good" range. A page passes when LCP, INP and CLS are all good. If INP does not have enough data, the assessment looks at LCP and CLS alone. If either LCP or CLS has no data, the page cannot be assessed.

Field data (CrUX) vs lab data (Lighthouse)

Field data is a record of how real Chrome users loaded the page over the past 28 days, across many devices and networks. Lab data is one page load on one simulated device with fixed network conditions. It is normal for the two not to match.

The differences that change how you interpret the report:

• INP cannot be measured in the lab, because it needs a real person to tap or click. Lighthouse uses TBT as a stand-in, and TBT only covers the loading phase. A page with good TBT can still have poor INP if the slow moment comes when a visitor opens a menu or applies a product filter after the page has loaded.
• Lab CLS counts only shifts during load, in the first screen. Field CLS covers the whole life of the page, including shifts that happen after the visitor scrolls.
• Field LCP benefits from caching. Returning visitors already have files stored, while a lab test starts from an empty cache every time. The element counted as LCP can also differ with screen size and with the content each visitor sees.
• Field data moves slowly. It is a rolling 28-day record that updates daily, so a fix made today shows up gradually over the following weeks. Lab data reflects the change as soon as you re-test.

Google's guidance is to use field data to decide what to fix first, because it reflects what visitors experience, and to use lab data to find the cause and confirm that a fix worked.

When no real-user data appears

CrUX only holds data for pages that are publicly accessible and have enough visitors, and Google does not disclose the minimum. When a page falls short, PageSpeed Insights switches to origin-level data, which combines every page on the domain. Check the "This URL" and "Origin" toggle in the report to see which one you are looking at. If the whole origin lacks data, the top section stays empty and the Lighthouse result is all you have to go on.

Where to fix LCP, INP and CLS

This table lists Google's thresholds for the three Core Web Vitals and the parts of a site that usually cause a failure.

LCP: start by finding the LCP element

The Lighthouse section names the element counted as Largest Contentful Paint. It is usually a banner image or the page's main heading. Once you know which element it is, work through these in order:

• Server response time (TTFB). If the server answers slowly, everything after it is slow. The fixes sit in hosting, server-side caching and a CDN.
• The LCP image must not be lazy-loaded. It should be in the HTML from the start so the browser discovers it early, and fetchpriority="high" can tell the browser to load it first.
• Image file size. Serve an image sized for the space it fills, in a modern format such as WebP or AVIF.
• Render-blocking CSS and JavaScript in the head. Move anything the first screen does not need so that it loads later.

INP: give the main thread less to do

INP is poor when the browser is busy running JavaScript at the moment a visitor taps. The fix is in the code more than on the server. Look at the audits about JavaScript execution time and third-party code in the report. Chat widgets, ad tags and several tracking tags loading together are common culprits. Remove tags nobody uses, delay scripts that are not needed for the first interaction, and break long JavaScript tasks into shorter ones. A very large DOM, such as a category page rendering hundreds of products at once, also slows every tap.

CLS: reserve the space before content arrives

Layout shifts happen when something appears and pushes content that is already on screen. Prevent them by setting width and height on every image and video, giving ad slots and third-party embeds a minimum height, and never inserting a banner or notice bar above existing content after load. Web fonts are another cause. When the real font replaces a fallback with a different width or line height, whole paragraphs move.

Why the mobile score is lower than desktop

The mobile score is lower because the test conditions are harsher. It does not mean the mobile version of the site is built worse. Google explains that Lighthouse runs the Mobile tab by simulating a mid-tier phone on a mobile network, and the Desktop tab by emulating a desktop computer on a wired connection. The same page with the same code gets very different scores.

The gap shows most in JavaScript. A mid-tier phone's processor runs scripts far more slowly than a desktop computer, so TBT rises, and TBT carries the most weight in the score. Sites built on an off-the-shelf theme with many plugins, or sites that render everything with client-side JavaScript, see an especially wide gap between the two tabs.

To decide which tab matters more, check what devices your visitors use in the device report in Google Analytics. For a site whose visitors arrive mostly on phones, the Mobile tab is the one closer to what customers experience.

Does a low score really affect SEO?

Yes, but not through the 0 to 100 score. Google states in its own documentation that its ranking systems use Core Web Vitals, which are LCP, INP and CLS measured from real users. The Performance score is a Lighthouse lab result meant to help developers find problems.

The size of the effect matters too. Google says good Core Web Vitals do not guarantee a top position, and that Search tries to show the most relevant content even when the page experience is sub-par. It also says there is no single page experience signal. Speed helps when content and relevance are otherwise close.

Rankings aside, a page that loads slowly and does not respond to taps loses people before they read or order, whether they came from Google, an ad or a link shared in LINE. Speed fixes pay off across every channel. If you are planning SEO work as a whole, count Core Web Vitals as one technical task alongside crawling, indexing and site structure.

What score is enough?

The practical target is passing the Core Web Vitals assessment on mobile, not scoring 100. Google's own documentation says that chasing a perfect score for SEO reasons may not be the best use of your time.

A sensible order of targets:

1. Get real-user LCP, INP and CLS into the good range, all three. This is the line Google uses for pass or fail.
2. If there is no real-user data yet, use the mobile Lighthouse score as a proxy. A green score (90 or above) is a good sign, but a page in the orange band can still pass Core Web Vitals when its real visitors have better devices and networks than the simulated conditions.
3. Once you pass, switch from chasing points to monitoring. Re-test every time a plugin, marketing tag or design change goes live.

An illustrative example: a product page scores 62 in mobile Lighthouse, but its real-user data shows LCP of 2.1 seconds, INP of 160 milliseconds and CLS of 0.05. That page already passes Core Web Vitals. What remains is improvement for visitors on slow devices, and none of it is urgent for SEO. In the opposite case, a page scores 91 but real-user INP sits at 380 milliseconds. It does not pass, and the job is to find which interaction is slow.

A workflow that ends in something you can act on

Testing the home page alone and drawing conclusions for the whole site is a common mistake, since the home page tends to be the best-maintained page. A fuller picture comes from these steps:

1. Pick one representative page per template: home page, category page, product page, article page and contact form. Speed problems usually live in templates, so one template fix reaches every page built on it.
2. Test the Mobile tab first. Note the Core Web Vitals verdict and which metrics fail.
3. Scroll to the Lighthouse section and use the "Show audits relevant to" filter to select only the failing metric. The fix list gets much shorter.
4. Fix one thing at a time, re-test several times, and compare the metric values as well as the overall score.
5. Keep tracking real-user data in the Core Web Vitals report in Google Search Console, which groups URLs that share the same problem.

PageSpeed Insights looks at one URL at a time and reports symptoms more than structural causes. To see how speed problems connect to crawling, duplicate pages or internal linking, you have to read it alongside a full site review, which is the scope of an SEO audit.

What to watch for on websites in the Thai market

Thai fonts. When a site loads a Thai web font in several weights, each weight is a separate request, and Thai script has vowels and tone marks above and below the baseline, which gives it a different line height from the system fallback font. When the real font swaps in, text moves and the shift is counted as CLS. Cut the weights down to the ones in use, preload the main font, and tune the fallback font so its size is close to the real one.

Traffic from apps. Links opened from chat and social apps often open in a browser embedded in the app. CrUX does not include Android apps that use WebView, and it does not include Chrome on iOS. A site whose customers come mostly through those channels, or mostly use iPhones, may see real-user data in PageSpeed Insights that does not represent its whole customer base. Read it next to your own analytics.

Accumulated marketing tags. Business sites often carry ad pixels for several platforms, a chat button and promotional pop-ups. These scripts hit INP and TBT directly. Reviewing which tags are still in use should be a routine job.

When the problem is in the theme or page structure itself and point fixes are not enough, a rebuild with speed targets set from the start may be more worthwhile. See the web design service page, or for WordPress sites the WordPress web design page.

Frequently asked questions

Is PageSpeed Insights free?

Yes, it is free and needs no login. Open pagespeed.web.dev, paste the URL you want to check and press Analyze. It works on any public page, including a competitor's, but real-user data appears only for pages with enough visitors in the CrUX data set.

Why do two tests give different scores?

Because the Lighthouse score comes from one real page load, which depends on the network and the resources of the test machine at that moment. Ads and third-party scripts that respond differently on each run also play a part. Run the test several times and take the middle result. The real-user data at the top of the report is steadier because it covers 28 days.

Why has the real-user data not changed after a fix?

Because field data looks back over 28 days, and visits from before the fix are still counted. The numbers move a little at a time and reflect the fix fully once a complete 28-day period has passed. In the meantime, use the Lighthouse result to confirm the fix hit the right spot.

Do you need a score of 100 to rank on Google?

No. Google's ranking systems use Core Web Vitals from real users, not the 0 to 100 Lighthouse score, and Google itself says good results do not guarantee a top position. A better target is getting LCP, INP and CLS into the good range on mobile.

Should you check the Mobile or Desktop tab first?

Check the Mobile tab first, because its test conditions are harsher and most problems show up there. The exception is a site used almost entirely by office staff on computers, where both tabs deserve a look.

PageSpeed Insights tells you quickly where a page is slow. Deciding what to fix first, and whether the fix is worth it, takes a view of the whole site. To have speed checked together with crawling and indexing issues in one pass, see what is covered on the Relevant Audience SEO audit page.