Get early access to SEO software betas!

close

The Core Web Vitals Google Algorithm Update Is Live



The deadline to speed up your website is here. Are you ready?


Schedule a Page Speed Demo
menu
close

First Input Delay (FID): What You Need to Know

INTRODUCTION

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

WHAT IS FIRST INPUT DELAY?

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?"

WHY SHOULD MARKETERS CARE ABOUT FIRST INPUT DELAY?

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

FID SEO IMPACTS

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.

FID USER EXPERIENCE IMPACTS

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.

WHAT FACTORS AFFECT FIRST INPUT DELAY?

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.

HOW DO YOU MEASURE FIRST INPUT DELAY?

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.

FID THRESHOLDS

  • Under 100 milliseconds or less is considered “good”
  • Between 100 and 300 milliseconds is considered “in need of improvement”
  • Above 300 milliseconds is considered “poor”

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:

  • Chrome UX Report
  • Page Speed Insights Tool
  • Core Web Vitals Report in Search Console

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.

HOW DO YOU IMPROVE FIRST INPUT DELAY?

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

IMPROVE FID BY OPTIMIZING YOUR CSS CODE

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. 

IMPROVE FID BY OPTIMIZING YOUR JAVASCRIPT CODE

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.

IMPROVE FID BY REDUCING THIRD PARTY CODE IMPACTS

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.

Frequently Asked Questions

What is first input delay?

First Input Delay is one of the new Core Web Vitals metrics that will be used in the new  Google “Page Experience” update rolling out in the summer of 2021. It measures the responsiveness of a web page as users attempt to interact with links and buttons.

What is maximum 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.

How important is first input delay for SEO?

First Input Delay’s lab proxy, Total Blocking Time, accounts for 25% of your Google Performance Score (which doubles as your “Page Speed” score on mobile and desktop in Google’s PageSpeed Insights tool as well). More importantly, it is also one of the new Core Web Vitals that will play ranking factors in the new page experience update. In order to pass the Core Web Vitals assessment, you need to pass all three metrics, so this metric must be accounted for in your optimization strategy.

How is first input delay calculated in the field versus the lab?

First Input Delay is a metric that can only be measured in the field. There need to be real-world user interactions to gather data for this metric, which can be found in the Chrome User Experience. In the lab, a good proxy for First Input Delay is the “Total Blocking Time” metric, which measures the amount of time a browser is busy processing requests longer than 50 milliseconds. Google has said that improvements to this metric usually correspond to improvements in first input delay scores.

How do you fix first input delay issues?

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.