In May of 2020, Google announced that Core Web Vitals would become an official ranking measure in 2021. This introduced special focus on Page Experience, or the signals that measure how a user perceives the experience of interacting with your website.
We don’t want to dive into what Core Web Vitals are, or the specifics of each measurement. If that’s what you are interested in, we recommend any of the following articles:
Instead, we want to focus on LCP. Specifically issues we’re seeing, improvements customers are making, and where Content Delivery Networks (CDN) can help.
Of the three core metrics (LCP, FID, CLS) for Core Web Vitals, LCP is the one metric where a CDN can have the most impact. Things like FID and CLS are highly dependent on the application, and in some instances, devices capabilities and configurations.
At it’s core, LCP is really measuring performance. How fast before the user can have an enjoyable experience on the site.
In the networking world, we used to speak using terms like Time to First Byte (TTFB) or Time to Connection, Total Time To Load (TTL). Time and time, however, we would realize there was a big disconnect, and strong debates, around the merit of these values for users and who they were really serving.
The introduction of LCP is designed to change this, and really flips the debate on it’s head. LCP measures when the page becomes useful to the user, or when the main content on the screen has likely loaded.
Put simply, it’s typically when the biggest piece of content loads (i.e., image or text). This is important, because if you look at most modern websites, the biggest piece of content is typically the hero image.
The image above is an example of a hero image. It has two main elements we are mostly familiar with (i.e., an image – the boy, and content – the main callouts).
LCP is looking to see how long it takes to load those two things. We have found that special emphasis is put on images if they exist. This makes sense as LCP is really about reporting back on the total render time of the largest content element, so when images exist it takes precedence.
As we help more customers prepare for the upcoming changes, here are some of the things we have noticed first-hand dramatically affecting low LCP scores:
Here are some of the things that have been helping customers tackle their LCP problem:
Optimize images. Optimize images. Optimize images. If your website has a hero with an image, you better ensure that it’s optimized. This should stand true for all the images you’re serving, but definitely on your main pages. In other words, you don’t need a high-resolution image designed for 8k as your hero image.
Introduce Height and Width elements to your image tags to help the browser reserve space.
This one is kind of funny as we moved away from this practice with CSS and became very comfortable using “absolutes” but with the new focus on Page Experiences there is special attention being placed to image dimensions.
You do this by adding these options. It is important because it helps the browser reserve space, reducing shifting in the layout (i.e., CLS).
<img width="400" height="400">
Load images according to what is needed by the platform making the request. You can do this by leveraging srcset in your image tags.
<img srscet="noc-600w.jpg 600w, noc-1000w.jpg 1000w">
This helps the browser quickly identify which images to load at which resolutions.
I’ll be honest, this is not a world I spend a lot of time in, but it’s definitely something they are searching for. I was completely ignorant to the fact that there were “modern” image formats, and I bet many others are as well.
|JPEG 2000||by the JPEG group, the oldest of the JPEG successors, available in Safari|
|WebP||by Google, available in all browsers|
|AVIF||by the Alliance for Open Media (AOM), available in Chrome and Firefox|
|HEIC||by the MPEG group, based on HEVC and available in iOS|
|JPEG XL||by the Alliance for Open Media (AOM), available in Chrome and Firefox|
|WebP2||by Google, an experimental successor to WebP|
The team at cloudinary shared a really good table showing the different compressions and their impacts:
The TLDR; version is that every script and stylesheet introduces a delay in the rendering process. So every time your site loads a third-party script or stylesheet it introduces what is known as a render-blocking resources.
This is especially true for CMS platforms that are reliant on a theme / plugin ecosystem. A lot of themes and plugins will load non-critical resources unbeknownst to the website owner.
The team at web.dev provide a great resource on how to think about render-blocking scripts, and the folks at Namehero give a great tutorial on how to do this inline without a plugin.
Optimizing your LCP is going to require a bit more work, but CDN’s can definitely help. They help by improving the time it takes to respond to the users request.
CDN’s improve the LCP by working to solve the slower response times, and cutting down the initial time to connect and deliver content. They do this by leveraging the edge and getting your content closer to the user (reducing the roundtrip time for each request).
If I’m in San Diego, and make a request to your site, if it’s hosted in Virginia the request has to travel a lot farther than if it was on the West Coast. If the CDN has a node in Los Angeles, the travel time is dramatically shorter. While the time to travel contributes to improving your overall performance, it won’t solve it entirely but it is critical to beginning the process.
A very simple way to think of it is in terms of your browser. The longer it takes your browser to get a response, the longer it takes to start the rendering process. There is no sense doing any of the above, if your responses are slow.
The exact gain to your LCP is going to be wholly dependent on the type of site you have. The changes are supposed to start with mobile but we should all assume it’ll carry over to desktop in short order. Have fun optimizing!