Site loading speed (website performance — English) is the time that passes from the moment the browser starts processing your site to the moment the site is fully loaded.
It seems that everything is simple, but not quite. And here’s why.
How to measure site speed
Previously, the main metric of site loading was load event . It showed when the entire page had finished loading, including related resources such as images or style sheets.
Download completion is an important metric, but it doesn’t tell you anything about how the download process went.
However, the user will rate the first site as faster. Because he could see the image or text on the screen even before it was fully loaded. On the second site, he could only wait, watching the white background.
A site that allows a visitor to interact with it without delay will be considered faster. Not the best option when the site is fully loaded, but the user is forced to wait a few seconds before being able to scroll the page.
Download metrics are user-centric
To take into account all the nuances of speed, Google presented User-Centric Performance Metrics.
As the name suggests, they focus not only on page loading, but also on how a specific user sees this loading.
In short, Google divided page loading into several stages:
- How quickly the user sees the first elements of the page to understand that the download has already started.
- How quickly the user sees the main content of the page so that he can start familiarizing himself with it.
- How long the user has to wait before being able to interact with the site.
- Are there sudden changes in page elements during loading.
Now Google takes into account all these metrics together with the standard load event.
List of main metrics:
| TTFB (Time to First Byte) | Time to First Byte shows how long it takes the user’s browser to retrieve the first byte of page content. |
| FCP (First Contentful Paint) | Measures the time from when the page is loaded until any part of the page’s content is displayed on the screen. |
| LCP (Largest Contentful Paint) | Display time of the largest image or text block visible on the screen. |
| CLS (Cumulative Layout Shift) | Total layout displacement measures the total sum of all displacements that occurred during the entire page load or view time. |
| FID (First Input Delay) | Measures the time from the first interaction with the page (clicking on a link, button, or using a custom JavaScript-based control) to the moment when the browser can start processing a response to that interaction. |
| TBT (Total Blocking Time) | The total blocking time is the time during which Long Tasks (tasks lasting more than 50 ms) block the main thread and affect the usability of the page. It shows how long a page remains unresponsive before it becomes fully interactive. TBT measures what happens between FCP and TTI. |
| TTI (Time To Interactive) | Time to interaction shows how long it takes for a page to become fully interactive. It is measured in seconds. |
| Speed Index | Speed index. Shows how quickly the content is visually displayed when the page loads. |
| INP (Interaction to Next Paint) | Tracks the latency of all user interactions with the page. A low INP indicates that the page responded quickly to user requests. |
Google has separated the most important metrics — LCP, FID, CLS — into a separate group. It is called “Core Web Vitals”. The main focus of marketers revolves around this group. But in my opinion, other metrics should not be ignored because they work in synergy.
You can see how complex the process works in the Lighthouse calculator .
Monitoring Core Web Vitals and other metrics
When you are faced with the task of regularly monitoring your site’s loading speed, the first thing that comes to mind is Google PageSpeed Insights or Lighthouse data. But later it becomes clear that this is not the best option. Because in reality PageSpeed does not show the speed of the site to the users.
For example: a website has good loading speed indicators for PC, but the mobile version is not optimized in the best way. At first glance, we should spend a lot of time to change this. However, our site is a cloud service that is mainly used by users from desktop computers. That is, the absolute majority of users get a positive interaction experience and consider the site to be fast. Google will see a similar situation because they track real user data, not PageSpeed Insights data.
Lab and Field data
Lab data is data generated by a one-time check of a single URL by a single device. That is, it is an emulation of the loading of your page by the PageSpeed Insights service or another similar monitoring service.
Field (field) data — shows the real experience of interaction of users of your site.
While some of the metrics mentioned above are only measured in the Lab (TBT, TTI, and Speed index), others (LCP, FCP, CLS, etc.) can be measured in the Field.
How to measure site speed?
It is best to combine both methods. Lab for development, troubleshooting and basic testing, Field — for monitoring the real situation.
Lab data measurement services
- WebPageTest is one of the best Lab test tools in my opinion.
- The Pagespeed insights report is a standard tool from Google that uses Lighthouse and includes some data from the Chrome UX report.
- Lighthouse is a standard tool for Google Chrome.
- GTMetrix is a website monitoring tool.
All tools have their advantages and disadvantages.
Advantages:
- you can track data for individual URLs;
- it is possible to measure the performance of pages on test websites to check the difference between versions before and after deployment;
- you can get tips on how to improve performance.
Disadvantages:
- it is impossible to track groups of pages or the data of the entire website;
- the advice provided by the services often contradicts each other or does not directly affect the metrics;
- numbers can lead to misinterpretation, as in the example with optimized and non-optimized rendering.
Field data
Chrome UX report
Chrome UX reports are created using a free template provided by the Chrome team and contain data about websites from the Chrome database.
An example of such a report is the CrUX report
Benefits of Chrome UX reports:
- access to real user data based on metrics that can be measured in the field;
- review of historical data for half a year;
- quick creation of a report based on a template.
Disadvantages of Chrome UX reports:
- individual URLs or groups of pages cannot be tracked. Only the entire domain;
- provide only monthly data, without the possibility of daily viewing;
- reports are updated only once a month (on the 2nd Tuesday of the month).
Events in Google Analytics
Using the Web Vitals library, you can configure sending data about Pagespeed metrics through the browser API and send them to Google Analytics or another source.
Advantages:
- constant monitoring can be set up;
- you can track individual URLs, groups of pages or the entire website;
- data can be viewed for different periods — day, month, week, etc.;
- reports can be used to create dashboards by device type, country and any other metric;
- reports can be used to segment and analyze events with good or bad performance.
Disadvantages:
- required development or implementation through GTM ;
- many GA events are generated, so sending all metrics data is not recommended;
- default events show mostly average values, so not very informative.
Read also about the advantages of the Core Web Vitals dashboard and the instructions for creating monitoring through GA4.
