Web Vitals: Delighting Google and your Users

May 13, 2020

Last week, Google introduced a new program called Web Vitals. As web.dev describes it, “Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential in delivering a great user experience on the web.” With this, Google is simplifying the clutter of metrics found in various tools and putting the ones most essential for a quality user experience front and centre. These metrics are called Core Web Vitals.

The d-word

2000 or so years ago, an architect named Vitruvius wrote a famous line in his treatise, De architecture, often translated as “Well building hath three conditions: firmness, commodity, and delight.” Delight has persisted as a design concept to the present day. There is debate, of course, over its importance and what it even means. Some see it as referring to finishing touches or “a cherry on top.” When delight is viewed this way, it can become associated with superficial embellishments and attract criticism, like in John Pavlus’s article “‘Delightful’ Interaction Design Needs To Die.”

To make a distinction between embellishments and a more holistic view of delight, Therese Fessenden differentiates superficial delight and deep delight in her article “A Theory of User Delight: Why Usability Is the Foundation for Delightful Experiences.” She describes deep delight as being achieved once all user needs are met, including functionality, reliability, usability and pleasurability.

When it comes to the web, Google has embraced the D-word in presenting its opinion of what makes a good user experience. It defines the core foundations of a delightful web experience as:

• Fast
• Integrated
• Reliable
• Engaging

To delight its users, Google needs to be able to reliably guide them towards positive experiences on the web. Considering its role as gatekeeper, site owners would be wise to aim to meet Google’s standards. However, there are a lot of tools and metrics to measure the quality of a web experience, and it can be hard to know what’s most important.

So, what are the Core Web Vitals?

Google has established three Core Web Vitals (for now). They seem to be focused on the Fast and Reliable elements of the delightful web experience recipe.

LCP - largest contentful paint

• Measures loading performance
• Recommended: <2.5 seconds
• Measured in the lab or the field

Largest Contentful Paint (LCP) measures perceived load speed. Web pages tend to load in bits and pieces, and the LCP occurs when the image, video or text block that takes up the most visible space appears. This metric is considered important because when this largest piece loads, it’s likely that the page’s main content has loaded and it’s assumed that the page is now useful to the user. Although it may take more time for additional smaller elements to appear, having the main elements load quickly creates the perception of a fast load speed.

FID - first input delay

• Measures interactivity
• Recommended: <100 milliseconds
• Measured in the field

First Input Delay (FID) measures load responsiveness. It’s how long the web browser takes to respond to the first input a user attempts on an interactive element on the page—typically this would be click or a tap. Imagine the frustration of trying to click the “Buy” button for concert tickets the second they go live only to have to wait for ads to load in before you can continue. Once a user can see something on the page, they assume they can interact with it without delay. A high FID is confusing and frustrating. A low FID helps ensure the page is usable.

CLS - cumulative layout shift

• Measures visual stability
• Recommended: A CLS score <0.1
• Measured in the lab or the field

Cumulative Layout Shift (CLS) measures the stability of page content. Imagine reading a paragraph of text as other elements on the page continue to load in, and the block of text jumps down, and you lose your place. Have you ever gone to tap a button and some unseen force compels an ad to appear and moves the button immediately before your tap? Let’s just say it’s not delightful. Every time a layout shift happens that isn’t the result of user input, a layout shift score is calculated.

The layout shift score is determined by multiplying two fractions. One is the total portion of the user’s viewport that was affected by the element shift, and the other is the portion of the user’s viewport that represents the distance that the shifted element moved. All of these scores are added together to form the CLS score for a page.

What is lab measurement?

Lab measurement refers to running automated tests in a simulated environment. These tests are impacted by the performance and network connectivity of the machine running the tests, so they don’t always match up with the results seen in the real world. Lab tests are most useful during the development process to get performance metrics before launching a new site, or a change to an existing site.

How to run lab tests

Lighthouse is a tool that can be used from the command line to run lab performance audits on a site. It can be configured to be automatically run regularly to detect changes to performance over time and can also be integrated into a site’s continuous integration process to catch performance issues that might be introduced by launching a new feature or bug fix.

Lighthouse audits can also be run directly in the Google Chrome browser’s DevTools:

1. Navigate to the page you would like to test in Chrome.
2. Open DevTools by opening the Chrome menu in the browser window, selecting the option “More Tools,” and then selecting “Developer Tools.”
3. Select the “Audits” tab.
4. Click “Generate report.”

LCP and CLS metrics are available in Lighthouse. As FID is based on real-world user inputs, it cannot be measured in the lab. There is, however, a lab metric called Total Blocking Time (TBT) that can be used as a proxy. When TBT improves, generally FID will improve.

What is field measurement?

Google states that the Core Web Vitals are first and foremost field metrics. Field measurement refers to collecting performance data from actual users of a site. The Chrome User Experience Report collects anonymized data from users of Google’s Chrome browser who have consented to share their statistics.

How to measure field data

Chrome User Experience Report data is provided on Google BigQuery. Anyone can access this, but it requires a Google Cloud Platform account and is geared towards technical users. PageSpeed Insights provides a basic summary based on this data publicly, without requiring an account or technical knowledge. The Speed Report in Search Console also provides some of this information in a user-friendly way, and with more granular, detailed data than PageSpeed Insights. Search Console is only accessible to site owners who have verified their site ownership.

The Chrome User Experience Report includes LCP, FID and CLS data. Both PageSpeed Insights and Search Console include FID, with LCP and CLS coming soon. To get more valuable, specific information to help solve performance issues, sites can also collect these metrics using JavaScript. The logic can be written manually, but Google provides a library called web-vitals to make it easier.

This data can be stored however and wherever the site owner wishes. It can be paired with existing analytics, so when diagnosing issues, developers have access to important context. For example, it would allow you to analyze which pages the performance issues affect, whether the issue is only impacting a subset of users (such as logged-in users) and which devices and web browsers are associated with issues.

Why is this important?

When a site starts loading, the clock is already ticking. For example, in a study of select eCommerce sites, the bounce rates (users who view a single page and left) were compared to how long the sites took to load. At a load time of 3 seconds, the bounce rate was 11%. For 4 seconds, it was 24%. For 5 seconds, it was 38%. Users have high expectations of speed and reliability. A low LCP will give users the perception that the website is loading quickly and will help keep them around. It’s pretty easy to see how FID and CLS are important metrics too. Nobody likes to be frustrated by unexpected delays or trying to chase buttons around the page.

Google is always tweaking its web search ranking logic, and its first announcement regarding using site speed as part of its formula came back in 2010. The emphasis that Google is now placing on these Core Web Vitals signals that these metrics are very likely to form part of its ranking algorithm now, or in the future. So, it might be a good idea to have a look at how you’re doing in these areas. Google even has a Chrome Extension in developer preview to show these three metrics for any site you visit.

Paying attention to Core Web Vitals will help drive more people to your site and, if you play your cards right, provide them with deep delight once they get there.

August 20, 2020 update:

Google will begin to identify pages that have consistently met or exceeded the recommended measurements for the Core Web Vitals in future versions of the Chrome browser, starting as an experimental feature that can be enabled in Chrome 85 Beta on Android. Pages that meet the criteria will be identified with a new “Fast page” label, with a checkmark icon. This announcement further demonstrates the importance for site owners to monitor and improve their Core Web Vital scores.

When little checkmarks are up for grabs, you know things are getting serious.