First-Input-Delay<\/a> is a user-centric performance metric that measures the time between a user's first interaction with a webpage and the moment the Browser-Rendering-Engine<\/a> is able to start processing that interaction. It is a critical component of the Core-Web-Vitals<\/a> suite, specifically targeting the responsiveness and interactivity of a site during its initial load phase.<\/p> The primary cause of a poor First-Input-Delay<\/a> is heavy JavaScript<\/a> execution. When the Main-Thread<\/a> is occupied with parsing and executing large script files, it cannot respond to user inputs such as clicks, taps, or key presses. This creates a lag that can frustrate users and lead to higher bounce rates. While Lighthouse<\/a> provides a proxy metric called Total-Blocking-Time<\/a>, FID is a field metric that requires real user data, often collected via the Chrome-User-Experience-Report<\/a>. Documentation on optimizing these interactions can be found at web.dev<\/a>.<\/p> To provide a good user experience, sites should strive to have a First-Input-Delay<\/a> of 100 milliseconds or less. A delay between 100ms and 300ms is categorized as needing improvement, while anything above 300ms is considered poor. Developers can optimize these scores by minifying scripts, removing unused JavaScript<\/a>, or implementing code-splitting. Further technical details are available on MDN Web Docs<\/a>.<\/p> In the evolving landscape of Web-Performance<\/a>, Google has replaced FID with Interaction-to-Next-Paint<\/a> (INP) as a Core Web Vital. INP is considered a more comprehensive metric because it measures all interactions on a page, whereas FID only measured the very first one. More details on the transition can be found at web.dev's blog<\/a>.<\/p>Technical Mechanism<\/h2>
Thresholds and Benchmarks<\/h2>
Transition to Interaction to Next Paint<\/h2>
Related Topics<\/h3>