In the spring of 2021, Google will roll out a  major algorithm change  called the “Page Experience” update. This update introduces a new set of ranking factors and web performance metrics called “Core Web Vitals” — largest contentful paint (LCP), first input delay (FID), and cumulative layout shift (CLS) — that measure web performance and real user experience on any given website. In this article, we provide an introduction to the second metric and ranking factor: first input delay.

first input delay hero


The first thing that comes to mind when you think of load time is likely something visual — the time it takes until the browser loads the content of a page and you're able to view it. But what about the time it takes until you are about to have your first user interaction with the page? How long does it take for you to be able to click a link or button? In 2018, Google began to explore web performance metrics focused on user interaction, specifically first input delay (FID).

First input delay (FID) is a key metric in Google’s new set of “Core Web Vitals” that measures the delay in discrete event processing (like the click of a button) in order to capture a user’s first impression of a site’s interactivity and responsiveness. In other words, FID measures the experience users feel when trying to interact with elements on a page and answers the user question, "How long do I have to wait before I can interact with the page?"


There are at least a couple of reasons why marketers and other non-developer business professionals should care about first input delay.


The first reason is that FID will be a ranking factor starting in the spring of 2021. It’s a great way for search engines to measure the first impression you are making on users and the impact on total blocking time (a proxy for FID representing 25% of the weighted average in Lighthouse scores.) Furthermore, Google research has shown that the biggest interactivity issues tend to occur during the loading of a page as well, so encouraging webmasters to focus on these initial experiences will have downstream benefits on interactivity through the rest of the site browsing experience, too.


The second reason is the impact on users. First impressions with users are important. The responsiveness of elements on your site to user input could mean the difference between a loyal user or those that get frustrated, leave, and never return to do business with you. Imagine a scenario where a user clicks on a “book meeting” button, but nothing happens because the browser was busy loading other elements on the page before it could respond in a timely manner.


Input delay occurs when the browser is in the middle of some task (like parsing and executing a large javascript file) that prevents it from running event listeners and responding to the input request. It is typically caused by javascript and CSS that needs to load before HTML can be rendered. In fact, the more javascript your pages use, the more concerned you need to be about first input delay. The browser has rendered some of the content, but it isn’t interactive yet. That’s what causes the delay between when the click from a user is received and when the main thread from the browser is able to respond.

Write more on event handlers here.


First input delay (FID) measures the time from when a user first interacts with a page (like a click, key press, or tap) to when the browser begins to process the response to that action. It captures those early, critical inputs, even before the page is fully interactive. A good FID signals that the page is usable.


100 milliseconds is roughly the limit for when a user feels the system is reacting instantaneously. As such, Google treats it as the border between a first input delay that is “good” and one that is “in need of improvement.”

To measure FID, you can use the following tools and reports:

To help predict first input delay scores, consider using total blocking time as a proxy. TBT measures something different – the amount of time a browser is busy processing requests longer than 50 milliseconds – but improvements to this metric usually correspond to improvements in first input delay scores. As the main cause of “poor” first input delay is heavy JS execution. Optimizing how JS is parsed, compiled, and executed on your web pages will directly reduce these scores. 

Another metric to explore here is “maximum potential first input delay.” This value is found in the performance section of Google’s Lighthouse report and provides a score for the worst-case scenario where a user clicks on an element, like a button, just as the browser starts to execute the longest task on the main thread.


There are at least 3 ways to improve first input delay scores on your web pages.


In order to have a good FID score, the browser needs to first render the layout of the page. This means the browser has to be able to download and parse CSS files as fast as possible. Improve FID by optimizing CSS code on CSS heavy pages — minify, compress, and remove unused CSS. 


Optimizing javascript code is typically the best route to improving your FID score. When a browser is slow to load the first user interaction it's often because javscript tasks are blocking the browser’s main thread for extended periods of time, so the browser can't process user input.

You can improve FID by minifying, compressing, and breaking up longer Javascript tasks into smaller, asynchronous tasks. This makes it so the browser is actually able to begin processing event handlers in response to user interactions.

Breaking up long tasks could include things like removing network trips by caching code with the PRPL pattern and delegating some javascript code to be run on a web worker thread — which results in less work for the main thread and less input delay.

Specifically, try to keep javascript tasks under 50 milliseconds as longer tasks block the thread which further delays a response to the first user input. And if you code split (break longer tasks into smaller chunks), these user inputs can be processed in between tasks.


Adding something like an analytics service to your page requires the installation of a 3rd party script to your HTML, which can significantly affect page load performance and first input delay specifically. Consider passing on or removing scripts that don’t add clear value to your website.

In Summary

First input delay measures the delay in discrete event processing (like the click of a button) in order to capture a user’s first impression of a site’s interactivity and responsiveness.

Webmasters should care about this metric because it is set to be a ranking factor in the spring of 2021 and has a significant first impression on user experience with your website.

The length of javascript and CSS code-related tasks in the browser’s main processing thread have the greatest impact on first input delay. Optimizing CSS and breaking javascript tasks up into smaller, asynchronous chunks — in order to create more opportunities for the browser to respond in a reasonable time to user input — will do the most to improve these scores.

As this is Google’s own metric, there are a number of reports and tools that allow you to monitor and improve your FID scores including the Core Web Vitals Report in Search Console, Chrome UX Report, and Pagespeed Insights Tool.