Core Web Vitals LCP: why your landing page's first screen takes too long to appear

LCP (Largest Contentful Paint) measures the time it takes, from the moment a page starts loading, for the largest element visible on the first screen to fully render. On a landing page, that's almost never a button or a small logo: it's the hero image, a background video, or sometimes just the headline block if it takes up more space than anything else. Past 2.5 seconds, Google puts the page in the "needs improvement" or "poor" bucket — and the visitor doesn't need a score to feel like they're still waiting for the page to finish appearing.

What LCP measures — and what it doesn't

LCP is one of Google's three Core Web Vitals, alongside CLS (visual stability) and INP (responsiveness to interactions), which we cover in a separate article. Unlike total load time or the browser's onLoad event, LCP only cares about one specific moment: when the largest element in the visible viewport becomes fully rendered. A site can keep loading scripts, fonts, or sections further down the page for several seconds after a good LCP — that no longer affects this particular score, though it can still affect INP or the overall feel of the page.

The threshold that matters: 2.5 seconds, at the 75th percentile

Google sets three tiers: an LCP under 2.5 seconds is rated "good," between 2.5 and 4 seconds it "needs improvement," and past 4 seconds it's "poor." This isn't an average: Google evaluates the 75th percentile of real visits measured over a rolling 28-day window (CrUX data, the Chrome User Experience Report) — in other words, at least three out of four visitors, on their actual connection and device, need to land under 2.5 seconds. A lab test over fiber on a developer's workstation doesn't tell you much, then: it's your mobile visitors, on 4G, on an entry-level device, who determine the score that actually counts for search rankings.

Why it's not just a technical score

A study by Qingzhu Gao, Prasenjit Dey, and Parvez Ahammad, presented in 2017 and run through large-scale crowdsourcing across hundreds of retail web pages, compared classic loading metrics (like onLoad or time to first byte) against users' actual perception of how fast the visible above-the-fold content appeared. The result: those traditional metrics matched human judgment in less than 60% of cases, while a model centered on visible "above-the-fold" rendering explained user perception with close to 87% accuracy (Gao, Dey & Ahammad, 2017). That's exactly what LCP was designed to approximate: not "has the page finished loading," but "can the visitor finally see something substantial." On a landing page, that something is often your main argument — the headline and image that need to convince within a few seconds, as we cover in our article on the fold line.

The most common causes on a landing page

• A hero image that's too heavy or badly formatted — a JPEG or PNG exported at desktop screen size, served as-is to mobile, or without modern compression (WebP, AVIF).
• A server response time (TTFB) that's too slow — an overloaded shared host, no caching, or server-side rendering computed fresh on every request instead of a statically pre-generated site.
• Render-blocking resources — CSS or fonts loaded synchronously before the browser can paint anything to the screen at all.
• An image the browser discovers too late — loaded via JavaScript, set as an un-preloaded CSS background, or hidden behind a carousel that only reveals the first image after a script runs.
• A web font that delays the headline's render — if the headline is the largest visible element and a custom font blocks its rendering, the font — not the image — is what determines your LCP.

Fixing LCP without sacrificing the design

Always start by identifying the element that triggers the measurement, in Chrome DevTools' Performance tab or via PageSpeed Insights, which highlights it directly on a screenshot. If it's the hero image, serve it in a modern format (WebP or AVIF) and at the size actually displayed on mobile using srcset attributes, add fetchpriority="high" to tell the browser it's a priority, and above all never lazy-load it since it's visible the moment the page loads — lazy loading, useful further down the scroll, is counterproductive on the element that defines your LCP. If the headline block visually dominates instead (text-only layout, no hero visual), check that the font isn't blocking the render: a system font as an immediate fallback, or a web font with font-display: swap, avoids waiting on a font file before showing the text at all. Next.js handles a good part of this natively through its Image component (compression, modern formats, automatic sizing) — we cover the full setup in our article on deploying Next.js on Vercel.

The skeleton screen and entrance animation trap

We mention this in our article on skeleton screens: content that appears gradually through a JavaScript animation (fade-in, offset, scroll-reveal effect) artificially delays the moment the browser considers the element "painted," even if the image file has already finished downloading. A 400-to-600ms entrance animation on the headline or hero image can drag down an otherwise excellent LCP. The fix isn't to ban every animation, but to reserve entrance effects for sections below the fold, and let the hero block render immediately, with no initial opacity transition.

Special case: background video in the hero

A landing page using a looping video as a hero background — common on the Local Agency or Restaurant & Reservation templates (demo) for added atmosphere — should display a lightweight, preloaded "poster" image (the poster attribute on the video tag) while the video itself keeps loading in the background. It's that static image, not the video's first frame, that should count as the LCP element: compressed and served with priority, it gives an immediate visual result while the much heavier video takes whatever time it needs without penalizing the score.

Checking the result in the field, not just locally

A good LCP locally, on a fast development machine over a wired connection, guarantees nothing in the field. Google Search Console (the "Core Web Vitals" report) surfaces real CrUX data from your visitors once traffic is sufficient, while PageSpeed Insights combines a lab test with real-world data when it exists for the site. As with the general loading speed we cover elsewhere, the stakes go beyond the SEO score alone: past 2.5 to 3 seconds before seeing the page's main argument, a measurable share of visitors leaves before ever getting the chance to be convinced by the rest of the page.