What is First Input Delay (FID)?
First Input Delay (FID) is a Core Web Vitals metric defined by Google that measures the interactivity and responsiveness of web pages. When calculating a PageSpeed score for a URL, the First Input Delay (FID) value represents the time lag between the first user interaction with the page elements and when the web browser is actually able to process the user request.
When a user clicks on an interface element, such as a menu, button, or does any interaction triggering JavaScript event handlers, the web browser may still be busy doing something else, such as loading and rendering HTML, CSS, or executing scripts and not able to respond immediately to the request. Input latency creates a delay in event processing which is recorded as the FID value, determined by the time for the main thread to become fully idle.
Core Web Vitals prioritizes interactivity in the user experience (UX), which is negatively impacted by long page load times that decrease the responsiveness of page elements. Unlike other Google PageSpeed metrics, the First Input Delay (FID) value is totally reliant on field data from users. The calculation of FID requires a real user to interact with the web page directly.
What is First Input Delay (FID)?
First Input Delay (FID) is one of the three metrics that are used in the Core Web Vitals test. The other two factors are Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). The First Input Delay (FID) value is determined by Chrome User Experience Reports representing the field data from web browsers that have accessed the page historically. Google refers to this as Real User Monitoring (RUM). The calculation of the Google PageSpeed score by Lighthouse does not explicitly include the FID field data, but provides the TTI estimate from lab data.
First Input Delay (FID) was established to measure the first impression that users receive when interacting with a web page. The metric is a primary gauge of the responsiveness of page elements and the overall usability of the interface. GUI elements like menus, buttons, checkboxes, text fields, and links may be visibly rendered to the user, but their responsiveness can be delayed as the browser downloads other HTML, CSS, and JavaScript files. FID measures this delay time. The Time To Interactive (TTI) metric is similar, but does not record any user event activity.
The first input is defined as events from user interactions like mouse clicks, screen taps, and keyboard activity. The delay is calculated by measuring the time between the point when the first input event is recorded by the user and the main thread is fully idle or the browser is able to process the request. Note that this is the time that it takes for the browser to start processing the request, rather than the interactive response itself. In the example of the use of a dropdown menu, this is not recorded as the time required for the browser to open the dropdown, but rather the time that it takes for the browser to be able to “understand” the visitor clicked on it.
User experience (UX)
The PageSpeed score for a web page is calculated on the basis of statistical metrics that measure the perceived load speed, load responsiveness, runtime responsiveness, visual stability, and smoothness of the user experience (UX). The RAIL model divides the life cycle of a web application into the categories of response, animation, idle, and load for performance analysis. These factors allow the user experience to be standardized for assessment in SEO.
Not all of the Core Web Vitals information is included in the calculation of a PageSpeed score. The two tests are designed to complement each other. Core Web Vitals are primarily intended to evaluate whether a URL delivers its content and becomes interactive in a time under 5 seconds in production. The key performance metrics of the assessment are related to the user experience (UX). Google recommends that a web page delivers a visible response within 100 ms, animates a frame within 10 ms, and processes user input events within 50 ms.
In practice, the Core Web Vitals and PageSpeed reports should both be used for SEO when evaluating the user experience (UX), as improvements made to one will be carried over to the other beneficially. However, professionals should recognize that they are not identical standards. Google prioritizes the user experience (UX) for search engine rankings, combining CWV analysis with factors related to content, keywords, URL structure, titles, etc. in their algorithm weighting system. Web pages need to optimize all of these factors to rank favorably in SERPs.
What does FID measure?
First Input Delay (FID) measures the responsiveness of a web page when it is loaded in the browser. Specifically, it represents the time interval between when a user input event is first received and the main thread loading all of the required page elements and executing scripts becomes idle. If a web browser is still loading the HTML, CSS, and JavaScript files required for display and functionality or doing other long tasks in the main thread, it cannot process the user input from clicks or screen taps in the GUI effectively until it finishes. FID is used to assess these delays.
First Input Delay vs. Time to Interactive
The First Input Delay (FID) metric represents the average time for desktop and mobile views to become fully responsive on a web page, including user access by different endpoint devices and connection speeds. Long first input delays typically occur between the First Contentful Paint (FCP) rendering and the Time to Interactive (TTI), primarily because the web page has downloaded some of its display and GUI content but isn’t yet reliably interactive for users.
To illustrate how this can happen, FCP and TTI have been added to the timeline for SEO analysis. The Time to Interactive (TTI) value is calculated from lab data by Lighthouse and other tools, measuring the length of time required for the page to visually render, fully load all required scripts, and become capable of responding to user input through idleness of the main thread. In contrast to the FID formula, TTI does not require any real user activity on a page to calculate.
What is a good FID score?
Google defines a “good” First Input Delay (FID) score as less than 100 ms of input latency. A FID score of 100 to 300 ms is rated as “needs improvement” and any value over 300 ms is considered to be “poor”. The average of 75% of the users determines the overall rating. With an input latency of less than 85 ms, any click by a user on the interface elements will be experienced as a real-time event. Any FID lags over 100 ms are perceived as being delayed.
Statistical data & threshold value
The Chrome User Experience Report (CrUX) is used in the calculation of Core Web Vitals on the basis of real user experiences across millions of websites. This public dataset includes information on the type of device and speed of connection that the web browsers use to access a URL. Google has determined that the experience of 99% of desktop users and 78% of mobile browsers at the 75th percentile is rated as “good” at the threshold value of 100 ms for FID.
How to measure First Input Delay (FID)?
The First Input Delay (FID) value is calculated from field data that is generated by users who opt in to user experience reporting while navigating the web with the Chrome browser. Response to control activation is measured by recording the initial mouse, keyboard, or touch-pad activity entered by the users on the page and the time delay required for the input to be processed. These values are averaged to the 75th percentile by discarding the outlier values in the data set and the running average of the last 28 days of user activity produces the FID score for the page.
Assessment tools
The easiest and most common way to assess an FID score is by entering a URL into the Google PageSpeed Insights interface and generating a report. Because FID is based on field data, it is not always available. If the webpage is new and has not had enough visitors yet, there might not be enough data to reference. As the Chrome User Experience Report (CrUX) data is public, it can be accessed directly to see a detailed record of the types of devices and speed of connection of the user base. The Core Web Vitals report can also be generated by using Google’s Search Console service. Another method for analyzing the FID score is to install the web-vitals JavaScript library on the web server with custom code embedded on pages.
JavaScript calculation
The FID score can be calculated using JavaScript through the web-vitals library or by implementing code for the Event Timing API (part of the web-platform-tests project available on GitHub). The web-vitals library includes a simple call (getFID) that will automatically calculate the First Input Delay value for a web page and log it to an analytics console. This records values for different users and devices. Both solutions install on a web server independently and can be used to run comprehensive performance tests on URLs to determine Core Web Vitals scores.
What affects First Input Delay (FID)?
The FID score only measures the first user interaction with a web page. It does not take into account scrolling or zooming. If there is no user activity with the menus, links, or interface elements, a FID score is not recorded. The biggest problem leading to poor FID scores is third-party JavaScript files that need to be fetched from a remote server and take extra time to download. Analytics scripts, web fonts, tracking, and sharing buttons can cause long delays.
Large image files and iframe content can require significant bandwidth on slow connections and delay the loading of other page elements that are required for functionality. Polyfills that preserve JavaScript functionality for older browsers can add extra file size to downloads if they are served to users who do not require them. Advertisements that are fetched from a third-party server can also cause delays in rendering if the remote server does not respond quickly.
Page blocking occurs when large JavaScript files are embedded at the top of a page and prevent lower-level elements from becoming fully functional until they are downloaded and executed by the web browser. A slow remote server response time can affect the FID score by adding a delay before the web font, iframe, and third-party JavaScript elements are able to be downloaded. Most problems and issues can be debugged in the PageSpeed Insights report.
Contributing factors
New websites without sufficient field data from user reports on URLs will be difficult to analyze for FID through PageSpeed Insights reports. Open source CMS sites that operate without web page caching or CDN integration will perform the worst due to the need to query the database and run PHP code to render functional elements. Operating CMS sites on old versions of PHP can also slow down performance. Any site that lacks proper implementation of compression and minification for HTML, CSS, and JavaScript files will likely score poorly on First Input Delay (FID) ratings. GUI and design elements must always be optimized for the user experience.
Common examples
For websites running on shared, VPS, or dedicated servers, the initial call for a URL first goes to the DNS server which matches the domain name to an IP address. The web browser is then able to load the HTML, CSS, and JavaScript files required for functionality and display from the web server. If web page caching is not implemented to convert the dynamic content to a flat file or distribute it through a CDN, the need to query a database for the resource requests adds significant overhead to the time required to load a page. Web page caching eliminates these steps and simply serves a flat file to users that can be downloaded much more quickly overall.
How to improve First Input Delay (FID)?
The First Input Delay (FID) score is improved through PageSpeed optimization techniques that reduce the total file size of the download and limit the complexity of load elements in the main thread. This includes HTML, CSS, JavaScript, and image file size compression, as well as the lazy-loading of image files, iframe content, and videos. Lazy-loading creates a placeholder for image display and only downloads the file when it is in the active viewport, reducing the total time it takes a web page to become responsive. Compression of image files and conversion to file formats like WebP can reduce the total image size over 50% from .jpg and .png standards.
In most instances, all of the approaches for PageSpeed optimization cannot be implemented on every URL. Some of the SEO techniques require a major change of page structure and content. To reliably improve the FID score, make sure to address the factors below on each webpage:
- The Parsing of HTML and CSS
- The Extraction of Critical CSS
- The Minification of CSS Files
- The Deferment of Non-Critical CSS
JavaScript is run in the web browser and requires local resources on the user device to process. The total size of JavaScript files can be reduced by minification, which removes the script elements that are unneeded for the page display from the file entirely. Adding compression to the minified JavaScript file reduces the file size even further. Delaying the loading of JavaScript files until they are needed by the display is another technique that can improve the time required for a page to become interactive. Injecting inline CSS can reduce the load time of stylesheets.
Making use of the “Opportunities” recommendations provided by the Google PageSpeed report is the best way to perform search engine optimization (SEO) for Core Web Vitals. The most important techniques to improve the FID score involve reducing the total file size and complexity of the web page so that it will become responsive more quickly. Some of the best methods are to reduce the impact of third-party code and to delay the loading of third-party JavaScript resources by making them non-render blocking, async, and not required on the main thread. Examples of these elements are tracking and analytics scripts, popup chat windows, etc.
The framework that a website is built with can have a significant effect on the page load speed. Sites built with open source CMS platforms like WordPress, Drupal, and Joomla need to adopt automated techniques for PageSpeed optimization through plugin, module, and back-end solutions that implement the recommendations listed above to be successful in improving the FID score. It is especially important to configure web page caching and use a CDN service.
How to fix FID scores for WordPress sites?
WordPress is an open source CMS with a wide variety of free and subscription-based plugins that are available for Google PageSpeed optimization. Most of these are designed to provide solutions for common problems that are flagged by the PageSpeed report audit. One of the most common recommendations for WordPress sites is to “defer parsing of JavaScript.” This method delays the download of JS files until after the main content has rendered and becomes responsive, improving the FID score dramatically.
Browser caching of UI elements and compression of HTML/CSS files are other important tactics that minimize the total file size of downloads for a WP page. Establishing a cache validator requires WordPress administrators to add cache-control headers with last-modified and etag values so that the browser can determine if content has been modified since the last page load. Cache-control headers allow websites to declare the amount of time that content should remain in the cache before expiring. You may need to edit the .htaccess file for the cache settings to propagate across a WordPress site. Make sure to minify and defer the loading of non-critical CSS files, or inject the code inline for better load times. Automating these tactics across a WordPress site with back-end support will improve the FID score across all of the pages.
When the caching system for a WordPress site has been established, it can be further optimized for Google PageSpeed and Core Web Vitals by implementing the optimization techniques listed above. The most important tactic is the compression of HTML, CSS, JavaScript, and image files, which reduces the overall download size. JavaScript minification, lazy-loading of images, inline injection of CSS, and web server optimization will also boost the performance of WordPress websites. Remove unrequired plugins and third-party scripts that can lead to unexpected delays in page loads to improve FID scores. Browser caching speeds up the loading of GUI elements.
10Web Booster
10Web Booster is a comprehensive plugin solution for optimizing WordPress websites for Google PageSpeed and Core Web Vitals. 10Web Booster service implements comprehensive front-end and back-end optimization solutions for WordPress that apply the recommendations of the PageSpeed Insights report. 10Web Booster will improve the FID score of production websites automatically without the need for complex configuration of settings in wp-admin.
10Web Booster delivers:
- HTML, CSS, and JavaScript compression + minification
- Image compression and conversion to WebP format
- Lazy-loading of images, iframe content, and videos
- Optimized CSS and web font delivery for displays
- Web server performance optimization for CWV
- Guaranteed 90+ Google PageSpeed Insight scores
10Web Booster increases mobile traffic engagement for WordPress sites, improves page load speeds for better user retention, and leads to higher ecommerce conversion rates in production. Web publishers can sign up to get started with 10Web Booster for free with the choice of complete front-end optimization for Google PageSpeed running on your current hosting solution or high-performance back-end support running on Google Cloud Platform with Booster Pro.
