Looking at PageSpeed Insights Web Vitals

Written by

Walter G.

Published on

January 15 2021

Filed under

Performance

I run many different kinds of analysis on this website in order to check for weaknesses and to patch them up whenever possible. One of those is Google's PageSpeed Insights tool, which runs a very quick audit on your websites and then gives you a substantial amount of data back about its overall general performance.

This week, I took my site through the paces once again to test it out. This isn't the first time mind. You can read more about my previous tests in any of the following past articles:

Site optimization with PageSpeed (part 1)
Site optimization with PageSpeed (part 2)
Improving my PageSpeed Insights score

Because I make relatively frequent updates on this site, I tend to shift things around a fair amount. This (sometimes) causes issues with performance and with loading times and so running periodic checks has been hugely beneficial in keeping everything running in good order.

Google offers the Web Vitals initiative in order to help developers get an overall idea as to how their web properties are performing. That is the main area that I will be looking at in this analysis. To find out more about Web Vitals, you can check out the official breakdown right over here.

Here are my latest results:

PageSpeed Insights will give you 2 scores overall, one for your Desktop view and one for your mobile view. Typically, my desktop views tend to do better than my mobile views and that's because Google has certain requirements when it comes to having a 'good' mobile experience. I will only be talking about the desktop score for this article though, as it is the most relevant I think.

An 81 is not overall great. But it isn't terrible either. So let's take a look at what didn't fly.

Let's start off by looking at how various loading times affected the score. These are referred to as Web Vitals and are essentially a measure of quality signals that notify developers how their websites are performing from a user experience perspective.

While not terrible, there are ways to improve these numbers even further. Most will likely have to do with reducing image sizes, removing blocking scripts and perhaps removing a few animations in the process.

First Content Paint (FCP)

The FCP metric is a good indicator as to how your websites are behaving at load times. Pretty much, the server response times. From the looks of it, only 9% of the content on my homepage loaded in under 1s, which is considered the ideal time.

62% of the content took from 1s to 3s, which is the area that could use improvement. 29% of the content on the page, took over 3 seconds, which Insights flags as 'bad'. This is the area that I will most likely tackle first in addressing the performance issue. It's much easier to go from 'bad' to 'okay' as opposed to 'okay' to 'great'.

To further clarify, this is the time from when the page first starts to load, to when the first pixels begin to appear on the page. If you have too much heavy content at the top of your page for example (large images), this could definitely lower your overall score.

The same would go if you are loading resources from the web that need to be downloaded first and then rendered. In my case, there are a few things that could cause this. I have a relatively heavy background-image in the hero and I use a FontAwesome icons on top as well. (You can read more about FontAwesome here).

Largest Contentful Paint (LCP)

The LCP is a measure of performance on the main content of your website. Which traditionally has been a hard metric to capture, mainly due to various web design choices that people make. LCP in this case measures the render time of the largest image or text block in the visible viewport.

Currently, there are only a few elements that are taken into account when coming up with this score, those being:

<img> elements
<image> elements
<video> elements
An element loaded with a background image
Block level elements containing text blocks

47% of my large content loaded within a reasonable time frame, but that's still far from ideal. I will probably be looking at ways to reduce overall file size in order to improve this score.

First Input Delay (FID)

The FID measures the time from when the user first performs some form of input event on the page, such as clicking on a button or a link, to the time when the browser is able to begin to execute event handlers.

Essentially, the page loads, the user clicks on a button, how long before that's possible after page load for that button to trigger an event, is the measure.

If you load your event handlers and content appropriately, then this should not be an issue. The main reason why I scored a 99% in this area though, is because I don't have too much JavaScript getting triggered on the homepage.

There is a large hero area on top, a news feed right below it and a collections list below that. And all of that content gets rendered on the server, which means that by the time you see it, it's already fully loaded.

In order to have a 'good' score here, it is expected that content load in under 100ms. Anything above 300ms would be considered 'bad'.

Cumulative Layout Shift (CLS)

The CLS measures visual stability. Essentially, how much does your content move (or shift) when loading.

To give an example, some websites might have content loaded dynamically through an AJAX call on page load, which might 'shift' other content downwards some amount. If that content has a large load time, then a user might not realize it and maybe attempt to click on a button, only to have it shift down at the last second.

My score was not the greatest in this regard. And while I can't tell quite off the bat what is causing the issue, I have a feeling that it is likely due to the animation library fades in certain elements on load.

PageSpeed Insights expects a load time of under .1s in order to be ideal.

Web Vitals

The web is complex. There are images, files, audio, video, etc loading from all over the place and coalescing into what you call a website. Take into account that people from all over the world can look at 1 single page from their own browser and you can see where the issues start to spring up.

The Web Vitals initiative isn't concrete just yet. I have personally seen it change many times throughout the years, and that's because websites have changed throughout the years as well. In 2012 we did not have high-res photos and dynamic font-loading.

So while we have more tools to play with these days, it's still important to make sure that everything is functioning well under the hood.

Comments

No messages posted yet

Add comment