Largest Contentful Paint

Page speed used to be measured at the moment the browser announced it was done — the instant the last script, image and font finished downloading. The number came out clean, and it kept disagreeing with what people actually felt.

It disagreed in both directions. One image used only at the very bottom of a page arrives late, and the record says six seconds even though the reader has been reading for a while. The other way round, measurement stops at 1.2 seconds while the photo at the top of the screen sits as a gray rectangle for three seconds more.

So the meetings always went the same way. Marketing would say people arriving from ads leave before they see anything, and engineering would answer that the measurement says 1.2 seconds. Neither side was lying, but one was quoting the moment the files finished arriving and the other the moment there was something to look at.

Largest Contentful Paint (LCP) closes that gap by moving where the clock stops. Instead of asking what finished downloading, it asks when the biggest block on the screen appeared. The reasoning is that the moment a person feels a page has loaded is usually the moment that block shows up.

The browser picks the single largest element drawn inside the visible screen area, then measures from the start of the navigation to the moment that element was painted. The unit is seconds and lower is better.

Picking it takes three steps.

1. Gather the candidates. Photos, video poster images, background images and blocks of text all qualify. Any part of an element that runs off the screen is subtracted, so only the visible area counts toward its size.
2. Take the largest one by area. On a blog article that is usually the picture at the top; on a screen with no images it is typically the headline or the first paragraph block.
3. Subtract the moment the user hit the address from the moment that element was painted. A photo appearing at 2.8 seconds makes the LCP 2.8 seconds.

The value doesn't settle in one shot, and that shapes how the metric behaves. If a larger element shows up mid-load, the candidate changes and the record is updated. A headline may be the biggest thing at first, then a large photo lands late, the reference point moves to the photo, and the number slides back with it. Measurement stops the moment the user taps or scrolls, because once a person has acted the first impression is already formed no matter what appears afterwards.

Judgment never rests on one person's number. Records are collected across many users and read at the 75th percentile — line up 100 values fastest first and take what the 75th person experienced. An average lets a handful of very slow sessions pull the number up and hide the experience of everyone else, and the slowest value hands every decision to one person who opened the page on a subway.

Under 2.5 seconds is good, 2.5 to 4 seconds needs work, and above 4 seconds is poor. The line is drawn on the 75th-percentile value described above. If three out of four users saw the screen within 2.5 seconds, the page sits in the good band.

Those thresholds come from Core Web Vitals, the bundle that reads loading, responsiveness and visual stability together. It is the bundle search engines point at when they talk about ranking, which is why marketing ends up watching the same number as engineering.

Matching the measuring conditions causes more trouble than the value itself. A current laptop on office Wi-Fi puts most pages in the one-second range, while the same page on a three-year-old budget Android over a mobile network runs past four. So the score from a testing tool and the records gathered from real users are kept apart. The first is convenient for comparing before and after a fix; the second tells you where you stand right now.

Where the time goes decides what to do about it. If the server is slow to send its first response, nothing downstream will help. If the response is fast but the browser spends its time assembling the screen out of JavaScript, an approach like server-side rendering that ships the page already drawn is the answer. Start fixing before knowing which stretch is long and you usually make the fast part faster.

"LCP is 4.2 seconds. The hero image is up there at full resolution."

The largest element is heavier than it needs to be, and that is what's slow.

"Our 75th-percentile LCP went from 2.1 to 3.4 seconds after this release. What changed?"

The point where performance degraded has been pinned down, so someone should go through what shipped in between.

"The testing tool says 1.8 seconds but real users see 3.9. We need to look at this on mobile."

The development environment is better than reality, so the number came out optimistic.

At Pagedeck this number comes up most often on landing pages fed by ads. When Ravi brings in a week where signups look too low against the traffic, Theo opens the real-user records and checks LCP. Once it was a background photo at the top served at its original 3,000 pixels; another time the server was spending 1.4 seconds on the first response.

Measuring again after the fix is part of the same job. Only after the photo is cut down and the number comes back at 2.2 seconds does Ravi restart the same campaign. That is why marketing sits in on performance reviews.

The most common belief is that laying gray placeholders over a loading screen improves LCP. A screen with skeleton UI genuinely looks much faster, so it is an easy assumption to make. But an empty box filled with a flat color doesn't count as content and never enters the candidate pool, so the measurement keeps waiting for the real photo or text to arrive. Teams that miss this install skeletons, watch the number refuse to move, and conclude the metric is broken. What a skeleton reduces is the anxiety of waiting, not the wait.

Lowering the number by taking the largest element out of the measurement is just as common. Defer the photo at the top and the LCP element becomes the headline block, dropping the value from 3.8 seconds to 1.1. The metric improved and the user's wait for that photo didn't shorten by a millisecond — worse, the late photo shoves the sentence being read further down the page. Cumulative Layout Shift (CLS) catches that shove separately, so cheating one side shows up on the other. Lowering a metric and speeding up a screen are different jobs.