DEV Community

rokya elbarbary
rokya elbarbary

Posted on

Core Web Vitals Explained for the Marketers on Your Team

Core Web Vitals are Google's three user-experience metrics for loading, responsiveness and visual stability. They matter for two reasons: they are part of the page experience signals Google Search considers, and - more importantly - they describe whether real visitors can actually use your pages.

This guide explains each metric in plain language, how to measure it, and where fixes usually come from.

The three metrics

Metric Measures "Good" threshold (Google)
LCP - Largest Contentful Paint How long until the main content (usually a hero image or headline) is visible 2.5 seconds or less
INP - Interaction to Next Paint How quickly the page responds visually after a tap, click or key press 200 milliseconds or less
CLS - Cumulative Layout Shift How much content unexpectedly jumps around while loading 0.1 or less

Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Field data vs lab data

  • Field data comes from real Chrome users (the Chrome User Experience Report, shown in Search Console and PageSpeed Insights). This is what counts.
  • Lab data comes from a simulated test (Lighthouse). It is repeatable and good for debugging, but it cannot measure INP directly and it does not reflect your real users' devices and networks.

A page can score well in Lighthouse and still fail in the field, usually on mid-range Android phones on mobile networks.

Where LCP problems usually come from

  1. Slow server response (TTFB). Uncached HTML, slow APIs during server rendering, or no CDN close to your users.
  2. The LCP image is discovered late. For example, a hero image set as a CSS background or injected by JavaScript. Put it in the HTML as an <img> and consider fetchpriority="high".
  3. The LCP image is lazy-loaded. Never apply loading="lazy" to the above-the-fold hero.
  4. Oversized images. Serve responsive sizes (srcset) and modern formats.
  5. Render-blocking CSS and fonts. Inline critical CSS; use font-display: swap or optional.

Where INP problems usually come from

  1. Long JavaScript tasks on the main thread - large bundles, heavy hydration, third-party scripts.
  2. Tag manager bloat. Every chat widget, heatmap and pixel adds main-thread work. Audit tags quarterly and remove what nobody uses.
  3. Expensive event handlers that do layout-heavy work synchronously. Yield to the main thread and defer non-urgent work.

Where CLS problems usually come from

  1. Images and videos without width and height (or an aspect-ratio).
  2. Late-loading banners, cookie bars or promos that push content down instead of overlaying it.
  3. Web fonts that swap and change text size; match fallback font metrics.
  4. Ads or embeds inserted without reserved space.

A workable process for marketing teams

  1. Open the Core Web Vitals report in Search Console and group failing URLs by template (home, service page, blog post, landing page).
  2. Fix templates, not individual pages. One template fix can move hundreds of URLs.
  3. Use PageSpeed Insights on one representative URL per template to find the specific cause.
  4. Ship the fix, then wait: field data is a rolling 28-day window, so improvements take several weeks to show.
  5. Add a performance budget (bundle size, image weight, number of third-party tags) to your release checklist so the problem does not return.

Further reading

Top comments (0)