INP Optimisation · The Complete Technical Guide

The scheduler.yield() API (Chrome 115+, now in the HTML spec) explicitly yields control back to the browser, allowing it to process pending user inputs before resuming the current task. This is the most modern and recommended approach to breaking up long tasks:

async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // Yield every 50 items to allow browser to process inputs
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}

For browsers that do not yet support scheduler.yield(), the traditional fallback is await new Promise(resolve => setTimeout(resolve, 0)) — less precise but widely supported.

JavaScript that runs during page load (initialisation of analytics, feature flags, non-critical UI components) creates long tasks that block the main thread. Deferring this code until after the page becomes interactive reduces input delay for early interactions.

// Instead of running immediately on load:
window.addEventListener('load', () => {
  // Defer non-critical work using requestIdleCallback
  requestIdleCallback(() => {
    initAnalytics();
    loadChatWidget();
    prefetchNextPageData();
  });
});

requestIdleCallback schedules work during browser idle periods, preventing it from blocking user interactions.

Web Workers run JavaScript on a background thread, completely independent of the main thread. This means complex calculations, data processing, and heavy algorithmic work in event handlers can be moved to a Worker without blocking the UI:

// Main thread
const worker = new Worker('/js/data-processor.js');

button.addEventListener('click', () => {
  // Send data to worker instead of processing synchronously
  worker.postMessage({ action: 'processData', data: largeDataset });
});

worker.onmessage = (e) => {
  updateUI(e.data.result); // Update UI when worker is done
};

Web Workers cannot directly access the DOM but are ideal for computation-heavy tasks: image processing, sorting and filtering large datasets, encryption, and complex calculations.

In React applications, a single state update can trigger re-renders throughout the component tree if components are not properly memoised. This is one of the most common sources of poor INP in React-based sites.

• Use React.memo() to prevent re-renders of components whose props have not changed
• Use useMemo() to cache expensive calculated values between renders
• Use useCallback() to stabilise function references passed as props
• Split large components into smaller ones to limit re-render scope
• Use React 18's concurrent features (useTransition, startTransition) to mark non-urgent state updates as interruptible

localStorage and sessionStorage are synchronous APIs — reading from them blocks the main thread. In event handlers that fire frequently (scroll listeners, input listeners), synchronous storage access can significantly increase processing time. Use IndexedDB (async) for complex data or cache frequently-needed values in memory (JavaScript variables) rather than reading from storage on every event.

Large DOM trees (Google recommends keeping total DOM nodes under 1,500) increase the time required for style recalculation and layout. When an event handler modifies the DOM, the browser must recalculate styles and layout for potentially large portions of the tree. Reducing DOM complexity directly reduces presentation delay.

Common causes of excessive DOM size: deeply nested CSS frameworks generating many wrapper elements, rendering long lists without virtualisation, keeping off-screen components mounted in the DOM rather than conditionally rendering them.

CSS properties that trigger layout recalculation (width, height, top, left, margin, padding) cause the browser to recalculate positions of affected elements and their siblings. For animations or transitions triggered by user interaction, use only transform and opacity — these are handled by the compositor thread and do not require layout recalculation.

A facade is a static placeholder that replaces a third-party embed until the user explicitly interacts with it. Chat widgets, video embeds (YouTube, Vimeo), and map embeds are classic candidates. On page load, display a lightweight static image or placeholder. Only load the actual third-party embed when the user clicks on it:

• YouTube: Use the YouTube lite embed pattern — show a thumbnail image, load the YouTube iframe only on click. Saves ~500KB of JavaScript per embed.
• Chat widgets: Show a static "chat" button; load the full widget only when clicked. Most chat platforms support lazy-init APIs.
• Maps: Show a static map screenshot; load the interactive map only on interaction.

Google Tag Manager can fire tags in response to custom events rather than on page load. For analytics, heat mapping, and A/B testing scripts that are not needed for immediate interaction, configure them to fire after the first user interaction (click, scroll) rather than on DOMContentLoaded. This removes their long tasks from the critical page load path.