Of the three Core Web Vitals, LCP is the one most often in the red and the one that hurts most directly. Largest Contentful Paint measures when the biggest visible element in the first screen has finished loading. On most websites that element is an image, and on most websites that image is the entire reason for a poor score.
What LCP actually measures
LCP is the time from the click to the moment the largest chunk at the top of the page is in place. Not an average across all elements, but the timing of the single largest one: usually the hero image, sometimes a large heading, rarely a video still. Google draws the line at 2.5 seconds. Above that the value counts as needs improvement, from 4 seconds as poor.
The first reflex first: LCP is a number for the phone, not for your desk. On a mobile device over cellular, the same page loads many times slower than on your machine on office Wi-Fi. Test only on desktop and you never see the problem.
Field before lab: which number counts
There are two kinds of LCP values, and they get confused constantly. Lab data (Lighthouse, the test in the developer tools) simulates a load under standardized conditions. Field data comes from real users with real devices and networks. Google ranks by the field data.
So the right first step is not Lighthouse but the field data: in Google PageSpeed Insights, the box at the top with data from the Chrome User Experience Report, or the "Core Web Vitals" report in Search Console. A green lab score with a red field score is not rare and not a reason to relax.
The five brakes, in the order worth taking
First: the hero image is served too large. A photo 4000 pixels wide shown at 380 pixels on the phone wastes load time on pixels no one sees. A properly scaled image in the right format is the single most effective fix. Almost always.
Second: the most important image loads too late. If the hero image is marked "lazy load," the browser deliberately waits to load it even though it is needed immediately. That one image should not be deferred but loaded with priority. Lazy loading is meant for images further down, not for the topmost one.
Third: the server responds slowly. Before a single pixel loads, the server has to send the first byte. If that time is already high, no image trick helps. This is the site where a caching layer or faster hosting does more than any front-end tweak.
Fourth: fonts and scripts block rendering. Large font packages and scripts loaded before rendering hold the page up. What is not needed at the top does not need to come first.
Fifth: the layout jumps while loading. Strictly speaking this belongs to CLS, the second of the Core Web Vitals, but it feels like slowness. Fixed heights for image slots prevent the jump. The full relationship between the three values is in improving Core Web Vitals.
Why this is worth more than the number
A poor LCP costs not just ranking points but visitors, before they ever see your content. Someone who leaves while nothing is on screen yet counts as a bounce that looks like disinterest and is really impatience. That is why load time is the first suspect for any high bounce rate, before the copy. That link and what comes next is in reducing bounce rate.
Frequently asked questions
What is a good LCP value?
Google rates an LCP up to 2.5 seconds as good, between 2.5 and 4 seconds as needs improvement, and over 4 seconds as poor. What counts is the value from field data on mobile, not the lab value on desktop.
Why is my LCP poor even though the page feels fast?
Because you are probably opening it on desktop on a fast network, while Google ranks by the field data of real mobile users. Check the value in PageSpeed Insights in the field-data box or in the Core Web Vitals report in Search Console, for mobile.
What is usually the cause of a high LCP?
In the vast majority of cases the hero image at the top: served too large, or wrongly marked "lazy load" so the browser delays loading it. A properly scaled, priority-loaded image is the single most effective fix.