Core Web Vitals: how to optimise First Input Delay (FID)

Capping off our Core Web Vitals trilogy (see CLS & LCP), we will be looking at FID (First Input Delay) and how we can improve your website’s overall user interaction and site experience.

What is first input delay (FID)?

FID is the time between when a user interacts with elements on a page (clicking or tapping buttons and links), and how long the browser can begin processing the events before responding to those actions (usually with JavaScript). The faster those response times, the more responsive and snappy your user experience will be.

Please note that FID does NOT measure the time it takes for those interactions to be completed. For example, if a user clicks on a button and a modal window opens, the time it takes for that modal to open has no positive or negative effect on the FID metric.

Negative FID usually occurs when your website is still processing data in the background. This could be additional assets or scripts that are blocking the expected task. The site might look like it’s fully loaded and users can appear to start interacting with it. However, due to some assets being ‘lazy loaded’ or ‘deferred’ it may cause interactions to be delayed. This is a bad user experience and may make your site slow or sluggish.

What’s the main culprit of negative FID?

Javascript usually has the biggest negative effect on FID. JavaScript can create some truly amazing site experiences but over-use or inefficient use can cause heavy JavaScript files, and in some cases, can take a while to load for users. This increases the delay between the user’s first interaction and the expected output.

How can we optimise FID?

To improve & optimise FID, we first need to look at improving how we handle the site’s JavaScript. This may be how we compile, parse and execute the site’s scripts. 

We can also remove legacy scripts. If the sites have been live for a while, we can refactor, rewrite or optimise the current code to a more modern solution or practice.

We can reduce or defer third party scripts that may be prioritised over your site’s functional assets. Unless completely necessary, most JavaScript files should now be loaded asynchronously or deferred for overall better site performance.

We can use techniques such as code splitting to break up our JavaScript, so the browser only needs the code for the required user response. If you use code bundlers like Webpack or ParcelJS you can use their dynamic imports to load the functionality you need, only when it’s required.

You can even avoid JavaScript altogether. Although JavaScript can create extremely well crafted and functional experiences for users, a lot of the more basic JavaScript tasks can be accomplished using standard HTML & CSS with a bit of clever thinking.

Conclusion 

A quick note: Google’s FID cannot be measured if there is no site interaction data. Google requires real user data to determine the delay, so your site’s FID may change over time.

However, the FID scores we get can be mostly improved by looking at the site’s JavaScript and utilising some, if not all, of the techniques described above.