It goes without saying, having a fast website will improve the customer experience. All your KPIs will be better with a fast website. Okay, enough of motivation - let's get practical.

By the way, I've written this from the perspective of a website that has been developed for some years and has the legacy issues that time simply implies. To those that use modern tools like React and Next.js, this is not for you, but remember - client rendering is expensive!

So you've either taken interest in web performance, or you've been given the task to improve the web performance of your website. Where do you begin?

Start off by running the website through the Google Chrome tool 

. This will give you a bunch of metrics - FCP, LCP and CLS amongst others. Export the result and store it somewhere safe. When you've finished all the steps in this guide, you will run Lighthouse again and find that you're now a certified web performance ninja.

Surprisingly, not everyone loves web performance. It's up to you to make sure that the team around you is engaged in your work. If they don't know and understand what you do, what will happen the day you bid farewell? The website will slowly become slow again. Also, they won't know what a hero you are for making the Internet fast.

Before you begin doing ANY work, you should have a decent way to track metrics over time. You really want to be able to measure the effect of every effort. If you can't make management pay for decent tools like 

. You will forget to use Lighthouse before and after every deploy.

Okay, let the fun part begin. Soon. The goal is reduce the amount of things happening on page load. Practically, this means reduce the amount of things happening in your <head> tag as this will get the highest priority. In order to find high priority resources, we will start off by using WebPageTest and from there, we will do actual changes, sorted by impact.

Start off by running your website through 

 and make sure to learn how to interpret the waterfall image. In practice, what you want to do is to find at what time the website renders and remove anything that happens before render.

Let's break it down somewhat. The orange icon with a white cross are render blocking resources - they prevent the browser from rendering. This is typically CSS and Web fonts. Lighthouse is great at identifying 

Anything that happens early in the waterfall are high priority resources. If any of these resources are not deemed important, you should try to move them down the waterfall. More on that later.

If you have web fonts, and they're implemented in a render blocking way, this is a major low hanging fruit but with a trade-off. In order to please core web vitals, you should start off by making sure the font is not render blocking. For that, you can use the onload hack as described at the bottom on 

Upon this, you should make sure that your font families utilize 

However, now you've introduced a new problem - your CLS metrics will decline, if you're not really lucky. When the fallback font is replaced with the web font, it's likely that they don't allocate the same space, which makes the website layout shift. To mitigate this, you will need to adjust the fallback font into allocating the same space as the web font. This can be done with 

. If you want extra control over the loading of web fonts, you can use 

 - if you can live without a specific font - is to use whatever font that's on your system. This means Segoe UI for Windows, Roboto for Android and San Francisco for iOS. If you choose this path, you don't need to think about loading web fonts asynchronously and there will be no negative CLS impact.

The anti-flicker snippet is a utility from Google Tag Manager that hides your entire page until your A/B tests has loaded (or for a maximum of 4 seconds). Does it sound bad? It does, because it is. If your FCP and LCP is happening at the same time, it's because the snippet delays rendering of your website for such a long time for this to happen.

Either way, using the anti flicker snippet will worsen all your metrics except CLS. Actually, with the anti-flicker snippet, your CLS will be perfect because the snippet hides the page while it loads so... it's not a good thing.

As with web fonts, there's a trade-off. The benefit of using the snippet is that 

 user doesn't see the wrong version of a A/B test, but the drawback is that 

 users experience a slower website. Is it a reasonable trade-off? No.

Third party tracking scripts (high impact)

Every third party tracking scripts will have a small negative effect on your website. I found that the overall Lighthouse score would improve by 10-20% by removing all third party scripts (Google Analytics, Facebook Pixel and so on). However, the sales team will hate you and honestly, I don't think it's worth that hassle.

Now comes the tedious work. If you still have one large bundle for JS and another for CSS, you're doing it wrong. When I started working on my current assignment, our combined asset size (CSS + JS) was at 1.4 MiB - crazy! Unless you want to refactor everything, you will need to start splitting code. I only have experience from doing so using Webpack, but every bundler should be able to do it.

 is about breaking out code that only runs under certain criterias, for example on a certain page or if a certain component is on the page. A good way to start is by identifying "page types" - that is, pages that share a lot of functionality in a way that it makes sense to create a specific JS and CSS bundle for that page only. These bundles are called 

The other way of doing code splitting is by using 

. If the DOM contains a certain element or component, you can conditionally load a chunk of JS or CSS.

Both these methods will move code out of the main bundle into smaller pieces.

However, when you've started creating multiple files for your JS, you need to make sure that code is not duplicated. This is mitigated by using the 

Drop IE 11 browser support (low-medium impact)

IE 11 usage is very low these days. There's a good chance (risk) that you use a bunch of polyfills that only a small percentage of your users use. If you really need a polyfill - fine, include it in your main bundle or use a cool tool like 

Polyfill.io is really smart about how they include polyfills. They use the user agent to figure out what polyfills actually are needed.

Reduce usage of third party domains (low-medium impact)

Let's go back to the waterfall on WebPageTest. See those requests that are prepended with a green-yellow-purple bar? What these say, is that the client has to connect to a new domain and therefore has to do DNS lookup, TCP connection and SSL handshake - which is a penalty in time. If the request is highly prioritized, try to move this dependency from a third party domain to your own domain.

For the same reason, you should also serve your render blocking assets and your LCP from your own domain.

 in order to visualize what third party domains you depend on.

Google has excellent tools when it comes to finding unused code - 

. By using the code coverage tool, you will be able to find code that doesn't need to be in your main bundles. If a certain bundle contains a lot of unused code, that's a indication that you should either remove or load it dynamically, if it's needed.

Use lazy loading wisely (low-medium impact)

Lazy loading is almost always a good thing - why should the browser bother spending performance on things outside the viewport. The viewport is a key factor here - 

 lazy load your LCP. Lazy loading your LCP is exactly like telling the browser not to prioritize your most important content.

Everyone seems to hate jQuery these days, but for all the wrong reasons. jQuery is not a bad library, and it's far from the largest chunk of JS either. Also, the hassle of removing jQuery is often just too much work. I don't think it's worth the large effort.

Other things that all in all has high impact

These things probably goes without saying, but having a good host/server will improve your 

. Also, your website backend plays a large role here.

 will ensure fast deliveries and global presence. It's likely that there's a shorter distance between the CDN and the user, than between the web server and the user.

 is crucial so that the browser doesn't download things in vain.

. I'm personally not sold on WebP just yet - it just seems that everyone still use JPEG.

 will improve your performance. However, use them wisely - adding a preload means down-prioritizing something else.

If you've done all these things - congratulations. You are probably some months older, because that's the time it takes to do these things. You've probably run Lighthouse a thousand times since you started, but you should definitely see those metrics skyrocket. 

If not, send me a mail and I will see if I can spot some obvious flaw.

Also, to keep your interest up about web performance - make sure to follow 

A practical guide to improve your core web vitals

I have a sidetrack backlog on my current client where I look over the web performance of the website. It's a major e-commerce website that sells the products in Europe, US and Russia. When I started working with the client nearly a year ago, there wasn't much talk about web perf at all. However, things were in dire straits - we had a combined bundle of 1.4 mega bytes - way over the ~250 kB that Webpack recommends. Upon this, the site is also heavy on large images (not included in the asset size below).

My main focus has always been the "normal" backlog, so I've tried to squeeze in web perf work whenever I had time. I've probably spent at least 4-8 hours a week for the past 6 months, and a lot of that time has mostly been spent on research and testing things.

Today we're sitting at a combined bundle of less than 500 kB. I regret to say that I don't have any Lighthouse metrics from the start, but today they're roughly at around 50.

I'm not even close to being finished (if you even ever get to reach the finish line). However, I've really learnt a lot about web perf and there are many things that I thought would satisfy Lighthouse, but in the end didn't. 

If you're about to dive into web perf and core web vitals, let me first share some key learnings.

Set up web perf tracking and get your team engaged and onboard!

, I regret that I don't have any metrics for the website before I started. Some services that provide this kind of metric tracking is 

. If you can't convince management to pay for such a service, you can set up 

If you can, try to measure what web perf means for your organization in terms of money. This will make it easier for you to argue that the subscription cost is worth it.

, I hope you have nice colleagues that share your interest in web perf. I made the mistake in not involving my colleagues enough, and now that I've done so much - I don't have their attention. I also didn't involve the online team enough, so even they are not really aware of the gains I already achieved.

These learnings are crucial if you want to be successful!

As a last learning for this part - Core web vitals is the ultimate grind. It's not about getting rid of jQuery. Not even close. It's so much more - code splitting, replacing obsolete code and battling management in order to reduce third party scripts and change their beloved font. 

Core web vitals - Prelude

I often find myself in situations where I need specific logic based on some state, for example the value of an 

 type enables us to define a limited selection of constants in a key value fashion.

In this example, I will try to create a more usable enum while still preserving the limited selection of values. The scenario is a product type 

 and the extra thing I want to enable is different size sorting based on the product type.

The different product types are clothes and shoes.

There are some ways in which we can apply custom logic depending on product type. One way could be to simply add one or more 

 constructor, but if there are complex dependencies this will not be feasible. 

A more dynamic way to apply custom logic is to use the visitor pattern. I will show you that this also allow you to still use dependency injection and testable code.

This is the only overhead, but start off with creating specific classes for 

 into a abstract class and change the static properties.

Next step is to introduce a visitor interface ...

...  and a method to apply it to a product type.

. This is actually great, because typically, people seem to use 

 statements in order to do stuff based on the enum value. However, these 

 statements needs maintenance as new product types are added.

Now let's implement the product type visitor.

That's it! We are now able to use ProductTypeVisitor wherever we'd like, for example in a product controller.

There are many benefits by using this pattern. A product is often a domain entity and in a onion architecture - domain entities are placed in the core. Outside the layer, there's usually a data layer and on top of that, there's a presentation layer. The implementation of 

 can be in any of these layers, and thus, we can let it have 

 dependency it needs. It's just a matter of resolving these dependencies like you usually do - maybe in a controller constructor - and pass that dependency as a argument to the 

But hey, don't take only my word for it - 

Combining enums and Visitor pattern

From time to time, it so happens that I create a feature branch based on the wrong branch (for example, 

Whenever I do so, I create a new branch correctly and use this command to get all my changes (although not with history).

Andreas Jilvero AB

My blog

A practical guide to improve your core web vitals

Core web vitals - Prelude

Combining enums and Visitor pattern

My favourite git command

How to manually control Episerver cache