Search Console shows LCP, INP and CLS all failing on the same URL group. Start with the cheapest fix that moves two metrics at once, not with the worst number on the dashboard. The worst number is usually the most expensive one to move.
Does the order you fix them in actually matter?
It does, because a URL group is only counted as passing when all three metrics clear their thresholds at the 75th percentile of page loads. One failing metric keeps the whole group red, so the hardest fix sets your timeline whether you start with it or not.
That changes the question. You are not picking the metric with the ugliest number; you are sequencing work so the group flips as early as possible, and so each piece of work you ship is the smallest one that could have done the job. The Core Web Vitals program rewards finishing all three, not making progress on one.
What do the three failures usually have in common?
One cause, more often than three. A hero image without width and height, a render-blocking script in the head, or a web font that swaps in late will each push two metrics in the wrong direction at the same time.
Before you plan anything, look for the overlap. Heavy main-thread JavaScript delays the largest paint and also keeps the main thread busy when a visitor taps something, so it shows up as both an LCP and an INP problem. An ad slot or cookie banner injected above the fold hurts layout stability and pushes the main content down, which delays the paint that counts. Fixing the injection point fixes two rows on the report.
Three failing metrics rarely mean three projects. Find the one asset or script that appears in two of the three explanations and fix that first; the sequencing question often answers itself.
Which metric is usually the cheapest to move?
Cumulative Layout Shift, in most cases. Layout shift comes from content that arrives without reserved space, and reserving space is a markup change rather than an architecture change.
Set explicit dimensions or an aspect ratio on images, iframes and ad containers. Give injected elements a reserved height instead of letting them push the page around. Load fonts so the fallback and the real face occupy close to the same space. None of that requires touching your rendering strategy, which is why it tends to ship in days rather than quarters.
Largest Contentful Paint sits in the middle. Server response time, a render-blocking stylesheet, a lazy-loaded hero and above-the-fold content rendered on the client are the usual suspects, and most of them have a known remedy. Interaction to Next Paint is normally the expensive one, because long main-thread tasks and third-party tags are woven through the whole page rather than sitting in one file.
How close is each metric to its threshold?
Distance to the line decides what is worth doing this sprint. A metric sitting just over its threshold at the 75th percentile can flip on a modest change; one sitting far past it will not.
| Metric | Good | Poor | Usual causes | Typical cost to fix |
|---|---|---|---|---|
| LCP | 2.5s or less | Over 4.0s | Slow server response, render-blocking CSS or JS, lazy-loaded hero, client-rendered above-the-fold content | Medium |
| INP | 200ms or less | Over 500ms | Long main-thread tasks, third-party tags, expensive event handlers, large hydration cost | High |
| CLS | 0.10 or less | Over 0.25 | Unsized images and ad slots, late-injected banners, font swap, content inserted above the viewport | Low |
Pull the field numbers, not a lab score, and write down how far each one is from the good threshold. Two metrics a few percent over the line and one far past it is a different plan from three metrics all hovering at the edge.
When should INP go first anyway?
When the interaction being measured is the one that earns the money. A search box, a size selector, an add-to-cart button or a filter on a category page is where visitors decide whether the site works.
In that case the ranking question is secondary. A 600-millisecond delay on the control that drives the conversion rate costs you more than a red row in a report does, and the fix pays for itself regardless of what happens in organic search. The same logic runs in reverse: if the slow interaction is on a page nobody interacts with, INP is the last thing to spend a sprint on.
Chasing a lab score instead of the field data. A perfect Lighthouse run on a fast laptop says nothing about the 75th percentile of real visits on mid-range phones, and the assessment that affects search is built from the field numbers.
Why has the report not moved since you shipped the fix?
Because the field data behind it is a rolling 28-day window of real visits, collected from Chrome users who opted in to reporting rather than from a crawler hitting your page. A fix deployed today enters that window gradually.
Expect the curve to bend within a week or two and settle after four. If you need faster feedback, instrument the metrics yourself with the Web Vitals library and watch your own real-user numbers per release; Google Search Console is the confirmation, not the debugger. Shipping three fixes in one week and then arguing about which one worked is a familiar way to waste a month.
What should you fix this week?
Open the field data, write the three distances to threshold on one line, then find the asset or script that explains two of them. If one exists, that is the work, and the sequencing debate is over. If each metric has a genuinely separate cause, ship the layout-stability fixes now while the paint work is being scoped, and decide honestly whether the interaction work is a ranking project or a revenue project before anyone schedules it.