What Are Google Core Web Vitals (and How to Improve Them)?

In the middle of 2020, Google announced that starting in May 2021, Google Core Web Vitals would become a ranking factor in their SERPs (Search Engine Results Page).

Which means if you aren’t familiar with Core Web Vitals, you need to learn about them now. We’ll explain what they are, and how to improve them.

Google Core Web Vitals

Core Web Vitals (which are brand spanking new) are designed to measure the user experience of your site.

They specifically reflect the Load Time (LCP), Speed (FID), and Visual Stability (CLS) of a web page.

The Googe Core Web Vitals are:

Largest Contentful Paint (LCP)

This is how long it takes to have a page’s largest image or text content to load. Ideally, this load time metric would be under 1 second for your pages, but getting under 2.5 Seconds should be your minimum goal.

First Input Delay (FID)

This is how long it takes for your website page to become interactive. Meaning a user can click or scroll on your page. Ideally this number should be under 100ms.

Cumulative Layout Shift (CLS)

This measures the amount of unexpected layout changes of your visual page content. Ideally this number should be under 0.1.

Largest Contentful Paint (LCP)

Measuring Your Page Load Times

If you haven’t tested your site using Google Page Speed Insights, then you definitely should. It can point out your blind spots, and what you need to do to fix items.

LCP is a measurement of how long it takes your slowest element to load when a new user comes to your website.

It measures the load times for the following elements:

<img> elements

Fairly straightforward, these are any images on your website.

<image> elements inside an <svg> element

This one is a bit more technical, but if you create an SVG (Scalable Vector Graphics) that includes an image within it, that will also be included in the testing.

<video> elements (the poster image is used)

If you are hosting your videos via a third party (which you should absolutely be doing) this is referring to the “Poster Image”. Basically the image shown while the video is downloading, or until the user hits the play button.

An element with a background image loaded via the url() function (as opposed to a CSS gradient)

Any background images you’re using, even if they are hosted on another server/website.

Block-level elements containing text nodes or other inline-level text elements children.

Basically the text on your website. It can be more complicated than that, but usually it isn’t.

How do I improve my Largest Contentful Paint score?

There are a couple of things you can do to improve your score. Some you can do for free, some have some costs associated with them.

We’ll walk you through how to fix the most common issues we see, but Google’s tool will provide a list of the specific issues you need to address.

1 – Optimize Your Images

9 times out of 10, your largest piece of content is going to be an image.

If you’ve run your website through the Google Testing Tool, it will display what the Largest Element is for both Desktop and Mobile under “Diagnostics”:

Thankfully, this is one of the easiest things to fix, and you can do it for free!

There are two ways to fix this issue.

The first method is to manually optimize your images. This is what we recommend to all our clients, and what we do for every website we build.

Google has created a free tool, called Squoosh. Using this tool you can upload an image you want to use, optimize it with various settings (including resizing it as needed), and then download the optimized version of the image.

Squoosh allows you complete control over how your image looks, it is not a batch operation. This allows you to fine tune your images so they look great, and take up as little space as possible.

As for target sizes, you should aim to get any full width JPG images around 100-150 KB in size, and any other JPG images under 50 KB.

Some images might need to be bigger in order to not compromise on quality, or you may need to use a PNG which will generally run larger than a JPG image, but they should be the exception rather than the rule.

Keep in mind, if a specific image won’t look good when squooshed down, then you should consider finding a different image to use.

The second option (which we don’t recommend) is using a plugin that will automatically optimize your images for you.

This is a good option if you have a website with thousands of images, and you aren’t interested in optimizing them all one at a time.

There are a lot of plugin options, the two we recommend are Shortpixel and Imagify, although both of them have associated costs depending on how many images you are optimizing.

2 – Setup Page Caching

Page Caching is essentially the practice of storing certain parts of your website (images, etc.) on a website user’s computer, so that when they return to your website, those files don’t have to be resent from your server.

How do you set that up in WordPress? You’ll need to use a plugin.

We generally recommend W3 Total Cache, WP Super Cache or Cache Enabler, but there are other options available.

Just be sure you read through the plugin documentation and make sure you have your settings correctly configured.

And as with any plugin, test, test, test, to make sure there are no issues.

3 – Change Hosting Providers

Website hosting is a whole can of worms, but the simplest way to put it, with website hosting, you get what you pay for.

We understand that the GoDaddy hosting offer of $2.00/month is extremely appealing to a fresh company. However, their hosting service is terribly slow, has many issues, and will lead you to have a low LCP score.

If you are looking to host on a budget, we’d recommend using SiteGround. If you want something better, though a bit pricier, we’d recommend WPEngine or BigScoots.

You’ll want to find a host that is geared specifically for the type of website you have (WordPress websites ideally, but we are biased), but do your research. Ask questions.

And of course, run a Page Speed Insights test on your old server, and then run it again once the site has been moved to see where things have improved for you.

4 – Use a Content Delivery Network (CDN)

A Content Delivery Network (CDN) is a series of servers owned by a CDN Company that are spread out across the globe. As a site owner, you pay a CDN Company a fee to use that network of servers to send site users specific pieces of your website content.

So imagine your website has a large company photo that is 250 KB, and your hosting company is using servers based out of New Zealand (thanks a lot globalization!)

If a visitor to your website in Texas wants to load that image, their browser has to send that request to the website server in New Zealand, then your server has to send the image back to their computer in Texas.

Obviously this is a simplified explanation, but it’s basically how it works. The sheer physics of that information traveling from a server across the globe can cause delays in load times.

But if you are using a reputable CDN, they will have a server with your website images located near Texas, near Italy, near Australia, near Hawaii, etc.

Your site will then trigger the asset load from the CDN server nearest the user instead of your website server in New Zealand.

CDN Costs are variable, and depend on how much data you are transferring per month. Expect to pay around $0.15 per GB of data transferred this way.

Depending on how many assets your website loads, this can dramatically increase your site load times and improve your LCP Score.

First Input Delay (FID)

Measuring Your Website Speed

Alright, we’re getting into the thick of it now. Most of these recommendations on how to improve your First Input Delay will require you to know how to code.

Specifically, you’ll need to know Javascript, and be able to identify and resolve issues with how your website is coded.

If you don’t know Javascript, worry not, you can easily find someone to help with this task (not coincidentally, it’s something we can help out with).

But let’s walk through some of the common things that you can address to improve your FID score:

1 – Reduce or Optimize the Javascript You’re Using

There are many ways in which you can reduce or eliminate unneeded javascript on your pages.

You can defer unused JavaScript, or minimize unused polyfills.

For example, if you are using a plugin that adds some really cool functionality which you are using on only one page, but the plugin loads that code on every page, blocking that plugin from loading on those other pages will reduce your Javascript load.

With WordPress being an open source software, there are literally tens of thousands of WordPress themes and plugins created by a vast array of coders.

While this is amazing, it does also open you up to the risk of a theme or plugin being inefficiently coded. If your FID score is really bad, you may need to have a company do an audit of your plugins and theme.

Depending on the findings, you may need to switch what plugins you are using, or maybe even the website theme.

2 – Breakup Your Javascript

Alright, assuming you’ve now audited your site, and reduced as much of your unnecessary Javascript as possible, you may want to consider breaking up your longer running Javascript tasks into smaller, asynchronous tasks.

A long task in Javascript is anything that blocks the main thread for more than 50 ms. Generally speaking, if a long task exists, your Javascript is probably bloated.

Splitting up any long tasks you have will definitely improve your FID Score. But again, this will unfortunately require some coding expertise.

3 – Optimize Your Pages

There are some common issues we see on individual pages, that are relatively simple to fix:

1. JavaScript size bloat, heavy execution times and inefficient chunking. Try using Progressive Loading for your code and features.
2. Minimize your website’s reliance on cascading data fetches.
3. Minimize how much website data needs to be post-processed .
4. Reduce the number of Third Party tags and analytics you use on your site.
5. If you do use Third Party tags, identify which ones you can have load on demand (for example if you use ads on your site, delay the load of those ads if they are embedded below the fold of your site).
6. Prioritize your script loads. Sometimes Third Party scripts can pre-empt and delay first party scripts, which can delay your site being interaction-ready. Prioritize your code to load what will be the most valueable to your website users.

4 – Use a Web Worker

Frequently, the main cause of a poor FID score is a blocked main thread. In laymans terms, a Javascript script which is preventing the rest of the site from loading until it has fully executed.

By using the Web Workers, you can convert many of these scripts to run in the background, in particular if they don’t impact the UI (User Interface), which will improve your FID.

Some libraries you can consider using are:

• Comlink
• Workway
• Workerize

Cumulative Layout Shift (CLS)

Measuring Your Page’s Usability

“Oh my gosh, I was going to click on that, and it moved!”

Has that ever happened to you? It’s the endless frustration of mobile website users.

You begin reading a page, and suddenly the text drops to the middle of your phone, then jumps back up, then an advertisement appears right where you were going to click that “read more” button.

Here are the most common causes of this issue, and how to fix them:

1 – Images Without Dimensions

Always remember to include both the width and height size attributes for all of your images. Or, if you prefer, make sure you reserve the space the image needs with CSS aspect ratio boxes.

With the advent of responsive design, website coders began to eliminate the width and height attributes. Instead, sites would use CSS to resize the images instead, to fit whatever sized screen the website is being displayed on.

Whichever method you use, make sure that you are following the current best practices recommended by Google.

2 – Ads, embeds, and iframes without dimensions

Advertisements are probably the largest contributor to a low CLS score. Most Ad Networks/Publishers support dynamic ad sizes.

The Ad Size can have a direct impact on the revenue generated, since you’re able to optimize how effectively those ads are seen on different devices.

The downside is this can lead to a terrible user experience. When ads load late in the page rendering process, it can push the visible content on the site further down the page.

There are lot’s of moments during the ad lifecycle that can inadvertantely cause a layout shift:

• When the ad container is inserted into the DOM
• When the site resizes the ad container responsively
• The ad tag library can resize the ad container when it loads
• When the ad fills the container, which can cause it to resize if the final ad has a different size.

There are a couple of simple things you can do to account for these variables:

1. Make sure you statistically reserve space for your ad slots. Meaning, style the element before the ad tag library loads.
2. If your ads are interspersed in your content, reserve the slot size in your layouts. That way the layouts won’t shift if they’re loaded off-screen.
3. Be careful when placing non-sticky ads at the top of your page. When an ad shifts the content from the top of your page, the more content is moved, and the worse your CLS score will be. If you instead inject the ad into the middle of the content, less is moved, and the impact is smaller.
4. Make sure your reserved spaces don’t collapse if no ad is returned. You can do this by showing a placeholder.
5. If you’re unsure how big the ad space will be, simply reserve the largest possible size for the ad slot. It risks having some additional blank space if a smaller ad is served, but will lower your CLS score.
6. Choose the most likely size for any particular ad slot based on historical data for that position.

Embeds and iFrames present another set of challenges. These can include YouTube videos, Google Maps, Social Media Posts, etc.

Sometimes these kinds of embeds don’t know how large the content will be (for example, will a tweet include text, images, or both).

This, in turn, means there is not enough space reserved, which can cause layout shifts when they finally do load.

Similar to ad slots, you can minimize your layout shifts by reserving sufficient space for embeds with a placeholder/fallback.

3 – Dynamically injected content

The core principle here is to avoid inserting new content above any existing content, unless it is in response to a user interaction.

This often happens when banners or forms shift the rest of the pages content. A well meaning call to action; “Sign up for our newsletter!” or “Related Posts” can push your layouts around.

If you need to display dynamic content, make sure you reserve space in advance using placeholder or a skeleton framework, so when it does load it will not cause content to shift.

4 – Web Fonts causing FOIT/FOUT

Rendering web fonts can force your layouts to shift if your site is swapping the fallback font with a new font (Flash of Unstyled Text – FOUT) or invisible text being displayed until the new font is rendered (Flash of Invisible Text – FOIT).

You can minimize these issues by using a Font Loading API, or by using font-disaply CSS to modify the rendering behavior of custom fonts.

Testing Is Key

Phew! That was a lot. As you can see, the Google Core Web Vitals are… complicated.

But with the newest Algorithm change, Google is really focused on providing the best User Experience possible, in addition ot the best information available, to their users.

Make sure you test, and retest, and retest again regularly. As Google continues to update their requirements, and as web coding techniques evolve, you can’t afford to fall behind the curve.

If you take the steps we outlined above, you should be well on your way to having great scores. If you still need help, reach out, we’re happy to answer any questions you might have!