![\"\"](\"https:\/\/www.hostinger.com\/tutorials\/wp-content\/uploads\/sites\/2\/2022\/11\/eBook_-Build-website-in-9-steps_in-text-banner-1-1024x283.png\")
<\/a><\/figure>\n\n\n\n\n\n
What Is First Input Delay (FID)?<\/h2>\n
The First Input Delay is a metric used to track the delay time of the browser until it responds to user input, including clicks and taps. <\/p>\n <\/div>\n\n\n\n<\/p>
Why Is First Input Delay Important?<\/h2>
One of the factors that can affect the impression of a website is the first input delay. It is of the Core Web Vitals metrics, along with the Largest Contentful Paint (LCP), Cumulative Layout Shift (CSL), and the Interaction to Next Paint (INP).<\/p>
With Core Web Vitals, you can measure your page performance as well as investigate a provided report to help you improve your site and put it on the top of the search engines<\/a>.<\/p> Furthermore, those metrics impact user experience and a website’s ranking, affecting your search engine optimization (SEO) efforts. Page speed<\/a> is one of the main Google ranking factors.<\/p> If the website takes a long time to respond to a user’s interactions, it will also make users frustrated.<\/p> As most responsiveness issues occur when a web page is loading, keeping the first input delay score low is vital.<\/p> \n\n\n Read our detailed tutorial on 10 effective strategies to improve your Core Web Vitals<\/a>.<\/p>\n <\/div>\n\n\n\n<\/p> Having gone over why the first input delay is important for your page, it is time to test it to improve your website performance for better user interaction.<\/p> Unlike the cumulative layout shift and the largest contentful paint, the first input delay can only be measured with real user interaction on the page.<\/p> Here’s the list of tools you can use to test your first input delay:<\/p> For example, if you want to use PageSpeed Insights to test your first input delay, just enter one URL in the search box. Having done so, you will get an assessment of Core Web Vitals on your page and suggestions to improve your page. You can also see how long the input delay is on your web page.<\/p> Generally, 0.1 seconds is the limit for having the user feel that the system is reacting instantaneously.<\/p> As a result, to get a good score from the first input delay and fast user input, a website needs an FID of less than 100 ms<\/strong> as the maximum. Ideally, it should have less than 100 ms<\/strong> from 75%<\/strong> of all page loads, including mobile and desktop devices.<\/p> The graph below shows how the first input delay score is categorized into good, needs improvement, and poor.<\/p> The Max Potential First Input Delay (MPFID) is the longest task of a page. The MPFID measures a page’s response time while the longest task is running. Note that the measurement starts only after the first contentful paint is calculated.<\/p> The score results are taken from the comparison of the max potential FID time with the max potential FID times in real websites. For example, if you get your MPFID a green score, it means that your page performs better than 90%<\/strong> of real websites.<\/p> When you get a low first input delay score, identify which parts of the page need improvement to make your page work better.<\/p> One of the leading causes that make browsers unable to respond to user interactions promptly is user input getting blocked. It occurs when the browser’s main thread is busy doing other tasks.<\/p> These tasks usually include dealing with HTML, CSS, and Javascript, making them overworked. A long JavaScript task is a common error that causes the main thread to delay, and event listeners can’t run on the page. To find this problem, use PageSpeed Insights and look under the Avoid long main-thread tasks<\/strong> audit section.<\/p> After learning how to test your FID score and finding out any potential causes, it is time to optimize it.<\/p> Usually, JavaScript has the most significant impact on your FID score. For that reason, it is essential to optimize your JavaScript code.<\/p> Follow the suggestions below to do so:<\/p> Difficulty level: <\/strong>easy<\/p> Impact: <\/strong>high<\/p> When the browser’s main thread is busy and blocked, user requests cannot be processed. This makes the page unresponsive. The inadequate responsiveness is caused by a task running longer than 50 ms<\/strong>.<\/p> JavaScript tasks consume lots of resources that can affect your website speed performance<\/a>. To solve this problem, remove them or divide long tasks into smaller, asynchronous ones. At least, one task should take under 50 ms<\/strong>.<\/p> You can use the setTimeout<\/strong> function to break long tasks into smaller tasks as it will make the main thread respond to user inputs without delay.<\/p> Difficulty level: <\/strong>medium<\/p> Impact: <\/strong>high<\/p> Having a fast-loading website can improve its user experience. Many components, such as large images or JavaScript tasks, slow web browsers down.<\/p> To solve this issue, create progressive loading code by bundling all your JavaScript files into bundle.js<\/strong>. For this, you can use a webpack<\/a>.<\/p> Bundling also helps you minimize the page size and remove unused code or more easily minify it. Moreover, it makes the browser only load UI components when required.<\/p> Difficulty level: <\/strong>hard<\/p> Impact: <\/strong>high<\/p> Server-side rendering<\/a> (SSR) refers to displaying web pages on the server.<\/p> With the server-side render, your page is displayed quickly without waiting for resources to become available. It can solve indexed pages and crawl budget issues, benefiting your SEO<\/a>.<\/p> Moreover, server-side rendering can increase the speed of the first contentful paint and time to interactive (TTI) by avoiding sending large JavaScript files to the client. As a result, your web page load will run faster.<\/p> You can render the server-side version using front-end frameworks like Vue<\/strong>, React<\/a>, or Svelte<\/strong>. Before using those applications, make sure you have installed Node.js<\/a> to run JavaScript on the server.<\/p> Difficulty level: <\/strong>medium<\/p> Impact: <\/strong>high<\/p> Unlike server rendering, static rendering generates a single HTML page prepared once at build time. It helps the user access the page ahead of time.<\/p> You can use a static site generator, like Gatsby, to create static HTML pages from data, content, and templates. Then, it will generate a view of a page that can be served to the users.<\/p> Note that static rendering is not suitable for large sites that contain many pages or require response changes on every request. By generating all of your content, the site needs to be deployed and tested, affecting real-time updates. Moreover, your deployment could become impractical.<\/p> Difficulty level: <\/strong>hard<\/p> Impact: <\/strong>high<\/p> A slow page loading time can be caused by a third-party script that adds functionality to websites, such as live chat, ads, and analytics. Third-party code can cause problems, like processing too many network requests to different servers sending large JavaScript tasks or images files that block the main thread.<\/p> To review your third-party scripts, you can test your site on PageSpeed Insights. It will show you lists of the loaded third-party resource, along with the transfer size and the main thread blocking time.<\/p> Use async or defer attributes to improve your loading times in the third-party scripts. Doing so will help you eliminate the rendering blocking issue and trigger a faster web page loading process. Important scripts that are vital to the page load should not use async or defer attributes as it is only for external scripts.<\/p> Difficulty level: <\/strong>hard<\/p> Impact: <\/strong>high<\/p> Web workers<\/a> help reduce the main thread blocking time and improve the FID score of your site. They allow you to put long tasks on the background thread without interfering with the user interface, making your website more responsive.<\/p> Use the Worker(“path\/to\/worker\/script”)<\/strong> code to create a worker. It can send messages to the JavaScript code by posting messages to an event handler specified by that code and vice versa. Additionally, a web worker can perform input or output tasks using the XMLHttpRequest<\/a> or a fetch<\/a>.<\/p> To help you use a web worker, check out the following libraries:<\/p> Difficulty level: <\/strong>hard<\/p> Impact: <\/strong>high<\/p> Too many JavaScript tasks will take a lot of time to be parsed and executed. As a result, the browser’s response time will be delayed. The browser will pause when it finds a script tag that links to the external JavaScript code. That’s why it’s important to run only the needed code.<\/p> There are some options to optimize JavaScript, such as code-split and defer any non-critical JavaScript. Before that, you can use the Coverage<\/a> tab in Chrome DevTools to see how much unused JavaScript is on your web page.<\/p> Code-splitting allows you to split a JavaScript bundle into chunks and help your page load only when needed. This is also known as lazy loading<\/a>. Meanwhile, to defer any non-critical Javascript task, always use async or defer<\/a> for scripts that are not vital for the critical rendering path<\/a> or above the fold<\/a>.<\/p> Difficulty level: <\/strong>hard<\/p> Impact: <\/strong>low<\/p> Polyfill is code used to provide modern features on older browsers that do not natively support it. For example, when using modern JavaScript syntax and browser APIs to create code, you will need to transpile it and deliver polyfills so that the modern features will run in older browsers.<\/p> The usage of polyfills will create more bundles that will take a longer time to load for the browser. Therefore, it is essential to minimize the unused polyfills and only use them when needed.<\/p> To cut down the load time needed for your web page, you can use a JavaScript compiler, such as Babel, and use @babel\/preset-env<\/a> to include the required polyfills for older browsers. You can also cut down unused polyfills by enabling the bugfixes option for Babel 7.9.<\/p> Alternatively, deliver two separate bundles using module\/nomodule<\/a> to optimize polyfills.<\/p> The First Input Delay (FID) is a metric that must be tested with a data field based on real user interaction. Additionally, you should monitor other metrics that correlate with FID.<\/p> Let’s analyze in detail how the other metrics relate to FID scores.<\/p> The first contentful paint measures how long it takes to load on a page from initial loading until the content is displayed on the screen. The page content comes from the Document Object Model (DOM), including images, text, or charts.<\/p> Meanwhile, the first input delay measures how long it takes for a browser to respond. These two things significantly affect the user’s first impression before and after interacting with the page. FID and FCP have a solid correlation to give users a better first impression.<\/p> In addition, a fast FCP helps users be aware that the information they request is being processed, making them stay on the site.<\/p> Time to Interactive (TTI) measures how long it takes for a page to become fully interactive. The measurement starts after the FCP is performed when the user can interact on the page.<\/p> A fully interactive page means a page responds to user interaction in less than 50 ms<\/strong>, and event handlers are registered for the majority of visible page elements.<\/p> By knowing your TTI, you can identify whether your website pages are entirely usable. Along with good FID, your pages can be fully interactive as the user needs.<\/p> Total Blocking Time (TBT) and FID are pretty similar. They both measure how long the response time on the page is. The difference is TBT does not use user input. In short, TBT is the amount of time during which long tasks block the main thread.<\/p> Long Javascript tasks on web pages can affect FID and TBT assessments. By looking at the FID and TBT metrics, you can see how significant the impact of long tasks is on the site’s responsiveness.<\/p> These two metrics create a strong correlation and influence each other in the usability of a page. Therefore, increasing your TBT score can be used to optimize your FID.<\/p> \n\n\n Largest Contentful Paint (LCP): What It Is and 11 Ways to Improve It <\/a> Having a responsive website significantly impacts your website’s user experience. That’s why testing and analyzing core web vitals is essential, including the first input delay (FID). By doing so, you can improve the performance of your website pages.<\/p> The most common issue that causes long input delays is a blocked main thread. It is usually caused by unoptimized JavaScript. Therefore, to improve the first input delay score, optimize your JavaScript code by:<\/p>Suggested Reading<\/h4>\n
How to Test Your First Input Delay<\/h2>
\n
\n
![\"An](\"https:\/\/www.hostinger.com\/tutorials\/wp-content\/uploads\/sites\/2\/2024\/03\/core-web-vitals-desktop-1-1024x627.png\")
<\/a><\/figure>What Is a Good FID Score?<\/h3>
![\"First](\"\/tutorials\/wp-content\/uploads\/sites\/2\/2022\/03\/screenshot-of-first-input-delay-score-up-to-100-ms-is-good-up-to-300-ms-needs-improvement-and-more-than-300-ms-is-poor..jpg\")
<\/a><\/figure><\/div>Max Potential First Input Delay<\/h3>
![\"Max](\"\/tutorials\/wp-content\/uploads\/sites\/2\/2022\/03\/screenshot-of-max-potential-FID-time-in-milliseconds-0-100-is-fast-100-300-is-moderate-over-300-is-slow.jpg\")
<\/a><\/figure><\/div>How to Find the Cause of a Low FID Score<\/h2>
![PageSpeed Insights scressnshots with \"avoid long main-thread tasks\" highlighted](\"\/tutorials\/wp-content\/uploads\/sites\/2\/2022\/03\/screenshot-of-PageSpeed-%E2%80%8B%E2%80%8BInsights-with-the-avoid-long-main-thread-tasks-option.-1024x482.png\")
<\/a><\/figure><\/div>8 Ways to Optimize Your First Input Delay (FID)<\/h2>
1. Divide Long Tasks Into Smaller Ones<\/h3>
2. Implement Progressive Loading<\/h3>
3. Move Logic to Server-Side<\/h3>
![\"Hostinger](\"https:\/\/www.hostinger.com\/tutorials\/wp-content\/uploads\/sites\/2\/2023\/11\/Web-hosting_in-text-banner.png\")
<\/a><\/figure>4. Generate Content Statically<\/h3>
5. Review Third-Party Script Execution<\/h3>
6. Utilize Web Workers<\/h3>
\n
7. Optimize Unused and Non-Critical JavaScript<\/h3>
8. Revise Polyfills Usage<\/h3>
First Input Delay in Relation to Other Metrics<\/h2>
First Input Delay vs. First Contentful Paint (FCP)<\/h3>
First Input Delay vs. Time to Interactive (TTI)<\/h3>
First Input Delay vs Total Blocking Time (TBT)<\/h3>
Learn More About Other Core Web Vitals<\/h4>\n
\nCumulative Layout Shift (CLS): What It Is and How to Improve It<\/a>
\nINP: Understanding the New Core Web Vitals Metric and How to Optimize for It<\/a><\/p>\n <\/div>\n\n\n\n<\/p>Conclusion<\/h2>
\n