Speed Testing Performance Getting Started

How to Run a Free Website Speed Test (and Actually Understand the Results)

Most speed tests give you a score and nothing else. Here's how to run a proper test and read the results so you know exactly what's slow and how to fix it.

debugutils.dev ·

You paste a URL into a speed test tool. You get a number. Maybe it’s 45. Maybe it’s 78. Now what?

Most developers stop here — they see a score, feel either good or bad about it, and move on without understanding what’s actually slow or what to do about it. The score is a summary, not a diagnosis. The real value of a speed test is in the details underneath.

Here’s how to run a proper speed test and extract information you can actually act on.

Step 1: Choose the Right Tool

Not all speed tests are equal. Some give you a score and nothing else. Others give you the full picture — the score plus the diagnostic data you need to fix problems.

At minimum, you want a tool that provides:

  • Lighthouse Performance score — the standardized 0–100 benchmark
  • Core Web Vitals — LCP, CLS, and INP (the metrics Google uses for ranking)
  • Request waterfall — every resource your page loads, in order, with timing
  • Filmstrip — frame-by-frame screenshots of how the page loads visually
  • Prioritized recommendations — what to fix first and why

debugutils.dev gives you all of this for free, with no account required. Paste a URL and your report is ready in under 2 minutes.

Other options include Google PageSpeed Insights (good for field data, limited diagnostics), GTmetrix (freemium, waterfall included), and WebPageTest (powerful but complex). See our full comparison of speed test tools for a detailed breakdown.

Step 2: Test the Right Pages

Don’t just test your homepage. The homepage is usually the most optimized page on your site — and it’s rarely where conversions happen.

Test at least:

  • Your homepage — the front door, and what most people benchmark
  • A key landing page — where ad traffic or organic search traffic arrives
  • A product or service page — where purchase decisions happen
  • A blog post — often the heaviest pages due to images, embeds, and comments

You’ll often find that your homepage scores 75 but your product pages score 40. The product pages are where the real work is needed.

Step 3: Read the Score (But Don’t Stop There)

The Lighthouse Performance score ranges from 0 to 100:

ScoreRating
90–100Good
50–89Needs improvement
0–49Poor

The score is a weighted average of five metrics, with TBT (30%) and LCP (25%) carrying the most weight. A poor score in either of those metrics drags the whole number down.

The score tells you whether you have a problem. The next steps tell you what the problem is.

Step 4: Check Your Core Web Vitals

Core Web Vitals are the three metrics Google uses as a ranking signal. Your speed test report should show:

LCP (Largest Contentful Paint) — How long until the main content is visible. Under 2.5 seconds is good. This is usually the hero image or main heading.

CLS (Cumulative Layout Shift) — How much the page jumps around during load. Under 0.1 is good. Caused by images without dimensions, late-loading ads, and font swaps.

INP (Interaction to Next Paint) — How quickly the page responds to clicks and taps. Under 200ms is good. Caused by heavy JavaScript blocking the main thread.

If any of these are in the “Poor” range, that’s your priority. Google’s CrUX field data — real measurements from Chrome users — is what actually affects rankings, but lab tests give you the diagnostic detail to find and fix the issue.

Step 5: Read the Request Waterfall

The request waterfall is where the real diagnosis happens. It shows every file your page loads — HTML, CSS, JavaScript, images, fonts, third-party scripts — laid out on a timeline.

Look for:

A long first bar (HTML document). If the server takes over 800ms to respond, that’s a TTFB problem. Add caching or a CDN.

CSS and JS that block rendering. Resources at the top of the waterfall that must finish before the browser can paint anything. These are render-blocking resources — defer them.

A large image loading late. If your hero image starts loading halfway through the waterfall, the browser discovered it too late. Add a <link rel="preload"> with fetchpriority="high".

Many third-party script domains. Count the external domains in the waterfall. More than 5–10 is a red flag — third-party scripts are likely hurting TBT and INP.

Resources over 200KB. Large JavaScript bundles, uncompressed images, or oversized fonts. Each one is a candidate for optimization.

Step 6: Check the Recommendations

Your Lighthouse report includes an “Opportunities” section — a prioritized list of specific improvements with estimated time savings.

Start with the highest-impact items. Common ones:

  • “Eliminate render-blocking resources” — Defer JavaScript, inline critical CSS
  • “Properly size images” — Serve at the display size, not the original resolution
  • “Serve images in next-gen formats” — Convert to WebP or AVIF
  • “Reduce unused JavaScript” — Code split and tree-shake
  • “Reduce initial server response time” — Add caching

Don’t try to fix everything at once. Take the top 2–3 opportunities, implement them, and retest. Then take the next 2–3.

Step 7: Compare Lab and Field Data

If your site has enough traffic, your speed test should also show CrUX field data — real performance metrics from actual Chrome users. This is what Google uses for ranking.

Lab scores and field data often disagree. A site might score 85 in a lab test but fail Core Web Vitals in the field because real users are on slower mobile devices.

If field data is available: Use it to validate whether your lab improvements are translating to real-world gains.

If field data isn’t available: Your site doesn’t have enough Chrome traffic to generate CrUX data. Rely on lab tests and monitor Search Console as traffic grows.

What Good Looks Like

After running your test, you’re in good shape if:

  • Lighthouse Performance score: 70+ on mobile
  • LCP: under 2.5 seconds
  • CLS: under 0.1
  • INP: under 200ms
  • No major opportunities with > 1 second estimated savings

You’re in trouble if:

  • Performance score: under 50
  • LCP: over 4 seconds
  • Multiple render-blocking resources in the waterfall
  • Total page weight over 3MB
  • More than 10 third-party script domains

For detailed benchmarks by industry and metric, see our benchmarks guide.

Run Your First Test

Paste any URL into debugutils.dev right now. In under 2 minutes you’ll have a complete report — Lighthouse scores, Core Web Vitals, request waterfall, filmstrip, video recording, LCP element analysis, and CrUX field data — all free, no signup required.

The score is just the beginning. The waterfall and recommendations are where the real value is. Open them, read them, and you’ll know exactly what to fix first.

Try it yourself — it's free

Run a full speed test on any URL. No signup, no paywall. Get Lighthouse scores, Core Web Vitals, request waterfall, filmstrip, and actionable recommendations in under 2 minutes.

Run a free speed test →