Analyzing page performance...
Page Performance Summary
Enter a URL to analyze page speed performance.
⚡ Optimization Recommendations
-
📄
Enter a URL to get optimization suggestionsOur tool will analyze your page and provide specific recommendations to improve loading speed.
📊 Resource Breakdown
| Resource Type | Size | Requests | Impact |
|---|---|---|---|
| No data available. Enter a URL to analyze resources. | |||
User Guide
Enter the page URL
Any public page, not just a homepage — test the pages that actually earn you traffic. The test runs on Google’s infrastructure, so the result is independent of your own connection or computer.
Pick mobile or desktop
Mobile is the default and the one that matters most, because Google indexes mobile-first and simulates a mid-range phone on a throttled connection. Switch to Desktop to see the same page without those constraints — the gap between the two is usually the most useful thing on the page.
Read the four scores
Performance, Accessibility, Best Practices and SEO, each out of 100. Green is 90+, amber 50–89, red below 50. Underneath, the lab metrics show why, and the screenshot confirms the page rendered as you expected.
Fix in savings order
Opportunities are tagged by category and sorted by estimated time saved, so the top item is the one worth doing first. Download the report to hand to a developer, make the change, then re-test — results cache for 15 minutes, so use Run a fresh test to force a new measurement.
About the Website Speed Test
This tool runs a genuine Google Lighthouse audit through the PageSpeed Insights API — the same engine behind pagespeed.web.dev, and the same measurements Google uses when it assesses page experience. Nothing here is simulated by us or estimated from a formula. What you get is Google’s own analysis, presented so you can act on it.
It is free, needs no account, and reports all four Lighthouse categories rather than performance alone. That last point matters more than it sounds: most free speed tools request only the performance category and discard the rest, so a site can score 95 for speed while quietly failing accessibility checks nobody ever sees.
What the four scores mean
Performance is how fast the page becomes usable, weighted across five metrics. Accessibility checks whether the page can be used with a screen reader, a keyboard or low vision — contrast, labels, landmarks, alt text. Best Practices covers security and correctness: HTTPS, console errors, deprecated APIs, image aspect ratios. SEO checks the technical basics a crawler needs — a title, a meta description, crawlable links, a valid robots.txt.
Accessibility and SEO are the two most often ignored and the two easiest to fix. A missing form label or a low-contrast link takes minutes to correct and costs nothing, and both are checks you can verify yourself the moment you have changed them.
Lab data and field data are different things
The metrics in the main panel are lab data: one simulated page load, on Google’s hardware, on a modelled network. It is repeatable and diagnostic — it tells you what is slow and why — but it is a single run of a simulation, and small variations between tests are normal.
When Google has enough real traffic for the URL, a separate Real-User Core Web Vitals panel appears. That is field data from the Chrome User Experience Report: what actual visitors experienced over the last 28 days, across every device and connection they happened to be using. This is the data Google uses for ranking. Where the two disagree, the field data is the one that counts — and it is normal for a page to score well in the lab while its real-user numbers lag, because real visitors are on slower devices than Google’s test machine.
The field panel is hidden when Google has no data for the URL, which is normal for a page with modest traffic. It is not an error, and it is not something you can fix directly — it fills in as the page gets visitors.
The metrics, and what actually moves them
Largest Contentful Paint is when the biggest thing on screen finishes loading; Google wants it under 2.5 seconds. It is usually a hero image, a heading, or a font that arrives late. First Contentful Paint is the first pixel of content, and is dominated by server response time and render-blocking CSS.
Total Blocking Time measures how long the page is frozen while JavaScript runs, and is the single best proxy for “feels sluggish”. Cumulative Layout Shift measures how much the page jumps as it loads — almost always images without width and height, ads, or a late-loading font. Interaction to Next Paint, in the real-user panel, measures how quickly the page responds when someone taps.
Speed Index is how quickly the page visibly fills in, and Time to First Byte is how long the server took before sending anything — the one metric no amount of front-end work will fix.
Why your mobile score is lower than desktop
Almost every site scores worse on mobile, often by twenty points or more, and it is worth understanding why before you panic. PageSpeed’s mobile test simulates a mid-range Android phone on a throttled 4G connection. Desktop assumes a fast machine on a fast connection.
The bytes are identical. What differs is the processor. JavaScript that a laptop parses in 200 milliseconds can take a second on a phone, which is why a page can be visually quick on both and still score badly on one. If your mobile and desktop scores are far apart and the page weight is the same, the answer is nearly always JavaScript — too much of it, or loaded too early.
Mobile is the score to optimise for. Google indexes mobile-first, and most visitors arrive on a phone.
Results are cached for 15 minutes
A full Lighthouse run takes twenty to fifty seconds, so results are held for 15 minutes per URL and per device. Re-testing the same page returns instantly, and switching between mobile and desktop is free after the first run of each.
When you have changed something and want a genuinely new measurement, use Run a fresh test. That bypasses the cache and runs Lighthouse again. Do that after every deployment rather than trusting a cached number, and remember that scores vary by a few points between runs even with no changes — treat a five-point movement as noise and a fifteen-point movement as real.
If Google is unavailable
PageSpeed occasionally cannot answer — its quota is finite and the service has outages like any other. Rather than showing an error, the tool then measures what a server can see directly: response time, HTML weight, compression, cache headers, render-blocking scripts and images missing dimensions. A banner makes clear the numbers are ours rather than Google’s, and the performance score is left blank, because a Lighthouse score requires a full browser render and estimating one would be dishonest.
Reading the resource breakdown
The table groups every request by type and orders it by weight, with an impact rating based on the share of total bytes. It is the fastest way to find where the page’s weight actually is, and the answer surprises people: it is usually JavaScript, not images. A page whose JavaScript accounts for more than half its bytes will struggle on mobile no matter what else is optimised.
What to do with the results
Work down the opportunities in the order shown — they are sorted by estimated saving, so the top item has the largest measured effect. Fix, re-test, repeat. The report download gives you the whole audit as a text file, with the device recorded in the filename, which makes before-and-after comparison straightforward.
Speed is one part of technical health. The SEO Site Audit covers indexability, meta tags, structured data, security headers and domain records in one pass. Broken Link Checker finds dead links that waste crawl budget. If the resource breakdown points at images, Image Compressor is where to start, and Keyword Density Checker examines whether the page is actually about what you intended.
Frequently Asked Questions
Is this website speed test free?
Yes — no account, no email and no daily limit. Every result is on screen immediately, all four Lighthouse scores are shown, and the full report downloads as a text file without signing up for anything.
Where does the data come from?
Google’s PageSpeed Insights API, which runs a real Lighthouse audit on Google’s own infrastructure. It is the same engine and the same measurements as pagespeed.web.dev — presented with both devices, all four categories and a downloadable report.
What is a good performance score?
90 or above is good, 50 to 89 needs work, below 50 is poor. Treat it as a diagnostic rather than a target: a score of 100 on a page nobody visits is worth less than 75 on a page that converts. Scores also move a few points between identical runs, so only take a change of ten or more seriously.
Why is my mobile score so much lower than desktop?
Because the mobile test simulates a mid-range phone on a throttled 4G connection while desktop assumes a fast machine and connection. The bytes are the same; the processing power is not. A large gap between the two almost always means too much JavaScript, since that is the cost phones struggle with most.
What is the difference between lab data and field data?
Lab data is one simulated load on Google’s hardware — repeatable and good for diagnosis. Field data, shown in the Real-User Core Web Vitals panel, is what actual Chrome visitors experienced over the last 28 days. Field data is what Google uses for ranking, so where the two disagree, trust the field.
Why don’t I see any real-user data?
Google only publishes Core Web Vitals for URLs with enough traffic to anonymise the sample. A newer or quieter page simply has none yet, so the panel is hidden. It is not an error and there is nothing to fix — it appears as the page gains visitors.
What are Core Web Vitals?
Three metrics Google uses to judge page experience: LCP (how quickly the main content loads, target under 2.5 s), CLS (how much the layout jumps, target under 0.1) and INP (how quickly the page responds to a tap, target under 200 ms). All three appear in the real-user panel when Google has data for the page.
How do I improve my score fastest?
Work the opportunities in the order the tool lists them — they are sorted by estimated time saved, so the top one has the largest measured effect. For most sites that means reducing or deferring JavaScript, compressing images, and giving every image an explicit width and height to stop the layout jumping.
Why does the tool test accessibility and SEO too?
Because Lighthouse returns all four categories in the same response, and ignoring three of them would be discarding useful information. Accessibility and SEO problems are usually cheaper to fix than performance ones — a missing label or a low-contrast link takes minutes — and both are easy to verify once changed.
Why is my result marked as cached?
A full audit takes twenty to fifty seconds, so results are held for 15 minutes per URL and per device. That makes re-testing instant and switching devices free. When you have changed something, use Run a fresh test to bypass the cache and measure again.
Can I test a page other than the homepage?
Yes, and you should. Test the pages that earn traffic — product pages, popular articles, landing pages. Homepages are often the lightest page on a site and the least representative of what visitors actually load.
What does “measured by AMTake” mean on my result?
It means Google PageSpeed was unavailable — usually a quota limit — so the tool measured the page directly instead. You still get response time, page weight, compression, cache headers and render-blocking findings, but no performance score, because that requires a full browser render. Try again shortly for the complete Lighthouse result.