Largest Contentful Paint (LCP)
Largest Contentful Paint measures how long it takes for the biggest visible element on a page, usually the hero image or main headline, to finish rendering. It is the Core Web Vital that answers the question every visitor asks: when does this thing actually load?
Largest Contentful Paint, or LCP, is the loading metric in Core Web Vitals. It records the exact moment the largest piece of content visible in the viewport finishes painting. On most pages that is a hero image, a big banner, or the main headline. When a visitor stares at a blank or half-drawn screen, LCP is the number quantifying that pain. It is the closest thing Google has to measuring the question every visitor silently asks in the first second: is this page actually going to show up or not? I like LCP because it is honest. A lot of old speed metrics measured technical milestones that did not match what people perceived. LCP measures the moment the main thing you came to see appears, which is the moment a visitor decides the page is working. Get that moment to happen quickly and most of the perceived slowness complaints disappear, even if other parts of the page are still loading quietly in the background.
What element actually counts as the LCP element
Chrome picks the largest content element in the viewport at the moment the page settles. It is not always what you would guess. Sometimes it is your logo, sometimes a block of text, sometimes a background image you forgot existed. The first move in any LCP investigation is identifying which element Chrome is actually timing, because optimizing the wrong element is a great way to waste an afternoon and move nothing. PageSpeed Insights names the LCP element for you, so always start there before you touch anything.
- A hero or banner image is the most common LCP element on marketing pages.
- A large block of headline text is common on articles and blog posts.
- A video poster frame or an above-the-fold product photo on commerce pages.
Fixing LCP starts with one question: which element is Chrome timing, and what is standing between the browser and rendering it?
Slow LCP almost always comes down to the browser being delayed before it can paint that main element. The delay is usually a slow server, render-blocking resources, an unoptimized image, or a lazy-loaded hero that should never have been lazy-loaded in the first place. Each of these is a separate gate the browser has to clear, and your LCP is only as fast as the slowest gate. That is why a single oversized hero image or one blocking stylesheet can wreck an otherwise quick page. The table below maps the usual causes to the fix that actually moves the number, in roughly the order I work through them.
| Common cause | Practical fix |
|---|---|
| Slow server response time | Improve TTFB with caching and a faster host |
| Render-blocking CSS and JavaScript | Defer non-critical scripts, inline critical CSS |
| Heavy, unoptimized hero image | Compress, serve modern formats, size it correctly |
| Hero image set to lazy-load | Eager-load the above-the-fold image and preload it |
warningWATCH OUT
Never lazy-load your LCP element. Lazy loading is for images below the fold. Lazy-loading the hero tells the browser to wait, which is the exact opposite of what LCP rewards.
- 1Run the page through PageSpeed Insights and note which element is flagged as the LCP element.
- 2Confirm your server response is quick, since a slow TTFB caps how good LCP can ever get.
- 3Optimize and preload that element, then remove any lazy-load attribute from it and re-test.
targetShmul's rule of thumb
If your LCP is bad, do not start by trimming JavaScript. Start by confirming the server responds fast, then make the single largest visible element load as early and as light as possible. Most LCP wins come from those two moves alone. For the full process, walk through how LCP fits alongside INP and CLS in my Core Web Vitals playbook, and pair these fixes with your server-side TTFB work.
Want this handled by someone who has measured search for 20 years?
Work with me