Web Vitals: What is First Input Delay?

It measures page interactivity

First input delay, or 'FID', evaluates a your web page interactivity and responsiveness.

FID is a metric which measures the time from when a user first interacts with a page (e.g. click or tap a link) to the time at which the browser is able to respond and handle the interaction.

Continuous types of user interaction, like scrolling or zooming the page, are not measured using this metric.

First input delay is measured in milliseconds.

What is first input delay target time?

To provide users a good experience, you should aim for a first input delay of 100 milliseconds (0.1s) or less.

First Input Delay: Google Scoring Ranges

Is first input delay (FID) the same as time to interactive (TTI)?

No. Time to Interactive measures the time it takes for a page to be fully interactive. First Input Delay instead tracks user input that happens before the page is fully interactive.

My first input delay score is above 100ms is this OK?

If your FID score is above 100ms then Google will label the scoring as Needs improvement and if its above 300ms then it will be labeled Poor. You should try to ensure most of you users get an interactivity time of under 100ms. Google suggests the 75th percentile of page loads, segmented across all devices as a good threshold.

If you're worried about how your first input delay (FID) scores will impact your search rankings, then use our SERP site speed comparison tool to check how other websites ranking for your target keywords / vertical measure up.

How can I optimize first input delay time?

JavaScript is the number 1 enemy of fast first input times. JavaScript will block the browser’s main thread and this blocks the browser from being able to process user input.

In our experience first input delay for most websites is already within the core web vitals 'Good' score (it passes), if your website has a first input delay above 100ms (the 'Good' target time) then its likely there is some quick changes you can make to fix this.

Remove unused JavaScript

  1. Remove files: Large sites or sites with lots of legacy code, its possible for developers to miss cleaning up pages and we can sometimes find JavaScript files loaded on pages despite not being needed - remove them!
  2. Clean files: You should also have developers review JavaScript being loaded on pages, and confirm everything in these files are actually required - they may find some specific JS which is only required on X page but is being loaded across the whole site, this could be extracted to a separate JS file and loaded only where needed.
  3. Confirm requirements: Check if polyfills are used / required, many sites use polyfills to support older browsers which may be missing native functionality (especially if you're supporting Internet Explorer), modern browsers improve quite quickly so you may find that polyfills being loaded are no longer needed - you may also find you no longer need to support extremely old browsers which these polyfills are created for (like IE - which Microsoft officially no longer supports).
  4. Check third-party scripts: Remove third-party scripts which are no longer providing value to your page, or be smarter about which pages this code is loaded on.

Reduce impact of third-party code

  1. Check third-party scripts: (Same as point 4 above) - Remove any unused third-party code or check its only loaded on pages needed it.
  2. Optimize loading - non-critical: Optimize the loading strategy of non-critical third-party scripts, this can be done with defer or async attributes as well as lazy loading.

The defer attribute tells the browser not to wait for the script. Instead, the script is executed when the page has finished parsing.

<script defer src="https://cdn.example.com/script.js">

The async attribute tells the browser to fetch the script asynchronously in parallel, and once downloaded the browser will execute JavaScript code.

<script async src="https://cdn.example.com/script.js">
  1. Optimize loading - critical: Optimize the loading strategy of critical third-party scripts, used browser resource 'hints' to reduce the total download time of scripts. You can save 100–500 ms by establishing early connections to important third-party origins.

Preconnect to third-party scripts
rel="preconnect" informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible.

<link rel="preconnect" href="https://cdn.example.com">

Prefect to third-party scripts DNS
`rel="dns-prefetch" handles a small subset of what is handled by preconnect. Establishing a connection involves the DNS lookup and TCP handshake, and for secure origins, TLS negotiations.

<link rel="dns-prefetch" href="https://cdn.example.com">

Compress JavaScript

By minifying your JS files (removing white space etc), you can reduce file size and this will reduce download times.

You can minify JS with plugins for code editors, or through many of the free online minifier. Using a code editor plugin is preferential since it will generate a .min.js file and you can keep the original unminified code for future edits.

Move JavaScript off the main thread

You can use web workers to reduce the amount of JavaScript which is executed on the main thread.

Web workers can only be used for JavaScript which does not need to interact with the DOM, and would be a good solution for CPU-intensive computations.

Web Workers are a simple means for web content to run scripts in background threads.
Category: Web Vitals
Published:
Nick McBurney - Founder of SERPFast.com
Author: Nick McBurney

Founder of SERPFast.com and Lead Frontend Developer with a passion for site speed.