Core Web Vitals: How to Speed Up Your Site for SEO
Core Web Vitals: How to Speed Up Your Site for SEO
A prospect clicks your ad, your page takes four seconds to show anything useful, and they bounce before your headline finishes loading. You paid for that click. You got nothing. Multiply it across a month of traffic and slow pages quietly burn a chunk of your budget while you stare at a CPL number that refuses to drop.
Core Web Vitals are Google's attempt to put a score on that experience. They measure how fast your page shows content, how quickly it responds when someone taps a button, and whether the layout jumps around while it loads. Google uses them as a ranking signal, mostly as a tiebreaker between pages of similar quality. For a B2B site competing on a handful of high-intent keywords, a tiebreaker is worth winning.
This guide covers what the three metrics actually measure, how to read your real numbers (not the lab estimate that lies to you), and the specific fixes that tend to move the needle. Most of the wins are boring and one-time. That is good news.
The three metrics, in plain terms
Core Web Vitals are three measurements, each with a "good" threshold Google publishes. You want all three in the green at the 75th percentile of your real visitors, meaning three out of four page loads hit the target.
| Metric | What it measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the biggest element (hero image, headline) is visible | under 2.5s | 2.5s to 4.0s | over 4.0s |
| INP (Interaction to Next Paint) | How fast the page responds to a click, tap, or keypress | under 200ms | 200ms to 500ms | over 500ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | under 0.1 | 0.1 to 0.25 | over 0.25 |
One change worth knowing: INP replaced an older metric called First Input Delay in March 2024. FID only measured the delay before the browser started reacting. INP measures the whole round trip, from tap to visible response, across every interaction on the page. It is harder to pass, and it is the metric most sites fail.
LCP: the wait for something real
LCP is the moment your visitor sees the main thing they came for. Usually that is a hero image, a big headline, or a banner. If your largest element shows in under 2.5 seconds, you pass.
What drags LCP down is almost always the same short list: a slow server response, a giant unoptimized hero image, render-blocking CSS and JavaScript that the browser has to chew through first, and fonts that take their time. Fix those four and LCP usually falls into place.
INP: does the page feel dead
You tap a menu, nothing happens for half a second, then it opens. That lag is what INP catches. It is a responsiveness score, and on B2B sites the usual culprit is heavy JavaScript: chat widgets, analytics scripts, marketing tags, and bloated frameworks all competing for the browser's main thread.
INP is the hard one. As of mid-2026, a large share of sites still fail the 200ms bar, more than fail LCP or CLS. If you only have time to fix one metric, this is often where the work is.
CLS: stop the page from jumping
You go to click "Request a demo" and an ad or a late-loading banner shoves the button down, so you click something else. CLS scores that frustration. The fixes are mechanical and cheap: set explicit width and height on images and video, reserve space for ads and embeds, and avoid injecting content above what the reader is already looking at.
Field data versus lab data: read the right number
Here is the trap that wastes the most time. When you run Google PageSpeed Insights, you get two scores. One is the Lighthouse "lab" score, a simulation run on a virtual device. The other is field data from the Chrome User Experience Report (CrUX), built from real Chrome users visiting your site over the past 28 days.
Google ranks on the field data. The lab score is a diagnostic tool, useful for spotting problems, but it is not what affects your SEO. Plenty of teams chase a green Lighthouse score for weeks while their actual visitors, on mid-range phones over patchy mobile networks, get a different experience entirely.
So check field data first. If your page does not have enough traffic for CrUX to report on it, that is itself a signal: low-traffic pages are exactly where lab tools mislead you most.
Where to look:
- PageSpeed Insights (pagespeed.web.dev) shows both field and lab data for a single URL. Start here.
- Google Search Console has a Core Web Vitals report that groups your URLs into good, needs improvement, and poor, based on field data. This is your portfolio view.
- Chrome DevTools (the Performance and Lighthouse panels) is where you debug a specific page once you know it is slow.
Search Console is the one to check monthly. It tells you which page groups are failing and roughly how many URLs share the same problem, which usually points at a template rather than a single page.
A fix-it order that respects your time
You do not need to fix everything. You need to find which metric is failing, on which templates, and apply the handful of changes that matter. Work in this order.
1. Find the failing template, not the failing page. Most B2B sites have a few templates: home, service pages, blog posts, landing pages. If your blog template is slow, every post inherits the problem. Search Console groups URLs by similar behavior, so fix the template once and hundreds of pages improve together.
2. Compress and right-size images. This is the single highest-leverage fix for LCP, and the easiest. Convert images to WebP or AVIF, which are far smaller than JPEG or PNG at the same quality. Serve images at the size they actually display; a 4000px-wide hero squeezed into a 1200px slot is pure waste. Add loading="lazy" to images below the fold so they do not compete with the hero for bandwidth. A heavy image library is one of the most common reasons B2B pages feel sluggish, and the connection between page speed and conversion rate makes this worth doing for revenue alone, not just rankings.
3. Trim and defer JavaScript. This is your INP fix. Audit what loads on every page. That live chat widget, three analytics tools, a heatmap script, two ad pixels, and a tag manager firing a dozen tags all add up. Remove what you no longer use. Defer what is not needed immediately with defer or async. Load chat and tracking after the page is interactive, not before. If you run a single-page-app framework, look at code splitting so visitors download only the code for the page they are on.
4. Stabilize the layout. For CLS, set dimensions on every image and video so the browser reserves the space before they load:
<!-- Browser reserves the slot, so nothing jumps when the image arrives -->
<img src="hero.webp" width="1200" height="600" alt="Dashboard screenshot">
Reserve space for ad slots and embeds the same way. If you load custom fonts, use font-display: swap so text shows immediately in a fallback font instead of staying invisible.
5. Speed up the server response. If your server takes more than half a second to send the first byte, every metric suffers. Caching, a content delivery network (CDN), and a host that is not oversold all help. On WordPress, a caching plugin plus a CDN often cuts server response time enough to pull LCP into the green on its own.
These five steps are part of broader technical SEO work, and most of them are one-time changes. You fix the template, you do not fix it again next quarter.
Where the time usually goes on a slow B2B page:
Server response ████░░░░░░░░░░░░░░░░░░ slow TTFB, no caching
Render-blocking ██████░░░░░░░░░░░░░░░░ CSS and JS in the way
Hero image ████████░░░░░░░░░░░░░░ unoptimized, oversized
JavaScript exec ██████████░░░░░░░░░░░░ widgets, tags, frameworks ← INP lives here
(Illustrative: the exact split varies by site, but heavy JavaScript and oversized images are the two most common offenders.)
How much does this actually move rankings
Honest answer: it is a tiebreaker, not a magic lever. Google has been clear that content relevance and quality come first. A fast page with weak content will not outrank a slow page that answers the query better.
Where speed earns its keep is the close race. When you and a competitor have comparable content and authority on a commercial keyword, the better page experience can be the deciding nudge. And the second benefit has nothing to do with rankings: faster pages convert better. Mobile visitors on a 5-second page bounce far more than those on a 2-second page, so the same fix that helps SEO also lifts your website conversion rate. You get paid twice for the same work.
One more reality check. Most of your B2B traffic is mobile, even for buyers who will eventually convert from a desktop at the office. Google evaluates the mobile experience, so test on a real mid-range phone, not just your fast laptop. A mobile-first site is the baseline these metrics assume.
Common mistakes
A few patterns show up again and again on B2B sites we audit.
Chasing the Lighthouse score while ignoring field data. The simulation says 98, your real users get a 40, and you wonder why rankings did not move. Check CrUX.
Treating it as a one-time project and never re-checking. You ship a new landing page builder or a fresh batch of tracking tags, and INP quietly slides back into the red. Put the Search Console report on a monthly calendar.
Over-optimizing thin pages while the money pages stay slow. Your high-intent service and landing pages deserve the attention first. A blazing-fast 404 page helps no one.
Frequently asked questions
Are Core Web Vitals a Google ranking factor?
Yes, but a modest one. They are part of Google's page experience signals and mostly act as a tiebreaker between pages of similar relevance and authority. Strong content still matters far more, so treat speed as a multiplier on good content, not a substitute for it.
What is a good Core Web Vitals score?
You want all three metrics in the green at the 75th percentile of real visits: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Hitting the target for three out of four page loads is the bar.
Why is INP harder to pass than the other metrics?
INP measures how fast your page responds to every interaction, and it is dominated by JavaScript running on the browser's main thread. B2B sites tend to pile on chat widgets, analytics, and marketing tags, all of which compete for that thread. As of mid-2026 it is the most commonly failed of the three, so it usually deserves the most attention.
How long until improvements show up?
Field data in PageSpeed Insights and Search Console is based on a rolling 28-day window of real visitors, so expect roughly three to four weeks before your scores fully reflect a fix. The page itself is faster the moment you deploy; the reported number just lags behind.
Do I need a developer to fix this?
It depends on your stack. Image compression, lazy loading, and a caching plugin are doable on platforms like WordPress without code. Trimming JavaScript, setting image dimensions in templates, and configuring a CDN usually want a developer. Image and caching fixes alone often pull two of the three metrics green.
Does mobile or desktop matter more?
Mobile. Google evaluates the mobile experience as the default, and most B2B research now starts on a phone even when the deal closes on desktop. Test on a real mid-range device over a normal mobile connection, since that is closer to what your visitors actually have.
A short checklist
Before you call it done, confirm you have:
- Checked field data (CrUX) in PageSpeed Insights and Search Console, not just the lab score.
- Found the failing template, so one fix covers many pages.
- Compressed images to WebP or AVIF and right-sized them for their slots.
- Deferred or removed non-essential JavaScript to tackle INP.
- Set width and height on images and reserved space for ads and embeds.
- Enabled caching and a CDN to cut server response time.
- Tested on a real mobile device, not just your desktop.
Speed is one of the few SEO levers you control completely. No algorithm guesswork, no waiting on backlinks: you fix the page, the page is faster, and the same work lifts both rankings and conversion.
If you would rather not dig through CrUX reports and JavaScript bundles yourself, we can help. Start with a free 20-minute review of your top landing pages, where we identify which metric is costing you traffic and the two or three fixes that will move it fastest. Get in touch and we will take a look at your real numbers.