Tackling INP and LCP on Complex Web Applications

Core Web Vitals have been part of Google's ranking signals long enough that most publishers have at least looked at their scores. What fewer people have done is understand what those scores are actually measuring — and why fixing the number without understanding the underlying problem tends to produce short-lived improvements.

This is especially true for INP and LCP, the two metrics that cause the most confusion and the most wasted effort.

LCP: What It Measures and What It Misses

Largest Contentful Paint measures how long it takes for the largest visible element in the viewport to appear on screen. That element is usually a hero image, a large heading, or a video thumbnail.

The number is useful because it correlates reasonably well with how fast a page feels to a real user. A page with an LCP below 2.5 seconds generally doesn't feel sluggish. Above 4 seconds, it starts to feel broken.

But the metric can mislead you if you optimize for the measurement rather than the experience. It's possible to have a fast LCP and still have a page that feels frustratingly slow — if, for example, the LCP element loads quickly but the rest of the content takes another four seconds, or if the page layout shifts dramatically after the initial paint.

LCP is a proxy, not the whole truth. Use it as a starting point, not as the final word.

What Actually Causes Slow LCP

The most common culprits are unoptimized images, render-blocking resources, and slow server response times.

If your LCP element is a large image, check whether it's compressed appropriately (modern formats like WebP or AVIF are significantly smaller than JPEG for equivalent quality), whether it has a loading attribute set to "eager" rather than "lazy" (lazy loading is actively harmful for above-the-fold images), and whether it's being preloaded with a tag so the browser fetches it as early as possible.

Render-blocking resources — JavaScript and CSS that block the browser from showing anything until they've finished loading — are the second major category. Any script in the without async or defer attributes holds up the entire page render. Moving non-critical scripts to the bottom of the page or adding defer can meaningfully reduce LCP without touching a single image.

Server response time (technically measured as TTFB, Time to First Byte) matters too. If your server takes 1.5 seconds to respond before the browser has received a single byte of HTML, you've already consumed most of your LCP budget before the browser has started rendering anything. Server-side caching, CDN configuration, and database query optimization are where this gets fixed.

INP: the Metric That Actually Measures Interactivity

Interaction to Next Paint replaced First Input Delay in 2024, and the change was significant. FID only measured the delay before a browser started handling the first interaction. INP measures the entire response time of every interaction — click, tap, keystroke — that happens during a page visit, and takes the worst-performing one as the score.

In practice, this means INP is much harder to fake. You can't just optimize the initial page load and expect a good INP score. If your site's JavaScript makes the page sluggish every time someone opens a dropdown or clicks a filter, that cost shows up in INP even if LCP looks fine.

Why INP Is Hard to Fix

The root cause of poor INP is almost always JavaScript doing too much work on the main thread. Every time a user interacts with a page, the browser needs to run your event handlers, update the DOM, calculate layout, and paint the result. If any of those steps is slow, the interaction feels sluggish.

The most common specific problems are:

• Large JavaScript bundles that parse and execute slowly on lower-end devices
• Synchronous DOM queries inside event handlers (repeatedly asking the browser for layout information forces expensive recalculations)
• Heavy animation effects driven by JavaScript rather than CSS
• Third-party scripts (analytics, chat widgets, ad tags) that run on the main thread and compete with user interactions

Fixing these usually requires profiling with Chrome DevTools to identify which specific operations are taking the most time. The Performance panel's flame charts show you exactly where milliseconds are being spent during a recorded interaction.

The Device Gap You're Probably Ignoring

Most developers test Core Web Vitals on their own machines — often high-end laptops with fast processors and a strong Wi-Fi connection. Field data in Google Search Console reflects real users, many of whom are on mid-range Android phones with slower CPUs and variable network conditions.

A page that scores well in a lab environment on a MacBook Pro can score poorly in field data because the JavaScript that takes 50ms to parse on a fast machine takes 400ms on a budget phone.

The Chrome User Experience Report and Search Console's Core Web Vitals report use field data. Your local Lighthouse audit uses lab data. Pay more attention to the field data — that's what Google uses for ranking.

How to Prioritize

If you're dealing with both poor LCP and poor INP, LCP is usually the faster win because image optimization, preloading, and removing render-blocking resources are relatively straightforward changes. INP improvements tend to require more investigation and code changes.

Start with LCP if your score is currently in the "Poor" range (above 4 seconds). Move to INP once LCP is in a reasonable place, because the work is more involved and the benefits more targeted.

For most content-heavy sites, LCP improvements produce visible ranking improvements quickly. For heavily interactive sites — e-commerce, SaaS applications, anything with lots of filters and dynamic content — INP improvements matter more because users interact more frequently.

What Not to Do

Don't chase the PageSpeed Insights score as if it's the goal. The score is a useful indicator, not the objective. A page that scores 62 but loads noticeably faster for real users is better than a page that scores 88 but still feels slow because you optimized metrics rather than experience.

Don't remove useful JavaScript features to improve INP. Understand where the slowness is coming from first, then find ways to make the same functionality faster — lazy loading scripts, breaking long tasks into smaller chunks, deferring non-critical work until after the interaction response has been painted.

The point is for users to have a faster, calmer experience. Core Web Vitals are a way to measure whether that's happening, not an end in themselves.