- Web Applications
How to improve your website's Google ranking by fixing CLS
We're starting a new video series! 🎉. Well or actually one could also say we're continuing our series from before .
I any case! We're working on the Dinghy website a bit more. This time around we're taking a look into our performance scores, which we have not done once actually since we started to work on the website 😅.
Why is website performance important? Link to this headline
It's obvious that we all want websites we look at to load quickly so we can get to what we're looking for quickly. But website performance is more than just that.
There's a long history here and one could probably write books and books about the topic but we'll keep it short and simple for this post today:
Google defined a website's performance from the perspective of the user experience and gave us a couple metrics which make up the overall score of your website. Those metrics together are called the Core Web Vitals :
- LCP: Largest Contentful Paint
- FID: First Input Delay
- CLS: Cumulative Layout Shift
Cumulative Layout Shift – CLS Link to this headline
Today we're taking a closer look at CLS and how we can improve on that one.
To understand what CLS is and why it's something that affects User Experience let's take a look at this video:
We set the network speed to "Fast 3G" and disabled the browser cache (so everything is downloaded from the server as if we were visiting the website for the first time).
See what happens there? The text in the headline is first shown as 3 lines of text and then, a little later, it jumps onto 4 lines.
We did slow down the network, mainly so we can see what's happening but also to illustrate that this is a real issue, and not something that only happens under lab circumstances. A "fast 3G" connection is absolutely something many people use every day. Even in countries that have the advanced mobile networks, you could still be somewhere in the country side or in a subway and are left with a mediocre connection. If so, what you see in the video would happen right on your phone.
Webfonts can cause CLS Link to this headline
So what's happening here exactly?
The server sends the requested HTML document and the browser starts to read through it. In the <head/> of the document it will find a link to the CSS file that contains styles for the page. So it starts to download that one. After that's done, it reads through that CSS file and discovers that the website needs a custom webfont. So after loading the CSS, it starts to download those font files.
Until the browser finishes loading those fonts, it will show all text on the website in another font that's already installed on your computer. In my case that was Helvetica because I'm on Mac which has that installed. On Windows this might have been Arial, for example.
So then as soon as the fonts load, the browser exchanges that font with the new one which is a little wider that Helvetica, and that means in this case the text will jump onto 4 lines.
Let's fix that text jumping! Link to this headline
Thankfully there are two easy things we can do to improve the situation.
Preloading font files Link to this headline
The first recommendation most of those performance test tools have in store for you is to preload your fonts.
So remember how we established earlier that the browser first has to find and download the CSS file, which in turns let's it discover the fonts?
Well now we can take a shortcut to hint the browser at those font files early in the loading process:
<head>
<!-- Other elements in head -->
<link
rel="preload"
href="/fonts/reader-extralight-pro.woff2"
crossorigin="anonymous"
as="font"
type="font/woff2"
/>
<!-- Other elements in head -->
</head>The preload tag enables website authors to do exactly this. You tell it what type of resource it is and where to find it and the browser can start loading that resource as soon as it parses the <head/> of the the document
The font-display property Link to this headline
The way you tell a website that you want a custom font is through the @font-face declaration. In our case this looks like this:
@font-face {
font-family: 'Reader Pro';
src: url('/fonts/reader-extralight-pro.woff2') format('woff2');
font-weight: 100;
}Now additionally to that, we can also influence how to the browser should apply that font. The property to do that is called font-display (get all the details here ).
It has a few different options which I'm not going to cover all in this blog post, but let's look at two specific ones which illustrate the issue at hand pretty well.
One value you could set is font-display: swap;. This one tells the browser to wait for a short while for the font file to load before displaying the text on the website. If the font files don't load in that short period the browser will display text in the next fallback font – in our case Helvetica or Arial. If the font file arrives a short while later, it will swap it out for that new font. Hence the name of the value.
This behavior leads to our Cumulative Layout Shift.
To fix that we decided to opt for font-display: optional;. This one could potentially become a hot topic between web developers and designers because it behaves as follows:
The browser opens a 200ms window for the font files to load before it displays the text. That's a bit longer than swap allows. If the files arrive in that time frame the text will display right away in the correct font.
If the font files don't load in that time, the browser will continue to load the files and will place them in it's cache but will show the text in the fallback font. It will not swap it out, which means that a visitor could be seeing your entire page in the fallback font until they navigate to the next page. Upon navigation the next page will show the right font instantly, because the browser has downloaded those files and placed them in the cache, which makes them available instantly.
Cool, so which one's better? Link to this headline
That question must be answered by every product team individually. We here at Dinghy prioritized the user experience and opted to show the entire page in the fallback font in the case of a slower connection speed.
A few things to keep in mind:
- This only applies to the very first visit of the website since font files will be cached and hence will be available for any subsequent visit instantly
- Preloading only the font files necessary will give them a very good chance to arrive in that 200ms window, which means that the edge case in which a visitor will see your website in the fallback font really only applies to slow connection speeds
- At slow connection speeds your website visitor will thank you for letting them read through your website as soon as possible, instead of making them wait for your font, which you might care about a lot more than they do 😅
Summary Link to this headline
Good performance and good user experience are not only good for your users, they actually impact your SERP (Search Engine Results Page) ranking.
Making sure that your website loads quickly and is useable quickly, even on mediocre connections, it is an absolute must to make your website visitors happy.
Today we looked at Cumulative Layout Shift (CLS) which is one of the 3 Core Web Vitals and we'll look at the others in the next posts.
