Core Web Vitals: Measuring my site's speed in the real world

Google made it very clear to us a long time ago that speed is a crucial factor to be able to appear effectively in your search results: A page that loads faster will rank higher.

But even if we have this certainty, the key rules by which Google measures the speed of a site and its most influential characteristics have always remained in the background. PageSpeed Insights, Google's online tool, was for a long time a measure that we have all used, but the general complaint is that the score it throws up is still a dubious utopia elaborated in its own laboratories, foreign to authentic practicality.

Responding to this relative “thank you” that the community has had regarding PageSpeed Insights, Google has recently launched Core Web Vitals or Main Web Metrics, a tool that, this time, provides specific details about the speed and experience of your website in a plausible, more real context.

Core Web Vitals: what are the new 'web metrics' main' of Google?

With the appearance of these new “Core web metrics” in Google Search Console, the confusion invaded the webmasters since, in a matter of 24 hours, the scores of a site changed their values completely. Indeed, Google changed the very priorities of the metrics, meaning that Core Web Vitals is a different test formula, a renewed algorithm.

To avoid headaches, below we will analyze the strong aspects of the Main Web Metrics and we'll explain how to use (and understand) its metrics to more accurately test your website speed. We will address issues related to user experience, scoring and ranking in SERPs (search results pages). If something is not understood, or you have questions about your specific website, please do not hesitate to contact us at [email protected] or write us in the comments at the end of the analysis.

The 4 Core Web Vitals Measurements

The so-called Core Web Metrics bring together four measurement scores that Google uses to assess the speed of a particular URL. We say URL because any site is made up of multiple URLs, home being only one of them. Each URL, for example www.mysite.com/products/gift-boxes is measured exclusively. It is good to remember this because when we make improvements or tests of site accelerator plugins, we must always test the same URL to be able to measure the differences accurately.

Before we dive into the four measurements, it's worth clarifying that each of them is affected by a distinctive real-world scenario. For example, the speed of a site evaluated in a PC with broadband internet will receive different scores than a site tested with an older cell phone and 3G connection. That said, the double standard of Core Web Vitals must be taken into account: on the one hand, it tests the performance of a site, and on the other, it measures the speed (ability) of any terminal (read PC, Tablet or cell phone) to finish to present our site on the screen (being that in this last point it is not only about the connection speed, but about the type of processor/GPU with which said terminal is equipped).

With you, the 4 measurements that make up the Core Web Metrics score:

As we can see, these measurements all cover one condition exclusive, but the first three focus on the speed with which our site responds to visits. The last one, the CLS metric, is the only one that records how much pivot design during loading and also throughout the entire time a user X navigates through our site.

It is important to note that these tests are based on the assumption that the server is fast, since if the first thing that fails is the hosting service, all the rest of the measurements will be disastrous.

Metrics in depth

FCP: First Render with Content

As we have anticipated, FCP is the time to wait from when the internet browser launches the initial request to a URL and something first appears on the screen. The fundamental idea behind this measurement is that the perception of page load time improves when users can see that the screen is filling up.

Historically, Page Speed Insights gave greater weight to this measurement. This caused many sites to employ so-called place holders (placeholders), a resource that was overused in order to manipulate this score. Example: A gray rectangle appears where an image or video will later be uploaded. But, in the end, it generates the contradiction of having to load something useless delaying the arrival of the real content.

The FCP score is commonly affected by render-blocking objects such as style sheets (CSS) and scripts (JS). When a style class appears on a line of HTML (typically,

), rendering is blocked until that resource is downloaded and parsed so that it can be rendered by browser action. The same thing happens with JavaScripts. For this reason, methods to solve these obstacles are the use of 'lazy loading' or 'asynchronous', that is, queuing the loading of these elements, relegating them to the end.

To improve our FCP score, our site must be able to send the necessary resources to render first what will be visible in the display box. In other words, images in lower portions of the page should load later, or only when the user scrolls vertically across the screen. This is exactly the scenario where you use lazy loading of images and inline styles that apply exclusively to a given page.

LCP: Larger Content Rendering

This new measure counts the time between when the first request for content is launched and subsequently the content fills the screen. Recall that the previous measurement, FCP, times until the appearance of the first element, but LCP waits for the 'whole thing' (always within the visible area of our page in the display frame). Then, LCP awaits the end of the loading of texts, images, video, styles, fonts, etc. For this reason, now that Google has launched this measurement, certain tricks used by administrators to fake the appearance of information (for example, with place holders or additional scripts to enable lazy loading) is now useless or rather counterproductive.

The tips to improve the score given by this measurement are to correctly include the site sources and also ensure that the images of the visible area of the screen are loaded immediately (the latter using the native image tag srcset).

FID: First Interaction Latency

FID measures the time that the user is allowed to interact with the site (for example, scroll down). The counterexample, adverse case, is when we intend to navigate a site with our cell phone and everything seems to freeze, or shifts latently and abruptly, a sign that the processor of our device is not enough.

The causes that slow down or hinder the interaction are: analysis/processing of elements, rendering of bulky or complex CSS, execution of JavaScripts, display of heavy images or video.

On ad-supported sites, JS like ad trackers and servers they are the great cause of FID latencies. If this is not our case, our site may abound in own scripts. That's why, analyzing, discarding or reprogramming our JavaScripts is one of the first measures to take to improve the score of this measurement. The asynchronous loading method for the JS is the most suitable, which in many cases even becomes imperative for the code of Google Analytics.

Here too, the processing power of the device used to navigate is also a radical variable. We already mentioned that the difference between a high-performance PC versus a mobile phone from several generations ago is taken into account. The measure that FID counts is the time, beyond the programming of our site. A decent score on a state-of-the-art laptop is unparalleled in a world where a site is visited by countless devices with different CPU capacities and also different internet connection speeds (wifi, 3G, 4G or 5G). Therefore, as far as possible sites should be thought to be cautious also on mid to low end devices.

CLS: Cumulative Design Change

You will have noticed that, many times, while browsing a site on the cell phone, the eye is reading a text that suddenly changes places. An image loads at once and shifts everything to one side, the other, or down. The information we want to read seems to want to escape our sight. To say the least, it's frustrating. And this is exactly dancing of the elements that CLS measures: layout breaks while the site finishes loading.

The number one cause of these jumps is image downloads, particularly when the image call tag lacks the attributes width Y height, preventing the browser from knowing how much space each image will occupy until it finishes downloading. Therefore, when the image is presented, the information runs somewhere, and when another image appears, it happens again until all the information on the screen is loaded. Horrible.

Many site administrators use the tool PageSpeed Insights and it's respectable, but notice that this tool scores the start of the render only. Therefore, lazy loading of images, invisible to PageSpeed Insights since they load last, does not warn site developers about layout jumps during download.

Therefore, many sites have good scores in the first three metrics, but the user experience is poor and the CLS score is clearly low. The tip here is to clarify the dimensions of all the images that we use, either by direct HTML, with CSS or even in both languages.

Leveraging Vitals web metrics to speed up our site

Before starting, we offer the official link from Google support because it is interesting to take a good look at it (unfortunately, it is not in Spanish).

Having duly described how the four metrics work, it's time to point out the most useful way to take advantage of them in order to work on improving the speed and usability of our site.

we can think of three basic channels order to order our evaluation effectively: on the one hand, there is the 'real field data' that Google obtains from our site, on the other the 'laboratory' data provided by PageSpeed Insights, and finally the 'lab' data of the extension Website Vitals.

The field data they are the statistical synthesis of real world user experience: it is the genuine thing, factual; in other words, what happens on the screen of the PC or mobile device of users across the globe when they enter our site. Needless to say that is decisive for the SEO score of each URL of our site.

Meanwhile, the laboratory data they consist of a measurement taken at a given moment in specific circumstances that might not coincide with the real world. While Google is capable of extracting accurate lab data for a given URL, ultimately it is not possible to determine the intersection with the actual field data and how they benefit (or not). For example, if a developer made efforts that are reflected in the lab data, these improvements will take time to show up in statistics based on real-world measurements (because, logically, real users need to experience those improvements over time). said URL over time, gradually modifying the general statistics).

Let's deepen these three aspects in which we can order the data according to its origin.

Field Data

In any test or measurement of any branch of science, taking field data implies that a person travels (for example to the Amazon) and makes real measurements (of, for example, the humidity of the air) in different locations and at different times of the year. day. Taking 'field data' on a website works with the same logic. We can imagine it as Google 'filming' the individual experiences of users to a site in order to shape this measurement.

We can access the field data that Google makes of our site within Search Consoleexactly on the path Improvements → Main Web Metrics.

PageSpeed Insights will generally show us the field data for the test domain, and if the evaluated URL is 'popular' enough (i.e. frequented enough that Google can reliably measure it), we will also see the field data for that URL. specific URL.

The field data is average performance of the previous 28 days. If we have made significant improvements to our site, the field data issue may show up more quickly, especially if we make a request via Google Search Console.

Examining field data is the only certain way to know the performance of a web page.

Lab data from the PageSpeed Insights tool

PageSpeed Insights is a tool that allows us to quickly check the performance of a URL both in the (simulated) scenario of a mobile device and on a desktop PC. If our page has rendering and speed problems, PageSpeed Insights will notify us.

Luckily, it not only rates us, but also provides suggestions to improve the site in its different problematic contexts. In fact, help updated to integrate exclusive tips from Top Web Metrics. For example, if there is a large, poorly optimized image on the first viewable part of the page on our site, that image is likely to be listed as a problem within FCP (First Render with Content).

Please note that any tests of our site that have passed the tests are not displayed (it is hidden by default). Although veiling that information works to stick exclusively to what we should solve, it is still relevant information. For example, it would not be uncommon for a given URL to have a poor FID (First Interaction Latency) even though it passed all tests. If this is the case, it's worth investigating to note how many URLs narrowly passed (when it comes to improving speed, it all adds up).

We can reveal the successfully passed audits (tests) here: (see orange box towards the bottom of the screenshot).

It is crucial to remember that PageSpeed Insights Tool it cannot effectively measure CLS (Cumulative Layout Change) as it does not interact with the page for more than an instant. If a page alters its layout while downloading, Insights you won't be able to know.

Laboratory Information with the extension for Main Web Metrics

It is possible to quickly check the scores of the Main Metrics of any page that we navigate using a very practical extension that exists only for the Chrome browser: Web Vitals by Addyosmani (Firefox users will regret that it is not available for that browser).

For some brainiacs like us, Web Vitals can come in very handy because places a green or red icon after measuring the load of any site checking if its design is altered or not. In fact, if when scrolling down the site performs a rearrangement of elements, the icon will change from green to red (since it measures the interaction in real time).

We insist to remember that the extension evaluates a website weighing our hardware and also the speed of the internet. If there are problems related to excessive JS scripts or poorly optimized images, with a high-end computer they will not be noticeable, and therefore the extension will not be either.

With DeviceMode, Google allows us (and encourages) us to evaluate our site by simulating slow connections and devices, something very useful in combination with the Web Vital extension since it allows us to automatically check the URLs of our site spontaneously. If we're really willing to put our site to the test, it's worth getting familiar with both resources.

Conclusions

We know that the complexity of site speed is not exhausted in this note, but we are also aware that going even deeper into this topic can give you headaches. The general advice is to read carefully and take advantage of the 'opportunities' that Google tools offer us: every detail of Core Web Vitals o Core Web Metrics stand on a single maxim: Google will reward us when our site is fast and offers excellent usability.

It is worth clarifying that we can assume that the Google team continues to deepen its audit tools, and that even the priorities of the tests and their scores vary. The truth is that the world is becoming more “mobile”, people navigate more and more with cell phones and less and less with laptops or desktop PCs, and therefore the need (and demand) to work on the agile response of our sites becomes increasingly critical.

We invite you to leave your doubts and thoughts in the comments section.

Also remember that at Duplika we solve the problems of usability and speed of the sites through our service of Managed WordPress. We speed up your site, and we fine-tune it by improving all Google audits.

Is your WordPress site not performing as it should? Tired of slowness, bugs, or scaling issues? move in with us free.

Good luck, and thanks for reading.