The Truth About Website Speed Tests: Do You Really Need a Perfect Score?
We all know that website speed is crucial in delivering a great user experience and driving conversions. But when it comes to measuring your site‘s speed, it‘s easy to get fixated on chasing the elusive perfect 100 score in tools like Google PageSpeed Insights or Lighthouse.
However, a perfect score is often unrealistic, unnecessary, and doesn‘t tell the full story of how fast your site actually feels to users. Let‘s uncover the truth behind speed test scores and what really matters for your website‘s performance.
How Website Speed Tests Work
First, it‘s important to understand how popular speed testing tools actually measure your site‘s performance. Most tools like PageSpeed Insights, GTmetrix, WebPageTest, and Pingdom use synthetic testing, also known as lab data, to evaluate your pages.
With synthetic testing, the tool simulates a page load in a controlled environment and measures various performance metrics. This is done by:
-
Configuring a test agent with a specific device, browser, and network connection. For example, PageSpeed Insights uses a mid-tier mobile device on a slow 4G connection.
-
Sending a request to load the target webpage from one of the tool‘s servers, which is often the one closest to the tool‘s data center location (e.g. US East).
-
Measuring how long it takes for the page to load and tracking key milestones in the page load process, such as when content starts rendering and when the page becomes interactive.
-
Generating a report with performance metrics like Time to First Byte (TTFB), First Contentful Paint (FCP), Speed Index, Time to Interactive (TTI), and Total Blocking Time (TBT).
-
Calculating a performance score between 0-100 based on how the page performs against predefined speed thresholds. For example, PageSpeed Insights uses Lighthouse‘s scoring algorithm.
Here‘s a simplified visualization of the synthetic testing process:
[Diagram of a browser icon sending a request to a server icon, which responds with the website assets that are measured and scored by the testing tool]While this process provides a standardized and repeatable way to test website speed, the controlled environment is not always representative of real-world conditions or what actual users experience.
The Limitations of Synthetic Speed Test Scores
The biggest issue with relying on synthetic speed test scores is that they often don‘t reflect real user experiences. The performance data comes from a simulated environment that likely doesn‘t match the devices, network conditions, and locations of your actual users.
For example, if most of your traffic comes from mobile users in the US on newer 4G/5G devices, a test from PageSpeed Insights (which uses a mid-tier phone on slow 4G) will likely report slower speeds than what your real users experience.
There‘s often a gap between lab data and field data (real-user measurements). According to the 2021 Web Almanac by HTTP Archive, the median Largest Contentful Paint (LCP) from lab tests was 3 seconds slower than real user data:
| Metric | Lab Data | Field Data |
|---|---|---|
| LCP | 4.6s | 1.6s |
Source: Web Almanac 2021 – Performance
Clearly, synthetic test results can be overly pessimistic compared to reality. In addition, speed test scores are inconsistent and can fluctuate based on factors like:
- The testing tool used (e.g. PageSpeed Insights vs. WebPageTest)
- Test server location (e.g. US East vs. Europe)
- Time of day the test is run
- Number of tests run (e.g. a single test vs median of 3+ runs)
- Site hosting performance during test
For example, running PageSpeed Insights multiple times on the same page might produce dramatically different scores:
[Chart showing fluctuations in PageSpeed Insights scores over multiple tests of the same page URL]Chasing a specific speed score is often an exercise in futility because of this variability. A good score is directionally correct but obsessing over a few points distracts from what really matters – user experience.
Why a Perfect Speed Score Isn‘t Necessary
The fact is, the vast majority of websites don‘t have a perfect 100 score and probably never will. According to the 2021 Web Almanac, only 6% of websites got a "good" score in Lighthouse and less than 0.2% achieved a perfect score.
[Pie chart showing 6% of sites with good Lighthouse scores]Source: Web Almanac 2021 – Performance
Perfect scores are incredibly difficult and often not worth the immense effort required, especially for sites with lots of images, videos, third-party scripts, or dynamic functionality. Chasing a perfect score inevitably leads to diminishing returns.
More importantly, a perfect lab score doesn‘t guarantee a fast experience for real users. For example, the popular news site BBC.com got a dismal PageSpeed Insights score of 25 on mobile. Yet, its 75th percentile LCP from real user data (RUM) is a very respectable 2.5 seconds.
[Comparison of BBC homepage with low 25 PageSpeed Insights score but fast 2.5s 75th percentile LCP from CrUX report]Sources: PageSpeed Insights, CrUX Report
The key insight is that your users don‘t care about your PageSpeed score – they just want your site to be fast for them. Meeting most user expectations is more important than acing a lab test.
Focus on Real User Metrics Instead
A better approach to measuring and improving website speed is to focus on Real User Monitoring (RUM). RUM captures performance data from actual visitors as they interact with your site in the wild.
This field data is much more representative of what your users are actually experiencing across a range of devices, browsers, networks, and locations. It includes important metrics like:
- First Input Delay (FID): The time from when a user first interacts with your site (i.e. clicks a button) to the time when the browser is actually able to respond to that interaction.
- Cumulative Layout Shift (CLS): The unexpected shifting of web page elements while the page is still downloading. A low CLS helps ensure a good user experience.
- Largest Contentful Paint (LCP): The render time of the largest image or text block visible within the viewport. A good user experience is an LCP occurring within the first 2.5 seconds of the page starting to load.
Together with FID and CLS, LCP is one of Google‘s Core Web Vitals – a set of user-centric metrics that quantify key aspects of user experience.
Tracking Core Web Vitals from RUM tools like Google‘s CrUX dashboard, Search Console, or other RUM platforms is the best way to assess how well your site performs for real users.
For example, here‘s a CrUX dashboard showing the distribution of LCP experiences on a website:
[CrUX Dashboard image showing LCP percentiles for a site‘s url]Source: Chrome UX Report
You can see the percentage of "good", "needs improvement", and "poor" LCP experiences, as well as key percentiles like the 75th (2.5s). This aligns with Google‘s official guidance that sites should strive to have a "good" LCP for at least 75% of page visits.
Tracking RUM puts the focus on continuously improving actual user experiences rather than chasing an arbitrary lab score. Of course, synthetic tests still have a role to play, but more as a diagnostic tool to identify and fix performance issues.
Practical Tips to Improve Website Speed
Ultimately, the goal should be to optimize your site to be as fast as necessary, not as fast as possible at all costs. A reasonably fast site with a good experience will beat a blazing fast site with a subpar experience every time.
Here are some practical tips to improve your site‘s performance and deliver better experiences for users:
-
Use a fast, reliable web host with a content delivery network (CDN). This ensures fast server response times (TTFB) and geographically closer content delivery.
-
Optimize your content for faster loads:
- Properly size and compress images
- Minify JavaScript, CSS and HTML
- Use lazy-loading for offscreen images/video
- Optimize web fonts and icon libraries
- Minimize use of large, blocking third-party scripts
-
Implement caching at the server/CDN level and optimize your backend application code and database queries to reduce server processing times.
-
Prioritize content and resources that are visible in the initial viewport with techniques like critical CSS, preloading key resources, and deferring non-critical scripts.
-
Monitor RUM and Core Web Vitals to identify pages that are underperforming for real users and use synthetic tests to diagnose specific issues and test optimizations.
Remember, these optimizations are meant to create better experiences for your users – not just chase a number in a speed testing tool.
The Truth About Perfect Scores
Synthetic speed test scores can be useful for measuring performance in a lab environment, but they don‘t always reflect how your site performs for real users. Obsessing over a perfect 100 score often leads to diminishing returns and ignores what really matters – user experience.
Ultimately, your users don‘t care about what score your site gets in PageSpeed Insights or Lighthouse. They only care about their perceived experience in terms of how quickly your site loads and becomes interactive for them.
Instead of striving for a meaningless perfect score, invest your efforts in monitoring and optimizing for Core Web Vitals and other RUM metrics that quantify what actual users are experiencing. Use tools like CrUX Dashboard, Google Search Console, and your favorite RUM platform to track field data.
Continuously testing, iterating, and deploying site optimizations that make the experience better and faster for your users is what really moves the needle on website performance. Leave the vanity of perfect speed scores behind.
