Understanding Core Web Vitals 2021

An Introduction to Core Web Vitals

In May of 2021, Google will make changes to the Page Experience Ranking Algorithm. This update will be called Core Web Vitals. This means Top Stories will no longer require pages to be built with AMP HTML, and there will be three additional page performance metrics that will factor in Search Engine Optimization rankings.

These performance metrics are:

PageSpeed Insights example
  • Cumulative Layout Shift – Stability
    • The total of all unexpected layout shifts that occurs while a page loads.
    • You need a score of .1 or less to receive a Good rating.
  • Largest Contentful Paint – Load Times
    • A replacement for page load time, this measures actual website rendering performance.
    • Your load times need to be 2.5 seconds or faster to receive a Good rating here.
  • First Input Delay – Interactivity
    • How long it takes for the user’s browser to respond to their input, clicks, or scrolling.
    • Your site needs to be 100 ms or less to receive a Good rating.
Core Web Vitals Measurements

To pass Google’s assessment, you need to reach the minimum value for “Good” on at least 75% of your site’s pages. The “Good” rating for the three new metrics is derived from the 75th percentile of the CRUX dataset.

Passing this assessment will positively affect your Search Engine Page Rank and benefit the user experience of your pages.

To find out how your current site measures up against the Core Web Vitals metrics, you can run your website through PageSpeed Insights. A tool provided by Google that will give an accurate measurement for each of the metrics. While these metrics may change in the future, they have been developed to be a universal measurement of page speed and user experience.

How Google Measures Page Speed

Google collects data via API from Chrome, Chrome on Android, and Chromium Edge. The anonymized data from these browsers are compiled into the Chrome UX Report (CRUX). The CRUX report measures page loads regardless if the site is cached or not. It does not measure soft navigations within single-page applications. This means that single-page applications may be penalized upon the release of the Core Web Vitals update. This makes optimizing the Largest Contentful Paint and Cumulative Layout Shift even more critical for those kinds of sites.

The Page Speed Insight tool will provide three performance metrics:

  1. Field – Any available data from the CRUX report for the URL.
  2. Origin Summary – The aggregated field data for all of your website pages.
  3. Lab – Test results from a Google Server that has applied network throttling.

There is a chance that your page may not have had enough traffic to produce a Field report. If that is the case, you will only receive an Origin Summary.

Recommendations and Diagnostics are derived from the Lab test from Google. If available, performance metrics will be taken from the field results.

Now we will delve into how to diagnose and improve each of these three new Core Web Vitals metrics.

Largest Contentful Paint (LCP)

LCP measures how quickly the largest above the fold element is painted to the screen. Largest Contentful Paint is an alternative to Page Load Time. It is essentially a measurement of everything required for your website content; DNS, TLS, HTML, CSS, and blocking JS. It does not include asynchronous scripts or lazy-loaded content.

Largest Contentful Paint (LCP) example

The Largest Contentful Paint occurs when these three stages have been completed:

  1. HTML delivered and parsed.
  2. Critical Assets downloaded, parsed, and processed.
  3. LCP asset downloaded and rendered (image/video/fonts).

Delivering your site as quickly as possible is the key to improving page speed. Fast delivery comes down to the following key aspects:

  • DNS – Increase TTL (Time to Live) and use a premium DNS hosting service such as Cloudflare or DNS Made Easy instead of using the free nameservers provided by GoDaddy or Namecheap.
  • TCP – Use of a Content Delivery Network (CDN) will reduce the round trip time between the user and your server.
  • TLS – SSL certificates can slow down the delivery time of your site. Ensure that OCSP stapling is enabled on the SSL certificate. You may have to use OV instead of EV certificates to achieve this. You should also configure your CDN to use TLS v 1.3.
  • TTFB – The Time until First Byte is constrained by how fast the hosting server can create a response. The site should be cached in a CDN or reverse proxy to ensure this happens as quickly as possible. Otherwise, your server environment should be able to deliver pages within 100ms.
  • HTML – Enable document compression and make sure documents are under 50kB. Ensure that the <title> tag is first and that there are no <script> tags blocking the page load.

After downloading the HTML, the browser parses the document line by line to find critical path resources. CSS and JS in the head are given priority. Images in the body of the website are downloaded in the order that they appear. If the browser hits a blocking script tag, it will stop parsing and run the script. Due to this, all blocking scripts should be asynchronous or deferred.

When possible to do so, split the JS bundle by page. This will allow the smallest possible bundle to be sent and still use modern technologies. Note that the module has a default defer behavior:

<script type="module" src="script.esm.js"></sript>
<script nomodile src="script.js"></script>

After loading Javascript, the next path is CSS. The browser will block render on <link rel=”stylesheet”> tags. Bundling CSS by page will reduce unnecessary load times. You can also fetch and cache a stylesheet later in the page lifecycle using media=”none”.

<link rel="stylesheet" href="style.css" media="none" onload="this.media='all'">

LCP is measured independently of caching. Static assets such as JS, CSS, images, and fonts should be cached in the browser for at least one hour. These assets should also be compressed via gzip or brotli.

A common issue that occurs, especially in eCommerce, is many non-critical images loading into the page. Native lazy-loading is a great method to optimize LCP. The loading attribute is not yet supported in Safari, but it should be soon. All browsers which send data to CRUX, which does support it:

<img src="menu-img.jpg" alt="..." width="200" height="200" loading="lazy" >
<img src="hero-img.jpg" alt="..." width="1024" height="600" loading="eager" >

Load hero elements using the “eager” attribute and any image below the fold with the “lazy” attribute. This will give loading priority to the important elements and improve both LCP and user experience. In addition to lazy loading, the asses should be delivered as optimized as possible using whatever tools and services are available, like Cloudinary or Akamai Image and Video Manager. A rule of thumb is that a hero image should not be larger than 200kB.

The hero element should not be JavaScript, so image carousels and embedded video players should be replaced with static images and native <video> elements.

First Input Delay

First Input Delay measures how long it takes before the browser can react with user input. This is a direct measurement of how responsive the user interface feels to the user and how much payload is placed on the CPU. The only way to improve FID without degrading the UX of your site is to reduce the time spent executing JavaScript. A possible way to cheat the system here is to hide your content behind a loading screen or spinner. This will most likely negatively affect your LCP and CLS scores, though, so a balance must be achieved if you use this method.

If our goal is to improve FID and improve visual performance, there are only a few options:

  • Delay or remove third-party scripts
  • Defer non-critical scripts
  • Improve JS performance

To discover improvement areas, we need to run a performance test on a critical page to see what is consuming the most thread time. Investigate any large chunks and reduce where possible. Focus on the longest tasks. These are singular blocks of execution that are likely causing high input delays. High self-time can be due to the script itself being slow or the implementation being poor.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures how stable your website’s user interface (UI) feels to the user as they interact with a page. It is a sum of layout shifts during the page lifecycle. For example, when an advertisement’s banner loads on a webpage, it can cause the page’s main content to shift down. Layout shifts cause poor user experiences.

Core Web Vitals CLS Example

A perfect CLS score is 0, but up to .1 is acceptable.

CLS is measured by CRUX from the start of navigation through to when the user exits the page. Each time an unexpected layout shift occurs, it is summed into the CLS. Because this score requires user interaction to some degree, it is hard to measure via Google’s Lab. The Lab will often report the best-case scenario for your site.

Optimizing Cumulative Layout Shift is a matter of preventing layout shifts entirely. Here are the leading causes for layout shifts:

  • Web Fonts
    • The most surefire way to avoid font-based layout shifts is to preload the Webfont and use font-display: optional
  • Ads
    • Use a fallback image for when ads are blocked or fail to load
  • Late-loading CSS
    • Layout critical CSS should be in the critical path for rendering
  • Images
    • Always add a height and width attribute for your images
  • Dynamic Content
    • Pre-allocate layout space

Chrome’s developer tools will highlight elements that caused a layout shift in the performance profile and to what degree they affected your CLS. If you hover your mouse on the layout shift in the experience track, Chrome will highlight the page’s element. You can also set your browser to throttle the page in the Performance tab. This will allow you to witness the layout shifts visually.

Additional Key Metrics for Core Web Vitals

First Contentful Paint (FCP)

First Contentful Paint measures when the first paint of the site occurs. This is how a user knows that their navigation through your site is working.

Time to Interactive (TTI)

TTI is an approximate measure of when a site first feels interactive to the user.

Total Blocking Time (TBT)

TBT is a measure of how much of a workload is placed on the browser’s CPU while trying to load the page—measured by the time between FCP and TTI. Reducing this time will improve user experience and the perceived performance as well.

How to Track Performance

PageSpeed Insights, Lighthouse, and https://web.dev/ all provide measurements of your site’s performance. A dedicated real user measurement solution can also be used to provide more profound and accurate insights into your site’s performance.

Conclusion

The new Core Vitals Update is coming in May of 2021. It will play a large role in being eligible for the Top Stories in Google Search Engine Results Position. Google will use these three new metrics as signals to determine user-perceived performance and page speed.

Optimizing your site for these metrics will positively impact how your site ranks in the future and have an immediate effect on user experience – lowering bounce rate, increasing conversions, and increasing revenue.

Author Bio: Daniel Snell is an employee at Layer0.

Monitor Your App Free for 30 Days

Discover the power of Airbrake by starting a free 30-day trial of Airbrake. Quick sign-up, no credit card required. Get started.