We’ve migrated our documentation to a new site, which means some URLs have changed.
Subscriptions

Web Core Vitals - New Google Ranking Factor

Overview

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web. It aims to simplify the landscape and help sites focus on the metrics that matter most, the Core Web Vitals.

Starting June 2021, this change is going to affect all regular Google search results, mobile and desktop, based on certain criteria. But also, and this is an important point, Core Web Vitals are going to become criteria to appear in Google Top Stories. These are the news results that usually appear at the top of search results.

Previously, AMP was a requirement to appear in those Top Stories. AMP is going away. So you still have to meet the requirements for regular Google News inclusion, but AMP is not going to be a requirement anymore to appear in Top Stories. But you are going to have to meet a minimum threshold of Core Web Vitals. 

Note: Traditional internet search signals are still very much applicable - keywords, title, link analysis, etc.

The 3 signals for Core Web Vitals

The metrics that makeup Core Web Vitals will evolve over time. The current set focuses on three aspects of the user experience—loadinginteractivity, and visual stability—and includes the following metrics (and their respective thresholds):

  1. Largest contentful paint (LCP)

    This LCP signal looks at "How long it took the largest (usually more meaningful) content (text, image, or video) on the page to render."

    lcp.png

    Common causes for poor LCP:

    • Slow server response times - client’s content server

    • Render-blocking JavaScript and CSS

    • Slow resource load times

    • Client-side rendering

    Piano’s recommendations:

    Optimizing LCP

  2. Cumulative layout shift (CLS)

    This CLS signal looks at "How fast is the page stable? Applies only to above-the-fold (visible area)."

    Least important signal of the 3.

cls.png

Most common causes of high CLS are:

  • Images without dimensions, 

  • Ads, embeds, and iframes without dimensions, 

  • Dynamically injected content, 

  • Web fonts causing FOIT/FOUT (Flash of Invisible Text and Flash of Unstyled Text),

  • Actions waiting for a network response before updating the DOM.

How to improve your CLS:

  • Using font:display values and link rel=preload

  • Including width and height elements for videos and images

  • Wrong implementation of dynamically injected content 

See Google Guide

3. First input delay (FID)

This FID signal looks at "the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction."

fid.png

It is important to note that FID only measures the "delay" in event processing. It does not measure the event processing time itself nor the time it takes the browser to update the UI after running event handlers.

Consider the following timeline of a typical web page load:

Diagram.png

The above visualization shows a page that's making a couple of network requests for resources (most likely CSS and JS files), and—after those resources are finished downloading—they're processed on the main thread.

This results in periods where the main thread is momentarily busy, which is indicated by the beige-colored task blocks.

Consider what would happen if a user tried to interact with the page near the beginning of the longest task:

diagram2.png

Because the input occurs while the browser is in the middle of running a task, it has to wait until the task completes before it can respond to the input. The time it must wait is the FID value for this user on this page.

In this example, the user just happened to interact with the page at the beginning of the main thread's most busy period. If the user had interacted with the page just a moment earlier (during the idle period) the browser could have responded right away. This variance in input delay underscores the importance of looking at the distribution of FID values when reporting on the metric.

Not all users will interact with the site every time they visit.  Not all interactions are relevant to FID. In addition, some user’s first interactions will be at bad times (when the main thread is busy for an extended period of time), and some user’s first interactions will be at good times (when the main thread is completely idle).

FID is a metric that can only be measured in the field, as it requires a real user to interact with your page and thus cannot be measured in the lab. However, the Total Blocking Time (TBT) metric is lab-measurable, correlates well with FID in the field, and also captures issues that affect interactivity. Optimizations that improve TBT in the lab should also improve FID for your users.

You can measure FID with the following tools:

See Google Guide to optimize FID

Summary

LCP - the impact from Piano is limited in our understanding. Most of the implementations are using blurring or other CSS manipulation to render content unreadable. If the content is waiting for a signal from Piano then this metric will be adversely affected.

CLS - The least important of the three from Piano. The metric will be affected when there are inline templates waiting for Piano input above the fold on the page that changes the layout. E.g. banners at the top of the page.

FID - This is probably the metric with the largest link to Piano and will be measured by the time that the templates are loading before they can respond to the first input (click - register, subscribe). In most cases, even if requests made to Piano is “slow” to respond (e.g. due to distance to Piano cluster), the template will not show for the user to be able to interact and as such, FID will not be computed.  We will need to check if it is possible that Piano could contribute to an extended period of time in the JavaScript main thread task.

Overall, as long as the below conditions are met, Piano should not be affecting (specifically) these 3 signals adversely:

  • Content loading is not dependent on the signal from Piano (LCP)

  • The visible layout is not changed due to Piano templates (CLS)

  • No visible call-to-action (register, login, subscribe) are shown when Piano scripts are executing (FID)

Last updated: