Core Web Vitals in Practice: 12 Actions to Improve LCP, CLS, and INP

Core Web Vitals Are Not a Theoretical Exercise

Google's Core Web Vitals are the metrics that determine whether your site provides a good user experience — and they directly influence search rankings. But reading about LCP, CLS, and INP thresholds is different from actually improving them. This guide focuses on the specific, practical changes that move the needle. No theory dumps, no vague advice. Just twelve actions you can take, roughly in order of impact.

The Three Metrics That Matter

Before diving into fixes, here is what each metric measures:

• Largest Contentful Paint (LCP): How long until the largest visible element (usually a hero image, heading, or text block) fully renders. Target: under 2.5 seconds.
• Cumulative Layout Shift (CLS): How much the visible content shifts during loading. Target: under 0.1.
• Interaction to Next Paint (INP): How long it takes the page to respond visually after a user interaction (click, tap, keypress). Target: under 200 milliseconds.

Actions That Improve LCP

1. Optimize Your LCP Element

Identify the LCP element on your key pages — usually a hero image, a large heading, or a background image. Use your browser's developer tools or Lighthouse to pinpoint it. Once you know what it is, optimize it directly:

• If it is an image: serve it in WebP or AVIF format, compress it aggressively, and size it to the rendered dimensions (not a 4000-pixel source for a 800-pixel display).
• If it is a text block: ensure the font loads quickly (see Action 5).
• If it is a background image set via CSS: preload it with a <link rel="preload"> tag in the document head.

2. Reduce Server Response Time

LCP cannot be faster than your Time to First Byte (TTFB). If the server takes 1.5 seconds to respond, LCP will be at least 1.5 seconds plus rendering time. Improve TTFB by optimizing database queries, enabling server-side caching, using a CDN, and ensuring your hosting plan provides adequate resources.

3. Eliminate Render-Blocking Resources

CSS and synchronous JavaScript in the document head block rendering. The browser cannot paint anything until these resources are downloaded and processed. Move non-critical CSS to the bottom or load it asynchronously. Defer or async JavaScript that is not needed for the initial render. Inline critical CSS (the styles needed for above-the-fold content) directly in the HTML document.

4. Preload Critical Resources

Tell the browser about resources it needs immediately using <link rel="preload">. Preload the LCP image, critical fonts, and any CSS or JavaScript that is loaded by other CSS or JavaScript (which the browser cannot discover until it parses the parent resource). Preloading eliminates discovery delays and gets critical resources loading sooner.

5. Optimize Font Loading

Custom web fonts are a frequent LCP blocker. If your LCP element is text styled with a custom font, the text will not render until the font file is downloaded (or the font-display timeout fires). Fix this by:

• Using font-display: swap so the browser renders text in a fallback font immediately and swaps in the custom font when it loads.
• Preloading font files with <link rel="preload" as="font" crossorigin>.
• Self-hosting fonts instead of loading them from external services to reduce DNS lookups and connection overhead.
• Subsetting fonts to include only the character sets you actually use.

Actions That Improve CLS

6. Set Explicit Dimensions on Images and Videos

The most common cause of layout shift is images and videos that load without explicit width and height attributes. The browser does not know how much space to reserve until the resource loads, so content below shifts downward. Always set width and height attributes on images and videos, or use CSS aspect-ratio to reserve space before loading.

7. Reserve Space for Ads and Embeds

Third-party embeds — ads, social media widgets, video players — inject content dynamically. If the container has no minimum height, the embed pushes content down when it loads. Set a minimum height on embed containers that matches the expected content size. For ads, use placeholder containers that match the ad slot dimensions.

8. Avoid Inserting Content Above Existing Content

Banners, notification bars, and cookie consent modals that inject at the top of the page push everything else down. If you must show these elements, either reserve space for them in the initial layout or overlay them without affecting document flow. A notification bar that slides down from the top and pushes content is a CLS offender. One that overlays or uses a fixed position is not.

9. Use CSS Transform for Animations

Animations that change layout properties (width, height, top, left, margin) cause layout shifts. Animations that use CSS transforms (translate, scale, rotate) do not affect layout and therefore do not contribute to CLS. Whenever possible, animate visual changes using transforms instead of layout-affecting properties.

Actions That Improve INP

10. Break Up Long JavaScript Tasks

INP measures responsiveness, and the browser cannot respond to user interactions while it is executing JavaScript on the main thread. Long tasks (over 50 milliseconds) block the main thread and delay interaction responses. Break large JavaScript operations into smaller chunks using requestAnimationFrame, setTimeout, or the Scheduler API so the browser can process user input between chunks.

11. Reduce JavaScript Execution

The less JavaScript the browser has to process, the more responsive the page. Audit your JavaScript bundles for unused code. Use code splitting to load only the JavaScript needed for the current page. Remove or defer third-party scripts that are not critical for the visible content. Tree-shaking, lazy loading, and dynamic imports are all effective strategies.

12. Optimize Event Handlers

Event handlers that perform heavy computation, DOM manipulation, or synchronous network requests directly in response to user interactions cause poor INP scores. Move heavy work out of event handlers — use web workers for computation, batch DOM updates, and make network requests asynchronous. The event handler should respond quickly and visually (e.g., show a loading indicator) while heavy work happens in the background.

Measuring and Monitoring

Fixing Core Web Vitals is only half the job — you need to verify the improvements and prevent regressions. Use these measurement approaches:

• Lab data: Lighthouse and Chrome DevTools provide controlled, repeatable measurements on your development machine. Good for debugging specific issues.
• Field data: Chrome User Experience Report (CrUX) and real user monitoring (RUM) tools measure actual visitor experiences across diverse devices and networks. This is what search engines use for ranking decisions.
• Continuous monitoring: Integrate Lighthouse into your CI/CD pipeline to catch regressions before they reach production. Set thresholds that match your Core Web Vitals targets.

The Hosting Connection

Several of these actions connect directly to hosting decisions. TTFB depends on server hardware, software configuration, and geographic proximity. CDN configuration affects both TTFB and LCP. Database performance affects server response time for dynamic pages. Caching — at the server, CDN, and browser levels — reduces the work the server does per request. A site that is well-optimized at the code level but hosted on an underpowered, poorly configured server will still have poor Core Web Vitals.

Getting Started

Run Lighthouse on your three to five most important pages. Identify the biggest LCP, CLS, and INP issues on each. Start with the actions that address those specific issues. Measure after each change to confirm improvement. Then move to the next issue. Core Web Vitals improvement is iterative, not a single heroic effort. Each fix compounds, and the cumulative effect is a site that is measurably faster, more stable, and more responsive — which translates directly to better rankings and happier visitors.