
Fix the Core Web Vital that fails on the page where your visitors decide to buy or call, not the one that is easiest to fix. Check which of the three (loading, responsiveness, layout shift) is failing there for real visitors, and start with that one. For most sites the loading metric, LCP, is the one to look at first.
What are the three Core Web Vitals, and what counts as good?
Google names three: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Good means an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, each measured at the 75th percentile of real page loads, split by mobile and desktop.
In plain terms: how fast the main thing on the page appears, how quickly the page reacts when someone taps, and whether the layout jumps around while loading. The "75th percentile" part matters. Three out of four visits have to be good, so one fast test on your own laptop proves nothing. You need numbers from real visitors, which is what the Core Web Vitals report in Google Search Console shows.
Which Core Web Vital should you fix first?
Fix the one that fails on your most valuable page. A product page, a booking page and a contact page matter more than an old blog post, so open the report for that group of pages and fix the red metric there. If two fail, take LCP first, because it is the one most sites fail.
Guides that give an order give a fixed recipe. One tells you to fix server response first, then LCP, INP and CLS. Another says to start with LCP because loading speed creates the strongest first impression. Either recipe can be right for one site and wasted effort on another. The order you need is not about the metric at all. It is about the page: which one earns your money, and which metric is red on it.
The data explains why LCP is the usual answer. The 2025 Web Almanac, built on real-user data, found that on mobile 81% of sites had good CLS, 77% had good INP and only 62% had good LCP. Overall, mobile results reached 48% passing all three. Loading speed is where most sites lose.
Where does the time go when a page loads slowly?
LCP is the sum of four phases: the wait for the server's first byte, the delay before the browser starts fetching the main image or font, the time to download it, and the time to draw it. Google's guidance suggests roughly 40% of the 2.5 seconds for the server, 40% for the download, and under 10% for each of the other two.
That split is the most useful thing you can ask a developer for. "Make it faster" is not a brief. "Our delay phase is 900 milliseconds and should be under 250" is. Google's guidance says the Chrome DevTools performance panel and the Lighthouse report behind PageSpeed Insights both show this breakdown. If the server takes most of the time, no amount of image compression will save you. If the download is the problem, the image is too big or too far away.
The delay phase is the one site owners create by accident. The Web Almanac found that about 16 to 17% of pages lazy-load their main image, which it warns can be harmful, because the browser holds back the one image it should fetch first. Only about 2% of pages use a preload hint for it. Sixteen percent of mobile pages serve the main image from a different host, which adds connection time unless it is mitigated. These are small edits, not rebuilds, and they work on the phase most people never look at.
How do you improve INP and CLS without a rebuild?
INP measures the delay between a tap, click or key press and the next frame the user sees, across all interactions on the page. Above 200 milliseconds feels sluggish; above 500 is rated poor. Layout shift is usually fixed by reserving space: give images, embeds and banners a set size so nothing pushes the text down when it arrives.
INP is where third-party add-ons tend to hurt: chat widgets, tag managers, booking pop-ups. Each one runs code on the visitor's device, competing with the tap. Before changing any code, list every script the page loads and ask what each one earns. Removing one you no longer use costs nothing and can fix a failing metric. Fixing what is left is development work, and a team that builds websites and systems in code can profile it properly instead of guessing. Google's INP guide names the tap, click and key press as what is measured, so test on a real phone.
Do Core Web Vitals affect your Google ranking?
Google recommends them. Its documentation says it highly recommends good Core Web Vitals for success with Search, and that they align with what its core ranking systems seek to reward. It does not say how much they weigh against everything else. Treat them as one input, and as a visitor problem: a page that loads late loses people whether or not it ranks.
That is the honest case for working on them. Don't expect green scores alone to move rankings. But a slow, jumpy page undercuts everything else you pay to bring people to it. Speed is easiest to get right when it is part of the build, which is how a studio like onlyspell frames it, rather than a polish step at the end. If you are still choosing a stack, the overview of website technologies in 2026 is a good place to begin.
A practical order of work
Start in Search Console, open the Core Web Vitals report, and find the group of pages that includes your money page. Note the failing metric. Then look at the real-user numbers for that one page type, not the site average. Fix the biggest phase first, then re-measure. Search Console's figures reflect the last 28 days of real visits, so a fix takes weeks to show in full.
A page group needs a minimum amount of real-user data to appear in the report, so a small site may see nothing for some pages. Lab tools such as Lighthouse still give you the phase breakdown, only without the real-user verdict. When you are ready to put a number on the work, talk to us about your project.
Frequently asked questions
What replaced First Input Delay?
Interaction to Next Paint. Google describes INP as the successor to First Input Delay. INP improves on it by observing the latency of all click, tap and keyboard interactions on a page.
What is a good Core Web Vitals score?
LCP within 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, all at the 75th percentile of real visits. A page passes only when all three are good.
Where can I see my own Core Web Vitals?
In Google Search Console, under the Core Web Vitals report, which groups pages with a similar experience and gives each group a status for mobile and desktop, based on real-user data from the last 28 days. Lighthouse, which powers PageSpeed Insights, adds a breakdown of what slows a single page down.
Sources
If you still need additional help in developing and designing your website, our magic is here to help. Contact us today, and our wizards will help you immediately with your digital marketing needs!


