Every second a visitor spends staring at a blank screen after clicking through to your site chips away at their patience. The longer it takes for the page's main content to appear, that big headline, hero image, or block of text that makes the user think "okay, the page has loaded," the more likely they are to leave. The metric that quantifies exactly this experience is called Largest Contentful Paint, or LCP for short. LCP improvement work is one of the most critical topics in modern web performance, because this metric directly affects both the speed a user perceives and the value search engines assign to your page.
LCP measures when the largest content element painted in the visible area of the screen finishes rendering. That element is usually a large image, a background picture, a video poster frame, or a wide block of text. For the user, this is the moment the "real content has arrived." That is why LCP is an intuitive and powerful indicator that summarizes a page's loading experience in a single number. It is also the most visible, and often the most challenging, member of the core web vitals family.
In this guide we will cover exactly what LCP measures, which values count as "good," the real reasons behind a slow LCP, and most importantly how to improve this metric step by step. Whether or not you have a software background, after reading this you will know where to look on your own site and which fix to make first. The goal is not to pile up theory; it is to offer a practical roadmap that delivers measurable results when you apply it.
What Exactly Is Largest Contentful Paint?
Largest Contentful Paint is a timing metric that measures the moment the browser draws the largest content element within the viewport, relative to the start of the page load. The key phrase here is "largest." As the page loads, the browser continuously evaluates candidate elements and marks the one that covers the widest surface in the visible area as the LCP element. As loading progresses and a larger element gets painted, this marker is updated; once the main content has fully settled, the final LCP value is determined.
The main element types considered as LCP candidates are: <img> tags, image elements inside <svg>, blocks with background images loaded via url(), <video> elements with a poster frame, and block-level elements containing large text. On most content-heavy pages the LCP element is a hero image or a large heading.
There is one frequently confused point worth clarifying here. LCP is not the moment the entire page has loaded. LCP may well be complete even while dozens of images further down the page are still loading, because LCP only takes into account the area that is visible on the initial view. This distinction is critical for correct optimization: speeding up things the user cannot see on their screen does not lower your LCP.
How does LCP differ from FCP and other metrics?
First Contentful Paint (FCP) marks the very first piece of content painted on the screen, whereas LCP marks the largest and usually the most meaningful content. FCP says "something has started to arrive," while LCP says "the real content is here." That is why LCP is closer to the user's true expectation than FCP. Likewise, an older metric that measured interaction delay has today been replaced by INP; LCP, on the other hand, is concerned purely with loading speed and does not measure interactivity.
What Is a Good Value for LCP?
Before improving a metric, you need to know what the target is. The threshold values widely accepted for LCP are evaluated based on real-user data from the page on mobile and desktop. The table below summarizes these thresholds.
| LCP Value | Rating | Meaning |
|---|---|---|
| 2.5 seconds or less | Good | The user sees the main content quickly and the experience feels smooth |
| 2.5 - 4.0 seconds | Needs improvement | There is a noticeable delay, and bounce rate starts to climb |
| Over 4.0 seconds | Poor | Serious slowness, with a high risk of losing conversions and rankings |
There is a further subtlety when evaluating these values: it is not a single visit but the 75th percentile of the distribution across real users that matters. In other words, LCP must be at or below 2.5 seconds for 75 percent of visits for you to be rated "good." This approach surfaces the bad experiences that an average would hide, because a handful of users on fast connections cannot mask the problem experienced by the majority on slow devices.
Another important distinction is between lab data and field data. Lab tests take a one-off measurement in a controlled environment and are ideal for debugging. Field data, on the other hand, is collected from the real devices and connections of real users; for ranking purposes, this is what truly matters. Using both together is the healthiest approach: field data tells you a problem exists, while lab data helps you find its cause.
The Four Fundamental Causes Behind a Slow LCP
The most effective way to improve LCP is to understand where the elapsed time is going. LCP duration is generally broken down into four main components, and each one is a separate area for improvement:
- Server response time (TTFB): How long it takes the server to send the first byte after the browser sends a request. A slow server delays everything that follows.
- Resource load delay: The time until the LCP element (especially an image) is discovered and starts downloading. If the browser notices the resource late, loading starts late too.
- Resource load time: How long the LCP resource actually takes to download. Large, uncompressed files waste time here.
- Element render delay: The time between the resource being downloaded and the browser drawing it on the screen. Render-blocking resources prolong this stage.
The good news is that the sum of these four components gives you LCP; therefore finding the component with the biggest share and focusing on it produces the fastest win. On most sites a significant portion of LCP duration comes from images being discovered late and from render-blocking resources. In the sections below we will tackle each cause one by one.
Speed Up Server Response Time (TTFB)
The first link in the Largest Contentful Paint chain is the server. If the first byte arrives at 800 milliseconds, no image or CSS optimization can recover that lost time. That is why it usually makes sense to start improvements here.
- Use caching: Cache the page output or frequently accessed data so the server does not do work from scratch on every request. Full-page caching is highly effective on static or rarely changing pages.
- Take advantage of a CDN: A content delivery network serves your files from servers geographically close to the user. This reduces both network latency and the load on the origin server.
- Optimize the database and server code: Slow queries, unnecessary external API calls, and heavy template processing inflate TTFB. Minimize the work done before generating the response as much as possible.
- Establish connections early: Use
preconnecthints for critical third-party domains so that steps like DNS resolution and the TLS handshake complete before loading begins.
Another powerful technique is having the server send the response in chunks. If the <head> portion of the page is sent to the browser as soon as it is ready, the browser can start discovering and downloading CSS and important resources while it waits for the rest of the content. This way the browser is not left idle while the server is still working.
Make the LCP Image Discoverable Early and Prioritize It
On most sites the LCP element is a large image, and the biggest delay comes from the browser noticing this image late. The browser reads the HTML from top to bottom; if the critical image is hidden behind CSS, in an element added by JavaScript, or somewhere late in the document, downloading starts late too. Your goal is to present this image to the browser as early and as clearly as possible.
Put the image directly in the HTML
Place the LCP image directly in the HTML document with an <img> tag. If the image is added later via JavaScript or defined as a CSS background-image, the browser's preload scanner cannot find it early. Having the image directly in the HTML ensures it is discovered as early as possible.
Raise the priority with fetchpriority
The fetchpriority="high" attribute tells the browser that this image should be downloaded with the highest priority. Browsers tend to treat images as low priority by default; this attribute brings the LCP image to the front. However, apply it only to a single element, the actual LCP element; giving everything high priority amounts to giving nothing priority at all.
Don't fall into the lazy loading trap
Lazy loading is great for off-screen images, but it should never be applied to the LCP image. If you put the loading="lazy" attribute on the large image visible in the first view, the browser delays it and your LCP breaks badly. The rule is simple: leave the critical image visible in the first view as eager (the default) and lazy-load the rest.
Use preload when necessary
If the image cannot be discovered immediately in the HTML, for example because it is a CSS background, you can tell the browser to download this resource early with <link rel="preload">. For responsive images, using it together with the imagesrcset and imagesizes attributes ensures the correctly sized file is preloaded.
Serve the Image Efficiently
Getting the LCP image discovered early is only half the battle; the second half is downloading that image quickly. The goal here is to pull the file size down to the lowest possible level while preserving the image's visual quality.
- Prefer modern formats: Modern formats like AVIF and WebP offer much smaller file sizes at the same quality compared to older JPEG and PNG. You can provide a fallback format with the
<picture>tag depending on browser support. - Serve at the right size: Loading a 3000-pixel-wide image for something that will appear 600 pixels wide on screen is pure waste. Send the size appropriate to the device with the
srcsetandsizesattributes. - Tune the compression: Compress images to a level where the quality loss is not visible to the eye. Generally, a quality between 75 and 85 percent offers a good balance between file size and appearance.
- Specify dimension attributes: Giving the image
widthandheightvalues both prevents layout shift (CLS) and lets the browser reserve the space in advance.
If your LCP element is not an image but a large block of text, you should turn your attention to the fonts. Text remaining invisible while web fonts load delays LCP. By using font-display: swap you can have the text appear instantly with a system font first and then be swapped once the font loads. Loading critical fonts early with preload also provides a clear gain for text-based LCP.
Eliminate Render-Blocking Resources
The browser assumes it must process all of the CSS before it can paint the page. That is why CSS is, by nature, a render-blocking resource. Synchronously loaded JavaScript halts parsing in the same way. The larger and more numerous these resources are, the longer the LCP element takes to be drawn on the screen.
Inline the critical CSS
You can identify the minimum CSS needed to paint the first view and place it inline directly inside the HTML's <head>. The remaining, non-critical styles you load asynchronously so they do not block rendering. This way the browser starts painting the main content without waiting for an external CSS file to download.
Clean up unused CSS and JavaScript
Many sites load hundreds of kilobytes of CSS and JavaScript that the page does not actually use. Detecting and removing unused code reduces both download time and parsing overhead. Load large libraries piece by piece with code splitting, only when they are truly needed.
Defer JavaScript
Add the defer or async attribute to all scripts not needed for the page's initial render. defer lets a script download without blocking HTML parsing and run once the document is ready. Third-party code such as analytics, chat, and ad scripts in particular can almost always be deferred.
Third-party scripts are among the elements over which you have the least control but that can damage LCP the most. Every external script you add can keep the main thread busy and delay rendering. Questioning every third-party tool you add to the page with "is this really needed in the first view?" usually reveals unnecessary overhead.
The Impact of Client-Side Rendering and Late Loading
In applications that are entirely client-side rendered, LCP runs into an additional obstacle. The browser first receives an empty or skeleton HTML, and only after JavaScript is downloaded and executed is the content generated. In this case the LCP element does not even exist until the JavaScript runs; therefore LCP is naturally delayed.
Server-side rendering (SSR) or static site generation (SSG) are powerful solutions to mitigate this problem. When content is pre-generated on the server and sent as HTML, the browser can paint the LCP element without waiting for JavaScript. Modern frameworks offer hybrid approaches that render the initial load on the server and then add interactivity on the client; this approach is usually the healthiest for LCP.
If you have to use client-side rendering, at the very least keep the main JavaScript bundle small, render the critical content first, and defer off-screen components. In addition, parallelizing data fetching and prioritizing critical data speeds up the appearance of the main content.
Measure and Monitor LCP Correctly
You cannot improve what you cannot measure. Using the right tools during the LCP improvement process lets you both find the source of the problem and see whether the changes you made are working.
For field data, the real-user measurements (RUM) collected by browsers and performance platforms are the most valuable source, because they reflect real device and connection conditions. For lab data, the performance panel in browser developer tools and standard performance audit tools will do the job. These tools show you exactly which element the LCP element is and which component the time is being spent in.
A practical monitoring approach consists of these steps:
- First look at field data to learn the LCP distribution of your real users and the 75th percentile value.
- Run the problematic pages in a lab tool to identify the LCP element and the time distribution.
- Apply a fix targeting the component that takes the biggest share (server, discovery, loading, or render).
- After you ship the change, verify the result in both lab and field data.
- Put the improvement under continuous monitoring, because a newly added image or script can break the metric again.
The point worth underlining here is that LCP is not a one-time job. As site content grows, new features are added, and third-party tools increase, LCP can degrade over time. Regular monitoring is the only way to catch this regression early.
Frequently Asked Questions
Is LCP the same as the page being fully loaded?
No. LCP only measures the moment the largest content element visible in the first view is painted. LCP may already be complete even while images, scripts, and other resources further down the page are still loading. That is why speeding up elements the user does not see on their screen does not lower LCP; your focus should always be the first visible area.
How do I find out which element my LCP element is?
The performance panel in the browser's developer tools clearly shows the element marked as LCP while it records the page load. Most performance audit tools also indicate this element in their report under a "Largest Contentful Paint element" heading. Usually this element is a large hero image or the widest block of text on the page.
Why does lazy loading break LCP?
Lazy loading ensures an image downloads only when it approaches the visible area. But the LCP element is already visible in the first view; applying loading="lazy" to it causes the browser to delay it unnecessarily. That is why you should always eagerly load the critical image in the first view and apply lazy loading only to off-screen images.
My server is fast but LCP is still high, why?
In this case the delay is most likely in the stages after the server. The most common causes are: the LCP image being discovered late, large render-blocking CSS and JavaScript files, unoptimized large images, or late-loading web fonts. Looking at the LCP time distribution in a lab tool to see which component spends the most time clarifies the root cause.
Why are mobile and desktop LCP values different?
Mobile devices generally have lower processing power and more variable network conditions. The same page runs JavaScript more slowly and downloads resources later on mobile. That is why mobile LCP is almost always higher than desktop, and your optimization priority should usually be the mobile experience.
Does improving LCP directly raise my SEO ranking?
LCP is part of the core web vitals framework and is evaluated among the page experience signals. However, ranking depends not on a single metric but on many factors, including content quality. A good LCP gives you an edge among pages of equal quality and contributes indirectly by improving user behavior; but it does not compensate for weak content on its own.
Conclusion
Largest Contentful Paint is one of the metrics that best summarizes how quickly a page "opens" for the user, which is why it holds a special place within core web vitals. The essence of LCP improvement work lies in understanding where the elapsed time goes: server response, resource discovery, downloading, and drawing on the screen. Once you find which of these four stages spends the most time, you have also found the fix that will deliver the highest return.
In practice the most common wins are clear: speeding up the server response with caching and a CDN, putting the LCP image directly in the HTML and prioritizing it with fetchpriority, avoiding the lazy loading trap, serving images in modern formats and at the right size, and simplifying render-blocking CSS and JavaScript. Each of these steps makes a difference even on its own; applied together, they can move your LCP from the "poor" zone to the "good" zone.
Finally, remember that performance is not a one-time project but an ongoing discipline. Monitor real-user data regularly, check how LCP is affected each time a new feature or image is added, and catch regressions early. Once you build this habit, a fast first impression will keep sending a strong signal, continuously, to both your visitors and search engines.