Website Speed Test Pro

Analyze your site's performance with real Chrome browsers. Get Core Web Vitals, waterfall charts, and actionable recommendations.

About the Website Speed Test

This website speed test loads your page in a real browser and reports Core Web Vitals alongside a request waterfall, so you can see which specific resources are delaying the page rather than just how slow it is.

A website speed test is only useful if it tells you what to fix. A single score identifies that there is a problem; the waterfall identifies which request is causing it, which is the part you can act on.

Core Web Vitals are the metrics that matter because Google uses them as a ranking input. LCP measures when the main content appears and is usually delayed by an unoptimised hero image or a render-blocking stylesheet. CLS measures unexpected layout movement, almost always caused by images without dimensions or fonts swapping late. INP measures responsiveness to interaction.

The waterfall shows where the time actually goes: which requests block rendering, which chain sequentially when they could be parallel, and which are far larger than they need to be. Test the same page a few times, since a single run reflects one moment on one network path.

How to use the Website Speed Test

  1. Enter the URL. Provide the page you want tested.
  2. Run the test. The page is loaded in a real browser and measured.
  3. Read the Core Web Vitals. Check LCP, CLS and INP against the thresholds.
  4. Work the waterfall. Find the render-blocking and oversized requests, and fix those first.

Website Speed Test features

  • Core Web Vitals: LCP, CLS and INP
  • First Contentful Paint and time to first byte
  • Request waterfall showing what each resource cost
  • Mobile and desktop runs
  • Recommendations derived from the measurements
  • Loads your page in a real browser rather than estimating

Frequently asked questions

Which metrics are measured?

The three Core Web Vitals — Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint — alongside First Contentful Paint and time to first byte, which together separate a slow server from a slow page.

Why do mobile and desktop results differ so much?

Because the mobile run applies slower processing and a constrained network, which is closer to how most people actually arrive. It is also the profile Google weights for ranking, so the mobile figure is the one to act on.

What does the waterfall tell me?

The order and duration of every request, which is how you find the actual culprit — a blocking font, an oversized hero image, a third-party script that stalls everything behind it. The total alone never tells you what to fix.

What are good targets?

LCP under 2.5 seconds, CLS under 0.1 and INP under 200 milliseconds are the thresholds Google treats as good. Meeting all three matters more than a single headline score.

Does page speed really affect rankings?

Yes, but modestly and mostly as a tiebreaker — relevant content still wins. The stronger effect is on conversion, since people leave slow pages regardless of how well they rank.