Find out how fast a web page loads on a phone or a desktop. Enter a URL to get a 0 to 100 performance score, the Core Web Vitals (LCP, INP, CLS), real-user data from Chrome and a list of fixes ranked by the time they would save.
Last updated:
Starting test…0 s
Recent tests
Page
Device
Score
LCP
TBT
CLS
Tested
Advertisement
Advertisement
How to use the Website Speed Test
Enter the page URL, for example https://example.com/blog/. The page must be publicly reachable.
Choose Mobile or Desktop. Mobile is stricter and is what Google uses for ranking.
Click Run speed test and wait 15 to 60 seconds while Lighthouse loads and measures the page.
Read the score and metrics: green is good, orange needs improvement, red is poor.
Work through the opportunities from the top, then test again and compare in Recent tests.
Metric targets and score weights
Metric
What it measures
Good
Poor
Weight in score
Largest Contentful Paint (LCP)
When the biggest image or text block becomes visible
≤ 2.5 s
> 4.0 s
25%
Total Blocking Time (TBT)
Time the main thread was blocked by long JavaScript tasks between FCP and full interactivity
≤ 200 ms
> 600 ms
30%
Cumulative Layout Shift (CLS)
How much visible content jumps around while loading
≤ 0.1
> 0.25
25%
First Contentful Paint (FCP)
When the first text or image appears
≤ 1.8 s
> 3.0 s
10%
Speed Index (SI)
How quickly the visible area fills in
≤ 3.4 s
> 5.8 s
10%
Interaction to Next Paint (INP)
Delay between a tap, click or key press and the next frame (real users only)
≤ 200 ms
> 500 ms
Field data
Thresholds are those published by Google for Core Web Vitals and for Lighthouse mobile scoring (Lighthouse 10 and later). Desktop tests use tighter curves for the same metrics.
Fixes that usually help most
Slow LCP: compress and resize the hero image (WebP or AVIF), add fetchpriority="high" to it and never lazy-load it, serve pages from a CDN or cache, and reduce server response time (TTFB).
High TBT or INP: ship less JavaScript, remove unused third-party scripts and tag-manager tags, defer non-critical scripts, and split long tasks so the main thread can respond to input.
High CLS: set width and height (or aspect-ratio) on images, videos and iframes, reserve space for ads and embeds, and use font-display: optional or matched fallback fonts to avoid text reflow.
Slow FCP: remove render-blocking CSS and fonts from the head, inline the small critical CSS, and enable text compression (Brotli or gzip) and HTTP caching.
Work on the opportunities with the largest estimated savings first, deploy, then run the test again: the Recent tests table keeps your earlier scores so you can see the effect.
Frequently asked questions
How is the performance score calculated?
Lighthouse measures five lab metrics, converts each to a 0 to 100 score on a curve based on real website data, and takes a weighted average: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10%. A score of 90 or more is good, 50 to 89 needs improvement and below 50 is poor.
What are good Core Web Vitals?
Google considers a page good when, for at least 75% of visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less and Cumulative Layout Shift is 0.1 or less. Poor starts above 4 seconds, 500 milliseconds and 0.25 respectively.
Why is my mobile score lower than desktop?
The mobile test emulates a mid-range phone with a slower CPU and a throttled 4G connection, so JavaScript takes longer to run and files take longer to download. The desktop test uses a fast connection and no CPU slowdown. Most visitors are on phones, so the mobile score is the one to improve first.
Why does the score change between tests?
Every test loads the page again, and server response time, ads, third-party scripts, A/B tests and network routing differ slightly each time. Variations of a few points are normal. Run several tests and look at the trend, or rely on the real-user data, which averages 28 days of visits.
What is the difference between lab data and real-user data?
Lab data comes from this single test run in a controlled environment and is best for debugging. Real-user (field) data comes from the Chrome User Experience Report, an aggregate of real Chrome visits over the last 28 days, and is what Google uses for the page experience signal. Low-traffic pages often have no field data.
Why can't it test my localhost or staging site?
The test runs on Google's servers, which can only reach public URLs. For local, password-protected or intranet pages, open Chrome DevTools, go to the Lighthouse panel and run the same audit on your own machine.
Is the test free and private?
Yes, it is free and needs no account. The URL you enter is sent to Google's PageSpeed Insights API, which visits the page like a normal browser; results are shown here and the recent-tests list is stored only in your browser. Without an API key there is a shared quota, so you may occasionally be asked to wait a minute.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.