Mastering INP: Core Web Vitals with Astro Islands

The Sunset of FID: Why Google Re-Engineered Input Responsiveness

In 2024, Google made the most consequential change to its Core Web Vitals in four years: the permanent retirement of First Input Delay (FID) in favor of Interaction to Next Paint (INP).

To leadership and non-technical stakeholders, the acronym change seemed minor. To engineering teams maintaining monolithic Single-Page Applications (SPAs) and heavy server-side rendered frameworks (Next.js, Remix, Nuxt), it triggered an algorithmic reckoning.

Under the legacy FID metric, good Core Web Vitals were much easier to earn. The HTTP Archive’s Web Almanac found that 48% of mobile websites passed all three Core Web Vitals in 2024 with FID in place, against 43% once INP took over. This was because FID measured an artificially generous metric: the time between a user’s initial click and the browser beginning to process the event callback. It completely ignored how long the processing took, and it ignored every subsequent interaction on the page.

INP changed the rules entirely. INP measures the total latency of every single click, tap, and keyboard interaction throughout the entire user journey. Google’s documentation is precise about how the number is chosen: the reported value is the 98th percentile of all interactions on the page, ignoring one high outlier for every fifty interactions.

┌───────────────────────────────────────────────────────────────────────────────┐
│                       THE ANATOMY OF INP LATENCY                              │
├───────────────────────┬─────────────────────────────┬─────────────────────────┤
│ 1. INPUT DELAY        │ 2. PROCESSING TIME          │  3. PRESENTATION DELAY  │
│ Time waiting for main │ Time executing JavaScript   │ Time waiting for GPU    │
│ thread to become idle │ event callbacks and state   │ compositor to paint     │
│ before handling click │ updates in virtual DOM      │ next visual frame       │
├───────────────────────┴─────────────────────────────┴─────────────────────────┤
│ TOTAL INP DURATION: Must be < 200ms (75th percentile of mobile sessions)      │
└───────────────────────────────────────────────────────────────────────────────┘

Google’s Web Vitals documentation sets the “good” INP threshold at 200 milliseconds, assessed at the 75th percentile of page loads, and Google Search Central states that Core Web Vitals align with what its core ranking systems seek to reward.

The HTTP Archive’s Web Almanac measured that shift on real mobile traffic: when INP replaced FID in 2024, the share of mobile websites passing all three Core Web Vitals fell from 48% to 43%, and the fall was steepest on the sites shipping the most JavaScript.

1. Why Monolithic React Architectures Fail INP

To understand why traditional React, Vue, and Next.js applications struggle with INP, one must examine the physics of the single-threaded browser runtime.

Browsers execute user JavaScript, layout reflows, and style recalculations on a single main thread. When a user taps a filter dropdown, adds a luxury artifact to their cart, or toggles an accordion, the browser must schedule three distinct phases:

Phase 1: Input Delay (Main Thread Congestion)

If the user clicks while background JavaScript is running—such as analytics scripts, third-party tag managers, or React hydration loops—the click event sits in a queue until the main thread frees up. Google’s Long Tasks API defines a long task as any uninterrupted stretch of main-thread work of 50ms or more, and on a bloated SPA a single hydration pass is long enough to swallow the click whole.

Phase 2: Processing Duration (Virtual DOM Thrashing)

When the event handler executes, React reconciles the virtual DOM, updates state across component subtrees, and re-renders components. If handlers trigger expensive computations or cascading state changes, the processing phase stacks more long tasks on top of the first one, and every millisecond of it is added to the same interaction.

Phase 3: Presentation Delay (Layout & Composite Bottlenecks)

Before the user can see the button depress or the menu open, the browser must recalculate CSS styles, perform layout geometric passes, and composite the pixels to the GPU frame buffer. Layout thrashing—reading a measurement and then writing a style in the same frame—turns that final phase into another long task.

When these three phases are summed, a seemingly simple mobile button click can carry the page past the 200ms Google defines as a “good” INP and into the ‘Needs Improvement’ or ‘Poor’ tiers.

2. The Architectural Cure: Astro Islands & Zero Main-Thread Blocking

The structural flaw in React and Next.js is whole-page hydration. These frameworks treat the entire HTML page as a dynamic application that must be parsed and hydrated by the client CPU.

At Aura Logic, we resolve INP from first principles using the Islands Architecture. The two profiles below are an illustrative model of a heavily hydrated build against a static one, not a measurement of any particular site:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     INP PROFILES: MONOLITH VS. ISLANDS                      │
├─────────────────────────────────────────────────────────────────────────────┤
│ TRADITIONAL NEXT.JS / REACT SPA:                                            │
│ [ 350KB JS Download ] ──> [ Hydrate Whole Page: Main Thread Blocked 750ms ] │
│                                ▲ CLICK HERE ──> INP: 420ms (FAIL)           │
├─────────────────────────────────────────────────────────────────────────────┤
│ AURA LOGIC ASTRO ISLANDS:                                                   │
│ [ Pure Static HTML ] ──> [ Micro-Island Only (8KB) ] ──> [ Thread Idle ]    │
│                                ▲ CLICK HERE ──> INP: 28ms (PASS)            │
└─────────────────────────────────────────────────────────────────────────────┘

1. 0KB Base Runtime

By default, Astro compiles pages to zero client-side JavaScript. All layout elements (headers, typography, grids, footers) render as semantic HTML5. Because there is no hydration script parsing in the background, the browser main thread is completely idle when the user first interacts. In our own builds, input delay drops to under 5ms.

2. Isolated Micro-Islands

When a page requires true interactivity—such as our bespoke Custom Cursor, an interactive Scope Estimator, or dynamic navigation drawers—we isolate that specific component into a micro-island. Only that discrete component hydrates, using client:idle or client:visible. The rest of the document remains immutable HTML.

3. GPU-Accelerated CSS Transformations

Rather than mutating layout-triggering properties (left, top, width, height) during user interactions, our interaction systems exclusively utilize GPU-composited properties (transform: translate3d(...) and opacity). Because these mutations bypass the CPU layout reflow queue, presentation delay in our own builds drops to under 8ms.

3. The Empirical Benchmark: Real-World INP Telemetry

The performance differential between monolithic SPAs and isolated islands is quantifiable in live production environments. Read the two columns carefully, because they are not the same kind of number: the left column is a reference range for a heavily hydrated marketing build of the kind you find on a template, not a measurement of any particular site, and the right column is the target we set for our own builds.

4. Strategic Engineering Rules for Sub-50ms INP

For engineering teams seeking to optimize existing web properties for Google’s INP standard:

1. Decouple Layout from React: Migrate content pages, corporate marketing sections, and editorial hubs away from full-stack React runtimes into static .astro templates.
2. Break Up Long Tasks (scheduler.yield()): Google’s Long Tasks API documentation defines a long task as any uninterrupted period where the main UI thread is busy for 50ms or longer. For complex computational interactions, split those blocks into smaller micro-tasks using native scheduler.yield() or requestIdleCallback().
3. Avoid React Synthetic Event Traps: Direct DOM event listeners (addEventListener) configured with { passive: true } execute faster than heavy virtual DOM event bubbling trees.
4. Eliminate Layout Thrashing in Micro-Interactions: Never read layout properties (offsetHeight, getBoundingClientRect()) immediately before writing inline styles in the same frame.

Conclusion: Speed is the Definitive Competitive Moat

In modern organic search, Google’s position is documented rather than assumed: Search Central states that Core Web Vitals align with what its core ranking systems seek to reward. Mastering INP is not one clever trick; it is what happens when the page ships less and the browser is left alone.

By replacing obsolete, script-heavy single-page applications with the efficiency of static edge delivery and isolated client islands, forward-thinking organizations put all three Core Web Vitals in the ‘good’ band and give their teams a site that is fast and cheap to host.

Audit your web flagship’s Core Web Vitals and INP profile: Use our Scope Estimator or schedule a Technical Architecture Review.