Website speed test
To measure your website speed, paste its address here. The tool requests a measurement from Google PageSpeed Insights separately for mobile and for desktop and returns the Core Web Vitals — LCP, INP, CLS and TTFB — along with the overall Performance score, each with an explanation and a recommendation.
What gets measured is what Google itself judges speed by: real visitor data from the Chrome UX Report, and lab measurements from Lighthouse when no field data exists for the address. The two devices are scored separately, because results routinely differ by dozens of points.
- measurements per audit
- 2×
- Core Web Vitals metrics
- 4
- weight of speed in the score
- 25%
Mobile and desktop run in parallel, each in its own request.
LCP, INP (or TBT), CLS, plus TTFB.
Mobile and desktop combined; mobile counts for more.
Steps
How to measure website speed
The measurement is requested from Google, so you get the same numbers it sees.
- 01
Enter the page address
Ideally the specific page you care about — home page speed and product detail speed can have nothing in common.
- 02
Wait for both measurements
Mobile and desktop run in parallel. Lighthouse at Google is the slowest part of the audit, which is why it takes tens of seconds.
- 03
Compare mobile with desktop
The report shows both numbers side by side. Google indexes mobile-first, so the mobile figure matters more.
- 04
Start with the worst metric
Every metric comes with a note on what usually ruins it. Begin with the one furthest from its recommended threshold.
Which metrics get measured
Core Web Vitals are the three metrics Google uses to describe the loading experience. A fourth figure — server response time — belongs next to them, because the first three are hard to explain without it.
- LCP — Largest Contentful Paint
- How long the largest element in the first viewport takes to render, typically the hero image or headline. Good is under 2.5 s. It is ruined by a slow server, heavy images and fonts loaded after start-up.
- INP — Interaction to Next Paint
- How quickly the page responds to clicks and typing. Under 200 ms is fine. It replaced the older FID and is sensitive to how much JavaScript runs on the main thread.
- CLS — Cumulative Layout Shift
- How much content jumps around while loading. Under 0.1 is good. The usual culprits are images without dimensions, ads and banners injected above the content.
- TTFB — Time to First Byte
- How long the first byte of the response takes to arrive. A high TTFB pushes everything else back, and it is usually hosting, a missing cache or slow database queries.
- Performance score
- The 0–100 summary from Lighthouse. It is a weighted average of lab metrics, not a metric in itself — treat it as orientation, not as the goal.
Real-user data versus the lab
Field data (the Chrome UX Report) comes from actual visitors over the last twenty-eight days. It is the most honest number available, but it exists only for addresses with enough traffic.
When there is no field data, the measurement is done in the lab: Lighthouse loads the page on a simulated device over a slower network. The numbers are repeatable and good to tune against, but they do not describe what your visitors experience. The report always states which source the figures came from.
Lab values can differ by dozens of points between two runs — the measurement is sensitive to network and machine load on Google side. If you care about the effect of a change, compare several measurements, not two individual ones.
Why mobile and desktop are measured separately
The mobile measurement runs on a simulated slower CPU and a slower network. A page that feels brisk on a desktop can crawl on a phone — a thirty-point gap is nothing unusual.
Google indexes mobile-first, so the mobile version decides how the page is judged. That is why both numbers are shown separately rather than blended into one average that would tell the truth about neither device.
FAQ
What people ask about this
The same answers you would get from us by email — no marketing hedging.
What counts as a good website speed?
By Google thresholds: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, met by at least 75% of visits. A Performance score above 90 is excellent, 50–89 means there is room to improve, below 50 is a problem.
Why did I get a different number than last time?
Lab measurements are sensitive to machine and network load on Google side, so results vary between runs. Field data from the Chrome UX Report changes slowly by contrast, because it is a rolling twenty-eight-day average. When tracking the effect of an optimisation, compare the trend, not a single run.
Do you measure speed yourselves or through Google?
Core Web Vitals are requested from Google PageSpeed Insights, so you get exactly the numbers Google works with. Server response time (TTFB) we additionally measure ourselves while downloading the HTML, because it is available immediately and adds useful context.
Why does the speed measurement sometimes fail?
PageSpeed Insights has a request quota and Lighthouse occasionally drops out — on the same address mobile fails one time, desktop the next. The tool therefore attempts each measurement twice, and if the second attempt does not finish either, the category is left out of the overall score and the report offers a button to measure it again.
Will measuring make my site faster?
No, measuring is diagnosis only. But for every metric outside its recommended threshold the report says what most often causes it and where to look — images, JavaScript, fonts, caching or hosting.
Related guides
Website score
One 0–100 number from six areas, broken down to individual checks. Good for benchmarking competitors.
SEO check
Indexability, title, H1, canonical, Open Graph, robots.txt and sitemap — with a fix for every finding.
How Google sees you
Indexing, robots directives, search appearance, favicon and structured data — the crawler view, not the browser one.
All that is left is the address.
The audit takes about a minute, nothing is stored and all it needs is a public URL. Feel free to run it on a competitor.