Web Performance - Key metrics to ensure your website is Performant.
In this issue, we are going to go through on why you should care about the performance of your website and important metrics you can use to measure performance and improver user experience.
Over the next few weeks, I will be speaking at Google DevFest events regarding measuring your website performance. After previous talks that I gave, I have come to the realization that having an article that goes into detail in relation to the topic is important, as it gives attendees a place where they can learn more about the topic that’s better than slides.
On top of that, I also thought this would be a great article for my first-ever post here at Unstacked, a new newsletter that appeals to a broader developer audience, in contrast to my other newsletter - All Things Typescript (whispers - subscribe 😉).
Without wasting any more of your time, let’s dive into today’s issue about web performance and key metrics that you should always keep an eye on.
Web performance is all about making websites fast, including making slow processes seem fast.
Agenda
Why care about your website performance
Key Metrics to use to measure your Website Performance
Why?
Websites are a key component of our day-to-day lives. They connect us to vital information, and key services such as Government services, connect with people, and do business among so many things. This means it’s essential that our website provide a decent user experience.
The problem that exists is that while our website may behave as expected on our devices, our users won’t be accessing the device from our devices, but their own and under different circumstances.
This reminds me of this tweet I came across last year, which sadly I didn’t save, which had the following quote:
Your iPhone isn’t the real world
It’s important as web developers to remember that outside our comfort zone (developers are mostly well paid with access to the latest technologies at their hands), our users are not going to be in ideal locations to access our websites hence the above quote.
For instance in Africa, most people have budget smartphones, with low memory and CPU processing capabilities, and also a gotcha, and these people also live in areas with poor network connectivity such as rural areas.
As developers, we need to ensure that our websites have a decent if not great user experience for users with the cheapest devices and poor network conditions - the lowest common denominator as well for people with more expensive devices and great internet connection.
Metrics
Web Vitals
So, how do you know a website is performing well or poorly? How do you measure the performance of a website? This is where Web Vitals comes in, an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.
Web Vitals are metrics such as how long it takes for the user to see content on the web page they visited that we can use to understand how well your website is doing. If your website has good performance in these metrics, then the user experience is most likely great, otherwise poor.
Core Web Vitals
We are not going to go into all Web Vitals in this issue, I will leave that up for a future issue. Core Web Vitals are a subset of Web Vitals (goes without saying) and apply to all websites. Each vital in the Core Web Vitals measures important and distinct user experience metrics and reflects the real-world performance of your website, and the list will evolve over time, changing as needed.
As of the time of writing this issue, here are the core web vitals:
Largest Contentful Paint (LCP)
The Largest Contentful Paint (LCP) metric measures the render time of the largest block (text or image) that is visible within the viewport, from the point the page starts to load. This considers images, videos, text blocks, the first frame of animated images, and auto-playing videos, etc.
For your site to have a good LCP score, you need to achieve a score of 2.5s or less, ideally in 75% of all page loads on your websites.
Optimize for the Largest Contentful Paint
When you measure LCP either using Lighthouse or PageSpeed Insight, it usually provides a list of reasons why your LCP was given a certain score and how you can optimize for it.
If you have a website with a poor LCP score, here are some of the things you can do to optimize for LCP.
Improve your server response time
For images, CSS, javascript, HTML, and static files, consider using a CDN, with good caching policies as seen fit. If your server is slow, it impacts another metric called Time To First Byte (TTFB), which measures the time it takes for a request to get the first byte of the response. This is a subset metric for Largest Content Paint (LCP) and First Contentful Paint (FCP).
Optimize for Resource Discovery on your Web Page
Resources impacting LCP should always be loaded as early as possible. Your browser ships with a preload scanner, which will go through your raw HTML before it’s parsed by the browser and look for items it can prefetch such as images, and rel=preload Links.
To optimize for resource discovery:
ensure that all images have the image URL set inside
srsetorsrcattributes for images, don’t use javascript to set image src path for important resources, andCSS Background Images and Fonts are preloaded using the
<Link rel=preload />.
Give Priority to Important Resources to Loaded Upfront
After optimizing for discovery, it is important to ensure discovered resources are loaded before non-important ones. Resources such as images, that are non-blocking aren’t usually given priority by the browser even when they are discovered by the preload scanner. We can use the fetch-priority attribute to hint to the browser that an image is important and should be given priority.
<img fetchpriority="high" src="/path/to/important/image.webp">We can also de-prioritize resources, to ensure that we are not taking too much of the browser bandwidth and have enough of it to load important resources.
Others Optimization
Use modern image formats such as WebP. You can use a specialized image CDN that will automatically serve an image format compatible with the user's device.
Use Responsive Images. Don’t use one large image for all screen sizes, but instead use responsive images.
Compress Images to the smallest possible size, without impacting the quality too much.
Use appropriate cache settings ensuring that network latency is reduced and only necessary for the initial load of the resource
Remove any unnecessary CSS and Javascript for a page
Reduce font size
Cumulative Layout Shift (CLS)
One of the most frustrating things to users is when the content they are reading suddenly moves to a different location. This could be caused by things such as an image loading above the content, pushing the content down or some other content being added dynamically such as ads and the content has to move to create space for it.
This is quite difficult to see as a developer as we are usually lucky enough to be using fast or decent-speed internet, images are already cached, which reduces the load time for when we are testing.
CLS is an important metric as it measures unexpected layout shifts during the lifespan of a webpage. A layout shift occurs anytime visible elements to the user suddenly change positions and CLS helps us understand how often our web page is doing this.
There are two types of layout shifts to keep in mind:
unexpected layout shift - it wasn’t intended by the developer as part of the web page design and is bad,
and the expected layout shift - think of user-initiated layout shift, like when they click a button to expand a section or animated content.
Ideally, you should have zero layout shifts on your web page, but a good score is 0.1 or less for 75% of all page loads on your website.
To optimize for CLS, ensure that all your images have a fixed height and width, or add aspect ratio to them, so that the browser can reserve a place for them in the rendered page.
First Input Delay (FID)
Ever visited a web page and after it loaded, and you tried to click on a link or button and it took a while for the website to respond? First Input Delay (FID) measures this specific metric of how long it takes for the web page to respond to user interaction such as clicks, taps, and keyboard events during the loading process. For a good FID score, it should have a delay of 100 milliseconds or less.
In order to optimize for FID, you can do the following:
Reduce or minimize the Javascript that’s initially loaded by your application during the loading process.
Offload tasks from the main threads, i.e. use Web Workers to perform heavy computations. The main thread is blocking and when the browser is executing Javascript in the main thread, it will not process any user interactions.
Explore on-demand loading of Scripts as if you load too much on the main thread, it will slow down user interactions.
This can be done by deferring unused and unimportant javascript scripts. This can be achieved by adding the defer tag to your scripts. You can learn more about both def and async attributes here.
Code-splitting or lazy loading and loading the smaller chunks on demand.
And finally, minimize the use of pollyfills.
Interaction to Next Paint (INP)
Ever found yourself on a very sluggish website, where the page was slow to respond and even freezes once in a while? Interaction to Next Paint or INP is a metric that’s designed to measure the general interactivity of your website. Unlike the First Input Delay (FID) metric that focuses on time to first interaction, this focuses on all interactions on your website.
INP measures the latency of keyboard interactions, taps, and clicks during the lifespan of the site. The value of the longest interaction is the INP value, with any outliers ignored. A good INP is below 200 milliseconds.
You can do the following to optimize your INP score:
Remove unnecessary Javascript from your webpage as it impacts start-up performance. The browser has to download and parse all of the Javascript in order to provide interactivity, and if it’s too much, it means the first interaction will take a bit longer. You can achieve this by using techniques such as Lazy Loading where javascript is broken up into smaller chunks and only necessary Javascript is loaded up.
Avoid having heavy and long-running tasks on the main thread as they can block other processes hence impacting the performance of your site.
Minimize the size of the DOM - with large DOM elements, the rendering work takes longer and hence impacts the performance of your Website. With large DOM elements, both the initial rendering and any rerendering afterward are going to be very expensive and slow.
You can use content visibility to control whether an element's content is rendered or not.
Other techniques include the use of virtual lists where we only render visible parts of lists instead of everything at once, hence improving performance.
Be aware of the cost of Javascript rendering HTML and CSS. When your browser receives HTML, it can stream it and parse it chunk by chunk, ensuring the best performance. However, with the advent of modern frameworks such as React, Angular, Vue, etc. it’s common to ship a javascript site that then renders the HTML and sometimes even the CSS. This means your browser has to download all the necessary Javascript content, in this case, it will your whole application code (all pages), and then parse it, and only then you will see HTML content. This is very expensive and slow, and we have come up with techniques such as:
Server Side Rendering (SSR) where this work is done on the server instead so we can send HTML to the client,
and Lazy Loading, where we break up our application into smaller chunks that can be loaded as needed. As developers, however, we need to be aware of this and avoid it where necessary.
Conclusion
In this issue, we talked about Web Performance and important metrics to keep an eye on in order to ensure the user experience is decent if not great. We learned that it’s important to ensure that the lowest common denominator users get a good user experience and can use your website without struggling too much. It’s important for web developers to ensure a website with great performance and great user experience.