Last updated on July 31, 2021.
First Input Delay (FID) is a user-centric metric used by Google to measure the interactivity (load responsiveness) of a website. FID is one of three Core Web Vitals metrics (the other two being Largest Contentful Paint and Cumulative Layout Shift) that are part of Google page experience signals.
In the guide to First Input Delay, you will learn what FID is, how it works, and why it is important, what impacts FID, how to measure FID, how to optimize FID, and more.
First Input Delay, Core Web Vitals, And Google Page Experience
You clicked on a website’s link or tapped a button. But nothing happened. What went wrong? It could be that the site you were trying to access wasn’t as responsive as it should be. Is it because of the poor First Input Delay metric? Most likely!
With the introduction of Core Web Vitals, Google is taking the issues with web experience even more seriously (not that it didn’t do so before). However, now in 2021, it has become even more important than ever to have a website that provides an excellent user experience.
Fortunately, there are several tools and tips that Google offers to fix Core Web Vitals and optimize a website for a better user experience.
So before we dig deep into FID, here is a quick reminder for you:
- Core Web Vitals metrics are currently made up of the three metrics, such as Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). Check my guide to Core Web Vitals.
- First Input Delay measures interactivity which is about how quickly a web page responds to an interaction from the user (more details about that in just a moment).
- Largest Contentful Paint measures loading (check the full guide to Largest Contentful Paint)
- Cumulative Layout Shift measures visual stability (check the full guide to Cumulative Layout Shift)
- Core Web Vitals are one of five Google page experience signals which also include mobile-friendliness, HTTPS, safe browsing, and intrusive interstitials guidelines.
So let’s now focus on First Input Delay (FID). How do you know whether or not your site meets the desired levels of responsiveness and interactivity that Google very much so desires? Let’s find this and a lot more out!
What Is First Input Delay?
First Input Delay (FID) is a part of Core Web Vitals and is a metric used to capture the first impression of the user when they click on a site. FID measures the amount of time it takes for your browser to respond when a user has interacted with a website.
Ideally, to provide a good user experience, FID should be equal to or less than 100 ms.
The interaction that FID measures could be:
- Clicking a link
- Pressing a button
- Tapping on the screen
The time it takes the browser to respond to these interactions and for the website to react to the interaction, is calculated as FID.
There are a few characteristics of that FID that you should know about:
- FID is a field metric, mainly because it gauges the response time of a website and how quickly the browser is actually able to load elements on the page after the user has interacted with it.
- The data that’s collected via FID can vary dramatically, depending on various factors, such as the network conditions and capabilities of a device.
- The FID data cannot be reproduced (accurately) in a controlled lab setting, since it’s based on real-world interactions.
This makes First Input Delay one of the most important Core Web Vitals metrics calculated to determine a website’s interactivity speed and responsiveness.
Measuring First Input Delay (FID)
Like most other metrics, Google offers clear guidelines regarding what a good FID score is and what needs improvement. But first, let’s take a look at what different FID times mean.
First Input Delay Scores
Google PageSpeed Insights categorizes field data into 3 separate buckets. These buckets describe the experience of the user as good, needs improvement, or poor.
The PSI tool sets these thresholds for GOOD/NEEDS IMPROVEMENT/POOR based on the analysis of the CrUX dataset, which gives you the following results:
Good: An FID of 100 ms or less is almost imperceptible, which means users won’t even notice the delay.
Needs Improvement: Users might not recognize a 300 ms delay, but the algorithms do, and they may see it as a website going in the wrong direction.
Poor: FIDs that extend beyond 300 ms can easily be noticed by users. They give off a vibe that the web page is “frozen” and unresponsive.
How To Measure First Input Delay
Since it’s a field metric, there are some field tools that you can “wield” to measure FID. A few tools that Google suggests are:
- Chrome User Experience Report or CrUX. Google PageSpeed Insights or PSI falls under the CrUX report. Below is an example of how PSI reports Core Web Vitals scores that include FID.
- The Google Search Console Core Web Vitals report. To access the report, navigate to Enhancements > Core Web Vitals > Mobile and OPEN REPORT.
It should be noted that the actual processing or updating of the website as a consequence of that first user interaction or user input is not measured by first input delay (FID).
☝️ Another thing you need to know about CrUX’s underlying reports PSI and Public Google BigQuery Project report is that PSI field data as compared to the Chrome User Experience Report on BigQuery gets updated on a daily basis (for the past 28-day period), while the latter (BigQuery) only gets updated on a monthly basis.
⚡ Check the tools to measure Core Web Vitals (a list of 17 tools).
The Reasoning Behind 75th Percentile
First Input Delay (FID) is important because a web page can only pass the Core Web Vitals assessment if the 75th percentiles of all three metrics (FID, LCP, and CLS) are GOOD.
The 75th percentile values for metrics are used to make sure all pages offer a good user experience even under the most difficult device and poor network conditions.
How To Measure FID In The Lab
Even though field metrics are enough and should be enough for measuring FID, there is a metric in lab tools that you can use as an alternative: The total Blocking Time (TBT) metric.
It is a measurement offered in lab tools and is a great alternative to First Input Delay. However, it should be used only to reassure you that your First Input Delay fixes and optimizations are working.
Total Blocking Time (TBT) measures the time between two factors:
- Time to Interactive (TTI): The time delay between the moment the page starts loading till enough of the page is loaded that it can respond to user input right away.
- First Contentful Paint (FCP): The time it takes for a web page to load the first bit of content. This tells the users that the page is ready for interaction.
Before FID became the norm, TTI used to be the go-to responsiveness metric. But TTI is a relatively poor measure for checking instructiveness because it doesn’t take user interaction into account.
Here are the lab tools you can use to measure TBT, TTI and FCP:
- Lighthouse is the number one tool you can use to measure lab metrics.
- Lighthouse Scoring Calculator that can help you visualize progress in a site’s scores as specific metrics are improved.
- Chrome DevTools is a tool that lets you dig a bit deeper into how your site loads and what scores it gets.
- WebPageTest is a more advanced but a brilliant lab tool you also want to be using.
The improvements in TBT very often correlate with improvements in FID, so it is a good idea to use these lab tools to test any improvements and fixes.
How To Optimize First Input Delay
Like all Google Page Experience signals, FID aims to minimize user annoyance. Google is going to make Core Web Vitals a part of their ranking factors because it wants to nudge developers into creating websites that offer more than just good, valuable content, but they offer a great user experience.
Besides, even if First Input Delay is going to become a soft ranking factor, its real-world impact can be quite painfully hard on a site’s traffic. If users find a website unresponsive or lagging, they might simply opt for an alternative resource. Therefore, optimizing FID is a good idea for multiple reasons.
- Long tasks that are executed sequentially
- Poor interactivity optimization
- A blocked main thread
Thankfully, there are a lot of possible fixes to each of the above issues. Let’s talk about each one.
A long task is any code used on a website that effectively acts as a blockade for the main thread for 50 ms. The most common practice here is code splitting.
Dynamic import syntax is utilized in various build systems, such as Parcel or webpack, amongst others, and also as a module bundler. Additionally, Vue, Angular, and React are some of the client-side frameworks that can be used for abstractions, making the process of lazy-load a lot more streamlined at a component level.
Optimize For Better User Instructiveness
In order to improve FID, the site needs to be optimized for interaction readiness. There are multiple culprits and possible fixes.
First-party script execution
Down is a simple before/after comparison which is achieved by simply optimizing the loading of first-party scripts for apps.
Data-fetching (i.e. cascading fetches and large inline data stores) can also have a negative impact on a site’s interaction readiness, negatively impacting the First Input Delay.
Problems with third-Party script execution can really have a huge impact on FID. Many sites make use of analytics and tags from third parties, which, under normal situations, are considered best practices, but can put pressure on the network and result in the main thread going unresponsive after short periods of time.
In some instances, third-party scripts can also come in the way of first-party scripts due to bandwidth and priority on the main thread.
A quick fix can be to explore on-demand loading of third-party code for better performing third-party tags and prioritize loading the content that is going to offer the most value to the user first.
Unblock A Blocked Main Thread
- Minimize all unused polyfills
This can take up more time than what’s needed to display a page and will result in a poor First Input Delay. This is why it is crucial to always load code that is absolutely necessary to display a page.
You can also use
async for scripts that are not important for functions, such as above-the-fold or critical-path content.
Minimize Unused Polyfills
But what if new browsers are also downloading this “glue” code that’s useless for them, wasting precious loading microseconds? That’s what you need to optimize for.
Using transpilers like Babel or delivering different bundles for different environments, you can ensure that unused polyfills are not loaded in the first place.
- Whenever a user visits a site, the text generally appears first, which is then followed by other elements of the web page.
How To Improve First Input Delay (FID) In WordPress
Currently, there are about 75 million sites using WordPress. This means that WordPress has a market share of about 40%, which means it powers 40% of all the websites on the Internet. The chances are that either your site or the site you are auditing is based on WordPress.
So how do you optimize FID and other Core Web Vitals in the case of WordPress websites?
A few things to note here and a bunch of best practices on optimizing Core Web Vitals in WordPress:
- Many WordPress websites have poor scores of FID because they have tons of unused plugins and outdated themes. Cleaning this up can often make a huge difference!
- Many WordPress optimizations can be automated with the use of special speed and optimization plugins. Remember, however, that this may be a two-edged sword. Too many plugins will always have a negative impact on a site’s speed and performance.
- The best plugin to use to improve the Core Web Vitals metrics of a WordPress site (from my own experience) is WP Rocket which automatically implements all the most important optimizations, such as:
- Page caching
- Browser caching
- Database optimization
- Lazy Loading
- Cache and sitemap preloading
- DNS prefetching and resource preloading
- Optimization of web fonts
- Deferring JS loading
- Here are the results my website achieved thanks to WP Rocket. Check my review of WP Rocket to learn more about the plugin.
- Once the plugin has done its job and you are not satisfied with the result, you may think about hiring a developer who may implement some extra fixes.
- In addition to using a good performance plugin and possibly hiring a developer, you should also make sure the server is also optimized and uses the latest software (e.g. the latest version of PHP).
- Avoiding cheap or unknown WP themes can go a long way in optimizing a WordPress site.
GET ACCESS TO PREMIUM SEO CONTENT
Members of SEOSLY Pro get access to Olga’s SEO audit video guide where she documents her 500+ step SEO audit process, Olga’s mini video SEO audits, SEO audit templates, pro SEO auditing tips, and much more!
Join SEOSLY Pro to become a technical SEO expert in no time.
Olga Zarzeczna is a senior SEO specialist with 8+ years of experience. She has been doing SEO for both the biggest brands in the world and small businesses. She has done more than 150+ SEO audits so far. Olga has completed SEO courses and degrees at universities, such as UC Davis, University of Michigan, and Johns Hopkins University. She also completed Moz Academy! And, of course, has Google certifications. She keeps learning SEO and loves it. Olga is also a Google Product Expert specializing in areas, such as Google Search and Google Webmasters.