What Core Web Vitals are and why Google created them
Google formalized three Core Web Vitals in 2020 to measure felt usability. Traditional load metrics could be gamed while content appeared late, layouts jumped or buttons stayed unresponsive for two seconds.
Google's answer was to measure three specific, user-focused experiences: how fast the main content appears (Largest Contentful Paint), how quickly the page responds to input (Interaction to Next Paint), and how much the layout shifts while loading (Cumulative Layout Shift). Together, these three signals capture loading performance, interactivity, and visual stability, the dimensions of performance that users experience.
They're a confirmed ranking factor since 2021's page-experience signals, breaking ties between comparable pages. They also affect conversion and bounce rates: slow loading, frozen taps and shifting content lose visitors regardless of rank.
How fast the main content appears
Target: under 2.5 secondsHow quickly the page responds to taps and clicks
Target: under 200 millisecondsHow much the layout moves while loading
Target: under 0.1How fast your main photo or headline shows up (LCP)
LCP measures when the largest initially visible element appears, usually a business homepage's main photo or a text-heavy page's headline. It marks when visitors can identify the page's main content.
The target is 2.5 seconds or faster. Between 2.5 and 4.0 seconds is the "Needs Improvement" range. Above 4.0 seconds is failing. Google gathers this measurement from Chrome users on real devices and connections. The threshold applies to the actual median experience, not what it looks like on your development machine over fiber.
The most common LCP culprits include:
Bloated images commonly cause slow small-business pages. Modern, correctly sized formats reduce a 3–6 MB hero to 200–400 KB without visible loss. Fix format/size first.
Prioritize the main photo. Browsers otherwise discover it only after reading the page. Starting it first can save half a second or more, making key content appear nearly instantly.
Server delay blocks everything. An 800-millisecond initial response prevents any display, regardless of image optimization. Cheap shared hosting, missing caching and sluggish setups undermine the entire load.
Things that delay the page from appearing. If bulky styling or scripting files sit between the visitor and your content, they hold up the whole page: nothing can show until those files finish processing. Loading the essential styling right away and pushing non-essential scripts until later lets your content appear sooner.
How quickly the page responds when someone taps (INP)
INP replaced FID (First Input Delay) in March 2024. FID measured only delay before the first interaction began, ignoring completion and later 600ms freezes that could still pass.
INP measures every click, tap and keypress from action to visual response. Its score reflects slower interactions, catching intermittent lag that an average would hide.
The target is 200 milliseconds or under. Between 200 and 500ms is "Needs Improvement." Above 500ms is failing. Under 200ms, interactions feel instantaneous. Above 500ms, users feel the page is broken.
Long scripting blocks responses: device work runs sequentially, queuing taps/clicks. Common culprits are interactions rebuilding on each tap, analytics/marketing trackers firing during use and buttons triggering extensive work.
Split heavy scripts so taps can be handled between chunks. Defer unnecessary trackers/widgets/embeds during interaction. Cutting total scripting offers the largest improvement.
For hand-coded sites with little background scripting, slow tap response is rarely a problem. The sites that struggle with it are the ones built on heavy platforms or loaded down with marketing trackers.
Whether the page stays put instead of jumping around (CLS)
CLS measures visual instability: specifically, how much content moves unexpectedly during and after load. Every time an element shifts position without user input, CLS accumulates. It's scored as a number where 0 is no shifting and higher numbers mean more shifting. The target is 0.1 or under. Between 0.1 and 0.25 is "Needs Improvement." Above 0.25 is failing.
CLS captures disruptive shifts: a late image pushes reading down three inches; a banner appears half a second before a tap, causing the wrong click. These cause mistakes and abandonment.
Declare image dimensions upfront. Otherwise text lays out without reserved space and jumps when images arrive. Specified dimensions prevent movement while still supporting responsive resizing.
Font swaps can shift text. A temporary font with different dimensions reflows when branding loads. Avoid disruptive swaps, match fallback spacing or load fonts early enough to skip the fallback entirely.
Content that arrives late. Cookie banners, chat widgets, promotional bars, and ads often load after the rest of the page and shove existing content down. The fix is to set aside space for these elements in the page's layout from the start, so nothing moves when they show up.
New content inserted above what's already there. When something gets added above what the visitor can already see (a notification, a header that appears as they scroll, a row of testimonials that loads in), everything on screen jumps down. These additions should be locked to a fixed spot or loaded up front, before the visitor starts reading.
Thresholds, scoring, and what "passing" means
Each Core Web Vital has three zones: Good (pass), Needs Improvement (partial credit), and Poor (fail). An overall pass requires Good on all three at the 75th percentile of real-user visits. The 75th percentile rule means at least three out of four users, not merely the average visitor.
The thresholds in full:
| Metric | Good (pass) | Needs Improvement | Poor (fail) |
|---|---|---|---|
| LCP | Under 2.5s | 2.5s – 4.0s | Over 4.0s |
| INP | Under 200ms | 200ms – 500ms | Over 500ms |
| CLS | Under 0.1 | 0.1 – 0.25 | Over 0.25 |
Google uses real Chrome visits over a rolling 28-day average, so fixes take weeks to fully appear. Simulated phone/connection tests give immediate predictions. Both help, but only field data measures actual visitors.
Free PageSpeed Insights shows real visitors above simulations when traffic suffices. A 90+ simulation can coexist with Poor field results from older phones/slow connections. Google ranks using field data.
How to check your Core Web Vitals scores
There are four tools worth knowing, each giving you a different view of the data:
Google PageSpeed Insights (pagespeed.web.dev) diagnoses specific problems and scores any URL using simulations and, with sufficient traffic, real visits. Test desktop/mobile; phones score lower and Google prioritizes mobile.
Google Search Console's Experience → Core Web Vitals groups real-visitor pages as Good, Needs Improvement or Poor and identifies causes. Sufficient traffic enables a site-wide view; status-change emails help monitor Google's assessment.
Chrome's testing panel runs PageSpeed Insights-style simulations on private pre-launch sites, verifying fixes before publication and detailing each problem's causes step by step.
WebPageTest (webpagetest.org) gives you finer control: real devices, specific connection speeds, multiple test locations, and a detailed timeline of what loads when. It's the right tool when you've found a problem and need to understand exactly when each piece of the page loads and why. For most check-ups, PageSpeed Insights plus Search Console covers 80% of what you need.
One practical note: run any test at least three times and average the results. The instant simulated scores can swing 10–15% from one run to the next depending on how quickly your server happened to respond that moment. A single run is one data point; three runs give you a picture.
How each platform maps to Core Web Vitals scores
Core Web Vitals scores aren't just about how fast your images are. They're shaped by everything the platform loads into a visitor's browser before your images even get a chance. Understanding how each builder platform lines up with specific problems explains why cleaning things up fixes some sites but not others.
Wix often processes 400–700 KB of builder scripts before rendering, the weakest content-display performance. Mobile content usually appears in 3.5 to 6 seconds, Poor even with optimized images; scripts can delay taps over a third-second. Optimized mobile scores commonly remain 35–55 because platform weight dominates.
Squarespace has less scripting than Wix but still runs platform code. Content appears in 2.5 to 4 seconds, Needs Improvement. Fallback-to-brand font swaps commonly shift layouts; optimized mobile scores remain 45–65.
Webflow produces ready-to-serve pages, leading builders. Optimized images and nearby delivery can achieve Good main-content timing; careful fonts control shifts. Heavy interactions, animation and added widgets can delay taps. Optimized mobile scores reach 65–80, above Wix/Squarespace but below lean custom sites.
WordPress builders Elementor, Divi and WPBakery combine plugin and builder CSS/script weight. Elementor commonly fetches 30-plus files before working; heavy interaction scripts delay taps, and cheap shared servers delay content. All three health checks frequently fail together on shared hosting.
ArdinGate's hand-coded sites send only needed menus, prioritized hero, lean CSS and content. Proper servers with nearby delivery respond under a tenth-second, showing content under two seconds. No heavy scripts delay taps; declared image dimensions and early fonts prevent shifts. Mobile scores reach 88–98 with photos/video and 95–100 for text, achieved by building to targets from the start.
If optimized builder images still leave mobile content above 3 seconds, platform overhead is the bottleneck cleanup cannot remove. Build choice determines speed for local-search tiebreakers. Compare custom code and builders →
On a mobile-first hand-coded site, all three Core Web Vitals pass because the code is written to pass them — not patched afterward. See site speed optimization →
Key takeaways
- Core Web Vitals measure three things that users feel: how fast content appears (LCP), how quickly interactions respond (INP), and how stable the layout is (CLS).
- Your main content should appear in under 2.5 seconds. The biggest reasons it doesn't are bloated images and a slow-responding server. Few single fixes have as much impact as telling the page to load your main photo first.
- How fast a page reacts to taps got a stricter measurement from Google in March 2024 that watches every interaction across a whole visit, not just the first one. Too much background scripting bogging down the visitor's device is the main cause of slow reactions.
- Layout jumpiness should stay near zero. It's almost entirely caused by images without their size set in advance, custom-font swaps, and content that loads in late. All three have specific, concrete fixes.
- Google ranks on real-world data from actual Chrome visitors, not instant simulated scores. Changes you make take 4–6 weeks to show up in that real-world data for sites with meaningful traffic.
- Run PageSpeed Insights on mobile as well as desktop. Phone scores are consistently lower because the test simulates a mid-range phone on a slower connection, and mobile is what Google ranks on.
- Builder platforms (Wix, Squarespace, WordPress with heavy plugins) put a hard ceiling on your speed because of everything they load behind the scenes. Hand-coded sites don't carry that baseline weight, which is why they consistently score higher.
Related guides
Common questions
Do Core Web Vitals affect Google ranking directly?
Core Web Vitals joined ranking with 2021's completed page-experience rollout. Relevance, backlinks and on-page SEO usually matter more, but better vitals win comparable-page ties, especially among few local competitors. Lower bounce and higher conversion on fast, stable pages often outweigh ranking benefits.
What is the difference between INP and FID?
March 2024's INP replaced FID (First Input Delay), which measured only first-event processing delay, not completion. INP tracks every interaction through the next visual update; the 75th percentile becomes the page score. It catches later-session lag missed by FID, explaining why previously passing sites may fail.
My desktop score is 95 but my mobile score is 48. Why?
PageSpeed Insights simulates mid-range mobile hardware/slow connections versus fast, reliable desktops. Work can take four times longer on phones, with slower image downloads. This deliberately reflects real visitors; Google ranks on mobile, so 48 is the score to fix.
Can I fix Core Web Vitals on a Wix, Squarespace, or Webflow site?
Partially. Compress images, limit outside widgets and unnecessary movement, but Wix/Squarespace runtime cannot be removed. Webflow produces cleaner pages yet retains builder weight; custom starts without it. Below 55 after compression, the platform remains your speed ceiling.
What causes CLS and how do I fix it?
Layout shifts come from un-sized images, dimension-mismatched fallback/brand fonts, unreserved ads/embeds and late cookie/chat interfaces. Reserve image dimensions, smooth font swaps, fix ad-slot space and allocate banner space before rendering. Each prevents content being displaced after visitors see it.
How long until Core Web Vitals improvements show up in Google ranking?
Ranking uses rolling 28-day Chrome field data: improvements take 4–6 weeks with solid traffic, longer otherwise. Simulations update immediately; track PageSpeed Insights' real-world section for ranking data.