Core Web Vitals Checklist: How to Improve LCP, INP, and CLS

Overview

If you want to improve Core Web Vitals, start by separating the three metrics by failure mode. Largest Contentful Paint (LCP) is mainly about loading speed for the main visible content. Interaction to Next Paint (INP) is mainly about responsiveness after user input. Cumulative Layout Shift (CLS) is mainly about visual stability.

That distinction matters because teams often try to solve all three with the same general performance work. Compression, caching, and asset minification can help, but they do not automatically fix slow interactions or unstable layouts. A useful core web vitals checklist should tell you which class of problem you are dealing with before you start optimizing.

Use this baseline workflow:

• Identify whether the issue is primarily LCP, INP, CLS, or a combination.
• Check field data first when available, then use lab tools to reproduce and isolate causes.
• Optimize the bottleneck closest to the metric instead of applying broad changes everywhere.
• Validate on the templates and devices that matter most, not only on your homepage.
• Re-test after every meaningful release, dependency change, design refresh, or third-party integration update.

As a rule of thumb, performance work is easier when ownership is explicit. Decide who owns image delivery, rendering strategy, JavaScript budgets, third-party scripts, and release validation. Without that, teams often see temporary gains that disappear with the next feature launch.

This article focuses on practical actions you can reuse as your stack changes. If you are also refining build tooling, see Vite vs Webpack vs Parcel: Which Build Tool Makes Sense in 2026?. Build decisions do not replace performance engineering, but they can influence bundle size, code splitting behavior, and how quickly you can ship fixes.

Checklist by scenario

This section gives you a reusable page speed checklist by metric and by common site scenario. Start with the scenario that looks closest to your current bottleneck.

If LCP is the main problem

Your goal is to make the primary above-the-fold content discoverable, deliverable, and renderable as early as possible.

• Identify the LCP element. It is often a hero image, large heading block, banner, or featured card image. Confirm what the browser is actually counting.
• Reduce server and document wait time. Slow HTML delivery pushes every downstream request later.
• Prioritize the critical resource. If the LCP element is an image, make sure it is not lazily loaded when it should appear immediately.
• Use appropriately sized media. Large desktop images sent to mobile devices are a common LCP drag.
• Compress and cache static assets. This is basic, but still one of the most common misses.
• Inline only truly critical CSS. Too much render-blocking CSS delays first meaningful rendering.
• Defer non-critical JavaScript. Scripts that do not support above-the-fold content should not compete with it.
• Audit web fonts. Slow font loading can delay visible text or cause swaps that affect rendering quality.
• Check CDN and image pipeline behavior. Incorrect cache headers, missing variants, or oversized transformations can quietly slow key pages.
• Review SSR, SSG, and hydration tradeoffs. For some pages, static or server-rendered output improves initial rendering. For others, excessive hydration cancels the benefit.

Typical LCP scenarios:

• Marketing pages: oversized hero images, video backgrounds, heavy tag managers, and animation libraries.
• Commerce pages: product galleries, recommendation widgets, review embeds, and personalization scripts loading too early.
• Dashboard or app shells: large JavaScript boot sequences before any meaningful content appears.

If INP is the main problem

INP issues usually mean the browser is too busy to respond quickly to user input. The most common cause is too much JavaScript work on the main thread, especially during startup or after interaction.

• Find the slow interactions. Look for clicks, taps, or keypresses that trigger long tasks, heavy state updates, or expensive DOM changes.
• Reduce main-thread blocking. Break up long JavaScript tasks so the browser can paint sooner.
• Delay non-essential hydration. Not every interactive region needs to hydrate immediately.
• Limit large rerenders. Review component boundaries, memoization, and state scope in complex interfaces.
• Virtualize long lists. Rendering large data tables or feeds can degrade responsiveness fast.
• Trim event handler work. Avoid parsing, sorting, filtering, or layout-heavy logic directly inside user-triggered handlers when possible.
• Audit third-party scripts. Chat widgets, analytics bundles, A/B testing tools, and consent frameworks can degrade interaction quality.
• Use web workers where appropriate. Expensive computations should not always run on the main thread.
• Check animation strategy. Layout-triggering animations and continuous timers can reduce responsiveness.
• Test on lower-powered devices. INP problems often look acceptable on a developer laptop and poor on real user hardware.

Typical INP scenarios:

• Single-page apps: route transitions tied to large data fetches and full-screen rerenders.
• Admin tools: filtering, sorting, and search UI bound to large datasets.
• Content sites: sticky headers, modal systems, and ad stacks intercepting scroll and click behavior.

If your team is also evaluating package and dependency sprawl, that work can support INP improvements. A leaner dependency graph often reduces client-side cost. For related context, see npm vs pnpm vs Yarn: Package Manager Comparison for Modern JavaScript Teams.

If CLS is the main problem

CLS optimization is usually less about raw speed and more about predictable layout behavior. Users should not have content move unexpectedly while reading, tapping, or scrolling.

• Set explicit dimensions on images and embeds. Reserve space before content loads.
• Reserve room for ads, banners, and async components. Empty containers that expand later are a frequent source of layout shift.
• Avoid injecting content above existing content. Cookie notices, promo bars, and alerts should not push the page downward unexpectedly.
• Stabilize font rendering. Font swaps can shift text blocks if fallback metrics differ too much.
• Review skeleton and placeholder behavior. Placeholders should match final content dimensions as closely as possible.
• Be careful with sticky UI. Headers, drawers, chat prompts, and consent bars can change viewport layout.
• Check responsive breakpoints. Layouts that seem stable on desktop may jump on tablet or mobile widths.
• Audit animations. Animate transforms and opacity where possible instead of layout-affecting properties.
• Test logged-in and logged-out variants. Different header states or recommendation modules can shift the page differently.
• Inspect localization cases. Longer strings and alternate content blocks often reveal hidden instability.

Typical CLS scenarios:

• Media-rich articles: images inserted without reserved aspect ratios.
• Landing pages: delayed testimonial sliders, trust badges, or forms shifting the hero area.
• Apps with async panels: sidebars and notifications altering content width after render.

If all three metrics are weak

When LCP, INP, and CLS all look poor, avoid jumping straight into micro-optimizations. You probably need to review the page architecture.

• Map the critical rendering path from HTML response to visible content and first interaction.
• Remove or defer non-essential third-party code.
• Audit page templates rather than isolated pages.
• Check whether your frontend is shipping too much JavaScript for the user task.
• Review image strategy, route-level code splitting, caching, and hydration together.
• Set performance budgets for bundles, images, and third-party requests.
• Add release checks so regressions are caught before production.

Performance validation should be part of deployment hygiene, not a separate rescue project. A good companion process is a release checklist such as CI/CD Pipeline Checklist: What to Validate Before Every Production Deploy.

What to double-check

Before you conclude that a fix worked, verify the context around the metric. Many teams improve a score in one environment and accidentally leave the underlying user experience unchanged.

• Field data versus lab data: Lab tests help reproduce issues, but real users see different networks, devices, and cache states. Treat lab wins as provisional until they hold up in production.
• Template coverage: Homepages are rarely the full story. Check article pages, product pages, search results, account screens, and other high-traffic templates.
• Device classes: Mid-range mobile devices often reveal problems hidden on high-end hardware.
• User states: Logged-in views, personalized modules, consent states, and regional variants may perform differently.
• Cold and warm cache behavior: A page can feel fast after caching and still fail badly for first-time visitors.
• Third-party variance: Tag managers and external scripts often behave differently by geography, environment, or time of day.
• Regression risk after refactors: Image component changes, design system updates, or analytics additions can quietly damage metrics.
• Hydration cost after framework upgrades: New framework versions may help overall, but individual routes can still regress.

It is also worth checking whether your optimization created a tradeoff elsewhere. For example, aggressive lazy loading can improve initial payload size while making visible content appear later. Cutting JavaScript can improve INP, but replacing interactive feedback with delayed server round trips may hurt usability in other ways. Better Core Web Vitals should still feel better to use.

For teams working across multiple packages or applications, repository structure can affect how easily performance fixes are maintained and enforced. If that is relevant to your workflow, Monorepo Tooling Comparison: Turborepo vs Nx vs Native Workspaces offers useful background.

Common mistakes

Most stalled performance programs do not fail because the fixes are unknown. They fail because teams optimize the wrong layer, test only in narrow conditions, or let regressions re-enter the stack.

• Treating Lighthouse-style testing as the whole truth. Lab tools are useful, but they are not a substitute for production monitoring.
• Optimizing the homepage and ignoring the rest of the site. Core Web Vitals are usually won or lost on templates with real traffic and real complexity.
• Lazy loading above-the-fold images. This frequently hurts LCP more than it helps.
• Shipping large client bundles by default. Many pages do not need full interactivity at load time.
• Ignoring third-party code. External scripts often account for a large share of performance instability.
• Assuming one framework feature fixes everything. Server rendering, islands, code splitting, and caching are helpful patterns, not automatic outcomes.
• Using placeholders that do not match final layout. This creates avoidable CLS.
• Focusing only on transfer size. Parse, execute, render, and layout costs matter too, especially for INP.
• Skipping performance budgets in CI. Without guardrails, regressions return through normal feature delivery.
• Making changes without preserving measurement history. If you cannot compare before and after, you cannot tell which fixes actually mattered.

Another common mistake is treating performance as an isolated frontend concern. Hosting, caching, image processing, edge behavior, and release workflows all shape user experience. Even basic infrastructure choices can influence your starting point, especially if origin response times are inconsistent or static assets are not delivered efficiently.

When to revisit

This checklist is most useful when revisited on a schedule and after specific changes. Core Web Vitals are not static because your pages, dependencies, traffic patterns, and browser behavior are not static.

Revisit this checklist when any of the following happens:

• Before seasonal planning cycles: especially if your team expects traffic spikes, campaign pages, or product launches.
• When workflows or tools change: new framework versions, new bundlers, design system rewrites, or package manager changes can alter output and runtime behavior.
• After major redesigns: hero media, layout systems, font changes, and component shifts often affect all three metrics.
• After adding third-party integrations: analytics, consent tools, testing platforms, support widgets, and ad systems deserve immediate retesting.
• After changing image or CDN pipelines: delivery behavior can improve or regress depending on configuration.
• When field data trends worsen: even if lab tests still look acceptable.
• Before large deployment process changes: especially if release frequency is increasing and regression risk rises.

A practical recurring workflow looks like this:

1. Pick your highest-value templates and user flows.
2. Review field data for LCP, INP, and CLS by device type.
3. Choose one or two bottlenecks with the clearest impact.
4. Ship targeted fixes instead of broad rewrites.
5. Validate in lab conditions and production.
6. Document what changed and what moved.
7. Add a release guardrail so the same issue does not reappear.

If you need one final rule to keep this sustainable, use this: tie every performance fix to an owner, a page type, and a release check. That turns a page speed checklist into an operating habit.

And if your performance work overlaps with infrastructure decisions or deployment maturity, it helps to connect those systems early. Related reads include Kubernetes vs Docker Compose: When to Use Each for Small Teams and Growing Apps and CI/CD Pipeline Checklist: What to Validate Before Every Production Deploy. Better performance is easier to keep when your delivery process is predictable.

Use this guide as a living checklist: return to it before launches, after toolchain updates, and whenever user experience starts to drift. The best Core Web Vitals strategy is not chasing scores. It is building pages that load promptly, respond reliably, and stay visually stable under real conditions.