Core Web Vitals optimization tips from Chrome Dev Summit 2020

Google dedicated several presentations to Core Web Vitals (CWV) at their virtual 2020 Chrome Dev Summit. They provided details on how CWV are scored, the most common issues that affect the scores, and CSS tips and tricks to improve page scores.

The 2020 Chrome Dev Summit has come and gone. I watched the page experience and CSS presentations live and kept notes for topics I wanted to look into further and share here.

This article covers essential details about how Google approaches Core Web Vitals, and some of the best methods to optimize for it.

Cumulative Layout Shift (CLS) weighting

Not all Core Web Vitals are equal. At least, not yet.

Today Cumulative Layout Shift (CLS) isn’t weighted as heavily as Largest Contentful Paint (LCP) and First Input Delay (FID). However, it will be weighted more equally in Q2 2021.

CLS’s lower weighting is important to know about if you’re deemphasizing or ignoring CLS because it’s not adversely affecting your overall Lighthouse score. If the individual CLS score is outside of the “Good” range in your Lighthouse report, I recommend optimizing it before May 2021 to avoid any unexpected surprises from Google.

Cumulative Layout Shift Score

Images affect CLS the most

The most common issue with CLS are image elements shifting because they don’t have the width and height specified within the img element. When responsive design became a thing, the width and height of an image were removed, and web developers relied on the following CSS to make images responsive.

img { max-width:100%;height:auto; }

The problem with that technique is that the browser doesn’t know what the height is. That results in the page content shifting once the image loads.

Having a fixed width and height is no longer a problem when coupled with the example CSS code. That’s because all major browsers now support aspect ratio. Browsers determine the aspect ratio based on the fixed width and height but rely on the CSS code to make the image the same width as the container.

If you use WordPress, it hardcodes the width and height for all images. So if you use the CSS code example, images shouldn’t shift. However, if you have manually added images – you didn’t use the Image block editor – and they don’t have a height and width, they will need to be updated. Fortunately, WP Rocket just updated its caching plugin to fix that for you automatically.

Image Dimensions in WP Rocket

Ads matter too

Dynamic ads were also called out as a primary cause for layout shifts. The same rules apply for ads as they do for images. Ads will need to have a fixed height from now on, or they will adversely affect the CLS results.

Fixed Placeholder

Render hacking with content-visiblity:auto;

An almost too good to be true rendering performance hack was presented during the Summit. They showed how you could use the content-visibility CSS property to boost rendering speed.

content-visibility enables the user agent to skip an element’s rendering work, including layout and painting, until it is needed. Because rendering is skipped, if a large portion of your content is off-screen, leveraging the content-visibility property makes the initial user load much faster. It also allows for faster interactions with the on-screen content.

I tested out the technique on the Coywolf Reviews CleanMyMac review, which has an excessive amount of autoplay Cloudflare Stream videos on it. It miraculously decreased the Speed Index time from 14.5 seconds to 1.5 seconds. Unfortunately, it also increased the CLS and made the scrollbar shift and become janky.

Lighthouse Scores

To alleviate the scrollbar issue, they recommend using the contain-intrinsic-size CSS property. The property allows you to specify the estimated height for content blocks, but the results still weren’t ideal when I used it.

The technique works best when you can apply it sparingly to large content sections (chunks) below-the-fold. Since every paragraph, list, image, and blockquote is contained within a block on WordPress, it makes creating content chunks below-the-fold virtually impossible. That’s the likely reason why I couldn’t produce acceptable results.

Chunk sections

The technique does have a lot of promise, but mainly for sites that can automatically create sections and estimate the height for each section. That sounds like a WordPress plugin that’s waiting to be made.

Lastly, the technique only works on Chrome (version 85 and higher). As an SEO, as long as it doesn’t break the UX on other browsers, I recommend using Chrome-only CSS if it can improve page experience scores. That’s because Googlebot uses evergreen Chromimium to render pages and its CrUX data comes exclusively from people using Chrome.

Fixing text shifting with @font-face descriptors

Sites with unique fonts should be using font-display:swap; to speed up how fast their pages render. However, one common side effect is that it can make text shift once the font is loaded and swapped with the web font, affecting CLS.

Font metric override properties were recently created to bring visual symmetry to swapped fonts and prevent shifting text. Myles C. Maxfield, says it’s designed to “improve Interoperability across browsers and operating systems, so that the same font always looks the same on the same site, regardless of OS or browser.”

By assigning percentages to the ascent-override, descent-override, and line-gap-override properties, the font metrics can be adjusted to keep text from shifting when it’s swapped.

CSS Font Modifications

While these properties are intended to be interoperable across browsers and operating systems, it currently only works on Chrome 87. As I stated previously, if it only works in Chrome and doesn’t break the UX in other browsers, I recommend implementing it to take advantage of Googlebot using evergreen Chromium.

Collect real user monitoring (RUM) data

It’s one thing to run Lighthouse reports with Chrome Dev Tools or to use the Measure tool on web.dev, but if you want to collect data that will be the most similar to the CrUX data Google will use as a ranking factor, you’ll want to use real user monitoring (RUM). Google published Web Vitals monitoring code on GitHub, and it can be used to collect RUM metrics from visitors to your site.

It uses a tiny 1K library to record the following metrics:

  1. Cumulative Layout Shift (CLS)
  2. First Input Delay (FID)
  3. Larget Contentful Paint (LCP)
  4. First Contentful Paint (FCP)
  5. Time to First Byte (TTFB)

RUM is the best way for development teams to have a clear and accurate understanding of how their sites perform in Web Vitals. It’s something I will be recommending to the developers I work with.

Next steps

I encourage you to consider and test the methods mentioned in this article. If they are too technical, please pass them along to a developer. I continue to believe that Web Vitals will be a bigger deal than most people are expecting.

Related Articles

Jon is the founder of Coywolf and the EIC and the primary author reporting for Coywolf News. He is an industry veteran with over 25 years of digital marketing and internet technologies experience. Follow @henshaw