Google Website Speed Test: The Complete Guide

"Google website speed test" almost always means one specific tool: PageSpeed Insights, at pagespeed.web.dev. Paste in a URL, and within a few seconds you get a 0-100 performance score, a breakdown of Core Web Vitals, and a list of specific fixes ranked by estimated impact. It draws on two different data sources — a simulated lab test run at that moment, and real visitor data collected over the previous 28 days — and understanding which one you're looking at explains most of the confusion people run into with the tool.

This guide covers how to run the test properly, what the score and the three Core Web Vitals actually measure, why lab and field numbers frequently disagree, why mobile and desktop results can look like two different websites, and where the same underlying data shows up elsewhere in Google's tools so you're not re-running a manual test every time you want a read on performance.

What "Google Speed Test" Actually Refers To

There's no single tool literally called "Google Speed Test" — the name people search covers a small family of related tools that share the same underlying engine. PageSpeed Insights (PSI) is the one most people land on: it's free, requires no login, and runs from a browser. Under the hood, PSI runs Lighthouse, an open-source auditing tool that also ships inside Chrome DevTools, against a simulated environment, and pairs the result with real-world field data from the Chrome UX Report (CrUX), a dataset Google builds from opted-in Chrome users.

The practical difference between these tools is where you run them from. PSI is the public-facing web version anyone can use on any live URL. Lighthouse in DevTools runs locally in your own browser, which is useful for testing a page before it's publicly deployed, or for testing something behind a login wall. Search Console's Core Web Vitals report shows the same field metrics as PSI, but aggregated across every URL on your property and grouped by page type, rather than one URL at a time. These aren't three different opinions about your site's speed — they're three views into overlapping data.

Running the Test

Go to pagespeed.web.dev, paste in the full URL including https://, and run the test. It checks mobile results by default, with a tab to switch to desktop. Give it 10 to 30 seconds — during that time it's actually loading your page in a controlled environment, not looking up a cached number from an index somewhere.

• The score is a single 0-100 number, color-coded: 0-49 is red and treated as poor, 50-89 is orange and treated as needing improvement, 90-100 is green and treated as good.
• That score is a weighted composite of several lab metrics — it is not the same thing as your official Core Web Vitals pass or fail status, which is judged separately using field data against fixed thresholds.
• Below the score, the three Core Web Vitals appear twice: once as lab-simulated numbers for this specific run, and once, if enough real traffic exists, as 28-day field data.
• Below that sits a ranked list of Opportunities, which carry an estimated time saving, and Diagnostics, which flag issues without a clean time estimate attached.

Lab Data vs. Field Data: The Distinction That Actually Matters

Every PSI report contains two different kinds of numbers, and mixing them up is the single most common misreading of the tool. Lab data comes from Lighthouse running your page once, right now, on a simulated mid-range device over a simulated network connection. It's controlled and repeatable in principle, which makes it useful for debugging: change something, re-run the test, and see the effect of that one change in isolation.

Field data comes from the Chrome UX Report: real page loads from real Chrome users who have opted into usage reporting, aggregated over the trailing 28 days. It reflects actual devices, actual network conditions, and actual browser tabs competing for the same resources, which is why a page can score 95 in the lab and still show a poor Core Web Vitals field assessment. The lab test has no idea that a meaningful share of your real visitors are on a three-year-old Android phone over patchy mobile data; the field data does.

One more wrinkle worth knowing before it confuses you: if a URL doesn't get enough Chrome traffic to build a statistically reliable sample, PSI cannot show page-level field data at all. In that case it falls back to an origin summary, the aggregate for the whole domain, or shows no field data whatsoever. This is common for low-traffic pages and doesn't mean the page went untested; it means there isn't enough real-user volume behind it to report on safely.

The Three Core Web Vitals, Explained

Core Web Vitals are three specific metrics Google uses to represent loading speed, responsiveness, and visual stability. Each has a "good" threshold measured at the 75th percentile of real visits, meaning three out of four of your visits need to clear the bar, not just your best-case load.

• Largest Contentful Paint (LCP) is the time until the largest visible element, usually a hero image or a heading block, finishes rendering. Good is 2.5 seconds or less. It's usually broken by slow server response time, render-blocking CSS or JS, or an unoptimized hero image.
• Interaction to Next Paint (INP) measures how long the page takes to visibly respond after a user interaction such as a click, tap, or key press, sampled across the entire visit rather than just the first interaction. Good is 200 milliseconds or less. INP replaced First Input Delay as the official responsiveness metric in March 2024, because FID only measured the delay before the first interaction started and missed responsiveness problems that showed up later in a session. INP is usually broken by long JavaScript tasks that block the browser's main thread.
• Cumulative Layout Shift (CLS) measures how much visible content unexpectedly moves during a page's life. Good is 0.1 or less. It's usually caused by images or ads loading without reserved space, or by web fonts that swap in and reflow text after the page already looks loaded.

Reading the Opportunities and Diagnostics

Below the Core Web Vitals section, PSI lists specific, ranked issues found on the page. Opportunities carry an estimated time saving; Diagnostics flag problems without a clean number attached, because their real impact varies too much from page to page. A few worth recognizing before you see them:

• Eliminate render-blocking resources — CSS or JavaScript that has to finish loading and parsing before the browser can start painting visible content.
• Properly size and compress images, and serve them in a modern format such as WebP or AVIF instead of an uncompressed JPEG or PNG.
• Reduce unused JavaScript and CSS, which often comes from a theme or plugin shipping code the page never actually executes.
• Reduce server response time, also called Time to First Byte — this one sits outside the front end entirely, pointing at hosting, database queries, or an uncached backend.
• Preconnect to required origins, which tells the browser to open a connection early to a third-party domain, such as a font host or analytics script, before it's actually needed.
• Treat the estimated savings next to each opportunity as a priority order, not a sum to add up — PSI calculates each figure somewhat independently, so fixing five issues that each claim 0.4 seconds will not literally save two seconds, because several of those fixes overlap in what they affect under the hood.

Why Mobile and Desktop Scores Rarely Match

It's normal, even expected, for the same URL to score 40 on mobile and 95 on desktop. PSI's mobile test simulates a mid-tier Android device on a connection throttled to roughly a slower 4G signal, while the desktop test runs under a much less constrained environment closer to a typical office or home connection. That gap isn't a flaw in the tool; it's a deliberate attempt to reflect the actual spread of hardware people carry around versus what they sit down at.

The mobile number deserves more weight than the desktop one for most sites, for a simple reason: Google indexes and evaluates the mobile version of a page by default, and mobile devices make up the majority of Chrome's field data pool for most consumer-facing sites. A desktop score that looks great is not evidence the page is fast for the audience Google is actually measuring it against.

How This Connects to Rankings

Core Web Vitals are part of Google's documented page experience signals, but the practical weight is smaller than the anxiety around it suggests. Relevance, whether the page actually answers the query, dominates ranking decisions; Core Web Vitals functions closer to a tiebreaker among pages that are otherwise comparable matches for a search. Chasing a perfect PSI score on a page that weakly answers the query it targets will not outrank a slower page that answers the query well.

It's also worth being precise about what actually gets evaluated for ranking purposes. Search Console's Core Web Vitals report groups your URLs by similar page type and buckets each group as Good, Needs Improvement, or Poor using field data, not the numeric PSI score from a single test. A PSI run is a diagnostic snapshot for one URL right now; the assessment that's relevant to page experience signals is the field-data status for the group of pages a given URL belongs to, evaluated over a rolling window of time.

Where Else to Find This Data

Once you've fixed what a PSI report surfaces, you don't need to keep manually re-running it to keep tabs on performance going forward. A few other places surface the same underlying data, and none of them replace the others: PSI is best for a specific-page, right-now diagnosis; Search Console is best for a site-wide view over time; DevTools is best during development, before a page is even live. Used together, they cover the full loop from something feeling slow to a confirmed, measured fix.

• Search Console's Core Web Vitals report shows field data for every indexed URL, grouped by similar pages, with trend over time and a clear view of which page groups need attention. It's the closest thing to a site-wide dashboard for this data.
• Chrome DevTools' Lighthouse panel runs the same lab audit locally, in your own browser, which is useful for testing a page before it's public or for isolating the effect of a single change during development.
• The CrUX Dashboard is a public template, built on Looker Studio, that charts historical field data for any origin with enough traffic, useful for confirming a change actually moved the needle over several weeks rather than trusting one snapshot.
• The web-vitals JavaScript library suits sites that want continuous real-user monitoring rather than periodic spot checks; this small library reports live Core Web Vitals data from actual visitors back into your own analytics.