What LCP measures
Largest Contentful Paint records the moment the biggest visible thing on the screen finishes rendering. Not the moment the server responded, not the moment the last script finished — the moment a visitor could see the main item on the page. It is one of the three Core Web Vitals, and it stands in for the everyday question of when the page looked ready.
The browser picks the element itself, and it can change during loading. A heading may hold the title briefly until a hero image arrives and takes over. The element counted is whichever was largest at the point the visitor first interacted, or when loading settled. On most business sites that is a hero image, a background image, a large heading or a video poster frame.
It helps to think of the measurement in parts: how long the server took to send the first byte, how long before the browser even started fetching that element, how long the fetch itself took, and how long after that before it was painted. Each part has different fixes, and a page can be slow in only one of them.
Why LCP matters
It is the vital that visitors feel most directly. A page that shows its main content quickly feels usable even if work continues underneath; a page that sits blank while a large image downloads feels broken, and people leave before anything loads.
Search engines use it too, as part of page experience, drawn from real visits rather than a test run. That distinction matters in Nepal and across much of South Asia, where most visits arrive on mobile networks and mid-range Android phones. A hero image that appears instantly on an office connection can take a long, visible pause on a phone in a suburb of Kathmandu, and it is the phone’s experience that is recorded.
Common mistakes with LCP
The biggest is optimising against a laboratory test alone. A tool that loads the page once from a data centre tells you what could happen; the field data behind Search Console tells you what did happen to real visitors on their own devices and connections. They frequently disagree, and only one of them is what gets reported.
The next is lazy-loading the hero image. Deferring images below the fold is good practice, but a blanket rule defers the very element being measured, and the score gets worse. Fonts cause a similar trap: a heading that waits for a web font cannot be painted, so the page holds an empty space where the largest element should be.
Then there are the ordinary faults — an enormous uncompressed image, render-blocking stylesheets and scripts in the head, a slow server response before anything can start, and content built entirely in the browser so nothing paints until the JavaScript has run.
How to act on it
Identify the element first. PageSpeed Insights names it, and the browser’s performance panel shows it on your own page. Everything after that is aimed at that one element: size and compress it properly, serve a modern image format, tell the browser to fetch it early, and never lazy-load it.
Then clear the road in front of it. Cut or defer render-blocking resources, reduce the server’s response time with caching and a content delivery network, and let text display in a fallback font rather than waiting. Re-check against field data, not the lab score, and give it time — the reported figure covers a rolling window of real visits, so it moves after your fix, not with it. Where images are the culprit, lazy loading policy and page speed work usually go together, and the other Core Web Vitals improve alongside it.