Core Web Vitals consist of First Contentful Paint, Largest Contentful Paint, and First Input Delay. The first two both measure the amount of time it takes for content to visually render on a page – or visually paint on a page.
To render doesn’t capture the load responsiveness, however, nor the speed of a page’s response to the interaction of a user.
First Input Delay, on the other hand, captures the first impression of a user on the website’s responsiveness and interactivity. This means that it measures the time from when a user first interacts with a page until the time when the browser is actually able to respond to the interaction.
As such, First Input Delay is a field metric and so can’t be replicated in a lab environment. To measure the response delay, a real user interaction is needed. To help bridge the gap and get a close reading of First Input Delay, looking at the Total Blocking Time is recommended.
Despite not being exactly the same, improvements to Total Blocking Time have strong correlations to improvements in First Input Delay.
The culprit
The main issue when it comes to First Input Delay is an overweight JavaScript. So optimizing JavaScript is like squats at the gym: it is the one move that gives the body the most improvement.
And so with this in mind, let’s take a look at some ways in which brands and retailers can optimize their First Input Delay and improve their overall Core Web Vitals.
Break it up
Beyond reducing the amount of JS that loads, the next port of call will be to look at the breakdown of long-running code.
Long tasks, those in which site users can encounter an unresponsive user interface. Pieces of code that blocks the main thread for 50 milliseconds or longer are defined as a long task. It is a good indicator of JS bloating, and so slimming it down and reducing input delay this way can be very beneficial.
First-party scripts
Within web apps, first-party scripts lead to delays in interactivity readiness. Progressive loading of code as well as features are able to help distribute the workload and improve the readiness of interaction. Elsewhere, server-side apps have the appearance of quick loading times, yet have caution because user interactions can be blocked by large-script executions.
These blockages can take multiple hundred milliseconds – even reaching seconds. In this case, it’s best to consider the shift to logic server-side during the build, or generating more static content.
A web worker
Another main cause of input delay is a blocked main thread. In steps the web worker, which allows JavaScript to run on a background thread. This implies shifting non-user interaction parts to a separate worker thread – suppressing main thread blocking time and ultimately First Input Delay.
Web workers can be worked well on libraries such as Workway, Workerize, and Comlink.
The unused polyfills
When you code using JavaScript syntax and reference modern browser APIs, then you need to transpile it as well as include polyfills so that it is able to function across older browsers.
The most critical concern around polyfills is that newer browsers should not have to download it if they do not need it. To squeeze the size of JavaScript, erasing unused polyfills as much as possible is a great idea.
PS: ArganoUV is one of the world’s leading Core Web Vitals teams. Contact us to see how we can work together.
