First Input Delay (Fid): How Long Do I Have To Wait To Interact With The Site? 

What it is and how to optimize the metric which measures user interactivity. What are at stake here are search engine rankings and conversions, primarily from mobile devices. Among the aims of Google Page Experience - the update designed to improve online UX - there is the prevention of a disastrous or at least uncomfortable interaction between the user and the website, especially on mobile devices where searches and conversions are increasingly higher in number.

 

They won’t wait more than 4 seconds

Have you ever forgotten what you were searching for on a site because the response time to your click on a button or a link was longer and more tedious than you had expected? This happens more often than you might think, especially on mobile devices. The potential loyal customer then abandons that site with a “This is the last you’ll be seeing of me” mindset. This subjective experience as confirmed in a Chromium study, suggests that a user’s attention span on a mobile device does not exceed 8 seconds, and recommends that the optimum time for an expected response is 4 seconds.

First Input Delay: a new assessment parameter

One of the various objectives set by the Google Page Experience, the update aimed at improving UX online, is also the following: preventing disastrous or limiting awkward interaction as much as possible between users and a site, especially from smartphones, where searches and conversions are increasingly more concentrated.

Not surprisingly, First Input Delay is one of the new Core Web Vitals, a trio of user-centric metrics introduced by Google in May 2021 to measure and quantify page experience.  In fact, FID measures the time elapsed between users‘ first interaction with a page, such as interacting with a button or clicking on a link, and the exact moment when the browser responds to the interaction.

This is a user-focused metric, as in addition to measuring the responsiveness of sites to user input, it also quantifies the experience users have when interacting with web pages that do not respond. 

As a matter of fact, Google considers Core Web Vitals as ranking factors in the SERPs and so ignoring them can have dire consequences for organic traffic and conversions. But they also present an opportunity: implementing the changes suggested in the update and improving those parameters means improving your own visitors’ and clients’ user experience regardless of ranking in search engine results. Various surveys have highlighted how a delay of just one tenth of a second can affect up to 10% of conversions while one extra second can lose up to 15%. To make it clear, here is some data provided by Google support regarding website performance:

  • Loading times between 1-3 seconds, bounce rate frequency +32%
  • Loading times between 1-6 seconds, bounce rate frequency +106%

We are therefore talking about the time expressed in milliseconds that elapses between the first interaction of a user on a web page and the response of the browser to that interaction. Time during which aspects such as scrolling or zooming, for example, are not taken into account. There can be many reasons for the delay: the web page may be busy with other work or the user’s device may simply be slow.

First Input Delay: what does it measures and how is it calculated

Before delving into what exactly First Input Delay measures and how to improve this important metric, let’s quickly run through the three Core Web Vitals:

  • Largest Contentful Paint (LCP): it is the loading speed factor and measures the time taken to render the biggest content, image or text block on the visible area of the page. The LCP measured by resource loading performance in the most difficult phase should be within 2.5 seconds to be considered good.
  • First Input Delay: it is the interactivity factor and measures the time it takes for the user’s browser to respond when a user first interacts with a site.
  • Cumulative Layout Shifts (CLS): it measures visible stability by summing all individual visible layout shifts while a site is loading. unforeseen and which occur after the area of interest has been loaded. The result could be an interaction with the void or perhaps another link.

So, FID evaluates the quality of the user experience in terms of page speed interactions.  It should be made clear that, like the other new signals, this metric is based on the user’s real-world experience during site navigation and not on a lab-controlled setting.

To the point, First Input Delay calculates the time lapse between a user’s first interaction with a page, which could be a click on a link or a button, and the browser’s actual first response to that interaction in milliseconds.   Crucially, it measures the first input delay in event processing and not the event processing time as a whole, which, if split up into individual responses, would be useless for improving the metric. Zooming and scrolling are more related to other parameters and so are not included in this measurement.     

A delay which is equal to or less than a 100 milliseconds, one tenth of a second, is classified as good in relation to Google Page Experience parameters, whereas anything up to 300 milliseconds is tolerable but in need of improvementAnything above this threshold is classed as poor from a good user experience perspective.

The same Google suggests that “to ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” But beware: although Google sets all Core Web Vitals thresholds at the 75th percentile, it would be more useful to set the threshold for FID at the 95th-99th percentiles given the variability of this parameter from user to user. An upward shift allows a webmaster to identify the worst user experiences and flags up the elements that are possibly in need of improvement in order to better interactivity on the web site pages.

First Input Delay: What delays interaction and how to fix it

It must be remembered that FID, a parameter which reflects the real user experience when interacting with the site, can be measured using various tools:

  • Chrome User Experience Report
  • PageSpeed Insights(field and laboratory data): specifically, this tool records the laboratory and field performance of a resource on desktop and mobile devices.
  • JavaScript library: These are reusable codes through which specific properties and functions of a website are assigned.
  • Lighthouse: is an automated website control tool that supports developers in diagnosing problems and identifying opportunities for improving the user experience. Aspects such as performance and accessibility are also taken into account.
  • Search Console (Core Web Vitals report): useful for analysing all the pages of a domain that are collected by results, dividing them between mobile and desktop.

But what can delay the start of an interaction? A delay generally occurs when the browser’s main thread is already busy processing something else, especially as is the case in large JavaScript file which, when running, takes priority and can block the main thread thus leading to an unresponsive page. The browser then has to wait until the task completes before it can respond to the input.

In short, if a site is likely to make a first bad impression on a user due to frustratingly long waiting times while looking for articles, or worse still, products and services, the main culprit is usually heavy JavaScript execution.  Having to intervene with programing language or resort to workarounds so as to lighten the load of the main thread and reduce delay times from the user’s first interaction, is fatal.

First Input Delay: what to do to fight interaction delay

The requested actions are not always simple, fast and painless and good results cannot be guaranteed. 

 Possible actions are as follows:

  • Shortening JS working time: doing so could limit the amount of JavaScript on the pages, thus reducing the amount of time the browser would need to execute the code;
  • Minimizing third- party code;
  • Splitting upmain tasks into many smaller tasks consecutively;
  • Compressing JavaScript code and removing unused code;
  • Reducing the number of requests;
  • Lowering transfer size.

 A layer can provide an alternative non-invasive plug n’ play which overcomes all these issues in one go.  It is positioned between the server and the user browser and takes charge of optimizing response times.  This layer can manage the cache and optimization techniques, does not need to intervene with the source code, is able to significantly improve overall site performance, optimizes all of the Core Web Vitals and if needed, functions in multi-country domains thus eliminating the possibility of human error for loading content and modifying codes.

The positive effects on ranking and user experience are almost immediate. According to a Deloitte study, what is at stake here is an 8.4% increase in conversions in retail from mobile devices and a +9.2% rise of average value of orders with a performance improvement of just 0.1 seconds. Why leave a user waiting for an interaction response? Not only is it a sign of bad manners, but it costs money too.