How to Test Website Speed with Google? A Detailed Guide to PageSpeed Insights

When a website loads slowly, many site owners instinctively think of testing it with Google. Google's own PageSpeed Insights is one of the most commonly used web performance testing tools. After entering a URL, you can see performance scores for both mobile and desktop, check Core Web Vitals metrics like LCP, INP, and CLS, and identify issues with images, JavaScript, CSS, and server response.

However, the "90" or "100" scores from PageSpeed Insights shouldn't be taken as the actual loading speed of your site. It's better at analyzing the loading and interaction performance of the page itself. To know whether your site is truly fast across different regions and network providers, you need to combine it with other network speed test results.

Below, we'll look at how to test website speed with Google from a practical standpoint, and how to interpret the various data in PageSpeed Insights.

1. What is Google PageSpeed Insights?

Google PageSpeed Insights, often abbreviated as PSI, is a web performance analysis tool from Google. Simply enter the URL of the page you want to test, and you can view performance data for both mobile and desktop devices.

PageSpeed Insights provides two main types of information:

One is field data from real Chrome users, known as CrUX data. The other is lab data from Lighthouse, which runs in a controlled test environment. The former reflects the real-world experience of users over the past period, while the latter is better for identifying specific performance issues on the current page. Google currently states that PSI's field data covers the past 28 days.

So, PageSpeed Insights doesn't just tell you "how many seconds it takes to open the page." It evaluates web experience from multiple angles, including page loading, interaction responsiveness, and visual stability.

For those working on Google SEO, standalone sites, cross-border e-commerce, or content sites, its greatest value isn't the score itself, but helping you find where the page is actually slow.

2. How to Test Website Speed with Google?

Using PageSpeed Insights for Google website speed testing isn't complicated; the whole process can be done in a few minutes.

1. Open Google PageSpeed Insights

Go to the Google PageSpeed Insights website and enter the URL of the page you want to test in the input box.

It's recommended to enter the full URL, for example:

https://www.example.com/

If you want to test a specific product page, article page, or landing page, you can enter that page's URL directly.

Many people only test their homepage, which isn't quite enough.

A fast homepage doesn't mean all pages on the site are fast. Product pages may load more product images, article pages may have ad scripts, and landing pages may need to request multiple APIs. Front-end resources and server requests vary greatly between pages, so the final speed test results will naturally differ.

For an important website, it's advisable to test at least the homepage, key content pages, and core conversion pages.

2. Click "Analyze"

After entering the URL, click "Analyze," and PageSpeed Insights will start crawling and testing the page.

Once the test is complete, it generates a full performance report.

If the page can't be accessed normally, the server responds abnormally, or the site restricts Google's testing requests, the test may fail. In such cases, don't rush to blame PageSpeed; first confirm that the target page is publicly accessible.

3. Check Mobile and Desktop Separately

PageSpeed Insights shows test results for both mobile and desktop devices.

These two results often differ.

For example, a site might score 92 on desktop but only 58 on mobile, which isn't uncommon. Computers have different processing power and network environments than phones, and mobile testing often exposes issues like long JavaScript execution times, oversized above-the-fold images, or excessive page resources.

Therefore, when testing with Google, don't stop just because desktop shows green.

If most of your traffic comes from mobile, the mobile results deserve more attention.

3. How to Read PageSpeed Insights Results?

The first time you open a PageSpeed Insights report, the most common issue is having too much data and not knowing where to start.

Actually, there's no need to study every item from top to bottom. First, divide the report into "Field Data" and "Lab Data"—that makes it much easier to understand.

1. Field Data

If the page has enough real visitor samples, PageSpeed Insights will show field data.

This data comes from the Chrome User Experience Report, or CrUX.

It doesn't reflect the test you just ran, but rather the experience data accumulated from real Chrome users visiting the page across different devices and network conditions. PSI currently shows data from the past 28 days, using the 75th percentile for assessment.

This section is mainly useful for answering: How is the real user experience on this page?

You'll often see: LCP; INP; CLS; FCP; TTFB.

In particular, LCP, INP, and CLS are the three core metrics of Google's Core Web Vitals.

Note that not all pages will show field data.

If your site is new, has low traffic, or Chrome hasn't collected enough samples, PageSpeed Insights may not show field data for the specific page; sometimes it falls back to domain-level data. If the entire site still lacks sufficient data, it may simply say there isn't enough field data.

This doesn't mean your site is broken; it just means there's not enough data yet.

2. Lab Data

Lab data is primarily generated by Lighthouse in a simulated environment. Unlike field data, it's better for diagnosing issues on the current page.

For example, the report might reveal: oversized images, long JavaScript execution times, CSS blocking page rendering, slow initial server response, or a large amount of unused front-end resources.

In simple terms, the two types of data can be understood like this:

So, if field data is poor, first confirm "the problem exists," then use Lighthouse's lab report to dig into the causes.

4. What's a Normal PageSpeed Insights Score?

The most prominent part of PageSpeed Insights is usually the Performance score at the top.

Currently, Lighthouse's performance score categories are:

Scores above 90 typically show green, 50–89 orange, and 49 and below red.

But there's a common misconception: A score closer to 100 doesn't necessarily mean your site is faster.

Google itself notes that achieving 100 is difficult and unrealistic. If your site already scores 95, spending a lot of development time to push it to 100 likely won't make a noticeable difference to real users.

In contrast, if a site scores only 40–50 and clearly has issues like slow above-the-fold loading or janky interactions, fixing those main bottlenecks will usually have a more visible impact.

So when looking at PageSpeed reports, don't just stare at the number in the circle.

The score can be a quick reference, but what really matters is: Which metrics are slowing down the page, and do they affect real users?

5. How to Read the Three Most Important Google Speed Metrics?

Google's Core Web Vitals currently consist of LCP, INP, and CLS, corresponding to loading speed, interaction responsiveness, and page stability.

1. LCP: How Quickly Does Main Content Appear?

LCP, short for Largest Contentful Paint, can be understood as: When does the most important content on the page actually appear on screen after a user opens it?

For example, on a product page, the largest product image above the fold might be the LCP element; on an article page, a large cover image or heading area could be the LCP element.

The recommended thresholds are:

If LCP is high, common causes include oversized above-the-fold images, slow server response, slow font loading, and CSS or JavaScript blocking rendering.

2. INP: How Responsive Is the Page After User Interaction?

INP, short for Interaction to Next Paint, focuses on whether the page responds promptly after user interaction. For example, clicking a navigation menu, tapping a filter button, or expanding a content area—if the page visibly freezes for a moment before responding, INP is likely high.

The recommended thresholds are:

When INP is poor, focus on JavaScript execution, main thread tasks, and complex interaction logic.

3. CLS: Does the Page Jump Around During Loading?

CLS, short for Cumulative Layout Shift, measures visual stability.

A typical scenario:

You're about to click a button on an article, but suddenly an ad image loads above, pushing the button down, and you end up clicking the wrong spot.

This kind of unexpected layout shift during loading is what CLS detects.

The recommended thresholds are:

For images, videos, iframes, or ad slots, setting explicit width and height dimensions in advance can reduce many unnecessary layout shifts.

6. Why Is PageSpeed High but the Site Still Loads Slowly?

Some sites score over 90 on PageSpeed Insights, yet users in certain regions still find them slow. Others have well-compressed front-end resources, but real visits often involve long waits.

The reason is: PageSpeed Insights measures page performance, not the full network quality between users and your server.

When users actually visit a site, many factors come into play, such as server location, ISP routing, DNS resolution, network latency, packet loss, cross-border egress, CDN nodes, and origin fetch routes.

For example, if your server is in the US and the page is lightweight with optimized JavaScript and images, PageSpeed might look great.

But if your main users are in mainland China, data still has to traverse long cross-border network paths. During peak hours, if international egress is congested or routing is suboptimal, real users may still perceive the site as slow.

This kind of issue is hard to diagnose with PageSpeed alone.

To further check how your site performs across different regions and ISPs in China, you can use Chahu for a multi-node website speed test. Enter your site URL and test across national three-network nodes, focusing on whether there are significant response time differences between regions.

If PageSpeed is fine but some China Telecom, China Unicom, or China Mobile nodes are notably slow, shift your troubleshooting from front-end code to network routing, CDN, server location, or ISP links.

Conversely, if network responses are stable across regions but PageSpeed metrics like LCP and INP are still poor, the problem is more likely on the page itself. Combining both tests is more effective than relying on a single PageSpeed score to find the root cause.

7. How to Fix Common PageSpeed Insights Issues?

PageSpeed Insights lists many optimization suggestions, but not every one needs immediate action. Start with issues that have the most visible impact.

1. Slow Image Loading

Images are often one of the largest bandwidth consumers on a page, especially for product sites, e-commerce, and image-heavy content sites.

If the above-the-fold area loads several MB of high-res images, it can easily drag down LCP.

First, check whether image dimensions are much larger than the displayed size, and compress images. If possible, use modern formats like WebP or AVIF, and enable lazy loading for below-the-fold images.

Note: Don't lazy-load critical above-the-fold images, as that can delay main content even further.

2. Too Many JavaScript Files

Many sites add analytics tools, chat widgets, or marketing plugins, each injecting more JavaScript into the page.

As plugins accumulate, pages may not look heavier, but browsers have to execute increasingly large scripts.

If PageSpeed reports long JavaScript execution times, check for unused plugins, duplicated scripts, and third-party code that doesn't need to run immediately on page load.

Remove what you can, and defer loading for scripts that aren't needed for the initial view.

3. CSS Blocking Rendering

Too many CSS files or improper loading can also delay above-the-fold rendering.

If the report keeps flagging render-blocking resources, check whether you're loading a lot of CSS that the page doesn't actually use.

Some sites use heavy themes or page builders, causing even simple pages to load the entire theme's stylesheet. In such cases, compressing files alone has limited effect; reducing unnecessary resources is more important.

4. Slow Server Response

If the front-end is well-optimized but the server takes too long to return the first byte, the page won't be fast.

In this case, investigate server load, database queries, dynamic code, cache hit rates, and CDN origin fetch performance.

Especially for WordPress, online stores, and dynamic content sites, back-end response time is often more critical than image compression.

5. Severe Layout Shifts

If CLS is high, focus on elements that load later.

Common culprits include ad slots, images, videos, iframes, cookie banners, and dynamically injected content.

An effective approach is to reserve space for these elements in advance, rather than letting them push content around after loading.

8. Is PageSpeed Insights Enough for Google Speed Testing?

If you just want to check front-end performance, PageSpeed Insights provides a lot of valuable information.

But to fully understand "why the site is slow," it's not enough on its own.

Different tools address different layers:

When troubleshooting site speed, a more practical approach isn't chasing a "perfect score" in one tool, but first determining which layer the problem is in. If PageSpeed scores are low, dig into images, JavaScript, CSS, server response, and Core Web Vitals. If PageSpeed looks good but real users still report slowness, shift attention to region, ISP, DNS, network routing, CDN, and origin server location.

That's where the value of Google speed testing lies. It helps you determine whether the page itself has obvious performance bottlenecks, but whether a site is truly fast ultimately needs verification in real user environments. Combining PageSpeed Insights' page analysis with multi-node network speed tests is usually more effective than looking at a single performance score, and it gets you closer to the speed users actually experience.

FAQ

Q1: Does a low PageSpeed Insights score directly affect Google SEO rankings?

A: Google has clarified that the "score in the circle" isn't a direct ranking factor. What matters is the actual performance of Core Web Vitals. As long as your LCP, INP, and CLS data fall within the "good" range (usually the green area in the report), even a total Performance score of 70–80 won't cause Google to penalize you for speed. There's no need to over-optimize just to hit 100.

Q2: My site just launched, and LCP is consistently too long. What's the fastest step-by-step troubleshooting approach?

A: First, check which element PSI identifies as the LCP element (usually a large above-the-fold image, carousel, or heading). The typical steps are: First, see if that image is compressed and in a modern format like WebP or AVIF. Second, check if you've mistakenly applied lazy-loading to the above-the-fold image. Third, if the image is fine, look at whether the server response time (TTFB) is the bottleneck.

Q3: INP keeps showing orange or red. How do I fix it?

A: Poor INP is usually caused by JavaScript blocking the browser's main thread. When users click menus or filters, the browser is busy running background scripts and can't respond promptly. Common solutions include removing unused marketing/analytics scripts, deferring third-party plugins that aren't needed initially, or having a front-end developer optimize long tasks.

Q4: Elements on my page always "jump" during loading. What's the most effective way to improve CLS?

A: CLS is most affected by late-loading resources pushing content around. The most effective fix is to set explicit width and height ratios (aspect ratio) or reserved space in CSS for all images, banner ad slots, and video frames. That way, even before the resource loads, the space is already reserved, preventing the page from shifting.

Q5: For SEO, should I test the homepage or specific article/product pages?

A: It's best to sample test. The homepage is usually the most complex with the most plugins, so it's valuable. But conversion pages and high-traffic article pages are where you actually attract users. Article pages might have many high-res images causing LCP issues, while product pages might have heavy JavaScript due to variant selections. Test the homepage, a core product page, and a high-traffic article page for a comprehensive view.