Core Web Vitals Explained: LCP, CLS, TBT, and What They Mean

What Core Web Vitals Are

Core Web Vitals are three metrics Google uses to measure how fast and stable your website feels to visitors. They became a confirmed ranking factor in 2021. Sites with good Core Web Vitals get a ranking boost in search results. Sites with poor scores do not get penalized directly, but they miss the boost their competitors receive.

The three metrics are:

• LCP (Largest Contentful Paint): How fast the main content loads.
• CLS (Cumulative Layout Shift): How much the page layout moves around while loading.
• TBT (Total Blocking Time): How long the page is frozen and unresponsive.

Google measures these on real user devices through Chrome User Experience Report (CrUX) data. PageSpeed Insights shows both lab data (simulated) and field data (real users). The field data is what Google uses for rankings.

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element to render on screen. This is usually a hero image, a large heading, or a video thumbnail. It answers the question: "How long does the visitor wait before they see the main content?"

Good: Under 2.5 seconds.
Needs improvement: 2.5 to 4.0 seconds.
Poor: Over 4.0 seconds.

Most WordPress and Webflow sites fall in the 2.5 to 5.0 second range on mobile. Static HTML sites typically achieve 0.8 to 1.5 seconds.

What causes slow LCP:

• Unoptimized images (3MB hero images that should be 100KB WebP files)
• Slow server response time (WordPress database queries adding 200-800ms)
• Render-blocking CSS and JavaScript (the browser cannot paint until these load)
• Client-side rendering frameworks (React, Vue) that build the page in the browser instead of serving ready HTML

How to fix it: Serve images in WebP/AVIF format at the correct dimensions. Inline critical CSS. Defer non-essential JavaScript. Use a CDN. Or switch to static HTML where LCP is inherently fast because the HTML is ready before the request arrives.

CLS: Cumulative Layout Shift

CLS measures how much the page content shifts around while loading. You have experienced this: you start reading a paragraph, an ad loads above it, and the text jumps down. You click a button, an image loads above it, and you accidentally click something else. That is layout shift.

Good: Under 0.1.
Needs improvement: 0.1 to 0.25.
Poor: Over 0.25.

What causes layout shift:

• Images without width and height attributes (the browser does not know how much space to reserve)
• Ads, embeds, or iframes that load after the initial content
• Web fonts that swap in after system fonts have rendered (FOUT — Flash of Unstyled Text)
• Dynamically injected content (cookie banners, notification bars, chat widgets)

How to fix it: Always set explicit width and height on images and video elements. Use font-display: swap with preloaded font files. Reserve space for ads and embeds with CSS aspect-ratio or min-height. Load third-party widgets after the main content is stable.

Static sites have an advantage here because there is no dynamic content injection. The HTML describes exactly what renders. No surprises during load.

TBT: Total Blocking Time

TBT measures how long the main thread is blocked by JavaScript during page load. While the main thread is blocked, the page is frozen. Clicks do not register. Scrolling stutters. The page looks loaded but does not respond.

Good: Under 200 milliseconds.
Needs improvement: 200 to 600 milliseconds.
Poor: Over 600 milliseconds.

TBT is a lab metric that approximates First Input Delay (FID) and Interaction to Next Paint (INP) in the field. Google uses INP as the official field metric, but TBT in PageSpeed Insights is a reliable proxy.

What causes high TBT:

• Large JavaScript bundles (React, Angular, Vue frameworks ship 100-500KB of JavaScript)
• WordPress plugins loading scripts on every page (analytics, chat, social, forms, sliders)
• Third-party scripts (Google Tag Manager, Facebook Pixel, Hotjar, Intercom) competing for the main thread
• Unminified or uncompressed JavaScript

How to fix it: Remove unused JavaScript. Defer non-critical scripts with async or defer attributes. Split large bundles into smaller chunks. Or build with static HTML where the total JavaScript is under 10KB instead of 200-500KB.

How Google Uses These Scores

Core Web Vitals are one of many ranking signals. They do not override content relevance, backlinks, or search intent matching. A fast site with irrelevant content will not outrank a slow site with exactly what the searcher needs.

But among pages with similar content quality and relevance, Core Web Vitals act as a tiebreaker. In competitive search categories where 10 sites have equally good content, the faster sites get the edge.

Google evaluates Core Web Vitals at the page level, not the site level. A single slow page does not drag down your entire domain. But if most of your pages have poor scores, the cumulative effect limits your search visibility.

The practical impact: sites that improve from poor to good Core Web Vitals typically see a 5 to 15% increase in organic traffic within 4 to 8 weeks. The lift comes from both ranking improvements and reduced bounce rates (fast sites keep visitors longer).

How to Check Your Scores

Three tools, each measuring slightly different things:

PageSpeed Insights — the standard. Shows both lab data (simulated on a mid-tier mobile device) and field data (real Chrome users over the past 28 days). The field data is what Google uses for rankings. This is the score that matters most.

GTmetrix — shows a performance waterfall chart that makes it easy to see exactly which resources are slow. Useful for diagnosing specific issues.

WebPageTest — the most detailed. Lets you test from different locations, different devices, different connection speeds. Shows filmstrip views of the page loading frame by frame. Best for deep technical analysis.

Start with PageSpeed Insights. Enter your URL, run the test on mobile (not desktop — mobile scores are typically 20-40 points lower and mobile is what Google prioritizes), and note your LCP, CLS, and TBT scores.

Score Benchmarks by Platform

Based on our audits of hundreds of sites across platforms:

• Squarespace: 40-65 mobile PageSpeed. LCP 3-6s. TBT 300-800ms. CLS 0.05-0.3. The platform overhead is baked in and cannot be optimized away.
• WordPress (no optimization): 35-60. LCP 3-7s. TBT 400-1000ms. Plugin bloat is the main culprit.
• WordPress (optimized): 65-80. LCP 2-4s. TBT 150-400ms. Caching and image optimization help but cannot eliminate the architecture overhead.
• Webflow: 70-85. LCP 2-3.5s. TBT 100-300ms. Cleaner than WordPress but still ships framework JavaScript.
• Static HTML/CSS: 90-99. LCP 0.6-1.5s. TBT 10-50ms. CLS 0-0.02. No framework, no overhead, no ceiling.

If your site is on WordPress or Squarespace and scores below 70, the platform is the bottleneck. Optimization can improve scores incrementally, but the architecture sets a ceiling. Breaking through that ceiling requires a different approach.

Get Your Score Checked

Our free site audit runs your URL through PageSpeed Insights and shows your Core Web Vitals scores alongside actionable recommendations. Takes 15 seconds.

If your scores need work, we offer two paths: optimization of your existing site (fixing images, scripts, and caching) or migration to static HTML for a permanent fix. Optimization starts at $1,000. Full migrations start at $2,500. See our audit service page for details or get in touch for a custom recommendation.