Why LCP Is the One Speed Metric Clients Actually Feel
Ask a client what they thought of their new site and the first thing they mention is usually how fast it felt. Not the mobile score, not the layout shift number, not any lab metric. Just that gut-level impression of the page appearing. That moment is almost always controlled by Largest Contentful Paint. It is the one performance number that maps directly onto how a real person experiences loading a page, which is exactly why it is worth understanding properly.
On this page
What LCP Measures
LCP is the browser’s best guess at the moment a page feels loaded. Not when the first pixel appears, not when every last script has fired. The specific point when the biggest visible element lands on screen.
That element is usually a hero image, a large block of text, or a banner sitting above the fold. The browser watches the page build itself, tracks which element takes up the most space in the viewport, and records the timestamp when that element finishes rendering. That timestamp is your LCP score. Google considers anything under 2.5 seconds good and anything over 4 seconds a problem, with a middle band where pages scrape by without excelling at either end.
The reason this matters is that the biggest element is almost always the one your visitor is consciously or unconsciously waiting for before they decide the page has arrived. A spinner finishing in the corner of the screen means nothing to them. The hero image completing does.
Raw page speed, in the purely technical sense, measures things like time-to-first-byte or the waterfall of network requests. Most visitors never perceive those numbers directly. LCP is different because it maps to something a real person notices, the moment the page stops feeling empty. That is why it sits at the centre of the Core Web Vitals scoring framework, rather than the dozens of other timing signals browsers collect behind the scenes.
Why Other Speed Metrics Miss the Point
TTFB, FCP and TBT all have legitimate uses, but none of them map cleanly to what a visitor experiences when a page loads.
Time to First Byte measures how quickly your server responds, which matters for infrastructure decisions but tells a user nothing about whether they can see anything useful yet. First Contentful Paint fires the moment any content appears, even if that content is a loading spinner or a tiny navigation logo tucked in the corner. Total Blocking Time captures how long the main thread is tied up, which is important for interactivity, but again it is a number that lives inside a developer’s console, not in a visitor’s perception.
The gap between these metrics and real-world experience is why you can hand a client a PageSpeed Insights report full of decent scores and still have them tell you the site feels slow. They are not wrong. They just felt something the numbers did not show.
LCP is different because it measures the moment the dominant piece of content lands, usually the hero image or the main heading block. That is the visual beat where a visitor decides whether the page has arrived or whether they are still waiting. The page speed metrics Google scores you on are all worth understanding, but if you had to pick one that a real person can feel, it is this one.
What Causes a Poor LCP Score
Hero images and server response
Google’s guidance points to four main culprits, and on WordPress sites you see all four with depressing regularity. Hero images are the most common offender. A theme ships with a full-width banner image that’s 2MB, uncompressed, served without fetchpriority="high", and loaded lazily because someone left the default settings untouched. The browser queues it behind everything else, and the LCP time balloons to four or five seconds before the image even starts painting.
Slow server response causes quiet devastation in a different way. If the time to first byte is above 600ms, the browser is already behind before it has downloaded a single asset. Shared hosting on an overloaded server will do this every time.
Render-blocking resources and client-side rendering
Render-blocking resources compound the problem fast. A theme that enqueues three Google Fonts calls and two undeferred JavaScript files is effectively making the browser sit on its hands before it can touch the main content. Those delays stack.
Client-side rendering is the fourth culprit, and the one most often overlooked during a build. Builders that lean heavily on JavaScript to assemble the page mean the server sends an almost empty HTML document, and the browser has to run the JS, parse the result, and then paint the LCP element. That entire process happens after load, which is why a site can feel fast on a developer’s machine and sluggish everywhere else. If you want to understand how Core Web Vitals scoring works across these delays, the relationship between TTFB and LCP is a good place to start unpicking it.
How Clients Describe a Bad LCP
Nobody rings up and says “my Largest Contentful Paint is sitting at 6.2 seconds.” What they say is “it just felt slow” or “the page kind of hung there before anything loaded” or, the one that sticks with me most, “it looked broken.”
That last one is telling. When the main image or headline block takes too long to appear, visitors cannot tell whether something has gone wrong with the site. The browser is loading, the tab is spinning, but the screen is visually empty. That gap between the moment a user clicks and the moment they see something real and meaningful is exactly what Google’s Core Web Vitals scoring is trying to measure with LCP. Clients feel it as impatience, then doubt, then a back button. The score just puts a number on it.
That translation matters when you are explaining a technical audit to someone who runs a plumbing business or sells handmade ceramics. They do not need to understand render pipelines. They need to know that the “it felt sluggish” complaint their customers keep mentioning is fixable, and that there is a specific measurement telling you exactly how bad the problem is.
Does LCP Affect Rankings?
Yes, but not in the way most people assume. LCP is part of Google’s Core Web Vitals assessment, which feeds into a ranking signal called Page Experience. It counts. It is just not the only thing that counts.
Google has been transparent about this for a while now. Core Web Vitals are a tiebreaker, not a trump card. A page with useful, well-structured content and strong relevance signals will outrank a fast-loading page that says very little. Where LCP starts to tip the scales is when two pages are broadly similar in quality and the crawlers are choosing between them. At that point, the site that loads its main content in under 2.5 seconds has a real edge over one sitting at 4 or 5 seconds.
If you look at the page speed metrics Google scores you on, LCP carries the most visible weight of the three Core Web Vitals, partly because it is the one that directly maps to how a real visitor experiences a page loading in front of them. Fix your content first, then fix your speed. Both matter, and in competitive niches where the content quality between sites is close, a poor LCP score can be the quiet reason a page stalls on page two.
Where to Start if Your LCP Score Needs Work
Sort the image first
The single most reliable place to start is the image. On most WordPress sites, the LCP element is a hero image or a large above-the-fold graphic, and the fix almost always falls into one of three areas, the file is too heavy, it is not preloaded, or it is being loaded lazily when it should not be. Strip the lazy-load attribute from your hero image first. Then check whether the image is preloaded with a <link rel="preload"> tag in the document head. If neither of those is in place, sorting them out tends to move the needle faster than anything else on the list.
Check hosting response time and fonts
After the image, look at your hosting response time. A slow server adds latency before a single byte of your image has transferred, and no amount of image optimisation fully compensates for a host that takes 600ms just to respond. You can read Google’s own guidance on the page speed metrics Google scores you on to understand how TTFB feeds directly into your LCP window.
Fonts are the next thing to check. A render-blocking web font can delay the LCP element by several hundred milliseconds even when your image is perfectly optimised.
On a typical WordPress site, a focused round of fixes takes two to four weeks to show movement in field data. Lab scores update immediately, but real-world Chrome User Experience Report data reflects actual visits accumulated over 28 days, so patience matters here.