Website Speed Test: How to Run One and Read the Results

A website speed test measures how quickly your pages load and respond for visitors. It is one of the most useful checks you can run, because slow pages frustrate people, hurt conversions and can weaken your search performance. The catch is that different tools measure different things, so a score on its own can mislead you.

This guide shows which tools to use, how to read the numbers, and which fixes usually make the biggest difference.

The best website speed test tools

Tool	What it shows	Best for
PageSpeed Insights	Real-user Core Web Vitals plus a Lighthouse lab report	A quick, Google-aligned health check
Google Search Console	Core Web Vitals grouped by URL type across your site	Finding which templates have problems
Lighthouse in Chrome DevTools	Lab audit run on your own machine	Debugging during development
WebPageTest	Detailed waterfalls, filmstrips, many locations and devices	Deep diagnosis of what loads when
GTmetrix	Lighthouse-based report with waterfall and history	Monitoring and easy-to-share reports

A note on "speed test Google"

People searching "speed test google" often want one of two different things. Typing "internet speed test" into Google runs a test of your own connection's download and upload speed. That says nothing about your website. To test a site, use Google PageSpeed Insights instead.

How to run a website speed test properly

1. Pick representative pages. Test your home page, a top landing page, a product or service page, a blog post and checkout or contact. Each template behaves differently.
2. Test mobile first. Most tools simulate a mid-range phone on a slower network, which is closer to many visitors' reality than your office laptop.
3. Run each test more than once. Lab results vary run to run; look at the middle result rather than the best.
4. Test from relevant locations. If your customers are in another region, choose a test location near them in WebPageTest.
5. Record a baseline. Save the numbers before you change anything so you can prove what worked.

How to read the results: field data vs lab data

PageSpeed Insights shows two kinds of data, and mixing them up is the most common mistake.

• Field data comes from the Chrome User Experience Report: real visitors' experiences over the previous 28 days. It is what Google uses for Core Web Vitals assessment. Low-traffic pages may not have enough data.
• Lab data comes from a single simulated Lighthouse run. It is ideal for debugging, but it is not what your visitors experienced.

The Lighthouse performance score (0 to 100) is a lab summary. It is useful for spotting problems but is not a ranking factor in itself. Focus on the Core Web Vitals.

Core Web Vitals thresholds

Metric	Measures	Good	Poor
Largest Contentful Paint (LCP)	How fast the main content appears	2.5 s or less	Over 4 s
Interaction to Next Paint (INP)	How quickly the page responds to taps, clicks and typing	200 ms or less	Over 500 ms
Cumulative Layout Shift (CLS)	How much the layout jumps while loading	0.1 or less	Over 0.25

Google assesses these at the 75th percentile of visits, so most of your visitors need a good experience, not just the fastest ones. INP replaced First Input Delay as a Core Web Vital in March 2024, so older guides that mention FID are out of date.

Why speed test tools disagree

It is normal to get different numbers from different tools. Common reasons include:

• Different simulated devices, network speeds and test locations.
• Lab tests versus real-user data.
• Caching: a first visit is slower than a repeat visit.
• Third-party scripts such as ads, chat widgets and tag managers that load differently each time.
• Personalization, cookie banners and A/B tests changing what loads.

Pick one primary tool for tracking over time, and use the others for diagnosis. When a number looks wrong, open the waterfall chart. It shows every file in the order it loaded, how big it was and how long it took, which usually points straight at the culprit: a huge image, a slow server response or a script that blocks everything behind it.

The fixes that usually matter most

For slow LCP

• Compress and correctly size hero images, and serve WebP or AVIF.
• Do not lazy-load the main above-the-fold image; consider giving it fetchpriority="high".
• Improve server response time with caching, a CDN and better hosting.
• Reduce render-blocking CSS and fonts.

For poor INP

• Cut unused JavaScript and remove plugins you do not need.
• Break long tasks into smaller pieces and defer non-critical scripts.
• Audit third-party tags and load them after the main content.

For high CLS

• Set width and height on images, videos and embeds.
• Reserve space for ads, banners and cookie notices.
• Use font-display settings and matching fallback fonts to limit text reflow.

Speed is part of a wider technical picture. If you are planning a redesign or platform move, our SEO website migration checklist shows how to protect performance and rankings during the switch, and our guide to how search engines really work explains where page experience fits.

When to get help

Some fixes are quick wins: compressing images, removing an unused plugin or enabling caching. Others, such as reworking a theme's JavaScript, restructuring templates or moving hosting, need a developer. If your field data stays in the "needs improvement" or "poor" range after the basics, Pro Pixel's bug fixing and optimization service can profile your site and fix the root causes. Faster pages also support our search engine optimization work, since search visibility and user experience go hand in hand.

Frequently asked questions