There is a specific kind of anxiety that sets in when a founder looks at their PageSpeed Insights score for the first time. The number is usually somewhere in the seventies. The page is full of red and orange warnings. And the natural response is to assume the site is broken in some fundamental way that needs immediate fixing.
Most of the time, it is not. And chasing that score is one of the most reliable ways to waste an engineering sprint on things that will not meaningfully help your business.
Here is an honest account of what Core Web Vitals actually are in 2026, which parts Google genuinely uses to rank your site, and which parts you can safely ignore while you focus on the ones that matter.
What the metrics actually are
Core Web Vitals are Google's attempt to measure how a real user experiences your page, not how clean the code is, not how many requests it makes, but how it actually feels to load and use it.
The three that matter are LCP, CLS, and INP.
LCP, Largest Contentful Paint, measures how long it takes for the main content of your page to become visible. If someone lands on your site and is staring at a blank or half-loaded screen for more than two and a half seconds, you have a bad LCP. Google uses this as a direct ranking signal.
CLS, Cumulative Layout Shift, measures whether your page jumps around as it loads. The frustrating experience of going to click a button and having it leap out of the way because an image loaded late is bad CLS. It is also a ranking signal, and it is worth caring about for the simpler reason that it makes your site feel broken.
INP, Interaction to Next Paint, replaced FID in 2024 and measures how quickly your page responds to input. When someone clicks something and nothing happens for a beat, that is bad INP. It matters less for ranking than LCP and CLS, but it matters a great deal for whether someone trusts your product enough to keep using it.
What Google actually weights
Not all three are equal, and understanding the difference saves you from making the wrong tradeoffs.
LCP is the one to fix first, and it is the one most startup sites fail on. The cause is almost always one of two things: an image that is too large and not properly optimised, or render-blocking scripts loading before the main content. Both are fixable without a rebuild. Neither fix requires a genius, but both require someone who actually knows what they are doing rather than just running the Lighthouse report and hoping the suggestions translate to real improvements.
CLS failures are usually structural. Fonts that do not have explicit dimensions set, images without width and height attributes, third-party embeds loading asynchronously without reserved space. These are the kinds of decisions that get made or not made when a site is built, which is why we build them correctly from the start rather than retrofitting them later.
INP problems tend to show up in JavaScript-heavy sites where a lot is happening on the main thread. If your site is primarily a marketing page rather than a web app, you will rarely hit this threshold. If it is doing more, it warrants attention.
What you can safely stop worrying about
The PageSpeed score. Not because performance does not matter, it does, enormously, but because the score is a composite of many things, and optimising for the number is not the same as optimising for the signals Google actually uses. A site can score 72 and still have excellent real-world Core Web Vitals. A site can score 98 and still load slowly for users on average hardware in average network conditions.
The number of HTTP requests. This was important in 2015 and has not been the key bottleneck since HTTP/2 became standard.
Eliminating every third-party script. Yes, third-party scripts add weight. But stripping every analytics and chat tool from your site in pursuit of a perfect score usually costs you more in data and conversion capability than it saves in ranking.
The warnings about render-blocking resources that are not actually on the critical path. Lighthouse flags aggressively. Not every flag is a real problem.
The thing most teams miss
Core Web Vitals are measured from real user data, not just lab tests. Google's ranking considers your field data, the actual experience of real visitors on real devices, not just what Lighthouse reports in a controlled test. The two can diverge significantly, and the field data is what actually counts.
This means that the best optimisations are the ones that improve real-world performance, not simulated performance. A faster server, proper image formats and lazy loading, no render-blocking scripts in the critical path, a build that does not ship three hundred kilobytes of JavaScript to render a paragraph of text. These are the fundamentals, and they compound.
We build for field data from the start, not lab scores. The sites we build consistently hit the good thresholds for all three metrics because the decisions that produce those results are made in the architecture and in the code, not applied as patches after launch.
If your site is failing on Core Web Vitals and you want an honest read on why, and what it would actually cost to fix, that is exactly what our website review covers. We will tell you which problems are structural and which ones are noise.