How to test your website's page speed for free (step by step)

Bounce probability rises 32% when load time goes from the 1-3 second range to 1-5 seconds, and 106% once it reaches 1-6 seconds (Google/SOASTA Research via Think with Google, 2017). If your site is anywhere near those numbers, you’re losing visitors before they see anything you built.

Most “speed test” content doesn’t help with that. It’s a listicle ranking ten tools against each other, or a page of theory that tells you what Core Web Vitals are without ever showing you where to click. This guide is the walkthrough that’s usually missing: run one free test in under five minutes, and know exactly what the resulting numbers mean.

Key Takeaways

• Run your homepage through Google PageSpeed Insights (free, no account) and check your three Core Web Vitals scores: LCP, INP, and CLS.
• “Good” means LCP ≤2.5s, INP ≤200ms, and CLS ≤0.1, met by at least 75% of real visits, not just your one test.
• Cross-check with GTmetrix (free account) for a visual breakdown of what’s actually slow.
• If two or more scores land in “Needs Improvement” or “Poor,” that’s worth investigating before it costs you visitors.

What you’ll need before you start

Just your website’s URL and about five minutes. No account, no developer, and no cost for the first and most important test.

Test on both desktop and mobile if you can. Results often differ significantly between the two, and Google’s own Core Web Vitals ranking signal weighs mobile more heavily for most sites. A site that scores “Good” on desktop can easily land in “Needs Improvement” on mobile, so don’t stop after one device.

At Behold, running this exact pair of tests (PageSpeed Insights first, GTmetrix as the cross-check) is a standard part of every client site review before we touch a single line of code. It’s the fastest way to separate a real performance problem from a subjective “it feels slow” complaint.

Step 1: Run Google PageSpeed Insights

Go to PageSpeed Insights, paste in your homepage URL, and click Analyze. This is the same field data Google uses for its own Core Web Vitals ranking signal. That makes it the most authoritative free starting point: you’re seeing what Google itself sees, not a third-party approximation.

The report that comes back has two distinct parts, and mixing them up is the single most common source of confusion:

• Field data: real measurements from actual visitors to your site over the past 28 days, sourced from the Chrome User Experience Report (CrUX). This is what Google uses for ranking. It only appears if your site gets enough Chrome traffic to qualify.
• Lab data: a single simulated test run right now, in a controlled environment. Useful for diagnosing why something is slow, but it’s one snapshot, not a pattern.

Most consumer-facing speed guides skip this distinction entirely. That’s exactly why so many site owners get confused when their “score” looks fine in one place and poor in another. They’re often looking at lab data in one tool and field data in another: two different things measured two different ways. If your site is too low-traffic for field data to appear, lean on lab data plus the GTmetrix cross-check in Step 3.

Run the test on your homepage first, then on one or two of your most-visited inner pages. A slow product page or contact form can cost you conversions even when your homepage looks fine.

Step 2: Understand your three Core Web Vitals scores

You’re looking for three numbers (LCP, INP, and CLS), each with a “Good” threshold that has to be met by at least 75% of real visits, not just the one test you just ran (Google, Core Web Vitals documentation, retrieved August 2026).

That 75th-percentile framing matters more than it sounds. A single fast test run doesn’t prove your site is fast for real visitors on real connections. It proves your site was fast for one visit, under one set of conditions. Core Web Vitals asks a harder, more honest question: is your site fast for three-quarters of the people who actually show up?

In plain language, each metric measures something different:

• LCP (Largest Contentful Paint): how long it takes the biggest visible element (usually a hero image or heading) to load. This is your loading speed.
• INP (Interaction to Next Paint): how quickly the page responds after someone clicks, taps, or types. This is your responsiveness. INP replaced an older metric called FID in 2024, and it measures the worst interaction delay across the whole visit rather than just the first one, which makes it a stricter, more realistic test than what it replaced.
• CLS (Cumulative Layout Shift): how much content jumps around while the page loads. This is your visual stability: the metric behind that frustrating moment when you go to tap a button and an ad loads in above it first.

Metric	Good	Needs Improvement	Poor
LCP (loading)	≤2.5s	2.5s–4.0s	>4.0s
INP (responsiveness)	≤200ms	200ms–500ms	>500ms
CLS (visual stability)	≤0.1	0.1–0.25	>0.25

All three measured at the 75th percentile of real visits over a rolling 28-day window (Google, Core Web Vitals documentation, retrieved August 2026).

Notice that INP and CLS give you less room than LCP does. Their “Good” range covers only 40% of the distance to “Poor,” compared to 62.5% for LCP. Your page can be moderately slow to load and still count as Good, but it has almost no tolerance for feeling unresponsive or jumpy before it tips into Needs Improvement.

For a deeper breakdown of what drives each of these scores down, see the complete guide to Core Web Vitals.

Step 3: Cross-check with GTmetrix

PageSpeed Insights won’t always agree exactly with other tools, since different testing environments produce different lab numbers, but GTmetrix’s waterfall view shows you what specifically is slow in a way PageSpeed Insights doesn’t make as visual.

Go to GTmetrix, sign up for a free account (no credit card required, a handful of tests included per month), and run the same URL you just tested. Instead of a single score, you’ll get a waterfall chart: a timeline of every file your page requested, in order, with how long each one took.

A typical waterfall breaks a page load into rough phases: DNS lookup, server connection, waiting for the first byte of response (TTFB), then downloading and rendering everything else.

The single longest bar on your own report is usually your best clue for where to start fixing things: a long “Waiting” phase points at your server or hosting, a long “Content Download” phase usually points at unoptimized images.

If your GTmetrix score and your PageSpeed Insights score disagree, that’s normal, not a bug. They’re measuring different things in different ways, so treat both tools as answering different questions rather than competing for the “right” number. Why your site might be slow covers the common causes behind exactly that kind of disagreement.

Step 4: Test real-world conditions (optional, for the curious)

WebPageTest lets you simulate a visitor on a slower connection, an older device, or a different geographic location. It’s worth running if your first two tests came back borderline, not essential if they didn’t.

This step earns its place in a specific situation: PageSpeed Insights and GTmetrix broadly agree your site is fine, but you suspect one segment of visitors is having a worse experience than your test conditions show. Mobile users on 4G, or visitors in a region far from your server, are the usual suspects. For most small business sites, the first two tools are enough to make a decision. Treat WebPageTest as the tiebreaker, not the default.

What counts as “good enough” for a small business website

You don’t need a perfect 100 score. You need to clear the “Good” threshold on all three Core Web Vitals for the majority of real visitors, a meaningfully lower bar than chasing a flawless lab result.

Chasing a perfect score past that point has diminishing returns: the difference between a 95 and a 100 rarely changes whether a real visitor notices your site is fast. The difference between “Poor” and “Good” on even one metric, on the other hand, is the difference visitors actually feel. So fix whichever metric is furthest from “Good” first, rather than polishing whichever one is easiest.

A borderline score (just inside “Needs Improvement”) on a single metric is worth watching, not panicking over. Two or three metrics landing in “Needs Improvement” or “Poor” together is the pattern worth acting on. If your results came back that way, other signs it might be time for a rebuild covers the broader picture beyond just speed.

How often should you re-test?

Re-test after any major change (new images, a new plugin, a theme update, a redesign) and otherwise roughly quarterly.

Core Web Vitals field data is a rolling 28-day average. A single bad day of traffic or a temporary server hiccup won’t meaningfully move your score, and a single good test run doesn’t guarantee next month looks the same. Short-term swings aren’t the signal to watch; a sustained shift over weeks is. Set a simple quarterly reminder, and re-test immediately any time you or a developer changes something that touches images, scripts, or the page layout.

Conclusion

Run PageSpeed Insights first. It’s free, needs no account, and shows you the same field data Google uses to rank your site. Understand the 75th-percentile framing before you judge your result: one fast test doesn’t prove your site is fast for real visitors. Then cross-check with GTmetrix if anything looks off, using its waterfall view to see exactly what’s slow rather than just how slow.

If your results came back in “Needs Improvement” or “Poor” territory, the common causes behind a slow score is the next place to look. And for the fuller picture of how Core Web Vitals fits into your site’s overall health, the full Core Web Vitals playbook is the place to go next.