Google's March 2026 core update tightened the Largest Contentful Paint threshold from 2.5 seconds to 2.0, and rolled the three vitals into a composite performance score that now sits alongside content signals rather than behind them.
The practical consequence is that a site which comfortably passed in the spring may be failing now while nothing about it changed. Half a second sounds small. It is the difference between the middle of the pass band and the wrong side of the line for a very large number of sites.
What LCP measures and why it is stubborn
Largest Contentful Paint is the moment the largest visible element in the viewport finishes rendering. Usually a hero image, sometimes a heading, occasionally a video poster.
It is the hardest of the three vitals to improve because it depends on everything before it. Server response time, redirects, connection setup, when the browser discovers the resource, how large the resource is, and whether anything is blocking rendering. A slow LCP is a symptom with a long list of possible causes, which is why generic advice rarely helps.
It is also the metric most affected by real conditions. Laboratory tools measure on fast connections, and the score Google uses comes from actual visitors on actual devices, including the ones on poor mobile connections. Passing in a testing tool while failing in the field is common and entirely expected.
This is a different problem from responsiveness, which we covered separately in fixing INP. INP is about work blocking the main thread after interaction. LCP is about how long the page takes to show anything meaningful in the first place.
The composite score changes the strategy
Previously the three metrics were assessed with some independence. Now they roll into a single score, which has a consequence worth planning around.
One weak metric drags the whole result. A site with excellent CLS and INP but LCP at 2.4 seconds no longer gets partial credit for the two it does well. Effort spent improving an already good metric returns almost nothing, while the weak one determines the outcome.
So the correct approach is unbalanced on purpose. Find the worst metric, fix it until it is comfortably inside the threshold, then reassess. Spreading effort evenly across three metrics is the intuitive plan and the wrong one.
Mobile also carries more weight than desktop in 2026. If you have limited time, the mobile number is the one to work on, and it is usually the worse of the two by some margin.
Find the actual element before changing anything
The most common waste in performance work is optimising something that is not the LCP element.
Open the page in Chrome DevTools, run a Performance trace, and look at the LCP marker. It tells you precisely which element it measured. Teams routinely spend a week compressing images when the LCP element was a heading blocked by a web font, or a hero that was already small and simply discovered late.
Then establish where the time goes. Server response before anything arrives, resource load once discovered, or render delay after loading. Each has a different fix and they are not interchangeable.
Use field data rather than a single lab run to decide priority. The Chrome User Experience Report shows what real visitors experienced, and the gap between that and your laptop is where the problem usually lives.
We have watched teams spend a fortnight optimising images on pages whose largest element was a heading blocked by a web font. The measurement takes ten minutes and decides whether the fortnight is worth anything at all.
The fixes that reliably move LCP
If the element is an image, three things matter more than compression. Preload it so the browser does not wait to discover it in the markup. Serve it in a modern format at the size actually displayed rather than the size uploaded. Never lazy load the LCP image, which is a surprisingly common mistake introduced by applying lazy loading site wide.
If time is going to server response, the fix is upstream of the front end. Caching, database query work, or a hosting tier that stops being adequate under load. No amount of image optimisation compensates for a slow first byte, and this is where a site that was fine at launch degrades as it grows.
If the delay is in rendering, look at what blocks it. Render blocking stylesheets, fonts loading before text can paint, and third party scripts in the head. Fonts in particular cause LCP failures on text based pages, and a sensible font display strategy fixes more than it costs.
Third party tags deserve their own examination. Analytics, chat widgets, consent managers and advertising scripts accumulate over years, each added by someone with a reason, none removed. They are frequently the difference between 1.8 seconds and 2.3.
In practice that ordering is what we run, and it is rare to reach the end of it. Most sites we see are fixed by the first two, and the rest of the list exists for the ones that are not.
What this is worth commercially
The ranking effect of the vitals is real and modest. Content relevance still dominates, and a fast page about nothing does not outrank a slow page that answers the question.
The commercial effect is larger and independent of ranking. A page that shows something in under two seconds keeps people who would otherwise leave, and that shows in conversion rather than position. We put numbers on that in what happens in the first five seconds.
Which is the honest reason to do this work. Treating it as an SEO obligation produces a scramble to clear a threshold and then neglect until the next change. Treating it as customer experience produces a site that stays fast, and clears the threshold as a side effect.
If your site has drifted and you would rather have it diagnosed than guessed at, our web app development team works from field data rather than a lab score.
Frequently Asked Questions
We passed six months ago. Why are we failing now?
The threshold moved from 2.5 seconds to 2.0 in the March 2026 core update. A site sitting at 2.2 was passing comfortably and is now failing without a single change to the site. Check your current numbers rather than relying on a report from earlier in the year.
Which metric should we fix first?
The worst one, on mobile. Because the vitals now roll into a composite score, improving a metric that already passes returns very little while the failing one determines the outcome. This is the one case where uneven effort is correct.
Our lab test passes but Search Console says we fail.
Lab tests run on a fast connection from one location. Google uses field data from real visitors, including those on slow mobile networks and older devices. When they disagree, the field data is the one that counts, and the gap is usually the actual problem rather than a measurement error.
Does LCP really affect rankings?
It contributes and it is not decisive. Relevance still dominates. The composite score sits alongside content signals now rather than behind them, which raises its weight, but a fast page will not outrank a genuinely better answer. Treat it as one factor and as a conversion issue in its own right.
What is the single most common cause?
An unoptimised hero image that is lazy loaded, or a web font blocking text from painting. Between them these account for a large share of LCP failures, and both are fixable in hours rather than weeks once identified.
How long before improvements show up?
Search Console reports on a 28 day rolling window of field data, so a fix deployed today takes weeks to fully reflect. Use lab tools to confirm the change worked immediately, then wait for the field data to catch up rather than assuming the fix failed.
Is this worth it for a small business site?
Yes, for the conversion reason rather than the ranking one. Visitors leaving before the page appears is a direct loss regardless of where you rank, and small sites are often the easiest to fix because there is less accumulated third party weight to unpick.
Talk to our team if your vitals moved and you want the cause identified before anyone starts optimising.