This is part 2 of An introduction to Core Web Vitals, a 3 part series about Core Web Vitals. Core Web Vitals refer to three key metrics that provide a good measure of your website’s user experience. However, in June 2021, Core Web Vitals became one of the ranking signals that Google uses to rank its search engine results. Thus Core Web Vitals began to not only impact conversions but traffic as well. As such, they are one of the most important parts of SiteImp audits.
Last article
Last article, I wrote about cumulative layout shift. Cumulative layout shift refers to the total of all layout shifts. Layout shifts are caused by things like img (or other elements) without explicit height and width attributes set, web fonts, and DOM updates/content updates that depend upon other services.
This article
This article, I’m going to talk about first input delay. First input delay (FID) and largest contentful paint are the two performance centric core web vitals. First input delay measures responsiveness. It specifically measures the time between user input and the browser’s reaction to the response. However, it only focuses on the types of input that will be handled by the browser’s main (or UI) thread.
I’ll explain with an example. Let’s say that you have a link on your web page. A user clicks the link and it takes 1 second for their browser to recognize the click and start that request. That would be an input delay of 1 second and would be reflected in first input delay. However, let’s say that the same user tries to zoom in your page. Zoom processes have different constraints and usually outside the browser’s main thread. Zoom delays are a type of input delay but they won’t be measured in first input delay because any measurements just won’t be accurate.
What causes input delay?
We defined input delay as the time between user input and the browser’s reaction. As such, first input delay is a measurement of how long it takes a page to become responsive to user input after it is downloaded.
Input delays happen because the browser is busy doing something else. In other words, the main thread is busy doing something else so the user input has to wait for it to become available. In the field, you’ll often see very large input delays when the browser is busy processing large javascript files or files. It can’t run any event listeners (so cannot begin to respond to input) because the Javascript it’s loading might change those event listeners!
It’s important to remember that FID only covers the delay between user input and when the browser is ready to start executing the new task. It does not measure that tasks processing or execution time. Nor does it measure the next page load. It only speaks to the gap between when a user does something and the browser recognizes that it did something.
Think of a communication like this:
- User - Hey browser, tell the website that my name is Greg.
- Browser - …
- Website - …
- User - …
- Browser - “Hey website, the user’s name is Greg.”
- Website - “Hi Greg.”
Input delay measures the points between 1 and 5.
Preventing input delay
This will sound like a recurring theme (it is), but the best way to prevent input delay is to be very careful about page composition and resources. A very easy way to solve input delay problems is to take tasks away from the main thread. And the easiest way to do this is to cut down on the number of resources you serve on every page.
If you cannot completely remove the resource, defer it. When SiteImp calculates total transfer, it focuses on resources that have to load before the page is responsive. As a general rule, if your website has to download more than the original Doom before your page is responsive, your users are going to have an awful experience.
In other words, if you want to fight FID, fight bloat.
Outside of fighting page bloat, you get into areas of optimizing javascript. Optimizing javascript is outside the scale of this article but as a general warning, if you’re going to start optimizing javascript, make sure you have a very good testing rig. It’s remarkably easy to implement very subtle bugs into code and they can be a real pain to diagnose at 2am.
Next article
Next article, I’m going to talk about Largest Contentful Paint (LCP). Largest contentful paint is another important metric to measure how quickly your web pages load. It measures the time it takes to show the user the largest content on the page. Hence the name…:)