Technical · Jun 25, 2026 · 10 min read · by the Keystone Search team

Site speed and Core Web Vitals, in plain terms

Site speed is one of those topics where everyone agrees it matters, but very few people can tell you what to actually change. You read that a slow site loses customers, you run a test, you get a score out of 100, and then you stare at a list of warnings written in a language that seems designed to make you feel inadequate. This guide is meant to cut through that. We will go through what the Core Web Vitals actually measure, what genuinely moves them, and how to decide which fixes are worth your time and which are not.

The honest starting point is this: speed is a means, not an end. Nobody buys from you because your Largest Contentful Paint is 1.8 seconds instead of 2.4. They buy because the page felt responsive, the thing they wanted appeared quickly, and nothing got in their way. Google built Core Web Vitals to approximate that human experience with numbers, because numbers are easier to rank by. So when we talk about improving these metrics, what we are really doing is improving the felt experience of using your site, and the score is just the scoreboard.

What the three metrics actually measure

There are three Core Web Vitals, and each one captures a different kind of frustration. Once you understand the frustration behind the metric, the metric stops being abstract.

Largest Contentful Paint (LCP) measures how long it takes for the biggest visible thing on the page to render. That is usually a hero image, a banner, or a large block of text. In plain terms, it answers the question: how long until the page looks like it has loaded? A visitor does not care about background scripts finishing. They care about seeing the main content. Google considers anything under 2.5 seconds good, up to 4 seconds needs improvement, and beyond that is poor.

Interaction to Next Paint (INP) measures responsiveness. When someone taps a button or clicks a menu, how long before the page visibly reacts? This replaced the old First Input Delay metric because FID only looked at the first interaction, which flattered most sites. INP looks across the whole session and reports the worst experiences. It answers: when I click something, does this site feel sluggish or snappy? Under 200 milliseconds is good, up to 500 needs work, beyond that is poor.

Cumulative Layout Shift (CLS) measures visual stability. You have all experienced this: you go to tap a link, an ad loads above it, everything jumps down, and you tap the wrong thing. CLS quantifies how much the page moves around while it loads. A score under 0.1 is good, up to 0.25 needs improvement, and higher than that is poor. Unlike the other two, CLS is not measured in time but as a unitless score, which throws people off.

Two of these, LCP and INP, are about speed in the everyday sense. CLS is about something subtler that people rarely think to test for, which is exactly why it so often slips through unnoticed.

Lab data versus field data, and why your score keeps changing

Here is a distinction that saves a lot of confusion. When you run a tool like Lighthouse, you get lab data, which is a single test run in a controlled environment. It is repeatable and good for debugging, but it does not reflect your real visitors. When Google decides how to treat your site in search, it uses field data, collected from actual Chrome users who visited your pages. This comes from the Chrome User Experience Report, often called CrUX.

The two can disagree wildly. Your lab test might show a clean LCP because the test machine has a fast connection, while your real visitors on mid-range phones over patchy mobile data are seeing something far worse. The opposite happens too. This is why a site can pass Lighthouse and still get flagged in Search Console, and why chasing a perfect lab score is often a waste of time. Always anchor your work to field data first. If you do not have enough traffic for Google to collect field data, then lab data is your best available proxy, but treat it as an estimate.

Field data also reports at the 75th percentile, meaning Google looks at the experience of your slower three-quarters, not your average. A handful of slow sessions among many fast ones can still drag you below the threshold. This matters because it pushes your attention toward your worst-served visitors rather than your best-equipped ones.

What actually moves LCP

Most LCP problems come down to a few repeat offenders, and once you know them you can usually spot the culprit quickly.

The single most common cause is an oversized or slow-loading hero image. If the largest element is a photo, and that photo is a five-megabyte file being scaled down in the browser, your LCP is going to suffer no matter what else you do. The fixes here are concrete: serve images in modern formats like WebP or AVIF, size them appropriately for the display rather than shipping a desktop-sized image to a phone, and make sure the hero image is not lazy-loaded. Lazy loading is great for images below the fold, but applying it to the most important above-the-fold image delays the very thing LCP measures.

The second offender is render-blocking resources, usually CSS and JavaScript that the browser must download and process before it can paint anything. Trimming unused CSS, deferring non-critical JavaScript, and inlining the small amount of CSS needed to render the top of the page all help. The third is slow server response time, the gap before the browser even receives the first byte. If your server takes a second to respond, you have lost a second before any optimization can begin. Caching, a competent host, and a content delivery network address this.

If you want a single high-leverage move, it is almost always the hero image. Compress it, size it correctly, and let it load with priority. That one change resolves more LCP failures than any clever script-loading trick.

What actually moves INP and CLS

INP is the metric most people misunderstand, because the cause is usually not visible. Poor INP nearly always comes from JavaScript hogging the main thread. When someone clicks, the browser wants to respond, but it is busy running a heavy script, so the response waits in line. Third-party scripts are the usual suspects: chat widgets, analytics stacks, tag managers loading a dozen tools, heavy ad code. Each one runs on the same single thread that handles clicks.

The fix for INP is rarely a single setting. It is reducing how much JavaScript runs, breaking long tasks into smaller pieces so the browser can squeeze in a response, and being ruthless about third-party scripts. Audit every external script and ask whether it earns its place. A site that loads four analytics tools and three marketing pixels is paying for that convenience with responsiveness, and visitors feel it as lag even if they cannot name it.

CLS is usually the easiest to fix once you find it, because the causes are mechanical. Images and videos without defined dimensions cause shifts, because the browser does not reserve space and the content jumps when the media arrives. Always set width and height attributes, or use CSS aspect ratios, so the slot is held open. Ads and embeds that load late and push content down are another major source. Reserve space for them. Web fonts that swap mid-load can cause text to reflow, which a careful font-loading strategy smooths over. CLS rewards planning more than cleverness: decide where everything goes before it arrives.

Prioritising fixes by impact, not by score

This is where most speed projects go wrong. People open a report, see fifty warnings, and start at the top. But the warnings are not ranked by how much they matter to your actual visitors. A warning that shaves twenty milliseconds off a metric you already pass is noise. A warning tied to the metric you are failing, on the device most of your traffic uses, is signal.

Start by identifying which Core Web Vital you are actually failing in field data, and on which device type. If your mobile LCP is poor but desktop is fine, then desktop fixes are a distraction. Then identify the specific element responsible. For LCP, Search Console and Lighthouse will name the element. Fix the one thing that is dragging that one metric on that one device, then re-measure. Measuring after each change is non-negotiable, because performance work has a way of producing confident changes that move nothing.

A practical order of operations looks like this. First, confirm the failing metric and device from field data. Second, find the responsible element or script. Third, apply the highest-leverage fix for that cause: the hero image for LCP, the heaviest third-party script for INP, the unsized media for CLS. Fourth, re-measure in the lab to confirm direction, then wait for field data to confirm reality. Field data lags by weeks because it is collected over a rolling window, so be patient. The instinct to ship ten changes at once and declare victory is understandable but counterproductive, because when something regresses you will not know which change caused it.

It is also worth being honest about diminishing returns. Going from a poor score to a good one usually delivers real gains in engagement and conversion. Going from good to perfect rarely does. Once you are comfortably in the green for your main templates, your time is almost always better spent on content, search intent, and the parts of your strategy covered in a broader SEO roadmap for a growing business than on shaving the last few milliseconds.

How speed fits into the larger picture

Core Web Vitals are a ranking signal, but a modest one. Google has been clear that they act more as a tiebreaker than a primary factor. Between two pages of similar relevance and quality, the faster, more stable one has an edge. But a fast page with thin or mismatched content will not outrank a slightly slower page that genuinely answers the query. Speed cannot rescue weak content, and weak content cannot be fixed by speed.

This is why I treat speed as part of technical SEO foundations rather than as a growth lever in its own right. It is hygiene. You want it solid so that it is never the reason a good page underperforms, but you do not want to pour months into it while your content and intent matching languish. The right posture is to get into the green zone, keep an eye on it as you ship new templates and features, and then move your energy to the work that actually drives demand.

The most reassuring thing about Core Web Vitals, once you strip away the jargon, is that they reward exactly what you would want to do anyway: serve appropriately sized images, do not overload pages with scripts that earn nothing, and lay out your pages so they do not jump around. None of that requires deep technical wizardry. It requires discipline and a habit of measuring before you celebrate. Treat the score as feedback on the experience rather than the goal itself, fix the highest-impact thing for your real visitors, and re-measure. Do that a few times and you will have a fast, stable site without ever needing to understand the deeper mechanics that the tools love to lecture you about.

If you take one principle away, let it be this: find the single metric your real visitors are failing on the device they actually use, fix the single biggest cause of it, confirm the change moved the needle, and only then move on. Speed work done that way is fast, cheap, and durable. Speed work done by attacking a list of warnings top to bottom is slow, expensive, and usually disappointing. The difference is not effort. It is knowing which fix matters.