June 11, 2020 (Updated: April 9, 2021)
There are dozens of speed metrics we can track. Each one of them has different characteristics and portrays various factors of user experience. Because of the abundance of metrics, sometimes it’s difficult to know which ones are critical to track, no matter the context.
For this exact reason, Google has launched the Web Vitals initiative, pointing to a subset of metrics that should always be tracked. These metrics are called Core Web Vitals. While introducing new naming nomenclature might not seem like much, having consistent, clear advice on what to track and why is extremely valuable. That fact, combined with using Core Web Vitals to establish site ranking and grade user experience, makes Vitals essential.
In this article, you will learn what Core Web Vitals are, why are they important and how to track them.
Core Web Vitals is a set of metrics portraying three aspects of user experience: loading, interactivity and visual stability. Everyone should track these metrics.
Currently, Core Web Vitals set consists of:
The reason why First Input Delay only exists in one set is that it cannot be measured in a lab setting—there is no user input to be quantified. In those cases, Total Blocking Time is the recommended replacement. If you improve TBT in lab results (lab testing), FID is likely to be improved in real user monitoring (field testing). Make sure to use the right set of metrics for the suitable method of testing.
Bear in mind that in the future, the Core Web Vitals metric set might change. Since Core Web Vitals’ announcement, we have also already seen numerous improvements to the metric calculation. Those changes resulted in an observable difference in measurements for some sites and applications. To keep track of Core Web Vitals definition improvements, check the Chrome Speed Changelog.
Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time belong to the new generation of speed metrics that allow for successfully quantifying user experience to a degree we were not able to measure before. Each one of those metrics corresponds to the three facets of user experience mentioned above:
Additionally, with the new Lighthouse 6 scoring algorithm, all Core Web Vitals contribute to calculating the Performance Score. Their importance is not insignificant: LCP, TBT and CLS make up 55% of the score.
Mobile site speed is already used to rank sites within the Google’s search engine, and starting May 2021, Core Web Vitals measurements will be used to determine which pages are promoted to Google’s Top Stories. The metrics are embedded not only as a ranking factor but also a way of favouring sites with measurably better user experience. Now, your site speed is closely related to how you rank.
It’s going to be very hard to escape the repercussions of poor Core Web Vitals measurements (and low Performance Score). If we want to rank higher and have our content highlighted in Google search platforms, we must care about speed.
Last but not least, having very unambiguous guidance on which metrics are essential to monitor will be indispensable knowledge to both teams embarking on their speed journey and those that are seasoned in speed monitoring. In the abundance of information and advice, precise requirements are beneficial.
Most performance metrics have recommended ranges which constitute good user experience. Unfortunately, more often than not, these values are hard to find. Below, we share the desired Core Web Vitals readings for best user experience and avoidance of losing ranking:
|Metric||Good Measurement||Poor Measurement|
|Largest Contentful Paint||≤ 2.5s||> 4s|
|Cumulative Layout Shift||≤ 0.1||> 0.25|
|Total Blocking Time||≤ 300ms||> 600ms|
|First Input Delay||≤ 100ms||> 300ms|
To make sure Core Web Vitals stay within the range, we strongly recommend using performance budgets and monitoring before releasing to production. The earlier we spot changes and regressions, the faster we can prevent them from reaching potential and existing customers.
Unfortunately, it’s not easy to understand and mimic Google’s ranking algorithm. Core Web Vitals for ranking purposes are collected by the Google Chrome browser directly from its users. After the speed data is fully anonymised, it’s made available through the Chrome User Experience Report (CrUX).
CrUX doesn’t come without a handful of limitations:
This means that Google has not indexed your site in the report, so you won’t be able to see Core Web Vitals field data used for ranking. Additionally, the monthly publishing cadence makes it challenging to quickly react to potential speed regressions or observe wins as they happen. That’s why it’s critical to use continuous speed monitoring.
While Core Web Vitals contribute to ranking through measurements collected with CrUX, tracking those metrics in other lab and field tools is still beneficial. Maintaining fast measurements will translate to better experience and ranking.
Core Web Vitals are now available in most of free speed tooling such as Lighthouse, PageSpeed Insights, Chrome User Experience Report, Search Console’s Core Web Vitals report, Chrome Developer Tools and the Web Vitals Extension. These tools might be useful for one-off testing, but not when compared to continuous data from other services (comparing monitoring reports from various sources is a common mistake in tracking speed).
Calibre exposes all Core Vitals Metrics, which means you can visualise them on time-series charts, set budgets (pictured above), receive email speed reports and Slack alerts about all of them.
To be effective in improving speed and user experience, we need to observe trends over time, which is why continuous monitoring will be essential for success. Make sure to add Core Web Vitals to your speed monitoring today!
We will send you the latest site speed articles, tools, case studies and more, so you can become a better speed advocate.