Guide to Core Web Vitals
Core Web Vitals, or just Web Vitals, are a new set of performance metrics that help highlight aspects of web page development that affect User Experience (UX): page loading, interactivity, and visual stability. Google is set to make Core Web Vitals ranking factors as part of the Page Experience Update some time in 2021.
The metrics center on when certain events complete, including what is interactive or visually affected as these events take place while pages load until a point of stability relative to user experience. That means score values can change as users interact with your page. You achieve better scores when events occur faster along stop-watch time intervals.
Performance metrics for each Web Vital statistic is graded according to three outcomes:
- Good (passes)
- Needs Improvement
- Fail
The current metrics are:
- Largest Contentful Paint (LCP). The time interval between the start of a page load to when the largest image or text block in a user’s viewport is fully rendered. You might see the score change as your page loads and when content is visible but the largest node is still in the backlog yet to be displayed, which gets more noticeable on throttled connection speeds.
- First Input Delay (FID). The amount of time it takes for a page to be ready for user interactivity, meaning that as pages are assembling how long does it take for the page to respond to clicks, scrolls, or keyboard input processing their corresponding event handlers. User interaction can be significantly delayed by main thread-blocking script tasks.
- Cumulative Layout Shift (CLS). The measured distance and fraction of the viewport which shifts due to DOM manipulation or the lack of dimension attributes for major media elements. When we fail to define the dimensions for our hero images, for example, text on our pages first appears only to disruptively get displaced, causing a major content layout “shift” for our users.
Long-time users of PageSpeed Insights (PSI) may be familiar with similar metrics, many of which are going to stick around, but maybe not all of them will. Core Web Vitals represent a culmination of these other metrics and come out of the Developer Experience complexity with them. The simplicity of Web Vitals are meant to cut through the noise for welcomed clarity and fewer, grander metrics to follow.
Google plans to limit updates to annual Web Vitals version releases in order to prevent the goal posts from moving too frequently for site developers and SEOs. But expect Google to add new metrics over time. It looks like the next addition is going to measure page animations, but that metric is under development and won’t be introduced this year, for example.
How to analyze mobile and desktop Web Vitals scores
You get independent Web Vitals scores between mobile (phone) devices or desktop / laptop. In some tools you can specify which device category for running a query or test, and you can switch between them when both are available in a tool like Google PageSpeed Insights. PageSpeed Insights defaults to mobile stats, so you’ll need to switch to the desktop tab in order to see the difference in a page’s scores.
Google has added Core Web Vitals metrics to Search Console reporting when Chrome User Experience data is available. If you’re accessing Web Vitals scores within Search Console then the dashboard displays both device categories with scores across URLs covered by your indexing. You can drill down into groups of pages that are indicated as having problems.
Google exposes field data from over 18 million websites that have tallied enough stats to report Web Vitals as part of its Chrome User Experience Report (CrUX). The data is housed at Google’s BigQuery service where you can query historical stats from these websites going back several years. Updates are ongoing and available the second Tuesday of each month following the accumulated stats.
In order to see mobile and desktop scores using the new CrUX report, you’ll need ‘phone’ or ‘desktop’ as device form factors in your SQL statements. Interestingly, ‘mobile’ doesn’t work and ‘tablet’ works only rarely for the scarcity of the specified data. Google is sticking with a phone, tablet, or desktop form factor device classification in these data.
Tablet data can be seen in queries for the Google origin (domain), for example, but you aren’t going to see it for sites that are much less busy.
Understanding lab vs. field data
Conditions can result in wildly varying scores, and scores can literally change as you navigate pages. It’s important to understand how each score is tabulated, given a certain environment.
You can only truly interpret results after you first determine whether you’re looking at lab or field data. Web Vitals “lab” data are collected via browser API as part of page load event timers and mathematical approximations simulating user interactivity, whereas “field” data is made up of the same metrics collected from actual user experiences navigating your pages by transmitting those event timer values to a repository.
Lab data. Both SEO practitioners and developers can access lab data in real-time using PSI, WebPageTest, Chrome Dev Tools, and through a new ‘Web Vitals’ Chrome browser extension. PSI and WebPageTest tallies your scores from page load events and approximates page interactivity delays by counting up thread-blocking script task timings.
Lab data tools are incredibly useful in your workflow for reporting and ultimately improving scores. These should make up part of your TechSEO arsenal. For developers, if only a handful of templates power your website, then these lab data may be all that you regularly need unless you start seeing problems in field data catching you off-guard.
You can introduce the Web Vitals JavaScript library to your workflow and testing pipeline. Available via CDN, the library (less than 1k) can be included in production HTML and written to transmit independently gathered field data to where you want to collate them for reports. Example code demonstrates how to do so for transmitting scores to Google Analytics.
Lighthouse also comes with various access points which can be useful in your development workflow and it includes several additional tests that can help ensure your adherence to modern web standards. Lighthouse can help you debug situations where you are troubleshooting Web Vitals problems.
Comparing lab results with field data. Modern browsers beginning with Chrome measure how users actually experience your website in the wild via builtin JavaScript APIs. You can access these with plain old JavaScript, or choose one of Google’s libraries modified to suit your requirements. Google collects and, as noted, exposes field data from Chrome users with its CrUX report using the same browser APIs.
There are a few different ways to access or visualize CrUX data. You can utilize connectors from BigQuery output to other Google services for generating dashboards, such as a prebuilt connector for DataStudio.
It’s easier to access CrUX field data by verifying ownership of your website with Google Search Console where the dashboard displays it in an interface which allows you to drill down by clicking instead of having to write SQL queries.
Alternatively, you can simply use PSI which provides you data going back 28 days if they’ve got it. The API which drives that spot check recency report also has an independent open source JavaScript library that you can use to bring the data into your project. It serves as a standalone library where, for demonstration purposes, a developer already created a slick frontend app for it.
Troubleshooting Web Vitals reporting
Due to the dynamic nature of some of the timings, and how they’re collected, you’re always going to need to verify lab data with correlating field data and debug discrepancies. For example, subsequent page loads can vary your result values when using the Web Vitals Extension.
This can happen for a couple of reasons.
Your browser is able to assemble resources faster on refresh by virtue of utilizing its own cache reserve. Additionally, the extension is able to accumulate interactive values as you navigate the page in a way that is useful for approximating real-world field data rather than calculating a score by adding up thread-blocking script task timings.
For more accurate local results using the Web Vitals Extension and Chrome Dev Tools remember to empty your cache data or bypass it with shift-refresh when moving fast with the web browser in your workflow. Another tip is to load ‘about:blank’ before starting a performance recording session in Dev Tools for a clean start to the report.
Ideally, lab and field scores don’t differ too much without a good reason. Whenever you make significant changes, your lab results are going to be ahead of your field data. That means if you see failing tests in the field, and you’ve improved lab scores to pass, you either need to be patient for field data to catch up or push field data independently to Analytics to verify it.
You might imagine the trickiest field data score to emulate locally would be CLS. This isn’t necessarily the case. You can set an option to stick an overlay of Web Vitals using the Chrome Extension where when you interact with the page you can watch score changes as you navigate.
This works for FID as well. The FID score starts empty. Once with the first page interaction (click, scroll, or keyboard input) the timings of thread-blocking tasks are added to that moment which becomes your score.
Finally, the highly detailed information in Chrome Dev Tools lets you troubleshoot CLS to a fine-grained level with performance recording and playback. Look for the “Experience” section that outputs CLS shifts in the recording. There is also a setting for highlighting shifts in the display using a blue flash that wraps elements as they shift and add to your score.
Tool time
PageSpeed Insights. Your first stop measuring Web Vitals should be PageSpeed Insights. You get both lab data and field data (when available) in one report. You also get several other metrics largely related to improving failing pages, particularly findings that affect the speed of a page and downloading its assets.
Web Vitals Chrome Extension. Using the Chrome extension you can access Web Vitals on page load, and as discussed, you can interact with the page to troubleshoot in case you have First Input Delay and or Content Layout Shift problems. It’s also available to you page-to-page as you browse websites.
WebPageTest. Using this independent testing tool you can configure your approach with a variety of conditions. Built by Google engineers who are part of the Chromium team, the information is as authoritative as anything you get from Google itself and makes RESTful APIs available.
Google Search Console. If you haven’t already verified ownership of your website to use Google Search Console, then you should go and do so for help drilling down into problem areas with pages that are failing out in the field assuming you are showing in CrUX. You can drill down to locate groups of pages with similar problems, ultimately it links you to PageSpeed Insights.
Web Vitals JavaScript APIs. Use JavaScript to access the metrics directly from the browser and transmit them to a repository of your choice. Alternatively, you can introduce the test to your development process and ensure that changes you make aren’t going to negatively affect your scores after you push to production.
Chrome Dev Tools. Chrome itself provides the ultimate set of tools for discovering or tracing back problems using the highly detailed information available in reports and page load recordings in the Performance tab. The extensive array of tools and endless switches or options is ideal for the most exacting optimization work.
About The Author
