Core Web Vitals is Google's attempt to answer a hard question with three numbers: does this page feel good to use? Not "is it technically fast" — whether a real person on a real phone on real network conditions has a decent time.
Three metrics, each measuring a different kind of frustration.
What Core Web Vitals actually are
They are measured from real Chrome users visiting your site, aggregated over a rolling 28-day window, and reported at the 75th percentile. That last detail matters more than anything else in this article: Google grades you on your slower quarter of visitors, not your average one. A site that is fine on office wi-fi and miserable on a train fails.
If 74% of your visitors get a 2.0s load and 26% get 5.0s, your reported LCP is 5.0s and you fail. Optimising for your own browsing experience is how sites quietly fail for years.
LCP — how long until something useful appears
Largest Contentful Paint measures when the biggest element in the viewport finishes rendering. Usually a hero image, a headline, or a video poster frame. It is the moment the visitor stops looking at a blank rectangle and starts looking at your site.
Target: 2.5 seconds or less on mobile.
What breaks it, in the order we find it:
- The hero image is enormous. Resize it to the rendered width, convert to WebP, and serve responsive sizes with
srcset. - The hero image is lazy-loaded. This is a genuinely common own goal: a plugin adds
loading="lazy"to every image including the one at the top, so the browser deliberately waits before fetching the exact thing LCP measures. Above-the-fold images should be eager, and ideally preloaded. - Slow server response. If TTFB is 1.5s, LCP cannot beat 1.5s. Caching first, then hosting.
- Render-blocking CSS. The browser will not paint until the stylesheet is parsed.
<!-- Tell the browser about the hero before it finds it -->
<link rel="preload" as="image"
href="/img/hero-1600.webp"
imagesrcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w">INP — how long until the page responds
Interaction to Next Paint replaced First Input Delay in 2024, and it is a much harder test. FID only measured the delay before the first interaction was processed. INP looks at essentially every tap, click and key press during the visit and reports the worst one.
Target: 200 milliseconds or less.
INP is a JavaScript problem, almost without exception. When someone taps "Add to cart" and the main thread is busy running a carousel script, a chat widget's boot sequence and an A/B testing library, their tap sits in a queue. The button eventually reacts. It feels broken.
- Cut the JavaScript you do not need. Same audit as your plugin list — every script is a claim on the main thread.
- Break up long tasks. Anything over 50 ms of continuous work blocks input. Chunk it, or move it to a web worker.
- Defer non-critical third parties until after first interaction. Chat widgets in particular rarely need to load in the first three seconds.
- Give instant visual feedback. A button that changes state immediately and then does the work reads as responsive even when the work takes time.
CLS — how much the page moves under your thumb
Cumulative Layout Shift scores unexpected movement. You are about to tap a link, an image finishes loading above it, the whole page jumps, and you tap an ad instead. Everyone has done this. Everyone hated it.
Target: 0.1 or less.
CLS is the easiest of the three to fix and the one most often left broken:
- Set
widthandheighton every image and video. Modern browsers use them to compute an aspect ratio and reserve the space before the file arrives. This one change fixes the majority of CLS problems. - Reserve space for anything that appears late — ads, embeds, cookie banners, "free shipping" bars. Give the container a fixed
min-height. - Never insert content above existing content unless it is in response to a user action.
- Use
font-display: swapwith a metric-matched fallback so the text does not reflow when the web font lands.
See your own numbers in 30 seconds
The free Softshelf audit runs your URL through Google's own PageSpeed data and returns your performance, SEO and accessibility scores plus the specific elements slowing the page down. No signup, no sales call.
Lab data vs field data (this trips everyone up)
Run PageSpeed Insights and you get two panels that often disagree, sometimes dramatically. Here is the difference:
| Field data (CrUX) | Lab data (Lighthouse) | |
|---|---|---|
| Where it comes from | Real Chrome users, last 28 days | One simulated load, right now |
| Affects your ranking | Yes | No |
| Includes INP | Yes | No — estimates TBT instead |
| Available on new/low-traffic sites | Often not | Always |
| Best used for | Knowing whether you pass | Diagnosing why you don't |
The practical consequence: field data is your grade, lab data is your homework. And because field data moves on a 28-day rolling window, a fix you ship today will not fully show up in Search Console for about four weeks. Do not panic and undo good work in week two.
What failing actually costs
Ranking is the reason people usually look at Core Web Vitals, and it is the smaller half of the story. Google has been clear that page experience is a modest signal — a tiebreaker between comparable pages, not a substitute for relevance.
The bigger cost is conversion. Google's own field research puts the probability of a bounce up roughly 32% as load time goes from 1 to 3 seconds, and up 90% from 1 to 5 seconds. Deloitte's retail study found a 0.1-second improvement in load time associated with an 8.4% lift in retail conversions. Your mileage varies, but the direction never does.
Monthly visitors × conversion rate × average order value = revenue. Now recalculate with the conversion rate 15% higher. If that difference is bigger than a one-off optimisation fee, the decision has made itself.
A two-week plan to pass
Week one — the measurable wins.
- Day 1: record baselines for all three metrics, mobile, on your five most-visited URLs.
- Day 2: resize and convert every above-the-fold image; remove
loading="lazy"from the hero. - Day 3: add
widthandheightto every image sitewide. - Day 4: audit third-party scripts, remove the ones nobody reads, defer the rest.
- Day 5: enable caching, add a CDN, verify TTFB is under 800 ms.
Week two — the structural ones.
- Reserve space for banners, embeds and consent notices.
- Add
deferto every script that is not needed for first paint. - Cut font weights to the two you actually use, with
display=swapandpreconnect. - Preload the LCP element.
- Re-measure in the lab, then wait 28 days and check the field data in Search Console.
Most small business sites pass all three after this list. If yours does not, the ceiling is architectural — the theme, the page builder, or the hosting — and that is a different conversation.
Want this done for you this week?
Softshelf fixes performance and conversion problems on a flat fee — you approve a fixed number before anything starts, and you get a before/after report when it ships. Most speed sprints are delivered in 3–5 working days.
Frequently asked questions
What is a good Core Web Vitals score?
Pass all three at the 75th percentile on mobile: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Google reports these as a pass/fail per metric rather than a combined score.
How long until Search Console shows my improvements?
Field data uses a rolling 28-day window, so expect roughly four weeks before a fix is fully reflected. You will usually see the trend start to move within 7 to 10 days.
Why does my PageSpeed score change every time I run it?
The lab test simulates a throttled connection on shared infrastructure, so run-to-run variance of 5 to 10 points is normal. Judge changes by field data, or by the median of three lab runs.
Do Core Web Vitals matter for a site with no organic traffic?
They matter more, not less. If you are paying for every visitor through ads, a slow landing page means you pay for clicks that bounce before the page renders. The metrics are a conversion issue first and a ranking issue second.