Why INP Is the Metric That Matters Most in 2026
When Google officially retired First Input Delay (FID) and replaced it with Interaction to Next Paint (INP) as a Core Web Vital, the web performance world changed — and honestly, for the better. FID only measured the delay before the first interaction was processed. That's it. One interaction. INP, on the other hand, measures the responsiveness of every interaction throughout the entire page lifecycle — clicks, taps, keypresses — and reports the worst one (at the 75th percentile). The bar for what counts as a "responsive" website is now significantly higher.
And the business case? It's hard to argue with.
Trendyol, one of the largest e-commerce platforms in Turkey, reduced its INP by 50% and saw a 1% uplift in click-through rate — worth millions at their scale. redBus achieved a 7% increase in sales after INP optimizations. Hotstar doubled weekly card views on living room devices by cutting INP by 61%. These aren't marginal gains; they're transformative business outcomes driven by a single metric.
In this guide, we'll break INP down into its three constituent phases, walk through debugging with the Long Animation Frames (LoAF) API, cover practical optimization techniques for each phase, explore framework-specific strategies for React, Vue, and Angular, and show you how to move expensive work off the main thread with Web Workers. By the end, you'll have a complete playbook for achieving sub-200ms INP scores on real user devices.
So, let's dive in.
Understanding the Three Phases of INP
Every interaction measured by INP consists of three sequential phases. To optimize effectively, you need to understand where your time is being spent — because each phase has different causes and, importantly, different solutions.
Phase 1: Input Delay
Input delay is the time between when the user initiates an interaction (say, clicking a button) and when the first event handler for that interaction begins executing. This delay happens because the main thread might be busy doing something else — running a long task, parsing JavaScript, executing a timer callback, or processing rendering work from a previous interaction.
Here's a common scenario: the user clicks a filter button on a product listing page, but the main thread is still hydrating a lazy-loaded component. The click event just sits there in a queue, waiting for its turn. That waiting time is your input delay.
Good input delay is under 40ms. If yours is consistently above 100ms, you've almost certainly got long tasks blocking the main thread right when users are trying to interact.
Phase 2: Processing Duration
Processing duration covers the time your event handler callbacks take to execute. This is the code you directly control — your click handlers, input listeners, keydown callbacks, and all the synchronous work they trigger (including framework re-renders, state updates, and DOM mutations).
This phase is where most optimization effort pays off. If a click handler triggers a complex state recalculation, re-renders a large component tree, or performs synchronous data transformations, processing duration will balloon. I've seen handlers that look simple on the surface but kick off chain reactions through the component tree that eat up hundreds of milliseconds.
Phase 3: Presentation Delay
Presentation delay is the time from when your event handlers finish executing to when the browser actually paints the next frame to the screen. This includes style recalculation, layout, compositing, and painting. If your handlers mutated the DOM in ways that trigger expensive layouts — like changing element dimensions, inserting nodes that shift surrounding content, or reading layout properties that force synchronous layout — presentation delay will suffer.
The total INP for an interaction is the sum of all three:
INP = Input Delay + Processing Duration + Presentation DelayGoogle considers an INP under 200ms as "good," between 200ms and 500ms as "needs improvement," and above 500ms as "poor." These thresholds apply to the 75th percentile of interactions measured across real users.
Debugging INP with the Long Animation Frames (LoAF) API
Before you can optimize anything, you need to know exactly what's slow and why. The Long Animation Frames API, shipped in Chrome 123, is hands down the most powerful tool available for diagnosing INP issues. It replaces the older Long Tasks API with far richer attribution data.
What LoAF Tells You
A long animation frame is any frame that takes more than 50ms to complete. But here's the beautiful part — the LoAF API reports not just that a frame was long, but which scripts contributed to it, how long each script ran, the source URL, and the invoker (event handler name, timer, promise resolution, etc.). This level of detail makes it possible to pinpoint the exact function in the exact file causing a slow interaction.
That's a massive improvement over the old Long Tasks API, which basically just told you "hey, something was slow."
Observing Long Animation Frames
You can collect LoAF entries using a PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
startTime: entry.startTime,
scripts: entry.scripts.map(script => ({
invoker: script.invoker,
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
duration: script.duration,
executionStart: script.executionStart,
forcedStyleAndLayoutDuration: script.forcedStyleAndLayoutDuration,
})),
});
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });The scripts array is where the gold is. Each entry tells you which function from which file contributed to the long frame, and forcedStyleAndLayoutDuration reveals whether layout thrashing is playing a role.
Correlating LoAF with INP Using the web-vitals Library
The web-vitals library (version 4+) integrates LoAF data directly into INP attribution. When you report INP, you also get the long animation frames that intersected with the slow interaction:
import { onINP } from 'web-vitals/attribution';
onINP((metric) => {
const { attribution } = metric;
console.log('INP value:', metric.value);
console.log('INP element:', attribution.interactionTarget);
console.log('INP type:', attribution.interactionType);
// Phase breakdown
console.log('Input delay:', attribution.inputDelay);
console.log('Processing duration:', attribution.processingDuration);
console.log('Presentation delay:', attribution.presentationDelay);
// Long Animation Frame data
if (attribution.longAnimationFrameEntries) {
for (const loaf of attribution.longAnimationFrameEntries) {
for (const script of loaf.scripts) {
console.log('Slow script:', {
invoker: script.invoker,
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
duration: script.duration,
});
}
}
}
});This gives you the complete picture: which element was interacted with, what type of interaction it was, how much time was spent in each phase, and which scripts contributed to the slowness. Beacon this data to your analytics endpoint to understand INP issues at scale across your entire user base.
Using Chrome DevTools for Local Debugging
For local debugging, Chrome DevTools provides excellent INP diagnostics. Open the Performance panel, start a recording, perform the interaction you want to analyze, and stop the recording. Look for the "Interactions" track — it shows each interaction with its total duration and phase breakdown. Click on an interaction to see the associated main thread activity in the flame chart below.
Pay attention to tasks highlighted in red. These are tasks that exceeded 50ms and are likely contributing to poor INP. Drill into the call stack to find the specific function calls consuming the most time.
Optimizing Input Delay: Keeping the Main Thread Free
Input delay is caused by work that's already running on the main thread when the user interacts. The goal is straightforward: make sure the main thread is available when users want to interact. Here are the most effective strategies.
Breaking Up Long Tasks with scheduler.yield()
The scheduler.yield() API is, in my opinion, a genuine game-changer for INP optimization. Unlike setTimeout(), which puts your continuation at the back of the task queue, scheduler.yield() gives your continuation higher priority — it runs before other queued tasks while still giving the browser a chance to process user interactions.
async function processLargeDataset(items) {
const results = [];
for (let i = 0; i < items.length; i++) {
results.push(transformItem(items[i]));
// Yield every 5 items to keep the main thread responsive
if (i % 5 === 0) {
await scheduler.yield();
}
}
return results;
}
// Fallback for browsers that don't support scheduler.yield
async function yieldToMainThread() {
if ('scheduler' in globalThis && 'yield' in scheduler) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}The fallback pattern matters here: scheduler.yield() has full support in Chromium-based browsers but isn't yet available in Firefox or Safari. Using a fallback ensures your code still yields on all browsers, just without the priority benefit.
Deferring Non-Critical JavaScript
JavaScript that runs during page load is the most common source of input delay because it monopolizes the main thread during the exact window when users first try to interact. Audit your scripts and apply these loading strategies:
<!-- Critical: renders above-the-fold content -->
<script src="/js/critical.js"></script>
<!-- Important but not blocking: load async -->
<script src="/js/analytics.js" async></script>
<!-- Can wait until HTML is parsed: load deferred -->
<script src="/js/interactions.js" defer></script>
<!-- Non-essential: load when idle -->
<script>
if ('requestIdleCallback' in window) {
requestIdleCallback(() => {
const script = document.createElement('script');
script.src = '/js/non-essential.js';
document.body.appendChild(script);
});
}
</script>Minimizing Third-Party Script Impact
Third-party scripts — analytics, ads, chat widgets, social embeds — are often the biggest culprits when it comes to input delay. They execute during page load and frequently trigger long tasks that block the main thread. (I've seen a single chat widget add 400ms of blocking time on mobile devices.)
Strategies to mitigate their impact include loading third-party scripts only after user interaction (the "facade pattern"), using a tag manager with delayed execution, and setting resource hints to pre-connect to third-party origins without executing their scripts right away:
<!-- Pre-connect to third-party origin -->
<link rel="preconnect" href="https://www.google-analytics.com">
<!-- Facade pattern: load chat widget only when user clicks -->
<button id="chat-trigger" aria-label="Open chat support">
Chat with us
</button>
<script>
document.getElementById('chat-trigger').addEventListener('click', () => {
// Load the actual chat widget on demand
import('./chat-widget.js').then(module => module.init());
}, { once: true });
</script>Optimizing Processing Duration: Faster Event Handlers
Processing duration is the phase you have the most control over. It directly reflects the efficiency of your event handler code and the framework rendering it triggers.
Avoid Synchronous, Expensive Work in Event Handlers
Event handlers should do the minimum work necessary to acknowledge the interaction and schedule any heavy processing for later. A common anti-pattern (and one I see constantly in production codebases) is performing data transformations, API calls, and UI updates all synchronously within a single handler:
// BAD: Everything happens synchronously in the handler
button.addEventListener('click', () => {
const data = computeExpensiveFilter(allProducts); // 200ms
updateProductList(data); // 150ms
updateSidebar(data); // 50ms
trackAnalytics('filter_applied'); // 30ms
});
// GOOD: Immediate visual feedback, then deferred work
button.addEventListener('click', async () => {
// Immediate: show loading state (fast DOM update)
showLoadingSpinner();
// Yield to let the browser paint the loading state
await scheduler.yield();
// Now do the heavy work
const data = computeExpensiveFilter(allProducts);
updateProductList(data);
await scheduler.yield();
// Non-critical work last
updateSidebar(data);
trackAnalytics('filter_applied');
});The key insight here is that users perceive responsiveness through visual feedback. If the browser can paint a loading indicator within 200ms of the click, the interaction feels responsive — even if the full operation takes longer.
Debounce Rapid-Fire Interactions
Input events like keydown, input, and scroll can fire dozens of times per second. Each one triggers event handler processing, and if those handlers are expensive (filtering a list, recalculating a layout), INP will suffer. Debouncing ensures you only process the final state after a pause in input:
function debounce(fn, delay) {
let timeoutId;
return function (...args) {
clearTimeout(timeoutId);
timeoutId = setTimeout(() => fn.apply(this, args), delay);
};
}
const searchInput = document.getElementById('search');
searchInput.addEventListener('input', debounce((event) => {
filterResults(event.target.value);
}, 150));Reduce DOM Size and Complexity
Large DOM trees increase the cost of every operation your event handlers perform. Each DOM mutation may trigger style recalculation, layout, and paint across hundreds or thousands of elements.
Strategies to reduce DOM impact include virtualizing long lists (only rendering visible items), using content-visibility: auto to skip rendering off-screen content, removing hidden elements from the DOM entirely rather than hiding them with CSS, and batching DOM mutations using DocumentFragment:
// BAD: Individual DOM insertions trigger layout repeatedly
items.forEach(item => {
const li = document.createElement('li');
li.textContent = item.name;
list.appendChild(li); // Layout triggered each time
});
// GOOD: Batch mutations with DocumentFragment
const fragment = document.createDocumentFragment();
items.forEach(item => {
const li = document.createElement('li');
li.textContent = item.name;
fragment.appendChild(li);
});
list.appendChild(fragment); // Single layout triggeredOptimizing Presentation Delay: Efficient Rendering
Presentation delay is the time between your event handlers finishing and the browser completing the next paint. The main villain here? Layout thrashing — reading and writing layout properties in an interleaved pattern that forces the browser to recalculate layout multiple times within a single frame.
Eliminate Layout Thrashing
Layout thrashing occurs when you read a layout property (like offsetHeight, getBoundingClientRect(), or scrollTop), then write to the DOM, and then read again. Each read after a write forces the browser to recalculate layout synchronously:
// BAD: Layout thrashing — read, write, read, write
elements.forEach(el => {
const height = el.offsetHeight; // Read (forces layout)
el.style.height = height * 2 + 'px'; // Write (invalidates layout)
});
// Each iteration forces a synchronous layout recalculation
// GOOD: Batch reads, then batch writes
const heights = elements.map(el => el.offsetHeight); // All reads first
elements.forEach((el, i) => {
el.style.height = heights[i] * 2 + 'px'; // All writes second
});
// Only one layout recalculation neededThis pattern trips up a surprising number of developers. It looks innocent enough — you're just reading a value and setting it — but the performance difference can be dramatic.
Use CSS Containment
CSS containment tells the browser that an element's internal layout doesn't affect the rest of the page, allowing it to skip recalculating layout for elements outside the contained subtree:
.card {
contain: layout style;
}
.sidebar {
contain: layout style paint;
}
/* content-visibility skips rendering of off-screen content entirely */
.below-the-fold-section {
content-visibility: auto;
contain-intrinsic-size: 0 500px; /* Estimated height for scrollbar accuracy */
}The content-visibility: auto property is particularly powerful. It tells the browser to skip rendering an element entirely until it's near the viewport. For pages with lots of content below the fold, this can drastically reduce both initial render time and the cost of re-renders triggered by interactions.
Prefer Compositor-Only Animations
Animations triggered by interactions should use properties that the compositor thread can handle without involving the main thread. The compositor-friendly properties are transform, opacity, filter, and will-change. Avoid animating width, height, top, left, or margin — these trigger layout:
/* BAD: Animating layout-triggering properties */
.modal-enter {
animation: slideDown 300ms ease;
}
@keyframes slideDown {
from { height: 0; margin-top: -100px; }
to { height: auto; margin-top: 0; }
}
/* GOOD: Compositor-friendly animation */
.modal-enter {
animation: slideDown 300ms ease;
}
@keyframes slideDown {
from { transform: translateY(-100px); opacity: 0; }
to { transform: translateY(0); opacity: 1; }
}Framework-Specific INP Strategies
Modern JavaScript frameworks have their own rendering pipelines, and optimizing INP means understanding how each one handles updates, re-renders, and hydration.
React: Concurrent Features and Memoization
React 18+ introduced concurrent rendering, which automatically yields to the main thread every 5ms during rendering. That's a significant INP benefit out of the box, but you can amplify it with specific APIs:
import { useTransition, useDeferredValue, memo } from 'react';
function SearchResults({ query }) {
const [isPending, startTransition] = useTransition();
const [results, setResults] = useState([]);
const handleSearch = (newQuery) => {
// Urgent: update the input field immediately
setQuery(newQuery);
// Non-urgent: defer the expensive list rendering
startTransition(() => {
setResults(filterProducts(newQuery));
});
};
return (
<div>
<input onChange={(e) => handleSearch(e.target.value)} />
{isPending && <Spinner />}
<ProductList items={results} />
</div>
);
}
// Prevent unnecessary re-renders with memo
const ProductCard = memo(function ProductCard({ product }) {
return (
<div className="product-card">
<h3>{product.name}</h3>
<p>{product.price}</p>
</div>
);
});useTransition tells React that the state update inside startTransition is non-urgent and can be interrupted if the user interacts again. This keeps the input responsive even while a large list is being re-rendered. useDeferredValue provides a similar benefit for values derived from state.
Watch out for unnecessary re-renders — they're a common INP killer in React apps. Use the React DevTools Profiler to identify components that re-render when they shouldn't, and apply React.memo, useMemo, and useCallback strategically to prevent cascading re-renders.
Vue: Efficient Reactivity and Async Components
Vue's fine-grained reactivity system already minimizes unnecessary re-renders. However, you can still run into INP issues with large lists, heavy computed properties, or synchronous watchers:
<template>
<div>
<input v-model="searchQuery" @input="debouncedSearch" />
<Suspense>
<template #default>
<HeavyComponent :data="filteredData" />
</template>
<template #fallback>
<LoadingSpinner />
</template>
</Suspense>
</div>
</template>
<script setup>
import { ref, computed, defineAsyncComponent } from 'vue';
// Async component — only loaded when needed
const HeavyComponent = defineAsyncComponent(() =>
import('./HeavyComponent.vue')
);
const searchQuery = ref('');
const allProducts = ref([]);
// Use v-memo for list rendering to skip unchanged items
const filteredData = computed(() => {
if (!searchQuery.value) return allProducts.value;
return allProducts.value.filter(p =>
p.name.toLowerCase().includes(searchQuery.value.toLowerCase())
);
});
</script>Vue's v-memo directive is excellent for list rendering. It tells Vue to skip re-rendering a list item unless specific dependencies change — far more granular than re-rendering the entire list.
Angular: OnPush Change Detection and @defer
Angular's default change detection strategy checks every component in the tree on every event. For INP, switching to OnPush change detection is critical — it tells Angular to only re-check a component when its inputs change or an explicit change detection is triggered:
import { Component, ChangeDetectionStrategy } from '@angular/core';
@Component({
selector: 'app-product-list',
changeDetection: ChangeDetectionStrategy.OnPush,
template: `
<div class="product-list">
@for (product of products; track product.id) {
<app-product-card [product]="product" />
}
</div>
`
})
export class ProductListComponent {
products: Product[] = [];
}Angular's @defer block (available since Angular 17) is particularly powerful for INP. It lets you lazily load and render parts of your template based on triggers:
<!-- Only load this component when it enters the viewport -->
@defer (on viewport) {
<app-heavy-chart [data]="chartData" />
} @loading {
<div class="skeleton">Loading chart...</div>
} @placeholder {
<div class="placeholder">Chart will appear here</div>
}The track keyword in @for loops (replacing the old trackBy) helps Angular identify which items changed, which were added, and which were removed — avoiding full list re-renders.
Offloading Work to Web Workers
For computationally expensive operations that can't be broken into small enough chunks, Web Workers provide a way to run JavaScript on a separate thread entirely. The main thread stays free for user interactions — which is exactly what we want.
When to Use Web Workers
Web Workers are ideal for data parsing and transformation (JSON processing, CSV parsing), search and filtering across large datasets, image processing, cryptographic operations, and complex calculations like statistical analysis or charting data preparation. They're not suitable for DOM manipulation, though — workers have no access to the DOM.
Implementing a Worker for Data Processing
// worker.js — runs on a separate thread
self.addEventListener('message', (event) => {
const { type, payload } = event.data;
switch (type) {
case 'FILTER_PRODUCTS': {
const { products, filters } = payload;
const results = products.filter(product => {
return (
(!filters.category || product.category === filters.category) &&
(!filters.minPrice || product.price >= filters.minPrice) &&
(!filters.maxPrice || product.price <= filters.maxPrice) &&
(!filters.query || product.name.toLowerCase()
.includes(filters.query.toLowerCase()))
);
});
// Sort results
results.sort((a, b) => a.price - b.price);
self.postMessage({ type: 'FILTER_RESULTS', payload: results });
break;
}
}
});// main.js — on the main thread
const worker = new Worker('/worker.js');
// Listen for results from the worker
worker.addEventListener('message', (event) => {
const { type, payload } = event.data;
if (type === 'FILTER_RESULTS') {
renderProducts(payload);
hideLoadingSpinner();
}
});
// Handle filter interaction
filterButton.addEventListener('click', () => {
showLoadingSpinner(); // Immediate visual feedback
worker.postMessage({
type: 'FILTER_PRODUCTS',
payload: {
products: allProducts,
filters: getCurrentFilters(),
},
});
});Using Transferable Objects for Large Data
When transferring large datasets between the main thread and a worker, the default behavior is structured cloning — basically a deep copy of the data. For very large arrays, this copy operation can itself cause jank (kind of ironic, right?). Transferable objects solve this by transferring ownership of the memory rather than copying it:
// Transfer an ArrayBuffer to the worker (zero-copy)
const largeBuffer = new ArrayBuffer(1024 * 1024 * 10); // 10MB
worker.postMessage({ buffer: largeBuffer }, [largeBuffer]);
// largeBuffer is now detached — it cannot be used on the main thread
// For structured data, consider converting to ArrayBuffer
function transferJSON(worker, data) {
const json = JSON.stringify(data);
const encoder = new TextEncoder();
const buffer = encoder.encode(json).buffer;
worker.postMessage({ buffer }, [buffer]);
}This technique is especially valuable for applications processing large datasets, images, or binary files. The transfer is nearly instantaneous regardless of data size, because no copying occurs.
Measuring and Monitoring INP in Production
Optimizing INP isn't a one-time effort. New features, updated dependencies, and changing user behavior patterns can all degrade INP over time. A robust monitoring strategy catches regressions before they impact your users.
Setting Up Real User Monitoring (RUM)
Field data is essential because lab tools simply can't replicate the diversity of real user devices, networks, and interaction patterns. Here's a production-ready RUM setup using the web-vitals library:
import { onINP } from 'web-vitals/attribution';
function sendToAnalytics(metric) {
const body = {
name: metric.name,
value: metric.value,
rating: metric.rating, // 'good', 'needs-improvement', or 'poor'
delta: metric.delta,
id: metric.id,
page: window.location.pathname,
// Attribution data for debugging
attribution: {
interactionTarget: metric.attribution.interactionTarget,
interactionType: metric.attribution.interactionType,
inputDelay: metric.attribution.inputDelay,
processingDuration: metric.attribution.processingDuration,
presentationDelay: metric.attribution.presentationDelay,
},
};
// Use sendBeacon for reliable delivery during page unload
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/rum', JSON.stringify(body));
} else {
fetch('/api/rum', {
method: 'POST',
body: JSON.stringify(body),
keepalive: true,
});
}
}
onINP(sendToAnalytics);Creating an INP Dashboard
With RUM data flowing to your analytics backend, build a dashboard that tracks INP at the 75th percentile (the threshold Google uses). Break it down by page type, by device category (mobile vs. desktop — mobile will almost always have worse INP), by interaction type (clicks, keypresses, taps), and over time to spot regressions.
The phase breakdown data (input delay, processing duration, presentation delay) is critical for diagnosing which optimization strategy to apply when regressions show up.
Setting Performance Budgets
Integrate INP thresholds into your CI/CD pipeline. Tools like Lighthouse CI, SpeedCurve, and DebugBear can run synthetic tests on each pull request and fail the build if INP regresses beyond your budget:
// lighthouserc.js
module.exports = {
ci: {
assert: {
assertions: {
'interactive': ['warn', { maxNumericValue: 3500 }],
'total-blocking-time': ['error', { maxNumericValue: 300 }],
// TBT is a strong lab proxy for INP
},
},
},
};While Lighthouse doesn't directly measure INP (it's a field metric), Total Blocking Time (TBT) is a strong lab proxy. Sites that optimize for low TBT in lab testing almost always have good INP in the field.
An INP Optimization Checklist
Here's a systematic checklist you can follow for any INP optimization project:
- Measure first — Set up RUM with INP attribution to identify your worst interactions by page, element, and phase.
- Diagnose with LoAF — Use Long Animation Frame data to find the specific scripts and functions contributing to slow interactions.
- Tackle input delay — Break up long tasks with
scheduler.yield(), defer non-critical JavaScript, minimize third-party script impact during page load. - Optimize processing duration — Provide immediate visual feedback before heavy work, debounce rapid-fire events, reduce DOM size and complexity, and leverage framework-specific optimizations (React concurrent features, Vue
v-memo, AngularOnPush). - Reduce presentation delay — Eliminate layout thrashing, use CSS containment, prefer compositor-friendly animations, and apply
content-visibility: autoto off-screen content. - Offload heavy work — Move data processing, filtering, and computations to Web Workers when they can't be broken into small enough chunks on the main thread.
- Monitor continuously — Track INP at the 75th percentile over time, set performance budgets in CI, and alert on regressions.
Looking Ahead: INP and the Evolving Core Web Vitals Landscape
INP has solidified its position as the most impactful Core Web Vital for user experience and SEO. As Google continues refining its performance metrics in 2026 — with potential new metrics like the Visual Stability Index (VSI) on the horizon — the underlying principle remains the same: every millisecond of responsiveness matters.
The techniques we've covered here — from fine-grained debugging with the LoAF API to framework-specific rendering optimizations to Web Worker offloading — form a comprehensive toolkit for achieving and maintaining excellent INP scores. Start with measurement, focus your optimization effort where the data points, and build monitoring guardrails that protect your gains over time.
The sites that take INP seriously aren't just passing Google's thresholds. They're creating user experiences that feel instantaneous, driving measurable improvements in engagement, conversion, and revenue. With the tools and techniques available today, sub-200ms INP is an achievable target for any web application.