Core Web Vitals are Google’s standardized measures of how a web page performs from a user’s perspective. They are not measures of how a site looks, how much content it has, or how well it is optimized in the traditional SEO sense. They measure speed, responsiveness, and visual stability — specifically, what a user experiences when they load and interact with a page.
Google uses Core Web Vitals as a direct ranking signal. But their impact extends beyond search: the same performance characteristics that affect rankings also affect user behavior, conversion rates, and the experience of every visitor regardless of how they arrived.
The Three Core Web Vitals
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element on the page to load. This is typically the hero image, a large heading, or the main content block — whichever is the biggest element visible in the initial viewport.
Google’s threshold: under 2.5 seconds is Good, 2.5 to 4.0 seconds is Needs Improvement, over 4.0 seconds is Poor.
LCP is the most significant of the three metrics for most sites because it directly corresponds to the experience of waiting for the page to become useful. A user who lands on a page and sees it fill in slowly experiences that wait as the page being slow, regardless of any other technical considerations.
What affects LCP: Server response time, render-blocking resources (scripts and stylesheets that delay rendering), resource load times (especially for large images), and client-side rendering that delays when the main content appears.
Interaction to Next Paint (INP)
INP — which replaced First Input Delay (FID) in March 2024 — measures the latency of interactions with the page. When a user clicks a button, taps a menu item, or types in a field, INP measures how long it takes for the page to visually respond to that input.
Google’s threshold: under 200 milliseconds is Good, 200 to 500 milliseconds is Needs Improvement, over 500 milliseconds is Poor.
INP matters most on pages with significant user interaction: pages with dynamic filtering, complex forms, interactive charts, or JavaScript-heavy functionality. On primarily informational pages with minimal interaction, INP is less likely to be the primary performance concern.
What affects INP: JavaScript execution time, main thread blocking, and event handler efficiency. Pages that load significant amounts of JavaScript — advertising scripts, analytics, social widgets, chatbots — often have INP issues because those scripts compete with user interaction responses for main thread time.
Cumulative Layout Shift (CLS)
CLS measures visual stability — specifically, how much the page layout shifts unexpectedly as it loads. When images load without defined dimensions and push content down, when ads inject into the page and move what the user is reading, or when fonts load and cause text to reflow, those movements are layout shifts that CLS measures.
Google’s threshold: under 0.1 is Good, 0.1 to 0.25 is Needs Improvement, over 0.25 is Poor.
CLS problems are directly experienced as the page “jumping” under a user’s cursor or finger — causing them to click the wrong thing or lose their place in content. It is the Core Web Vital that most directly corresponds to a frustrating user experience.
What affects CLS: Images and media without explicit dimensions, dynamically injected content (ads, banners), web fonts that cause text reflow on load, and animations that shift content without using CSS transform properties.
Why Core Web Vitals Affect More Than Rankings
Conversion rates are sensitive to page speed. The relationship between page load time and conversion rate is well-documented: slower pages convert at lower rates across e-commerce, lead generation, and form completion. The same performance improvements that move a site from “Needs Improvement” to “Good” on LCP also reduce the user drop-off that happens when pages feel slow.
User retention is affected by perceived performance. Users who experience layout shifts, input delays, or slow loading are more likely to leave before converting and less likely to return. Core Web Vitals scores are proxies for these user experience factors.
Mobile performance is weighted heavily. Google’s Core Web Vitals measurement prioritizes mobile performance. Sites that perform well on desktop but poorly on mobile — common because mobile networks are slower and mobile CPUs process JavaScript more slowly — will have poor Core Web Vitals scores even if the desktop experience is acceptable.
How Builder Platforms Perform on Core Web Vitals
Builder platforms — Wix, Squarespace, Framer, and similar — frequently score below Good on Core Web Vitals, particularly LCP and INP. The platforms generate page code for their own systems rather than for the specific performance profile of each site. Every page loads the platform’s standard scripts, fonts, and styles regardless of whether the individual page needs them.
Site owners cannot tune this performance. They cannot eliminate unused scripts, configure a custom CDN, or modify how the platform serves resources. The performance ceiling is set by the platform.
How to Improve Core Web Vitals on a Drupal Site
Drupal, as a platform, gives developers the control they need to address Core Web Vitals. The specific improvements depend on what the assessment finds:
- LCP: Image optimization (next-gen formats, appropriate sizes, lazy loading for below-fold images, preload for the above-fold image), server response time improvements (caching, CDN configuration), elimination of render-blocking scripts.
- INP: Reducing JavaScript payload, deferring non-critical scripts, replacing heavy third-party widgets with lighter alternatives.
- CLS: Adding explicit width and height attributes to images and media, reserving space for dynamically loaded content, font loading optimization.
Drupal’s performance module ecosystem — BigPipe, Responsive Image, Image Optimization modules — addresses many of these systematically when configured correctly.
How Cool Fire Approaches Performance
Cool Fire Inc builds and maintains Drupal platforms with Core Web Vitals performance as a measurable standard for delivery. Platform assessments include a performance audit that identifies specific improvement opportunities before any work begins.
Frequently Asked Questions
What are Core Web Vitals and why do they matter?
Core Web Vitals are Google’s three standardized measures of user-experienced page performance: Largest Contentful Paint (loading speed), Interaction to Next Paint (input responsiveness), and Cumulative Layout Shift (visual stability). They matter because they are a direct Google ranking signal and because they correspond directly to user experience quality.
Do Core Web Vitals affect my search rankings?
Yes. Google uses Core Web Vitals as a ranking signal, integrated into the Page Experience ranking factors. Sites that score “Good” on Core Web Vitals have a measurable advantage over sites that score “Needs Improvement” or “Poor,” with all else equal. The impact is real but not always the dominant ranking factor for any given search result.
How do I check my Core Web Vitals scores?
Google’s PageSpeed Insights tool (pagespeed.web.dev) provides both lab data (simulated) and field data (real user measurements from the Chrome User Experience Report). Google Search Console also reports Core Web Vitals for pages with sufficient traffic data. Both are free.
Why do my Core Web Vitals scores differ between desktop and mobile?
Google primarily measures Core Web Vitals on mobile devices. Mobile networks are slower and mobile CPUs process JavaScript more slowly, which means the same page that performs well on desktop may score poorly on mobile. Google’s ranking signals prioritize the mobile score.
Can I improve Core Web Vitals on a Wix or Squarespace site?
To a limited extent. Some improvements — image compression, reducing unnecessary content — are available within builder platforms. The structural improvements that make the most difference — custom caching, CDN configuration, script elimination, server-level optimization — require control over the hosting environment that builder platforms do not expose.