📊Core Web Vitals: The Complete Guide

A complete reference for each Core Web Vital — what causes poor scores, how to diagnose issues, and proven strategies to improve each metric.

Hugo Team·March 21, 2026
core web vitalslcpfcptbtclsspeed indexoptimization

Core Web Vitals are Google's user-centric performance metrics that directly impact search rankings. Since June 2021, they've been part of Google's page experience ranking signal.[1] Here's everything you need to know about each metric.

LCP — Largest Contentful Paint

LCP reports the render time of the largest image, video, or text block visible in the viewport.[2] It's the best proxy for perceived "page loaded" from the user's perspective.

LCP
Good
Needs Improvement
Poor
≤ 2.5s2.5–4s> 4sseconds

Common Causes of Poor LCP

  • Slow server response times (high TTFB)
  • Render-blocking JavaScript and CSS
  • Slow resource load times (large images without optimization)
  • Client-side rendering (content not available until JS executes)[2]

How to Improve LCP

  • Use a CDN to reduce geographic latency
  • Preload the LCP image with <link rel="preload">[2]
  • Optimize and compress images (WebP/AVIF format)
  • Inline critical CSS and defer the rest
  • Use server-side rendering (SSR) instead of client-side rendering

FCP — First Contentful Paint

FCP marks the point when the browser renders the first piece of DOM content.[3] It answers "is anything happening?" for the user.

FCP
Good
Needs Improvement
Poor
≤ 1.8s1.8–3s> 3sseconds

How to Improve FCP

  • Eliminate render-blocking resources
  • Minify and compress CSS
  • Preconnect to required origins
  • Use font-display: swap to show text immediately[4]
  • Reduce server response time

TBT — Total Blocking Time

TBT measures the total time between FCP and Time to Interactive where the main thread is blocked long enough to prevent input responsiveness.[5] This is the lab metric equivalent of First Input Delay (FID).

TBT
Good
Needs Improvement
Poor
≤ 200ms200–600ms> 600msms

How to Improve TBT

  • Break up long JavaScript tasks into smaller chunks
  • Use code splitting to load only what's needed
  • Minimize third-party JavaScript impact
  • Use web workers for CPU-intensive operations
  • Defer non-critical JavaScript with async/defer[5]

CLS — Cumulative Layout Shift

CLS measures visual stability by quantifying how much visible content shifts during the page lifecycle.[6] Even small score changes are noticeable — a CLS of 0.1 means 10% of the viewport shifted unexpectedly.

CLS
Good
Needs Improvement
Poor
≤ 0.10.1–0.25> 0.25score

How to Improve CLS

  • Always include width and height attributes on images and videos[6]
  • Reserve space for ads and embeds with CSS aspect-ratio or explicit dimensions
  • Avoid inserting content above the fold after initial render
  • Use CSS transform animations instead of properties that trigger layout
  • Preload web fonts and use font-display: optional or swap[4]

SI — Speed Index

Speed Index uses video capture of the page loading to calculate how quickly content is visually complete.[7] It's a holistic metric that captures the overall "feel" of page load speed.

How to Improve SI

  • Minimize main-thread work to speed up rendering
  • Reduce critical request chains
  • Ensure text remains visible during font loading[4]
  • Use progressive image loading (blur-up technique)
  • Inline critical above-the-fold CSS

References

  1. [1]Google Search Central — Page experience update timeline — developers.google.com
  2. [2]web.dev — Largest Contentful Paint (LCP) — web.dev
  3. [3]web.dev — First Contentful Paint (FCP) — web.dev
  4. [4]web.dev — Ensure text remains visible during webfont load — web.dev
  5. [5]web.dev — Optimize Total Blocking Time — web.dev
  6. [6]web.dev — Cumulative Layout Shift (CLS) — web.dev
  7. [7]web.dev — Speed Index — developer.chrome.com

We value your privacy

We use localStorage to keep you signed in. No tracking cookies are set. Read our Cookie Policy and Privacy Policy for details.