To test your website’s speed, run its URL through a free tool like Google PageSpeed Insights, GTmetrix, or WebPageTest. Each loads your page in a real or simulated browser and reports load times plus a performance score. Test both mobile and desktop, run each test at least twice, and compare results across tools before changing anything.
That paragraph is the whole method in miniature. But the first time I ran a speed test, the report might as well have been in another language — TTFB, LCP, CLS, a score of 64 that felt like a failing grade. This guide fixes that: how to test website speed properly, which free tools to trust, and what every important number means for your visitors.
How fast should a website actually load?
Google’s widely cited research found that 53% of mobile visits are abandoned when a page takes longer than three seconds to load. Every extra second measurably cuts conversions and raises bounce rates.
Think of load time as three moments: first paint — something appears on screen (under ~1 second feels instant); main content visible — the page looks usable (Google measures this as LCP; under 2.5 seconds is “good”); fully interactive — buttons respond when clicked. If your LCP sits at 5 seconds, visitors stare at a half-loaded page and decide whether to leave. That’s the number to attack first.
What’s the best free way to test website speed?
Four tools cover everything, and all are free:
1. Google PageSpeed Insights. The default starting point. Enter a URL and get mobile and desktop reports with a 0–100 score, the Core Web Vitals, and a prioritized fix list. Its secret weapon is field data: real load times from actual Chrome users over the past 28 days. Lab scores show what a test measured; field data shows what your visitors experienced. When they disagree, trust the field data.
2. GTmetrix. My favorite for diagnosis: a letter grade plus a waterfall chart — a timeline of every file your page loads, with each file’s timing. When a page is slow, the waterfall shows exactly which file is the bottleneck instead of making you guess.
3. WebPageTest. The deepest free option. Choose the test location, browser, and connection speed, and get a filmstrip — screenshots of your page as it loads, frame by frame. When I need to prove a 4MB hero image is the problem, the filmstrip does it in one glance.
4. Pingdom Website Speed Test. The simplest: pick a location, enter a URL, get load time, page size, and request count. The fastest answer to “is it slow right now, roughly how slow.”
Don’t pay for a speed tool until you’ve outgrown all four. You almost certainly haven’t.
How do you run a speed test properly?
Test the pages visitors actually land on. Your homepage is usually your most optimized page — and the least interesting to test. Test your most-visited post, pricing page, or tool page instead.
Test mobile and desktop separately. The mobile report simulates a mid-tier phone on throttled 4G and will almost always score lower. That’s not a bug — most of your visitors are on phones, so the mobile number is the one that matters.
Run each test at least twice and take the median. The first run is often slower (cold cache, DNS lookups), and scores wobble with network congestion. Runs of 71, 74, and 68 mean your score is ~71.
Test from near your visitors. A test server in Virginia reports faster times than your visitors in Berlin experience. GTmetrix and WebPageTest let you pick the location — choose the one closest to your audience, and always compare against your own baseline before and after a change.
What do the numbers actually mean?
Performance score (0–100). A weighted blend of lab measurements — a rough health indicator. The gap between 92 and 98 is noise; between 55 and 85 is a real problem. There is no SEO bonus for a perfect 100.
TTFB — Time to First Byte. How long until the server sends the first byte — this measures your hosting, not your page design. Under 600ms is good; over a second means the server is the bottleneck.
LCP — Largest Contentful Paint. When the biggest visible element finishes rendering. Under 2.5 seconds is Google’s “good” threshold, and it’s the single most important number on the report — the moment your visitor thinks “okay, the page is here.”
INP — Interaction to Next Paint. How quickly the page responds to a click or tap. Under 200ms feels instant. Bad INP usually means heavy JavaScript is blocking the page — it looks loaded but ignores clicks.
CLS — Cumulative Layout Shift. How much the page jumps around while loading. Under 0.1 is good. Ever tapped a button and the layout shifted so you hit an ad instead? That’s bad CLS, caused by images and embeds without reserved dimensions.
Page weight. Total kilobytes and request count. The levers you directly control: fewer, smaller files means a faster page, almost without exception.
Why do my scores change every time I test website speed?
Because the web is a live system, not a lab bench. Cold vs. warm cache, a busy test server, ads loading different content each run, time of day — all of it moves the numbers. Run tests multiple times, compare medians, and measure against your own baseline instead of chasing a rival’s single screenshot.
What should I fix first if my site is slow?
In rough order of impact per hour of effort:
1. Images. On most slow sites, images are 50–70% of page weight. Compress them, resize to the displayed dimensions, and serve WebP or AVIF. This one step fixes more slow sites than everything else combined.
2. Caching and a CDN. Browser caching for repeat visits, plus a CDN serving static files from an edge near your visitors. Many hosts include both with one toggle.
3. Heavy scripts. Every plugin, tracker, and widget adds JavaScript that delays interactivity. If a script doesn’t earn its place, defer it or remove it.
4. Server response. If TTFB is over a second, the fix is hosting-level: a better plan or server-side caching. It’s fourth because it costs money — rule out the free fixes first.
5. Fonts. Custom fonts are render-blocking by default. Load only the weights you need, with font-display: swap so text appears immediately.
What’s a real example of speed testing catching the culprit?
Last week I ran this site’s responsive preview tool page through PageSpeed Insights and GTmetrix back to back. PageSpeed Insights gave the headline — mobile LCP needed work — but GTmetrix’s waterfall showed why: the five heaviest requests were all images, together outweighing the HTML, CSS, and JavaScript combined. One oversized PNG was doing more damage than every script on the page. Compressing and resizing the images cut page weight nearly in half and pulled LCP under the 2.5-second threshold on the retest. The lesson I keep relearning: when you test website speed, the score tells you there’s a problem, but the waterfall tells you which file to blame. Always look at both.
Speed is only half the pre-launch story. A fast page that renders broken at phone widths still loses the visitor — so once your numbers are healthy, run your site through our responsive preview tool and check desktop, tablet, and mobile side by side. Fast and correct at every width is the goal.
Frequently asked questions
How often should I test my website’s speed?
After every significant change — new theme, new plugin, redesigned page — plus a monthly baseline on key pages. Speed degrades gradually as scripts accumulate; a monthly check catches the drift before visitors notice.
Do I need a perfect 100 on PageSpeed Insights?
No. Aim for the real thresholds: LCP under 2.5 seconds, INP under 200ms, CLS under 0.1, and green field data. The gap between 90 and 100 is invisible to visitors.
Does website speed affect Google rankings?
Yes — Core Web Vitals are a confirmed ranking signal, and mobile-first indexing means your mobile speed is what counts. The bigger effect is behavioral: faster pages bounce less and convert more.
Why is my site slower on mobile than desktop?
The test simulates a mid-tier phone CPU on throttled 4G — harsher than your desktop on fiber — and real mobile visitors are on slower networks too. Your mobile score is the honest one; optimize for it first.