• What is First Input Delay (FID)?

First Input Delay (FID)

First Input Delay (FID) refers to a former Core Web Vital that measured the time between a user’s first interaction with a page and the moment the browser was ready to respond. FID was replaced by Interaction to Next Paint (INP) as a Core Web Vital in March 2024 because INP captures the full interaction latency while FID only measured the initial delay. FID remains a useful diagnostic metric but is no longer a ranking-eligible Core Web Vital.

What FID measured

FID specifically tracked:

Time from user input to event handler start. Only the delay before the browser could begin processing the interaction. Didn’t capture processing time or rendering time.

First interaction only. Only the first click, tap, or keypress on the page was measured. Subsequent interactions were ignored.

Target: under 100 milliseconds. The threshold for ‘good’ FID.

Why FID was replaced by INP

Three limitations FID had:

Missed the rest of the interaction. A page where the first click was fast but every subsequent click was slow would score well on FID but poorly in real-user experience.

Missed processing and rendering time. Even with low input delay, if the event handler took 500ms and the DOM update took another 300ms, FID wouldn’t reflect the total interaction pain.

Didn’t capture JavaScript-heavy pages well. Many modern sites have interactivity issues that FID systematically missed.

INP addresses all three: measures every interaction, captures full cycle (input โ†’ processing โ†’ presentation), more sensitive to JavaScript issues.

Is FID still useful?

Three scenarios where FID-style measurement still matters:

Diagnostic use. Even though INP is the ranking-relevant metric, FID can help isolate whether an interaction problem is at the input-delay stage or later in the cycle.

Historical comparison. Sites with long-running FID data can use it to track longer-term trends, understanding that INP and FID aren’t directly comparable.

First-impression-specific concerns. A page whose first interaction is especially performance-critical (e.g., a search input on a search site) may still benefit from FID-style measurement as a supplementary metric.

Migrating from FID to INP measurement

Three practical steps:

Update monitoring and dashboards. Replace FID as the primary interactivity metric; add INP.

Recalibrate thresholds. INP’s ‘good’ threshold is 200ms (versus FID’s 100ms). Don’t copy the FID target to INP.

Audit interaction-heavy pages specifically. INP tends to surface problems on pages with many interactions (dashboards, long forms, rich SPAs) that FID didn’t flag.

What caused poor FID (and now INP)

Four causes that affected both metrics:

Heavy initial JavaScript bundles. Large bundles blocking the main thread for long periods after page load.

Third-party script initialization. Analytics, ads, chat widgets initializing synchronously, blocking interaction response.

Framework hydration. React/Vue/Angular apps hydrating client-side after initial render, with interaction latency during that window.

Synchronous heavy event handlers. Interaction handlers doing compute-heavy work synchronously instead of deferring.

How FID compared across industries

Three patterns from research during FID’s active period:

E-commerce struggled. Heavy client-side personalisation and tracking scripts.

News sites were mixed. Ad-heavy sites scored poorly; editorial-focused with lighter monetisation scored well.

Developer and documentation sites scored well. Lean stacks, minimal third-party.

Penfriend and FID/INP

Penfriend-produced content is static HTML with no interactive JavaScript at the content level. FID and INP on Penfriend pages are driven entirely by the host site’s template and scripts. The content itself doesn’t contribute to interactivity problems - which is sometimes surprising to teams that assume AI-generated content would bloat their JavaScript. Clean HTML stays clean regardless of how it was produced.

Related terms