# Core Web Vitals for marketing sites

> Core Web Vitals for a marketing website: what LCP, INP and CLS measure, why hero media and third-party tags break them, and how we fix each one in Next.js.

Canonical page: https://kyvrel.com/blog/core-web-vitals-marketing-sites
Published: 2025-10-21 · 6 min read · Kyvrel

For a Core Web Vitals marketing website target, aim for three numbers: main content visible within 2.5 seconds, a response to every tap or click within 200 milliseconds, and almost no layout shift. Those are the "good" thresholds for LCP, INP and CLS. On most marketing sites, the problems come from the same few places: heavy hero media, third-party tags, cookie banners and late-loading fonts.

This guide explains each metric in plain terms, shows where marketing sites usually lose points, and lists the fixes we apply on Next.js builds.

## What are Core Web Vitals, and why do marketing sites fail them?

Core Web Vitals are three metrics Google uses to describe real-world page experience. They are measured from real visits in Chrome and reported at the 75th percentile, so three out of four visits need to hit the threshold.

![Three bars showing the good thresholds for loading, responsiveness and visual stability](https://kyvrel.com/blog/inline/core-web-vitals-marketing-sites-1.png)

- **Largest Contentful Paint (LCP)** measures loading. It records when the largest visible element, usually the hero image or headline, finishes rendering. Good is 2.5 seconds or less.
- **Interaction to Next Paint (INP)** measures responsiveness. It looks at how long the page takes to visibly react to clicks, taps and key presses across the whole visit. Good is 200 milliseconds or less. INP replaced First Input Delay as a Core Web Vital in March 2024.
- **Cumulative Layout Shift (CLS)** measures visual stability. It adds up unexpected movements of content while the page is open. Good is 0.1 or less.

Google's [web.dev overview of Web Vitals](https://web.dev/articles/vitals) defines each one in detail.

Marketing sites fail these for a specific reason. They are often built by a design team and then extended by a marketing team. Every campaign adds a tag, a widget or a bigger hero video. Each addition seems small. Together, they push the page over the limit.

Do Core Web Vitals affect rankings? They are part of the page experience signals Google's systems use, but relevance and content quality matter far more. The stronger reason to care is that slow, jumpy pages lose visitors before they read your offer.

## Field data vs lab data: measure the right thing

There are two kinds of measurement, and they often disagree.

- **Field data** comes from real users, through the Chrome User Experience Report. It is what Search Console's Core Web Vitals report shows. It reflects real devices and real networks, and it updates over a rolling 28-day window.
- **Lab data** comes from a test run in a controlled setting, such as Lighthouse or PageSpeed Insights' lab section. It is useful for debugging, because you can repeat it after every change.

A Lighthouse score of 98 on a fast laptop does not mean your visitors on mid-range phones are fine. Use lab tools to find and fix problems. Use field data to confirm the fix worked.

Low-traffic pages may not have enough field data of their own. In that case, Search Console groups them with similar pages, and you can add your own real-user monitoring.

## Fixing LCP: the hero is usually the problem

On most marketing pages, the LCP element is the hero image, the hero video's poster, or the main headline. The fixes are well known:

1. **Serve the hero image at the right size and format.** In Next.js, `next/image` generates responsive sizes and modern formats. Set the `sizes` attribute so phones do not download a desktop image.
2. **Prioritize it.** Mark the hero image with `priority` so it is preloaded, and never lazy-load anything above the fold.
3. **Avoid hero sliders and autoplay video.** A carousel delays the real LCP element and adds JavaScript. A static image or a strong headline usually communicates better anyway. Our article on [SaaS homepage design](https://kyvrel.com/blog/saas-homepage-design) covers hero patterns that work without them.
4. **Render on the server.** With React Server Components, the hero's HTML arrives complete. The browser does not wait for JavaScript to build the page.
5. **Cut render-blocking requests.** Inline critical CSS, self-host fonts, and remove unused stylesheets from third-party embeds.

Text LCP elements depend on fonts. If the headline waits for a web font, LCP waits too. That leads to the next fix.

## Fixing INP: third-party scripts and heavy JavaScript

INP problems come from the main thread being busy when the user interacts. On marketing sites, the usual culprits are not your own code:

- Tag managers loading several analytics and advertising pixels.
- Chat widgets that load a full application on every page.
- A/B testing tools that hide the page until their script decides what to show.
- Heavy animation libraries running scroll effects on every frame.
- Embedded third-party forms that bring their own frameworks.

What works:

- **Audit every tag.** For each script, ask who uses its data and when they last looked. Remove anything nobody can name an owner for.
- **Load late.** In Next.js, `next/script` with `lazyOnload` or `afterInteractive` keeps non-essential scripts out of the critical path.
- **Load on intent.** Show a lightweight chat button and load the full widget only when someone clicks it.
- **Ship less client JavaScript.** Keep most components as Server Components, and make only interactive parts client components.
- **Break up long tasks.** Event handlers should do the minimum before the next paint, and defer the rest.

Fewer third-party scripts also make security easier. Each one is another source in your Content Security Policy, as our [website security checklist](https://kyvrel.com/blog/website-security-checklist) explains.

## Fixing CLS: banners, fonts and embeds

Layout shift happens when something appears or resizes after the content around it has rendered.

- **Cookie banners.** Show them as an overlay fixed to the bottom of the viewport, not as a block that pushes the page down.
- **Images and video without dimensions.** Always set width and height, or an aspect ratio, so the browser reserves space.
- **Web fonts.** A fallback font with different metrics causes text to reflow when the web font arrives. `next/font` self-hosts fonts and adjusts the fallback's metrics to match, which removes most of this shift.
- **Embeds and ads.** Reserve a fixed-size container for maps, videos and third-party forms.
- **Late banners and announcements.** Promotional bars injected at the top of the page after load are a common cause. Render them on the server or reserve their space.

![Grid of common layout shift sources on marketing pages: banners, images, fonts, embeds and promo bars](https://kyvrel.com/blog/inline/core-web-vitals-marketing-sites-2.png)

## Core Web Vitals marketing website checklist

Use this before launch and after every major campaign:

- Hero image served via `next/image` with correct `sizes` and `priority`.
- No carousel or autoplaying video above the fold.
- Fonts self-hosted through `next/font`, with no more than two families.
- Every image, video and embed has reserved dimensions.
- Cookie banner rendered as a fixed overlay.
- Tag inventory reviewed, with an owner for every script.
- Non-essential scripts loaded with `lazyOnload` or on user intent.
- Most components rendered on the server.
- Lab checks pass on a throttled mid-range mobile profile.
- Field data in Search Console reviewed 28 days after launch.

Performance is easier to keep than to recover. A short budget agreed with marketing, such as "no new third-party script without review", protects the work after launch.

## Next step: a marketing site that stays fast

Our [landing page design services](https://kyvrel.com/products/landing-page) start at $5,000 for a one-page site with 8 sections, with 2 revision rounds and a typical timeline of 1-2 weeks. For a multi-page marketing site, our [corporate website](https://kyvrel.com/products/corporate-website) starts at $8,500. We build on Next.js, performance budgets are part of the build, and we check Core Web Vitals on every key template before launch.

If you are deciding between a site builder and a custom build, our [Webflow vs custom comparison](https://kyvrel.com/compare/webflow-vs-custom) sets out where each one makes performance easier or harder.
