Website speed test tools and how to read the results

Website speed testing is the first step to improving user experience and SEO, but many site owners, after running a few tests, are faced with a pile of numbers and charts that are difficult to interpret. The main question is not "how fast is my website?" but rather: "Which number should I trust and which problem should I solve first?" In this article, with a practical look at website speed testing tools, we examine the difference between lab data and field data and provide a clear framework for prioritizing fixes.

Why do website speed tests show different results?

If you test a page several times with different tools, you will likely see different numbers. This difference is natural and stems from two types of data that tools collect: Lab Data and Field Data.

What is Lab Data?

Lab data is obtained by running a test in a controlled and simulated environment. Tools like Lighthouse and GTmetrix run a headless browser with specific hardware specifications and network speed. The result of this test is a definitive number that is repeatable under identical conditions. But the problem is that these conditions differ from the real conditions of your users.

Example: Lighthouse by default assumes a mid-range mobile device (Moto G Power) with a simulated 4G network connection (with 150ms latency). If your users visit with flagship phones and high-speed Wi-Fi, the lab data will be slower than reality, and vice versa.

What is Field Data?

Field data is collected from real user interactions with your site. Google receives this data from the Chrome browser of users who have opened your page and displays it in tools like PageSpeed Insights and Search Console. This data includes a wide range of devices, networks, and geographic locations and is reported as a percentile.

Important note: Field data is only available for pages that have sufficient traffic (usually several thousand visits per month). For new or low-traffic pages, Google has no field data and only shows lab data.

Main website speed testing tools and their uses

Each tool is designed for a specific purpose. Using one tool for everything can lead to erroneous conclusions.

PageSpeed Insights (PSI)

This free Google tool combines lab data (Lighthouse) and field data (CrUX) in a single report. The top section of the report displays field data with the three main Core Web Vitals metrics: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). The bottom section shows lab data with a score from 0 to 100 and optimization opportunities.

Main use of PSI: Checking the overall status and viewing real and simulated data simultaneously.

WebPageTest

This tool is more advanced and allows you to specify the test location, browser type, connection speed, and even the number of repetitions. Its output includes a waterfall of requests, a video of the loading process, and more detailed analyses.

Main use: Examining technical details such as the order of resource loading, the latency of each request, and the impact of third-party scripts.

GTmetrix

This tool is based on Lighthouse but presents the report with a focus on fully loaded time and page size. Its free version has test location limitations, but it is useful for quick checks and comparing before and after changes.

Main use: Comparing different versions of a page or tracking changes after applying optimizations.

Key metrics in website speed testing: Which one to fix first?

After running a test, you are faced with dozens of metrics. Proper prioritization is the difference between a fast website and one full of unoptimized reports.

Prioritize Core Web Vitals metrics

These three metrics directly affect user experience and Google ranking:

• LCP (Largest Contentful Paint): The time it takes to display the largest content element (such as the main image or heading). Target: less than 2.5 seconds.
• INP (Interaction to Next Paint): The response delay to user interactions (clicks, taps). Target: less than 200 milliseconds.
• CLS (Cumulative Layout Shift): The amount of unexpected movement of page elements. Target: less than 0.1.

If field data shows these metrics as "poor," your first priority should be fixing these, not reducing image sizes or compressing CSS files.

Order of fixes based on impact and cost

A suggested framework for prioritization:

1. Image optimization: Convert to WebP or AVIF format, resize to actual display dimensions, use the loading="lazy" attribute for images below the fold. This usually has the greatest impact with the least risk.
2. Eliminate render-blocking JavaScript: Load scripts that load before the main render with the defer or async attribute. Delay third-party scripts (such as live chat or analytics tools) until after the page has fully loaded.
3. Enable browser caching and server-side caching: Set the Cache-Control header for static resources. Example for image files on an Nginx server:

location ~* \.(jpg|jpeg|png|webp|svg)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

1. Use a CDN: If your users are in different parts of Iran, a domestic CDN can noticeably reduce network latency. This is especially effective for static files and images.
2. Font optimization: Use the WOFF2 format and only load the required weights. Enable the font-display: swap property so text is displayed with a fallback font and then replaced with the main font.

Common mistakes in interpreting website speed test results

Many site owners see an improvement in the lab score after optimization, but the field data does not change. This happens for specific reasons:

Mistake one: Chasing a score of 100 in Lighthouse

The Lighthouse score is a composite indicator, and reaching 100 does not mean real speed. Sometimes removing an analytics script (such as Google Analytics) increases the score by 10 points but does not change field data, because that script loads asynchronously and has no noticeable impact on LCP. Instead of chasing the score, focus on Core Web Vitals metrics.

Mistake two: Ignoring the difference between lab data and field data

Suppose lab data shows LCP at 1.8 seconds, but field data shows 4.2 seconds. This discrepancy usually means the problem is on the server side or network, not in the front-end code. Common reasons:

• The server slows down during peak traffic (server resource issue).
• User connections to the server pass through congested routes.
• Images and files are loaded from the origin server rather than a CDN.

In this case, optimizing CSS and JavaScript code will not help. You need to examine the infrastructure: upgrading server resources, using server-side caching (such as Redis or Varnish), or moving to a better quality host.

Mistake three: Testing from only one geographic location

If your website has users across Iran, testing from one location (e.g., Tehran) does not give a complete picture. Use tools like WebPageTest and run tests from several different cities (e.g., Tehran, Mashhad, Ahvaz). The network latency difference between cities can be several hundred milliseconds, which directly affects LCP.

A real scenario: From report to action

Suppose the PageSpeed Insights report for your homepage shows these results:

• Field data: LCP = 3.8 seconds (poor), INP = 180ms (good), CLS = 0.05 (good)
• Lab data: Score 45, suggested opportunities: "Reduce unused JavaScript" and "Serve images in next-gen formats"

What is your priority? According to the framework above:

1. First, examine the images. The hero image is likely loaded in PNG format with a size of 2 MB. Converting to WebP with 80% quality and resizing to 1200px can improve LCP by 1 to 1.5 seconds.
2. Examine third-party scripts. If you have a live chat widget that loads before the main content, load it with defer or use conditional loading (only after user interaction).
3. After applying the changes, test again. If lab data improves but field data does not change after 28 days (the CrUX collection period), the problem is infrastructural, and you should examine the server or CDN.

Complementary tools for deeper analysis

In addition to the main tools, several other tools are useful for more detailed analysis:

• Chrome DevTools: The Network tab to view the order of resource loading and the Performance tab to record and analyze page rendering.
• Search Console: The Core Web Vitals report in the "Enhancements" section shows field data by page type (mobile/desktop) and URL grouping.
• Pingdom Tools: To check server response time (TTFB) and identify server-side slowness.

Summary: A practical routine for website speed testing

To make website speed testing a useful habit, we suggest this routine:

1. Every two weeks, check the homepage and 2-3 high-traffic pages with PageSpeed Insights.
2. If field data is available, prioritize improving Core Web Vitals metrics.
3. If field data is not available, use WebPageTest with a test location close to your main users.
4. After each change, run a before and after test and only keep changes that have a positive impact on LCP or INP.
5. Document: test date, metric values, applied changes, and the result. This prevents repeating mistakes.

Remember that website speed is not a one-time project but an ongoing process. With a proper understanding of lab and field data and prioritization based on real impact, you can noticeably improve user experience without wasting time on low-importance items. If your hosting infrastructure creates limitations and upgrading resources or using a CDN is on your agenda, reviewing quality hosting options can be a good starting point.