Good INP is 200 ms or less and good LCP is 2.5 s or less. Use this 2026 reference to measure, debug, and ship faster fixes in production. Read now.
What Good INP and LCP Mean in Practice
Interaction to Next Paint (INP) and Largest Contentful Paint (LCP) are the two Core Web Vitals most teams fight with once basic page load works. A good INP is 200 ms or less: when a user taps, clicks, or types, the browser should paint the next visual response within that window. A good LCP is 2.5 s or less: the main content element users care about should appear quickly enough that the page feels ready, not empty. Missing either target does not just hurt a score; it shows up as delayed buttons, frozen forms, or a hero that loads after the rest of the shell.
Treat the thresholds as production goals, not lab curiosities. Measure on real traffic when you can, and use lab tools to reproduce regressions. The rest of this guide is a 2026 reference for how to measure, debug, and ship fixes without guessing.
Measure Before You Optimize
Start with field data when it is available. Field metrics capture real devices, networks, and interaction patterns that synthetic runs often miss. Pair that with lab runs on a stable device profile so you can isolate regressions after a deploy. For INP, record which interactions fire late and which elements they target. For LCP, identify the actual LCP element—image, text block, or video poster—and note whether it is delayed by discovery, download, or render-blocking work.
Build a short debug loop: capture the metric, name the element or handler involved, then change one thing. Avoid multi-fix “performance passes” that hide which change helped. If you cannot reproduce a bad INP in the lab, instrument the live handlers with timestamps around input handling, main-thread work, and the subsequent paint so production tells you where time is spent.
Fix LCP: Discover, Download, Render
LCP almost always fails for one of three reasons: the browser finds the resource late, the resource takes too long to download, or something blocks paint after the bytes arrive. Prioritize discovery—ensure the LCP image or text is in the initial HTML or requested early, with correct dimensions so layout does not wait. Then reduce payload: modern image formats, right-sized sources, and caching help more than micro-optimizing CSS that is not on the critical path.
Finally, clear the path to first paint of that element. Defer non-critical scripts, avoid large synchronous work on the main thread during load, and do not hide the LCP candidate behind client-only rendering if the server can send meaningful markup. If the LCP element is a hero image, preload it only when it is truly the LCP candidate; preloading the wrong asset steals bandwidth from the one that matters.
- Confirm the real LCP element in the field, not only in a homepage screenshot.
- Make the resource discoverable early and sized correctly.
- Cut competing main-thread work and late-loaded UI that delays paint.
Fix INP: Keep the Main Thread Free After Input
INP is about responsiveness after input, not about first load alone. Break long tasks so the browser can paint between chunks of work. Defer non-urgent updates, batch DOM writes, and avoid expensive style recalculation inside click or key handlers. Prefer lightweight event handlers that schedule heavier work with yielding patterns rather than doing everything synchronously in the first turn after the event.
When third-party scripts or large frameworks own the main thread, audit what runs on every interaction. Remove unused listeners, debounce noisy input where that still feels instant, and keep visual feedback cheap—disable a button, show a spinner, or update a class—before kicking off network or compute. Ship fixes behind the same measure-debug-deploy loop: one interaction path, one change, re-check field INP. That discipline is how you hit 200 ms INP and 2.5 s LCP in production and keep them there after each release.