Free tool · Google PageSpeed · No signup
Free Website Speed Test
Test the speed of any public web page on a phone and a desktop. You get Google PageSpeed scores, a Core Web Vitals verdict from real visitors, a screenshot of what loads first, and a plain list of the files and scripts that slow the page down.
- Free, no signup
- Mobile and desktop
- Core Web Vitals
- Fix list included
Built by Nexora Solution · Last updated
What Is a Website Speed Test?
A website speed test loads a web page in a controlled browser, measures how quickly it becomes visible and usable, and reports the result as scores and timings. It tells you how fast a page feels to a visitor and which files or scripts are responsible when it feels slow.
This tool uses Google PageSpeed Insights, which runs Lighthouse, the open-source auditing engine built into Chrome. Using Google's own engine matters because the numbers match what Google reports in Search Console and what developers see in Chrome DevTools. You are not looking at an invented score from a third-party formula.
Speed matters for two reasons. First, people leave slow pages, and every second of waiting makes a sale, a call or a sign-up less likely. Second, Google measures loading, responsiveness and visual stability as part of its page experience signals. A fast page helps both the visitor and the search result.
How to Test Your Website Speed
Paste the full address of one public page, press the test button, and wait about 20 to 40 seconds. The tool tests the page twice, once as a phone and once as a desktop, so keep the tab open until both results appear.
Enter one page
Type or paste a URL such as https://example.com/pricing. Test your homepage first, then your most visited page and your most important landing page. Speed differs from page to page, so one result never describes the whole site.
Run the test
The test asks Google to load the page from its servers. Nothing is installed and nothing is added to your site. Public pages only.
Check mobile first
Most visits come from phones, and the phone test is the stricter one. Read the mobile result first, then switch to desktop to compare.
Open the fix list
Press See all details to see the files and scripts behind a slow score. Each item says what to change and how much time it can save.
Change one thing and test again
Fix the biggest item, run the test again and compare. If you change five things at once you cannot tell which one helped.
Test the exact address people reach. https://example.com and https://www.example.com can behave differently if one redirects to the other, and a redirect adds time before the page even starts to load.
How to Read Your Speed Test Results
Your result has four parts: a performance score from 0 to 100, a Core Web Vitals verdict from real visitors, a list of timings, and a list of fixes. The performance score is a summary. The timings and the fix list tell you what to do about it.
| Score | Rating | What it means |
|---|---|---|
| 90 to 100 | Good | The page loads quickly in the test. Keep it this way when you add content or scripts. |
| 50 to 89 | Needs improvement | The page works but feels slow in places. One or two fixes usually move it into the green. |
| 0 to 49 | Poor | Visitors will notice the delay. Look for oversized images, heavy JavaScript and slow server response first. |
Besides performance, the tool also reports Accessibility, Best Practices and SEO scores from the same Lighthouse run. These do not measure speed. They check things like readable text contrast, HTTPS and whether the page can be indexed, so treat them as a free quick check next to the speed result.
What goes into the performance score
Lighthouse combines five timings into one score, and they do not count equally. According to Google's Lighthouse documentation, Total Blocking Time carries 30 percent, Largest Contentful Paint 25 percent, Cumulative Layout Shift 25 percent, First Contentful Paint 10 percent and Speed Index 10 percent. This is why one slow script or one oversized hero image can drag the whole score down.
- Largest Contentful Paint (LCP): when the biggest visible element, often the main image or heading, finishes loading.
- Total Blocking Time (TBT): how long scripts keep the page from responding to a tap or click while it loads.
- Cumulative Layout Shift (CLS): how much the page jumps around while it loads.
- First Contentful Paint (FCP): when the first text or image appears.
- Speed Index: how quickly the visible part of the page fills in.
Core Web Vitals: The Three Numbers Google Judges
Core Web Vitals are three measurements of real visitor experience: loading (LCP), responsiveness (INP) and visual stability (CLS). A page passes when at least 75 percent of real visits fall in the good range for all three. The tool shows the share of visits that were good, needs-work and poor for each.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP, Largest Contentful Paint | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| INP, Interaction to Next Paint | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS, Cumulative Layout Shift | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
INP replaced First Input Delay as the responsiveness metric in March 2024. It looks at every tap, click and key press during a visit and reports one of the slowest, so a page that reacts late to a menu button or an add-to-cart click fails it even if the first interaction was fast.
If the tool shows no real-visitor verdict, that is not an error. Google only publishes this data for pages and sites with enough Chrome traffic. A new or low-traffic page has lab data only, which is still enough to find and fix the causes of slowness.
Lab Data vs Real-User Data
Lab data is one simulated page load made right now under fixed conditions. Real-user data (also called field data) is collected from actual Chrome visitors over the previous 28 days. They answer different questions, and a page can look fine in one and bad in the other.
| Compared | Lab data | Real-user (field) data |
|---|---|---|
| Source | One Lighthouse test run | Chrome visitors, last 28 days |
| Best for | Finding causes and testing a fix | Judging how visitors really experience the page |
| Available for | Every public page | Pages with enough traffic only |
| Changes after a fix | Immediately | Slowly, as the 28-day window moves |
This is why a fix can raise your lab score today and leave the Core Web Vitals verdict unchanged for weeks. The real-visitor numbers are a rolling average, so they only catch up as old visits drop out of the window.
What Usually Makes a Website Slow
Most slow websites are slow for the same few reasons: images that are larger than they need to be, too much JavaScript, third-party scripts, render-blocking files and a slow server. Your fix list names the exact files, so use this section to understand what each one means.
Oversized and old-format images
Images are usually the heaviest part of a page. A photo uploaded straight from a phone can be several megabytes when the screen only needs a few hundred kilobytes. Resize images to the size they are shown at, and use WebP or AVIF, which are typically much smaller than PNG or JPEG at similar quality.
Too much JavaScript
JavaScript has to be downloaded, parsed and run, and a phone does that slowly. Large bundles, unused libraries and heavy page builders show up as high Total Blocking Time. Remove what you do not use and load the rest only on the pages that need it.
Third-party scripts
Tag managers, chat widgets, ad pixels, heat maps and social embeds are each small, but together they often cost more time than your own code. Ask of each one whether you still use its data. If not, remove it.
Render-blocking CSS and fonts
The browser will not paint the page until it has the stylesheets it needs. A large stylesheet, or several of them, delays the first paint. Web fonts can also hide text until they load, so set font-display: swap and load only the weights you use.
Slow server response and no caching
If the server takes a long time to answer, nothing else can start. Cheap shared hosting, no page cache and long database queries are the usual causes. Cache headers also let returning visitors reuse files they already downloaded instead of fetching them again.
Layout shifts
Images, ads and embeds without a set width and height make the page jump when they load, which raises CLS. Give every image and embed fixed dimensions so the browser reserves its space in advance.
How to Make Your Website Faster, in Order
Fix the biggest problem first. A practical order is images, then scripts, then caching and hosting. Each step below is safe to try on its own, and the test tells you whether it worked.
Compress and resize images
Resize each image to its display size, convert it to WebP or AVIF, and lazy-load images below the first screen. Never lazy-load the main image at the top, because it is the element LCP measures.
Remove or delay scripts you do not need
Delete unused plugins and tracking tags. Load chat widgets and analytics after the page is ready instead of at the start.
Cache files and use a CDN
Send long cache headers for images, fonts, CSS and JavaScript, and serve them from a content delivery network close to your visitors.
Turn on text compression
Enable Brotli or gzip on your server so HTML, CSS and JavaScript travel in a smaller form.
Reduce blocking CSS and fonts
Inline the small amount of CSS needed for the first screen, load the rest later, and limit fonts to the weights you use.
Check the server
If the first request is slow, look at hosting, page caching and slow database queries before anything else.
Speed work has a stopping point. Once your Core Web Vitals pass for real visitors, extra lab points rarely change what people experience, and time is better spent on content.
If you would rather not do this yourself, Nexora builds fast, server-rendered websites and can work from your fix list. You can also run a free GEO audit to check whether AI search tools can read the same page.
What This Speed Test Cannot Tell You
A speed test measures one public page at one moment from Google's servers. It cannot see your logged-in pages, your visitors' real devices or the effect of a change you have not made yet, so use it as a guide and not as a guarantee.
- It tests one URL at a time, not the whole site.
- The result varies between runs, so a few points of difference is normal.
- Lab conditions are simulated. Your real visitors may have faster or slower phones and connections.
- Pages behind a login, a paywall, or a firewall that blocks Google's test servers cannot be tested.
- Real-visitor data is shown only when Google has enough traffic data for the page or site.
- A high score does not prove good rankings. Speed is one signal among many.
The test does not store the page it loads. Your last results are kept only in your own browser, so you can compare the next test against them, and no account is needed.
Website Speed Test FAQ
Is this website speed test really free?
Yes. You paste a URL and get the full result with no account, no email address and no watermark. The test runs on Google PageSpeed from your browser, so it is limited only by Google's own request limits, not by a Nexora paywall.
What is a good page speed score?
Google groups the performance score into three bands: 90 to 100 is good, 50 to 89 needs improvement, and 0 to 49 is poor. A perfect 100 is not required. Passing Core Web Vitals for real visitors matters more than the last few points of a lab score.
Why is my mobile score lower than my desktop score?
The mobile test simulates a mid-range phone on a slower connection, while the desktop test uses a fast computer and network. The same page does more work per second on the phone, so scripts, images and layout cost more. Most sites score lower on mobile, and mobile is the score to fix first.
Why does my score change every time I test?
A lab test is a single simulated load, and small differences in server response, network routing and third-party scripts move the result. Expect a few points of variation. Run the test two or three times and look at the pattern, not at one number.
What is the difference between lab data and real-user data?
Lab data comes from one controlled test run now. Real-user (field) data comes from Chrome users who visited the site over the last 28 days. Lab data is good for finding causes. Field data is what Google uses to judge Core Web Vitals, but it only exists for pages with enough traffic.
Does page speed affect Google rankings?
Yes, but modestly. Core Web Vitals are part of Google's page experience signals, and they act more like a tie-breaker than a main ranking factor. Relevant, helpful content still comes first. Speed also affects bounce rate and conversions directly, which is a good reason to fix it by itself.
How can I make my website faster?
Start with the biggest items in your results: compress and resize images, serve modern formats like WebP or AVIF, remove or delay third-party scripts, cache static files and use a CDN. Fix one thing, test again, and keep the change only if the score or the loading time improves.
Can I test a page that needs a login?
No. The test loads the page the way a first-time visitor would, so it can only read public pages. Pages behind a login, a paywall or a firewall that blocks Google's test servers return an error or a result for the login screen instead.
How often should I test my website speed?
Test after every release, plugin install or theme change, and at least once a month otherwise. New tracking scripts and larger images are the usual causes of a slow page that used to be fast.
Want a faster website without the guesswork?
Nexora Solution is a software company in Multan, Pakistan that builds fast, server-rendered websites and business software. Send us your test result and we will tell you what to fix first.