Free tool
How fast is your website?
Type in your website and Google tests how quickly it loads on a phone or a computer. You get a score out of 100, what slowed it down, and the biggest fixes in plain words. Free, with no sign-up.
- Takes
- About a minute
- Sign-up
- Not needed
- Your data
- Runs on Google’s servers. Nothing is saved here.
Try it
Check any website
Yours, a competitor’s, any public site. Google loads it on its own computers, the way a phone or a laptop would, and reports how quickly it showed up and what slowed it down. Stuck? Press Show me how in the window.
Website speed test
Live
Runs Google's free test · nothing is saved here
Ready
What you get
- A score out of 100One number for speed, plus scores for how easy the page is to use and how well Google can read it.
- How fast it shows upHow long the main part of the page takes to appear, and whether it stays still while it loads.
- What real visitors sawSpeeds measured on real Chrome visits over the last 28 days, when the site has enough visitors.
- The biggest fixesThe changes that would save the most time, explained in plain words.
Step by step
How to use it
The same steps the Show me how button walks you through in the window, one at a time.
Type a website address
Any public website works, yours or a competitor’s. You can leave out the https://.
Phone or computer
Most visitors use a phone, so start there. The computer test uses a faster connection.
Or try an example
Tap one of these to fill in a site we built, then run the test on it.
Run the test
Google loads the page on its own computers, which takes up to a minute.
Read the results
You get a score out of 100, how fast the page showed up, and the biggest fixes in plain words.
The numbers
What these numbers mean
The test runs Lighthouse, Google’s page checker, and reports four scores from 0 to 100. Google treats 90 to 100 as good, 50 to 89 as needing improvement, and anything below 50 as poor. Below them are the timing measures behind the speed score and, when Google has them, the Core Web Vitals from real visitors.
| Score | What it checks | Worth knowing |
|---|---|---|
| ScorePerformance | What it checksHow quickly the page loads and becomes usable in one simulated visit. It is a weighted blend of five lab metrics: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10%. | Worth knowingIt moves the most between runs, because it comes from a single page load. |
| ScoreAccessibility | What it checksAutomated checks for problems such as missing image alt text, low color contrast, form fields without labels and links without readable names. | Worth knowingLighthouse says automatic detection catches only a subset of issues, so 100 does not mean a site is fully accessible. |
| ScoreBest practices | What it checksChecks such as whether the page uses HTTPS, logs errors to the browser console, uses deprecated browser features or shows images at the wrong aspect ratio. | Worth knowingA console error flagged here can mean a script on the page is broken. |
| ScoreSEO | What it checksBasic technical checks: a title and meta description, a successful status code, crawlable links with descriptive text, a valid robots.txt and no block on indexing. | Worth knowingLighthouse notes that many ranking factors are not part of this score, so 100 here does not mean a page will rank. |
Metrics
The five lab metrics
These are the measurements behind the Performance score. Lighthouse uses stricter thresholds on desktop, so the test rates each run against the thresholds for its device.
| Metric | What it measures | Good on mobile | Good on desktop |
|---|---|---|---|
| MetricLargest Contentful Paint (LCP) | What it measuresWhen the largest image or block of text on the first screen finishes appearing. Often the hero image or the headline. | Good on mobile2.5 s or less | Good on desktop1.2 s or less |
| MetricFirst Contentful Paint (FCP) | What it measuresWhen the first text or image appears. | Good on mobile1.8 s or less | Good on desktop0.9 s or less |
| MetricTotal Blocking Time (TBT) | What it measuresHow long, in total, scripts kept the page too busy to respond to a tap or click while it loaded. | Good on mobile200 ms or less | Good on desktop150 ms or less |
| MetricCumulative Layout Shift (CLS) | What it measuresHow much visible content jumps around unexpectedly while the page loads. | Good on mobile0.1 or less | Good on desktop0.1 or less |
| MetricSpeed Index (SI) | What it measuresHow quickly the visible part of the page fills in. | Good on mobile3.4 s or less | Good on desktop1.3 s or less |
Thresholds from Google's Lighthouse documentation. On mobile, poor starts above 4 s for LCP, 3 s for FCP, 600 ms for TBT, 0.25 for CLS and 5.8 s for Speed Index.
Field data
Lab data and real-user data
The scores and the five metrics are lab data: one load of the page in Chrome on Google's servers. On mobile, Lighthouse simulates a mid-tier phone on a slow 4G connection, with 150 ms of latency, 1.6 Mbps of bandwidth and the processor slowed down four times. The desktop test uses a faster simulated connection and no processor slowdown. Lab data is good for diagnosing problems and checking a change, but it is one simulated visit, not your customers.
The real-user section comes from the Chrome User Experience Report: measurements from real Chrome users who visited the page over the previous 28 days. Google reports the 75th percentile, so three out of four visits were at least that good. When a page doesn't have enough visits of its own, Google falls back to data for the whole site, and the test says when that happens.
Real-user data includes Interaction to Next Paint (INP), which measures how quickly the page responds to actual taps, clicks and key presses. A lab test has no real visitor to interact with the page, so Lighthouse reports Total Blocking Time instead. Google describes TBT as a useful lab indicator of INP problems, but not a substitute for it.
Google Search Console's Core Web Vitals report is built from this same real-user data.
Common causes
What commonly slows small-business sites
Where Lighthouse has a name for the problem, it is shown in bold, so you can match it to the test's list of fixes.
Photos uploaded straight from a camera
A photo several thousand pixels wide, shown in a box a few hundred pixels wide, makes every visitor download the full file. Resizing it to the displayed size and saving it as WebP or AVIF fixes it. Listed as Improve image delivery.
A slider or video at the top of the page
The largest element on the first screen sets Largest Contentful Paint. A rotating slider or a background video makes that element heavy and late, where a single compressed image or a headline loads sooner.
Plugins that load everywhere
Page builders, sliders, galleries and form plugins often add their scripts and styles to every page, including pages that never use them. Listed as Reduce unused JavaScript and Render-blocking requests.
Third-party widgets
Chat bubbles, review carousels, booking embeds, social feeds and a stack of tracking tags each download and run code from another company's servers. They add to Total Blocking Time and to the page weight from other companies.
Slow hosting with no page caching
When the server builds each page from a database on every visit, the first byte arrives late and everything else waits for it. Page caching, or static pages served from a CDN, removes that wait. Listed as Document request latency.
Redirect chains
Typing the bare domain can bounce from http to https, then to www, then to a home page path. Each hop costs a round trip before the real page starts to load.
Too many web fonts
Several font families, or many weights of one, loaded from more than one provider delay text and can move the layout when they swap in.
Images and banners without reserved space
Images with no width and height, and cookie or promo banners inserted above the content, push the page around as it loads. That movement is what Cumulative Layout Shift measures.
Variability
Why scores change between runs
Run the same test twice and the Performance score will rarely match exactly. Lighthouse's documentation lists the reasons: the page itself changing between loads (different ads, A/B tests, rotating content), differences in network routing, the web server answering faster or slower at that moment, and differences in the hardware the test runs on.
The same documentation says the median of five runs is twice as stable as a single run. To check whether a change helped, run the test several times before and after and compare the middle results, not the best or the worst. When you run the same page and device again, the test shows how each score moved.
Compare mobile with mobile and desktop with desktop, since the two simulate different devices and use different thresholds. For the trend over weeks, the real-user data is steadier, because it covers 28 days of visits.
Questions
Common questions
Does page speed affect Google rankings?
Google says Core Web Vitals, the real-user measures of loading (LCP), responsiveness (INP) and visual stability (CLS), are used by its ranking systems, and recommends good Core Web Vitals for success with Search. The same guidance says Google always tries to show the most relevant content even when the page experience is poor, and that good results in reports or third-party tools don't guarantee top rankings.
Why is my mobile score lower than desktop?
The mobile test simulates a mid-tier phone on a slow 4G connection with the processor slowed down four times. The desktop test uses a faster connection and no processor slowdown, so the same page usually finishes sooner. Lighthouse also uses different thresholds for each device, which is why the test rates them separately.
Where do these results come from?
Your browser sends the address to Google's PageSpeed Insights API, which loads the page in Chrome on Google's servers and runs Lighthouse. This page shows what comes back. A run on Google's own PageSpeed Insights site is a separate page load, so its numbers can differ slightly.
Why does the test say Google has no real-user data?
Chrome only publishes real-user data for pages and sites with enough visits from Chrome users over the last 28 days. A newer site, or one with few visitors, may not have enough yet. The lab results still show what to fix.
What if the test can't load my site?
The test runs from Google's servers, not your computer, so it has to reach the site over the public internet. Firewalls and bot-protection services sometimes block it, and pages that stay blank until a script finishes can fail with a no-content error. The error message names the cause Google reported, and you can retry or run the test on Google's PageSpeed Insights site.
Is anything stored when I run a test?
The test runs between your browser and Google's API, and the results are not sent to us. The address and device you tested are added to this page's link so you can share it or come back to it. Like any page address on this site, that link can appear in our site analytics.
More to try
Related tools
- Any businessTry it
Quote request with photos
Ask a sample home repair company for a quote in five short steps, add photos, and see the email the owner gets.
- For contractorsTry it
Storm-ready Google ads
Send a storm warning over a sample service area and watch roof repair ads switch on there, then pause at all clear.
- For restaurantsTry it
Online ordering
Order from a sample pizzeria menu, pick pickup or delivery, and see the ticket the kitchen would get.
Next step
Want a faster website?
Send the address and what you need. We reply by email or phone with questions or a written proposal.