Because you are not the average visitor. You have the site cached, a good device, and fast internet. Largest Contentful Paint measures when the biggest thing on screen actually appears for real people, on real phones, on real networks. That number is usually much worse than what you experience.
This gap is the most common surprise in our first call with a new client. The site loads instantly for the founder who visits it ten times a day. Google reports it as slow. Both are true, because they are measuring different people.
LCP is the Core Web Vital that decides whether a page feels fast. It is also the one we fix most often, and the one where a single wrong attribute on a single image can cost you a full second. Here is how it works and how to fix it.
Largest Contentful Paint measures how long it takes for the biggest visible piece of content to render. Google's own web.dev documentation defines it as the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page. In plain terms, it is when the page looks loaded.
The metric exists because the old measurements lied. Page load time counted every last script and tracking pixel, long after the visitor was already reading. First Paint counted a blank background turning white. Neither matched what a person would call "loaded".
LCP picks the one element that dominates the screen and asks when it appeared. That is a much better proxy for the moment a visitor stops waiting and starts reading.
A short and specific set of things. Google lists image elements, image elements inside SVG, video elements using the poster image or first frame, elements with a background image loaded through the CSS url() function, and block-level elements that contain text. Whichever of those is largest in the viewport becomes your LCP element.
On most business sites the LCP element is the hero image or the hero headline. That is why the top of your page carries so much weight. Everything below the fold is irrelevant to this metric.
It is worth checking rather than guessing. We regularly find that the LCP element is not what the team assumed. A background image on a section, a logo that renders larger than expected, or a block of intro text can quietly be the thing being measured. Fixing the wrong element wastes a week.
2.5 seconds or less. Google's web.dev guidance says sites should strive for Largest Contentful Paint of 2.5 seconds or less, and that the measurement is taken at the 75th percentile of page loads, segmented across mobile and desktop separately. Anything slower puts you in the needs-improvement or poor band.
The mobile and desktop split matters more than most people realize. You can pass comfortably on desktop and fail on mobile, and mobile is where most traffic lives for the founders and marketers we work with.
Across the projects we deliver, our average PageSpeed score sits at 98, and getting there is mostly LCP work. Speed is not a mysterious art. It is a small number of decisions about what loads first, made consistently.
Because averages hide your worst experiences. The 75th percentile means three out of four visits must clear the threshold. A handful of very fast loads on good devices can drag an average down to something respectable while a quarter of your visitors sit staring at nothing.
This is a deliberately demanding standard, and we think it is the right one. A metric that lets you pass while 40% of visitors have a bad time is not measuring anything useful.
Practically, it means you optimize for the slow case. The mid-range Android phone on a patchy connection is your target, not the laptop on office wifi. If you only ever test in Chrome on your own machine, you are testing the case that was already fine.
Google breaks LCP into four sub-parts and gives a target share for each. Time to First Byte should be roughly 40% of total LCP. Resource load delay should be under 10%. Resource load duration should be roughly 40%. Element render delay should be under 10%. Together these tell you where the time is actually going.
This breakdown is the single most useful diagnostic tool in performance work, and almost nobody uses it. It turns a vague "the page is slow" into a specific answer about which of four things to fix.
If TTFB is eating most of your LCP, the problem is your server or your hosting, not your images. We wrote separately about what TTFB is and how to improve it, because that fix looks nothing like an image fix.
If resource load delay is high, the browser found out about your image too late. If load duration is high, the image is too big. If render delay is high, something is blocking the browser from painting, usually a font or a script. Four symptoms, four different cures.
Measure real visits, not just lab tests. PageSpeed Insights shows you both, and the field data section is the one that counts, because it comes from the Chrome User Experience Report rather than a single simulated load. Chrome DevTools then lets you identify the exact LCP element and its sub-part timings.
Our order of operations is always the same. Confirm which element is the LCP element. Pull the four sub-part timings. Find the one that is furthest from its target share. Fix that one thing. Measure again.
Resist fixing everything at once. When you change five things and the score moves, you have learned nothing about which change did the work, and you cannot repeat it on the next project. Google Search Console also reports Core Web Vitals across your whole site, which is the fastest way to spot whether one page template is dragging down hundreds of URLs.
Tell the browser it is important, and make it smaller. Google recommends setting fetchpriority="high" on the image likely to be your LCP element, which moves it to the front of the download queue. Then serve it in a modern format at the size it actually displays at, rather than a huge original scaled down in CSS.
Google is specific about the limits of this. Its guidance warns that setting a high priority on more than one or two images makes priority setting unhelpful, because if everything is urgent then nothing is. Pick the one image that matters.
For images referenced only inside CSS or JavaScript files, the browser cannot discover them until it has parsed those files. Google's recommendation there is a link rel="preload" combined with high fetch priority, so discovery does not wait on the stylesheet. This is a common cause of high resource load delay on sites with CSS background heroes.
The sizing work is where the biggest wins usually sit. Getting the format and dimensions right routinely cuts a hero image by most of its weight, and we covered that process in our guide to optimizing images for web performance.
Lazy loading the hero image is the big one, and Google states it flatly: never lazy-load your LCP image, as that will always lead to unnecessary resource load delay. Lazy loading is genuinely good for images below the fold. Applied to the hero, it tells the browser to wait before loading the one thing the metric is timing.
We find this on a large share of the sites we audit, usually because a plugin or a global setting applied lazy loading to every image at once. It is a one-line fix that can take a second off LCP, and it is free.
Web fonts are the second offender. If your LCP element is a text block and the font has not arrived, the browser may hold the paint, pushing render delay up. Third-party scripts in the head are the third, because they compete for bandwidth with the image you actually need.
The pattern across all three is the same. Something told the browser to spend its first moments on work that does not affect what the visitor sees.
It helps, but not as a magic lever. Core Web Vitals are a genuine ranking input, and they matter most as a tiebreaker between pages of similar relevance. A fast page will not outrank a far more useful slow one, and a slow page loses visitors before any ranking benefit could matter.
We argue for speed on commercial grounds rather than ranking grounds. People leave slow pages. That shows up in conversions before it shows up in positions, and it shows up regardless of what Google does with the signal. Our fuller take on the ranking side is in our piece on how Core Web Vitals affect SEO rankings.
Open PageSpeed Insights, run your busiest page on mobile, and find the LCP element and its four sub-part timings. Then make one change to the worst sub-part. That single loop, repeated three times, fixes most sites without any rebuild.
If the answer turns out to be TTFB, you have a hosting conversation rather than a design one. If it is the image, you have an afternoon of work. Either way you now know which, which is more than most teams start with.
If you would rather not spend your week inside DevTools, or you have run the tests and the numbers still do not make sense, we are happy to take a look and tell you where the time is going. Let's talk. You can reach our team at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.