Skip to content
50% OFF $299 $599
Lock in
§ 6.0.12 ARTICLE
Published Threshold≤ 200ms good Sources2 named Authored bySquareRank Team

Glossary · § 6.0.12 · Defined term

Interaction to Next Paint (INP)

Interaction to Next Paint (INP) is the time from a user interaction — click, tap, key press — to the next paint that reflects the result1. INP became a Core Web Vital on 12 March 2024, replacing First Input Delay (FID)2. The "good" threshold is 200 ms or less at the 75th percentile of real-user measurements.

INP captures the entire interaction: input delay, the processing time of any handler that runs in response, and the time to render the resulting change. FID only measured the input delay portion. The change from FID to INP made the metric meaningfully harder to pass for JavaScript-heavy sites.

Definition

Interaction to Next Paint (INP) is the time from a user interaction (click, tap, key press) to the next paint that reflects the result. INP became a Core Web Vital on 12 March 2024, replacing First Input Delay (FID). The 'good' threshold is 200 ms or less at the 75th percentile.

INP measures the worst interaction observed during the page lifespan (specifically, near the 98th-percentile-worst on long sessions), not the average. One painful interaction is enough to fail the metric for the whole page view. This is intentional — a user remembers the worst interaction more than the median one.

Why INP replaced FID

FID measured only the delay before a handler started running. INP measures the full round-trip from input to visual update. The change captures the user's actual experience of interaction lag rather than just the JavaScript thread availability at input time. Sites that passed FID by being fast at the first interaction often fail INP because subsequent interactions (or the work done by the first handler) take meaningful time.

The transition was announced in May 2022, INP ran as an experimental Web Vital from then through 12 March 2024, and on that date INP became the official interactivity Core Web Vital with FID retired. A site that hadn't paid attention saw its CWV score change on the 12 March 2024 calendar boundary.

What causes slow INP

Three main causes. (1) Heavy JavaScript event handlers — code that takes more than 50ms to execute on the main thread blocks paint. (2) Long tasks unrelated to the interaction — analytics scripts, third-party widgets, framework hydration — that occupy the main thread when the user interacts. (3) Large rendering work — interactions that trigger expensive layout or paint, like opening a modal that contains complex SVG or many DOM nodes.

On a Squarespace 7.1 site the most common offender is category (2): third-party scripts injected via Code Injection that aren't deferred or async-loaded. A site with a chat widget, an analytics tag manager, and a popup tool can have a clean Squarespace-side INP but a degraded composite INP because of the third-party overhead.

INP on Squarespace specifically

Squarespace passes INP out of the box on most pages — the platform's JavaScript bundle is reasonably well-optimised for interaction responsiveness. Where INP fails on Squarespace it's almost always due to Code-Injected third-party scripts. The install pattern: audit which scripts are loaded, defer or async every non-critical one, remove anything that does not earn its main-thread time.

A practical sequence: open the page in Chrome DevTools, run the Performance tab while clicking the page's primary interactive elements, find the worst INP interaction in the recording, identify which script's handler is blocking the thread. If it's Squarespace's own code, there's not much to do; the platform handles its own. If it's a Code-Injected third party, the fix is usually one of: defer the script, async it, remove it, or replace it with a lighter alternative. The full Squarespace install for JavaScript discipline lives at Squarespace JavaScript / defer.

INP is one Core Web Vital. Adjacent terms below.

Keep reading · § 6.0.12