Two pages can score identically on a website speed test and perform completely differently for real visitors. Running a speed test is straightforward. Reading the results correctly, understanding which numbers matter, what they are actually measuring, and where to look for real-world data rather than simulated scores, is where most people get stuck. This article covers how to run a website speed test, what each metric in the results means, why simulated scores and real visitor scores often differ, and how to use the results to make improvements that actually affect the people visiting your site.
A speed test is most useful when you know what to do with the output. A single score out of 100 tells you very little on its own. The individual metrics behind that score, and whether they come from a simulation or from real visitors, determine whether the results reflect what your visitors actually experience. For background on what the metrics measure, see the article on what page load time is and how it is measured.
What does a website speed test actually measure?
A speed test loads a page in a controlled environment and records how long specific parts of the loading process take. The tool measures things like how quickly the server responds, when the first content appears on screen, when the largest visible element finishes loading, how much the layout shifts during loading, and how long before the page responds to clicks. These measurements are then compared against standard thresholds to produce a score and flag areas for improvement.
Lab data versus field data
- Lab data: produced by a speed testing tool. The page is loaded from a fixed location using a simulated device and connection. Results are controlled and repeatable, but they do not reflect the full range of real visitor conditions
- Field data: collected from real visitors, aggregated over a rolling 28-day window. This is the data search engines use for Core Web Vitals scoring and ranking purposes
- A site can score 90 in a lab test and still have poor Core Web Vitals field data if real visitors are on slower devices, unstable connections, or geographically far from the server
- Always check both. Lab data is useful for diagnosing specific issues. Field data is what determines real-world and search ranking impact
How do you run a website speed test correctly?
Test on mobile first
- Search engines use mobile-first indexing, meaning they evaluate pages based on their mobile performance
- Mobile scores are almost always lower than desktop scores for the same page because mobile devices use slower processors and more variable connections
- Run both mobile and desktop tests, but treat the mobile result as your primary measure
Test your most visited pages, not just the homepage
- The homepage is often the fastest page on a site because it tends to have fewer images and scripts than interior pages
- Product pages, blog posts, and landing pages often score significantly worse and may have more impact on visitor experience and rankings
- Test the pages that receive the most traffic, not the ones most likely to look good
Run each test more than once
- Lab test results can vary between runs because of server load at the moment of testing, network conditions at the test location, and caching state
- Run each test two or three times and use the average as your baseline rather than relying on a single result
Test before and after making changes
- Establish a baseline score before making any changes to your site
- Run the same test after each improvement to measure its specific impact
- For field data, allow at least 28 days after changes before assessing the impact, since the data is a rolling 28-day average that updates gradually
How do you read a website speed test result?
Start with the failing metrics, not the overall score
- An overall score of 65 does not tell you what to fix. The individual metrics that are failing do
- Look at which Core Web Vitals are in the needs improvement or poor range: LCP, INP, and CLS
- Each failing metric points to a different part of the page or loading process to investigate
What each failing metric points to
- High Time to First Byte: server response is slow. Investigate hosting quality, server-side caching, and database performance
- Slow Largest Contentful Paint: the main visible element is taking too long to load. Typically caused by unoptimized images, _blocked_-blocking resources, or slow server response
- High Total Blocking Time or poor Interaction to Next Paint: JavaScript is blocking the main thread. Large script files and third-party scripts are common causes
- High Cumulative Layout Shift: elements are shifting position as the page loads. Caused by images without defined dimensions, late-loading content inserted above existing elements, or dynamically added banners
Reading the recommendations
- Speed testing tools list specific recommendations alongside an estimated time saving for each fix
- Address the recommendations with the largest estimated savings first for maximum impact per effort
- Some recommendations relate to third-party scripts or services outside your direct control. Note them but focus on what you can change
What are good website speed test scores?
Core Web Vitals thresholds
- Largest Contentful Paint under 2.5 seconds: good
- Interaction to Next Paint under 200 milliseconds: good
- Cumulative Layout Shift under 0.1: good
Overall score ranges
- 90 to 100: good
- 50 to 89: needs improvement
- 0 to 49: poor
How to use benchmarks practically
- These are absolute benchmarks, but your score needs to be better than the pages competing with you for the same keywords, not just above a generic threshold
- Search for your target keyword and run speed tests on the pages ranking above you. If your LCP is 3.2 seconds and theirs is 2.1 seconds, that gap is more actionable than a score difference in isolation
For a detailed breakdown of what LCP, INP, and CLS measure and how they are scored, see the article on what Core Web Vitals are.
How do you track website speed over time?
Set a baseline before you start optimizing
- Record your current scores for the pages you plan to improve before making any changes
- Note which metrics are failing and by how much
- After each round of changes, run the tests again and compare against the baseline to measure real improvement
Check field data regularly, not just after changes
- Field data in performance reports updates on a rolling 28-day window
- Check it monthly, or after any significant change to content, code, or hosting
- A drop in field data scores often coincides with a new large image being added, a new third-party script being installed, or a change in hosting configuration
Test after publishing new content
- A new blog post with unoptimized images can slow down that page significantly without affecting others
- A new landing page with heavy scripts can introduce blocking issues that a baseline test of the homepage would never reveal
- Building speed testing into the content publishing process prevents regressions from accumulating unnoticed
For a complete guide on the most impactful improvements to make based on your test results, see the article on how to reduce your website loading time. For guidance on image-related failures specifically, see the article on how to optimize images for faster loading.
How WEMASY supports website speed testing
WEMASY's analytics dashboard includes Core Web Vitals data for all pages built on the platform, drawn from real visitor field data. LCP, INP, and CLS scores are visible per page without needing to run external tests. Pages that fall below the good threshold are flagged with the specific metric that is failing, so you can go directly to the issue rather than reading through a full report.
Because the platform handles image compression, caching, minification, and CDN delivery automatically, the most common causes flagged by external speed tests are already addressed. Speed testing a WEMASY-built site typically surfaces content-specific issues rather than platform-level ones, which makes the results easier to act on.
See what is included at the WEMASY website builder, or review plan options on the pricing page.
Frequently asked questions
How do I test my website speed?
Enter your website URL into a speed testing tool. The tool loads your page under controlled conditions and produces scores for each loading metric across mobile and desktop. Look at the individual metric scores alongside the overall score — the failing metrics tell you where to focus. For real-world performance data based on actual visitors, check your website's performance or analytics dashboard if it includes Core Web Vitals field data. With WEMASY's website builder, you can set this up directly on your website.
What is a good website speed score?
A score of 90 or above is considered good, 50 to 89 needs improvement, and below 50 is poor. For Core Web Vitals specifically, the targets are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. A page passes the Core Web Vitals assessment only when all three metrics are in the good range based on real visitor field data.
Why does my speed test score vary between runs?
Lab test scores vary because conditions change between runs: server load at the moment of testing, network conditions at the test provider's location, and caching state all affect the result. Running the test multiple times and averaging the results gives a more reliable baseline. Field data, drawn from 28 days of real visitor measurements, is more stable and is the better indicator of consistent performance for ranking purposes.
Why is my mobile speed score lower than my desktop score?
Mobile speed tests simulate slower processors and mobile network connections, which produce lower scores for the same page compared to desktop. Search engines use mobile-first indexing, meaning the mobile performance of a page is what matters for rankings. Treat the mobile score as the primary result to optimize for, even if the desktop score looks acceptable.
What is the difference between lab data and field data in a speed test?
Lab data comes from a simulated test run under controlled conditions from a fixed location and device. It is consistent and useful for diagnosing specific issues. Field data comes from real visitors, aggregated over a rolling 28-day window, and reflects the full range of devices, connections, and locations your actual visitors use. Search engines use field data for Core Web Vitals scoring. A site can score well in a lab test and still have poor field data if real-world conditions for visitors differ significantly from the test environment.
How often should I run a website speed test?
Run a speed test after any significant change to your website: adding large images, installing new scripts, changing hosting, or publishing a new page type. For routine monitoring, reviewing field data from your analytics or performance dashboard monthly is sufficient. Field data updates on a rolling 28-day window, so frequent manual testing is not necessary, but monthly reviews help catch regressions before they affect rankings or visitor experience.