What Are Core Web Vitals — and How to Actually Fix Them

Core Web Vitals are Google’s way of measuring how a real person experiences a page as it loads and becomes usable. They are part of search ranking, but their value goes beyond SEO. A page that feels slow, unstable, or unresponsive creates friction. Visitors hesitate, lose trust, or leave before they have read anything useful.

The important point is that Core Web Vitals are not abstract technical scores. They describe familiar problems:

• The main content takes too long to appear.
• The page jumps while someone is trying to read or tap.
• A click or tap feels delayed because the browser is busy.

Improving these metrics usually means improving the site for everyone. It also forces better decisions about hosting, images, fonts, JavaScript, layout, and the way pages are built.

The three metrics

Google’s Core Web Vitals focus on three parts of the user experience: loading, visual stability, and responsiveness.

Each metric has a specific target, but the goal is not to chase a perfect score for its own sake. The goal is to remove the bottlenecks that make the page feel slow or unreliable.

LCP — Largest Contentful Paint

Largest Contentful Paint measures how long it takes for the largest visible content element to appear in the viewport. On most marketing sites, blogs, and landing pages, this is usually the hero image, main heading, featured image, or a large text block.

Target: under 2.5 seconds.

LCP matters because it is close to what a visitor experiences as “the page has loaded.” If the header appears quickly but the main content remains blank, the page still feels slow. Users do not judge performance by when every script has finished. They judge it by when the important content becomes visible.

Common causes of a bad LCP:

• A large, unoptimized hero image.
• Render-blocking CSS or JavaScript delaying the first paint.
• Slow server response, often measured as high TTFB.
• A web font that blocks text from showing.
• Client-side rendering that waits for JavaScript before showing meaningful content.
• Images being loaded too late because the browser does not know they are important.

The best LCP fixes usually come from reducing delay at the start of the page load.

Start with the LCP element itself. If it is an image, serve it at the correct dimensions. Do not upload a huge desktop image and rely on CSS to shrink it. Use modern formats such as AVIF or WebP where appropriate, and make sure responsive image sizes are configured properly. The browser should be able to choose an image that matches the screen and connection, not download more than it needs.

If the LCP image is critical, preload it. This tells the browser to fetch it early instead of discovering it later after CSS or JavaScript has been processed. Lazy loading is useful for images further down the page, but the main hero image usually should not be lazy loaded. If the first thing a visitor needs to see is delayed on purpose, LCP will suffer.

Next, look at CSS and JavaScript. Large stylesheets and scripts can block the browser from rendering the page. Inline critical CSS for the above-the-fold layout where it makes sense, and defer anything that is not needed immediately. The first view of the page should not depend on a long chain of files.

Server response also matters. A fast front end cannot fully compensate for a slow origin server. Good hosting, caching, and a CDN can reduce the time before the browser receives the first byte of HTML. For content-heavy sites, serving pre-rendered pages is often one of the cleanest ways to improve LCP.

Fonts can also delay LCP, especially when text is the largest visible element. Preload key fonts when needed, limit font weights, and use a sensible display strategy so text does not stay invisible while the font file downloads.

CLS — Cumulative Layout Shift

Cumulative Layout Shift measures how much the layout moves unexpectedly while the page is loading or being used. It captures the frustrating moment when a button moves just as someone tries to tap it, or when text shifts down because an image suddenly appears above it.

Target: under 0.1.

CLS is about trust and control. A page can load quickly and still feel poor if it keeps moving. Users should be able to read, scroll, and interact without the interface changing under them.

Common causes:

• Images or iframes with no width or height set.
• Ads, embeds, banners, or cookie notices injected after load.
• Fonts that swap and reflow the text.
• Late-loading content inserted above existing content.
• Animations that affect layout instead of using transform-based movement.

The most reliable CLS fix is to reserve space before content loads.

Always set dimensions on images, videos, and iframes. Modern responsive layouts can still preserve aspect ratio, but the browser needs enough information to allocate space before the media file arrives. Without dimensions, the browser lays out the page once, then moves everything when the image size becomes known.

Dynamic elements need the same treatment. If an ad slot, newsletter banner, product recommendation, or embedded widget will appear, reserve space for it in the layout. Do not inject it above content after the visitor has started reading. If the element may not always load, keep the reserved area stable or design a fallback that does not collapse unpredictably.

Fonts are another common source of layout shift. When a fallback font is replaced by a web font, the text can reflow because the letter shapes and spacing differ. Use a sensible font-display strategy and choose fallback fonts with similar metrics where possible. Also avoid loading too many custom font weights. Every extra file adds complexity and increases the chance of a poor loading experience.

Be careful with cookie banners and promotional bars. They often appear late, push the page down, and create layout shift. A banner that overlays the page may be less disruptive than one that inserts itself at the top after load, but it still needs to be designed responsibly.

INP — Interaction to Next Paint

Interaction to Next Paint measures how quickly a page visually responds after a user interaction, such as a click, tap, or key press. It replaced FID in 2024 and gives a broader view of responsiveness across the page experience.

Target: under 200ms.

INP matters because a page is not truly usable just because it has loaded. If a visitor taps a menu button and nothing happens for a moment, the site feels broken. If typing into a form lags, the experience feels heavy. If filters, accordions, navigation, or checkout steps respond slowly, the user loses confidence.

The usual culprit is one thing: too much JavaScript blocking the main thread.

The browser’s main thread handles a lot of work: parsing JavaScript, running scripts, calculating styles, laying out the page, painting pixels, and responding to user input. When JavaScript tasks are long or frequent, user interactions have to wait. That delay is what INP exposes.

Common causes of poor INP:

• Large JavaScript bundles.
• Heavy third-party scripts.
• Pages running far more client-side code than their interactivity requires.
• Expensive event handlers.
• Rendering too much UI after a single interaction.
• Analytics, tracking, chat widgets, and marketing scripts competing for main-thread time.

The best INP fix is to ship less JavaScript. Remove what is not needed. Split what remains. Defer scripts that are not required for the initial experience. Load third-party tools only where they are genuinely useful.

Avoid making every page behave like an app if it is mostly content. A blog post, service page, or documentation page usually does not need a large client-side framework to show text and images. Pages that arrive ready to read give the browser useful content immediately, with little work required from the user’s device.

When interactivity is needed, keep it focused. Small components should do small jobs. A mobile menu, search box, pricing toggle, or form validation script should not require a large application bundle. The less JavaScript the browser has to parse and execute, the faster it can respond to input.

Lab vs field — why your “100” can lie

Lighthouse and PageSpeed Insights are useful, but they are not the full story. They run synthetic tests under controlled conditions. That makes them helpful for debugging, comparing changes, and spotting obvious problems. But they do not always represent your real visitors.

Google uses field data for Core Web Vitals assessment where enough data is available. This comes from CrUX, which is based on real Chrome user experiences. Field data reflects real devices, real networks, real locations, real pages, and real browsing conditions.

That is why your lab score can look green while field data is red.

A synthetic test might run on a relatively consistent simulated connection. Your visitors may be using older phones, weak mobile networks, overloaded browsers, battery saver mode, or pages affected by third-party scripts that behave differently by region or session. They may also land on templates that Lighthouse did not test.

The reverse can happen too. A single Lighthouse run can look bad because of temporary server conditions or one slow test, while field data is healthier. Lab tools are snapshots. Field data is closer to lived experience.

Use both, but use them for different purposes.

Lighthouse is good for diagnosis. It can show render-blocking resources, unused JavaScript, image issues, main-thread work, and opportunities for improvement. Search Console is better for seeing whether Google considers your real user experience acceptable across groups of URLs.

Always check the Core Web Vitals report in Search Console, not just Lighthouse. If Search Console groups several similar pages together, treat that as a clue. A problem may not be isolated to one URL. It may be built into the template.

How to diagnose problems without guessing

Start by identifying which metric is failing. Do not optimize randomly.

If LCP is poor, find the LCP element. Is it an image, heading, banner, or block of text? Then work backward. Was the server slow to send HTML? Did CSS block rendering? Was the image too large? Was the image discovered late? Did a font delay text?

If CLS is poor, watch the page load slowly. Throttle the network in developer tools and reload. Look for images popping in, banners pushing content, embeds resizing, or fonts causing reflow. Layout shift is often visible once you slow the page down enough.

If INP is poor, inspect JavaScript. Look for long tasks, large bundles, and expensive interaction handlers. Test the actual things users do: open the menu, type in forms, click filters, expand accordions, interact with maps, and use search. INP is about interaction, so test interactions.

It also helps to separate first-party and third-party code. Many performance problems come from tools added over time: analytics, heatmaps, chat widgets, A/B testing scripts, embedded media, social widgets, and ad tags. Some are useful. Some are not. Each one should justify its cost.

The fastest fix is architectural

You can patch a slow site, but there is a ceiling. Compressing images, minifying files, and tweaking preload tags can help, but they cannot fully fix an architecture that sends too much work to the browser.

The biggest wins usually come from shipping less in the first place.

For many content sites, the ideal starting point is simple: the page is generated on the server and arrives as finished HTML, optimized assets, minimal CSS, and as little JavaScript as the page truly needs. The page should be readable before the browser has to run a large application. Interactivity should be added only where it improves the experience.

This is why pages that arrive ready to read perform so well for marketing sites, blogs, documentation, and service pages. They deliver meaningful content quickly, reduce main-thread work, and keep client-side processing to a minimum. Good Core Web Vitals become a natural result of the build process rather than an emergency cleanup task after launch.

This is exactly why I build content sites on a lightweight, content-first foundation where the page arrives as finished HTML and ships almost no JavaScript. Strong Core Web Vitals are not something you chase afterward; they are the default outcome of a lighter architecture and better front-end decisions. More on that approach: fast website development.

Core Web Vitals are one part of the bigger technical picture. Crawling, indexing, rendering, internal linking, structured data, and content quality all matter too. A fast page still needs to be discoverable, understandable, and technically clean: technical SEO.

If your scores are red and you want a practical plan to make them green for good, get in touch.