June 18, 2021 | 5 min read

How To Optimize First Input Delay

1. QuikRead

FID, like all Google Page Experience signals, attempts to reduce user frustration. Google will incorporate Core Web Vitals into their ranking considerations in order to encourage developers to create websites that provide more than just good, useful information, but also a great user experience.
Furthermore, even if First Input Delay becomes a soft ranking criterion, its real-world impact on a site’s traffic can be excruciatingly painful. If consumers encounter an inactive or slow website, they may just choose another resource. As a result, improving FID is a smart idea for a variety of reasons.
To improve FID, one must first identify the major offenders. Actually, there is just one problem – high JavaScript execution – and it has a multitude of effects on FID.

2. Heavy JavaScript execution

While JavaScript is being executed on the main thread, the browser cannot respond to most user input. In other words, while the main thread is busy, the browser cannot respond to user inputs. To make this better:
  • Break up Long Tasks
  • Optimize your page for interaction readiness
  • Use a web worker
  • Reduce JavaScript execution time
Fortunately, each of the aforementioned difficulties has a plethora of potential solutions. Let’s take a look at each one individually.

Break up Long Tasks

If you’ve previously worked to decrease the amount of JavaScript that loads on a single page, breaking down long-running code into smaller, asynchronous jobs might be effective.
Long Tasks are JavaScript execution durations during which your UI may become unresponsive to users. A Long Task is any piece of code that stalls the main thread for longer than 50 milliseconds. Long Tasks indicate the possibility of JavaScript bloat (loading and executing more than a user may need right now). Long jobs can be split up to decrease input latency on your site.
Break-up-Long-Tasks
As you use recommended practices like code splitting and dividing up your Long Tasks, your FID should increase dramatically. While TBT is not a field statistic, it may be used to monitor progress toward ultimately increasing both Time To Interactive (TTI) and FID.

Optimize your page for interactivity.

Poor FID and TBT scores in web apps that rely significantly on JavaScript can be caused by a variety of factors, including:

a. The execution of first-party scripts may cause interaction readiness to be delayed.

  • JavaScript size bloat, long execution times, and improper chunking may all slow down how quickly a website responds to user interaction, affecting FID, TBT, and TTI. Progressive loading of code and features can aid in spreading out this effort and improving interaction readiness.
  • Server-side rendered apps may appear to be rapidly painting pixels on the screen, but be wary of user interactions being stalled by lengthy script executions (e.g. re-hydration to wire up event listeners). If route-based code splitting is employed, this might take several hundred milliseconds, if not seconds. Consider moving more functionality to the server or creating more material statically during the development process.
The TBT scores for an application before and after optimizing first-party script loading are shown below. Users were able to engage with the website considerably sooner after shifting expensive script loading (and execution) for a non-essential component off the critical path.
Optimize-your-page-for-interactivity

b. Many characteristics of interaction readiness can be influenced by Data-fetching

Waiting on a waterfall of cascading fetches (for example, JavaScript and data fetch for components) might have an influence on interaction latency. Attempt to reduce your dependency on cascade data fetches.
Large inline datastores can increase HTML parsing time and have an effect on paint and interaction metrics. Attempt to reduce the amount of data that must be post-processed on the client-side.

c. Third-party script execution might also cause interaction latency to increase.

Many websites incorporate third-party tags and analytics, which can keep the network busy and cause the main thread to become unavailable on a regular basis, affecting interaction latency. Investigate on-demand loading of third-party code (for example, maybe don’t load those below-the-fold adverts until they’re closer to the viewport).
Third-party-script-execution-might-also-cause-interaction-latency-to-increase
In rare circumstances, third-party scripts might take precedence over first-party ones in terms of priority and bandwidth on the main thread, prolonging the time it takes for a website to become interactive. Prioritize loading what you feel will provide the most value to users first.

Employ a web worker

One of the most common reasons for input delay is a blocked main thread. Web workers allow JavaScript to operate in the background on a separate thread. Transferring non-UI activities to a separate worker thread can reduce main thread blocking time and, as a result, increase FID.
Consider utilizing the following libraries to make utilizing web workers on your site easier:
  • Comlink: A utility library that encapsulates and simplifies the usage of postMessage.
  • Workway: A web worker exporter with a broad range of capabilities.
  • Workerize: Incorporate a module into a web worker

Reduce JavaScript execution time

Limiting the amount of JavaScript on your website decreases the time the browser must spend running JavaScript code. This increases the speed with which the browser may begin to respond to any user activities.
Reduce-JavaScript-execution-time
To limit the amount of JavaScript that is performed on your website, do the following:
  • Defer unused javaScript
  • Minimize unused polyfills

a. Defer unused javaScript

All JavaScript is render-blocking by default. When a script tag refers to an external JavaScript file, the browser must halt what it’s doing and download, parse, build, and execute the JavaScript. As a result, you should only load the code that is required for the page or for responding to user input.
The Coverage tab in Chrome DevTools will tell you how much JavaScript is missing from your web page.
Defer-unused-javaScript
To reduce the amount of unnecessary JavaScript:
  • Code-split your package into many parts.
  • Use async or defer to delay any non-critical JavaScript, including third-party scripts.
Code-splitting is the notion of dividing a single big JavaScript bundle into smaller portions that may be loaded conditionally (also known as lazy-loading).Aside from code-splitting, always use async or defer for scripts that aren’t critical-path or above-the-fold material.
Unless there is a compelling reason not to, all third-party scripts should be loaded by default with either defer or async.

b. Minimize unused polyfills

The move from old to new is normal, but adapting anything new to replace something old may be difficult. Polyfills are used to make the JavaScript code for your new website (designed for new browsers) compatible with older browsers.
Minimize-unused-polyfills
But what if new browsers are also downloading this worthless “glue” code, wasting crucial loading microseconds? That is what you must optimize for.
You may prevent unnecessary polyfills from being loaded in the first place by using transpilers like Babel or supplying alternative bundles for various settings.

3. Final thoughts

The reason there is so much emphasis on JavaScript to enhance your website’s First Input Delay is simple:
When a person enters a website, the text is usually the first thing that they see, followed by other web page elements.
Despite the fact that the content on a website is visible to the user, they cannot scroll down, click on items, or zoom into pictures driven by JavaScript.
When it comes to improving a website’s First Input Delay, optimizing JavaScript should always be at the top of the list.

Related Posts

Leave A Comment