What Core Web Vitals are and why Google created them
Core Web Vitals are three measurements Google formalized in 2020 to capture what it feels like to use a web page. The underlying problem was that web developers had long been able to game traditional speed metrics — a page could score well on raw load time while still feeling unusable because the content loaded late, the page jumped around, or tapping a button did nothing 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 actually experience.
They matter for two distinct reasons. First, they're a confirmed Google ranking factor. When Core Web Vitals became part of Google's "page experience" signals in 2021, they started influencing search rankings directly — not as the biggest factor, but as a tiebreaker between otherwise comparable pages. Second, they affect conversion rates and bounce rates. A page that loads slowly, freezes on a tap, or shoves content downward while it loads loses visitors regardless of what rank it holds.
| Metric | Full name | What it measures | Target threshold |
|---|---|---|---|
| LCP | Largest Contentful Paint | How fast the main content appears | Under 2.5 seconds |
| INP | Interaction to Next Paint | How quickly the page responds to taps and clicks | Under 200 milliseconds |
| CLS | Cumulative Layout Shift | How much the layout moves while loading | Under 0.1 |
How fast your main photo or headline shows up (LCP)
LCP measures how long it takes for the biggest thing on the part of the screen a visitor sees first, before any scrolling, to show up. That's almost always either your main photo (on a typical business homepage) or your headline (on text-heavy pages like blog posts or guides). Whatever it is, LCP is measuring the moment your most important content becomes visible: the moment a visitor knows what the page is.
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. A main photo weighing 3–6 MB is the single most common reason content loads slowly on small business sites. Saved in a modern image format at the right size, that same photo can shrink to 200–400 KB without looking any worse, and it loads in a fraction of the time. The image format and file size are the first thing to fix on any slow-loading page.
The main photo isn't told to load first. By default, the visitor's browser doesn't know your main photo exists until it has read through the rest of the page. When the page is built to start loading that photo first, before anything else, the most important thing a visitor sees appears almost instantly. This one change can shave half a second or more off how fast your main content shows up.
A slow-responding server. If your site takes 800 milliseconds just to start responding, nothing on the page can appear until after that delay, no matter how well your photos are optimized. How quickly your site starts responding is the foundation everything else is built on. Cheap shared hosting, no system for remembering files between visits, or a sluggish setup can all drag this down.
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) as Google's interactivity metric in March 2024. FID had a fundamental flaw: it only measured the delay before the browser started processing the very first interaction, and it ignored how long that interaction took to complete. You could have a site where the first tap responded quickly but every subsequent click froze the page for 600ms. FID would call it passing.
INP fixes this by measuring the delay on every interaction during a visit: clicks, taps, and keyboard presses. For each one, it's the time from when the visitor acts to when the page actually updates on screen in response. INP reports a score that reflects the slower interactions, not just the average, so if most taps are fast but some lag, INP catches the laggy ones.
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.
What causes slow responses: Too much background scripting running at once. A visitor's device can only do one thing at a time, so while it's busy crunching through scripts, taps and clicks pile up waiting for it to finish. Any single chunk of scripting that runs too long directly delays how fast the page reacts. The usual culprits are heavy interactive features that rebuild themselves on every tap, analytics and marketing trackers that fire while someone is interacting, and buttons wired to do a lot of work the moment they're clicked.
How to fix it: Break that heavy scripting into smaller pieces so the device can stop and respond to a tap between them. Review every outside script (trackers, widgets, embeds) and hold back anything that doesn't need to run while someone is using the page. The biggest wins come from cutting the amount of scripting the page has to chew through in the first place.
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.
The user experience CLS measures is something everyone has felt: you're reading a paragraph, an image finishes loading above it and shoves everything down three inches, and you lose your place. Or you go to tap a button and a banner loads half a second late directly above where you're tapping — now you've clicked the wrong thing. These aren't cosmetic annoyances; they cause users to make mistakes and abandon pages.
Images that don't have their size set in advance. When the page doesn't know how big an image will be, it can't hold a spot open for it. It lays out the surrounding text without leaving room, then shoves everything around once the image finally loads. Telling the page each image's size up front holds the space open so nothing jumps, and it still works fine when images need to resize for different devices.
Custom fonts that shuffle the text around. If your branded font takes a moment to load, the page shows a stand-in font first, then swaps in the real one. If the two fonts take up different amounts of space, all the text reflows and jumps the moment the swap happens. The fix is to either skip that swap when it would cause a jump, or match the stand-in font's spacing to the real one so the change is invisible. Telling the page to load the font early can avoid the stand-in stage altogether.
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). To "pass" Core Web Vitals overall, a page needs to hit the Good threshold on all three metrics at the 75th percentile of real-user visits. The 75th percentile rule matters: it's not enough to be fast for your average visitor. A page needs to pass for at least three out of four real users.
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 judges your scores using real-world data: actual measurements from real people visiting your site in Chrome, gathered over the previous 28 days. Because it's a rolling 28-day average, changes you make today take a few weeks to fully show up in how Google sees you. Testing tools can also estimate your scores instantly by simulating a phone and a typical connection, but that's a prediction, not a measurement of real visitors. Both are useful; they answer different questions.
The free PageSpeed Insights tool shows both. Near the top, if your site gets enough traffic, you'll see a real-world section based on actual visitors. Below that is the simulated estimate. A page can score 90+ in the simulation and still rate Poor with real visitors if people on slow connections or older phones are dragging the average down. The real-world numbers are what Google's ranking actually uses.
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) is the starting point. Enter any web address, run it, and you get both the real-world scores from actual visitors (if your site has enough traffic) and an instant simulated estimate. Run it on mobile, not just desktop. Phones score lower across the board, and mobile is what Google looks at first. The report tells you specifically which parts of the page are causing which problems. It's a diagnostic tool, not just a report card.
Google Search Console has a Core Web Vitals report under "Experience" in the left sidebar. It sorts your pages into Good, Needs Improvement, and Poor buckets based on real-visitor data, and flags specific pages by the type of problem. If you have enough traffic, this gives you a whole-site view instead of checking one page at a time. It also emails you when your status changes. Set this up and check it; it's the most direct read on how Google is seeing your site.
Chrome's built-in testing panel runs the same simulated estimate as PageSpeed Insights. The advantage is you can run it on a private test version of your site before it goes live, which is handy for checking that a fix worked before you publish it. It also breaks down, step by step, exactly which parts of the page are responsible for each problem.
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 is the worst performer on how fast content appears. Wix pages load a large chunk of background scripting (often 400–700 KB) just to run their drag-and-drop editor, and all that has to be processed before anything can show on screen. As a result, the main content on a Wix page generally takes 3.5 to 6 seconds to appear on mobile, squarely in the "Poor" range, even after you've shrunk your images. Slow tap response is also a problem, because that same Wix scripting keeps the device busy and often delays taps by more than a third of a second. After optimizing images on a Wix page, mobile speed scores commonly land in the 35–55 range because the platform's own weight dominates.
Squarespace loads less background scripting than Wix, but still runs its own system on every page. Its main content tends to appear in 2.5 to 4 seconds (the "Needs Improvement" zone) rather than outright failing. Squarespace's biggest problem is layout jumpiness: its templates often show text in a stand-in font before the real one loads, so the text visibly shuffles around when the swap happens. After image optimization, mobile scores commonly fall in the 45–65 range.
Webflow is the strongest performer among the major builders because it turns your design into clean, ready-to-serve pages instead of assembling them on the fly in the visitor's browser. Your main content can reach the "Good" range if images are properly optimized and the site is served from a network close to each visitor. Layout jumpiness is manageable with careful font handling. Webflow's weak spot is tap responsiveness on sites loaded with heavy interactions, animations, or outside widgets added after the design is built. Optimized Webflow sites reach 65–80 on mobile, better than Wix or Squarespace but still short of what a lean hand-coded site achieves.
WordPress with a page builder (Elementor, Divi, WPBakery) stacks the weight of WordPress's plugins on top of the weight of a drag-and-drop builder's styling and scripting. A typical Elementor page has to fetch 30-plus separate files and run several chunks of scripting before anything on it works. Slow tap response is common because the builder handles taps with that same heavy scripting. Content also appears slowly because cheap shared hosting is sluggish to respond in the first place. Put it together and all three of Google's health checks can fail at once, which they frequently do on shared hosting.
Hand-coded sites (what ArdinGate builds) start from zero baggage. No platform engine boots up. No builder scripting loads. What reaches the visitor's browser is exactly what the page needs: the menu, the main photo set to load first, lean styling, and the content. On a properly configured server backed by a network that serves the site from somewhere near each visitor, the site starts responding in under a tenth of a second, which gives the main content a clean runway to appear in under two seconds. Slow taps aren't an issue because there's no heavy background scripting clogging things up. Jumpy layout is eliminated by setting every image's size up front and loading fonts early. Mobile speed scores land in the 88–98 range on pages with any photos or video at all, and 95–100 on text-heavy pages. These aren't scores you chase with patch-up work after launch. They're what you get when the site is built to meet the targets from day one.
If you're on a builder platform and your main content still takes more than 3 seconds to appear on mobile after you've shrunk your images, the platform itself is the bottleneck. More cleanup won't close that gap. For small business sites competing in local search where Google's speed health checks can break a tie, the choice of how the site is built is the choice that decides your speed. See how custom code compares to page 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. Telling the page to load your main photo first is one of the highest-impact single fixes there is.
- 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, not just 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.