Website speed test
Run Google Lighthouse on any page, on an emulated phone or desktop, and read the full result here: performance score, Core Web Vitals from real Chrome users, a loading filmstrip, what the page downloads, and what to fix first.
- Google Lighthouse results, shown on this page
- Real-user Core Web Vitals when Google has them
- Fixes sorted by estimated time saved
Performance score
Enter a URL to start
- RequestWaiting for inputSent to Google
- Load—On Google's servers
- Lab test—Lighthouse
- Real users—Chrome UX Report
Speed report
Enter a page URL above. Google Lighthouse tests it on an emulated phone or desktop, and the full report appears here: score, Core Web Vitals, filmstrip, page weight and what to fix first.
Fair-use limit for each visitor IP address: 12 tests per hour and 40 per day. Results are cached for 30 minutes per page and device.
Lab results and real-user results
A speed report mixes two kinds of data. Knowing which is which explains most surprises.
The lab test
Lighthouse loads the page once, on an emulated device with a throttled network, and measures it. Repeatable enough to compare changes.
Real users
The Chrome UX Report collects how real Chrome visitors experienced the page over 28 days, at the 75th percentile.
Score and Core Web Vitals
The 0 to 100 score is a weighted mix of five lab metrics. The Core Web Vitals assessment uses real-user LCP, INP and CLS.
Phone and desktop
The phone test slows the processor and network on purpose. A page can be fast on desktop and slow on a phone.
Speed metrics and their thresholds
Good and poor limits for real users, and each lab metric's share of the Lighthouse score.
| Metric | What it measures | Good | Poor | In the score |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the largest image or text block is shown | 2.5 s or less | over 4 s | 25% |
| Interaction to Next Paint (INP) | How fast the page reacts to taps, clicks and keys | 200 ms or less | over 500 ms | Field only |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less | over 0.25 | 25% |
| First Contentful Paint (FCP) | When the first text or image appears | 1.8 s or less | over 3 s | 10% |
| Time to First Byte (TTFB) | How long the server takes to start answering | 0.8 s or less | over 1.8 s | Field only |
| Total Blocking Time (TBT) | How long scripts block the page in the lab, a stand-in for INP | Lab only | Lab only | 30% |
| Speed Index | How quickly the visible page fills in | Lab only | Lab only | 10% |
How to use this tool
From a URL to a short list of speed fixes.
Enter the page URL
Any public page. Test the pages visitors land on most, not only the homepage.
Choose phone or desktop
Phone emulates a mid-range device on slow 4G; most sites should fix that first.
Wait for Google
Lighthouse loads the page on Google's servers. This takes 15 to 60 seconds.
Fix and test again
Start at the top of "What to fix first", then test again to see the difference.
What this tool does, and what it doesn't
A plain list, so you know exactly what to expect.
This tool does
- Run Google Lighthouse on phone or desktop
- Show real-user Core Web Vitals
- Sort fixes by estimated time saved
- Show the loading filmstrip and page weight
- Show the device and network Google used
- Export the results as CSV
This tool does not
- Run its own test machines
- Test pages behind a login
- Choose the test location
- Monitor speed over time
- Guarantee better rankings
- Store your URLs beyond the 30-minute cache
Where your data goes
Our server sends the URL to the Google PageSpeed Insights API, and Google loads the page from its own servers to test it. The result is cached on our server for 30 minutes, and fair-use counters use a hashed IP address, as described in our privacy policy. Links to other speed tools send the URL to those services only when you click them.
Why your results might look unexpected
The six situations people run into most, and what each one means.
Score changes between runs
Normal for a lab test. Compare the middle of three runs, or the real-user data.
Phone much slower than desktop
The phone test slows the network and processor on purpose, like a mid-range device.
No real-user data
Too few Chrome visits for the page or site. The lab result still applies.
Test busy or timed out
Google's quota is used up or the page is very slow. Wait a minute and try again.
Google could not load the page
It needs a login, blocks Google's servers or returned an error.
Fixed something, score unchanged
The result is cached for 30 minutes, and a CDN or page cache may still serve the old page.
Questions about website speed
Why does my score change every time I test?
The score comes from one lab run, and every run loads the page again: server response time, ads, third-party scripts, the CDN cache and Google's own test machines all vary a little. A few points up or down is normal. Run the test two or three times and look at the middle result, or rely on the real-user data, which covers 28 days.
Why is the mobile score lower than desktop?
The mobile test emulates a mid-range phone on a slow 4G connection with a slowed-down processor, while the desktop test uses a fast connection and no CPU slowdown. The report shows the exact settings Google used. Most visitors on phones really do have slower devices, so the mobile result is usually the one to work on.
Does Google use this score for rankings?
Not the score itself. Google Search uses Core Web Vitals from real Chrome users, the field data shown at the top of the report, as part of its page experience signals, which are one factor among many. The Lighthouse score is a lab measurement that helps you find and fix problems.
Why is there no real-user data?
The Chrome UX Report only includes pages and sites that get enough visits from Chrome users who share usage statistics. When the page itself has too few, the report falls back to data for the whole site, and new or small sites may have none. The lab test still works.
What should I fix first?
Start with the top of "What to fix first": it is sorted by the time Lighthouse estimates each fix would save. Common wins are a large hero image that loads late, render-blocking CSS or scripts, unused JavaScript, and images without width and height that make the layout jump. Savings are estimates; test again after each change.
Why did the test fail?
Google loads the page from its own servers. The test fails if the page needs a login, blocks Google's servers, returns an error, takes too long, or if the shared PageSpeed Insights quota is used up. The message says which one happened; wait a minute before trying again.
Where is my URL sent?
Our server sends it to the Google PageSpeed Insights API, and Google loads the page to test it. The result is cached on our server for 30 minutes so a repeat test is instant, and fair-use counters use a hashed IP address, as described in our privacy policy.