What Is LCP? How to Optimize Largest Contentful Paint

What is LCP (Largest Contentful Paint)?

LCP, or Largest Contentful Paint, is a Core Web Vitals metric that measures how long the largest image or text block in the visible area takes to render after a visitor opens a page. Google uses it to judge when the main content has loaded. In short, LCP is perceived loading speed.

It does not track when the page technically finishes. Instead, it tracks when the visitor feels the page is ready. That is why it reflects real experience better than older metrics. A browser may download dozens of files in the background, yet people only care when the big hero image shows up.

Our team looks at LCP first in most performance audits. It connects user experience, search visibility, and revenue. For the wider picture, read our Core Web Vitals guide. In this article we stay focused on LCP.

Why does LCP matter for SEO and conversions?

LCP is part of Google's page experience signals. A slow score alone will not wreck your rankings. However, when two pages have similar content quality, speed can tip the balance. The bigger effect shows up in user behavior.

When a page opens late, visitors do not wait. They hit the back button. As a result, bounce rate rises and conversions drop, especially on mobile and slow connections.

Paid traffic suffers too. In Google Ads you pay for the click, so a slow landing page wastes part of that spend. We cover the wider link between speed and rankings in our article on how site speed affects SEO.

• Organic visibility: page experience adds a small but real signal.
• Conversions: if the product image arrives late, people leave before they buy.
• Ad efficiency: a faster landing page turns the same budget into more real visits.

In short, LCP is not only a technical score. It is an indicator tied to revenue.

What are the LCP thresholds? What is a good LCP score?

Google sets clear thresholds. According to the web.dev LCP guide, a good experience means an LCP of 2.5 seconds or less. Anything above 4 seconds is poor. The range in between needs improvement.

The key detail is the percentile. Google looks at the 75th percentile of page loads. So at least 75% of your visits should have an LCP under 2.5 seconds. One fast test run is not enough.

Also note that mobile and desktop data are assessed separately. Mobile results are usually weaker, so we suggest starting with the mobile score.

Which elements count as the LCP element?

The LCP element is the largest content piece in the viewport at the time of measurement. It changes from page to page. For example, sometimes it is the hero image, and sometimes it is a big headline block.

The specification accepts only certain element types as candidates. The web.dev LCP guide lists them:

• img elements.
• Image elements inside an SVG.
• The poster image or first frame of a video element.
• Elements with a background image loaded through the CSS url() function.
• Block-level elements that contain text nodes or other inline text children.

In practice, the LCP element is often an image on mobile. On some blog templates, it is the title block instead. Do not guess which one applies to you. Measure it.

Also remember that the candidate can change while the page loads. A text block may count first, and then a large image takes over once it renders. The browser keeps tracking the largest candidate until the user interacts with the page.

How do you find the LCP element on your page?

Before you fix anything, you need to know which element is the LCP element. Optimizing the wrong element is the most common time waster we see, so identify it first. Luckily, finding it is easy, so start there.

1. Open the page in Chrome and press F12 to start DevTools.
2. In the Performance panel, record a page load and refresh.
3. Click the LCP marker on the timeline to see the related DOM element.
4. As an alternative, open your PageSpeed Insights result and find the LCP element entry.
5. Lighthouse shows the same information in its diagnostics section.

Also, test mobile and desktop separately. On responsive designs, each device can have a different LCP element. For example, the desktop version may show a large image while the mobile version shows a heading.

For a full walkthrough of the tool, see our Lighthouse performance test guide.

What is the difference between lab data and field data?

You can see LCP through two kinds of data. Lab data, such as Lighthouse, is one load in a controlled environment. Field data, such as the Chrome UX Report, comes from real visitors.

The two often disagree. A page that scores 1.8 seconds in the lab can show 3.2 seconds in the field. The reason is simple: real users have different devices, networks, and locations.

Therefore, make decisions with field data, and use lab data for debugging.

After you ship a fix, field data does not change right away. Because it is cumulative, the improvement takes time to show up.

What are the four subparts of LCP?

LCP is not one block of time. The web.dev guide on optimizing LCP splits it into four subparts. This split turns optimization from guesswork into diagnosis.

In other words, these percentages show the ideal distribution. If one subpart on your page is far above its share, that is where the problem lives.

For example, if resource load delay is 35%, the browser discovers the image too late. In that case, shrinking the file will not help. You need to make the image discoverable earlier.

This is the first step in our performance audits: we measure the subparts first, and then we target the biggest gap.

What are the most common causes of a slow LCP?

A slow LCP usually comes from a few familiar causes. The web.dev LCP guide highlights unoptimized images, late-loading resources, font delays, high TTFB, and render-blocking resources.

In the field, we see this pattern most often:

• The hero image is huge and uses an old format, such as an uncompressed JPEG or PNG.
• The LCP image was lazy-loaded by mistake.
• A script adds the image, so the browser finds it late.
• The server responds slowly and pages are not cached.
• Large CSS or JS files at the top block rendering.
• The heading stays invisible until a web font loads.

Few sites have all of them at once. Therefore, do not install a random speed plugin. Look at the subparts first and find which cause dominates on your site.

How do you make the LCP image load faster?

On most sites, the LCP element is an image. So image optimization is the highest-return step. However, there are two separate jobs here: making the file smaller and making the browser find it earlier.

To reduce the file size, apply the following:

• Use a modern format. WebP or AVIF usually produce smaller files than JPEG and PNG.
• Resize the image to the size it is displayed at. Do not show a 3000 pixel image in an 800 pixel slot.
• Serve the right size per device with srcset and sizes.
• Compress while checking quality by eye. A loss you cannot see is not a problem.

For quick resizing, try our free image resizer. For deeper methods, read our guide on image optimization for speed and SEO.

However, compression alone is not enough. If the browser discovers the image late, even a small file arrives late.

How do you use fetchpriority and preload for the LCP image?

The browser does not treat all images the same. You have to tell it that the LCP image matters most. Two tools help here, so use both.

The first is the fetchpriority="high" attribute. The web.dev optimization guide advises adding it to the LCP image while avoiding "high" on many elements. If everything is a priority, nothing is.

The second is the preload hint. If the image comes from a CSS background or a script, the browser finds it late. Preload warns it early.

• If the image is a plain img tag in HTML, fetchpriority alone is usually enough.
• If it comes from a CSS background, add a preload or, better, switch to an img tag.
• For responsive images, preload with imagesrcset so the right size downloads.

These two small changes often shorten resource load delay noticeably. Even so, measure first, apply the change, and measure again.

Why should you never lazy-load the LCP image?

Lazy loading is great for images below the fold. Applied to the LCP image, however, it backfires. The web.dev guide says it plainly: never lazy-load your LCP image, because it always adds unnecessary resource load delay.

Here is the problem: the browser waits for layout before it starts a lazy image. As a result, your most important image becomes the last to arrive.

A common cause is a theme or plugin that adds lazy loading to every image automatically. So the hero image gets included without you noticing.

• Remove the lazy attribute from the first visible image.
• Use loading="lazy" only for images below the fold.
• Check your theme or plugin settings for a first image exception.

To go deeper, read our explanation of lazy loading for SEO and page speed.

What image size and format should your hero image use?

The hero image is the picture that takes the most space on the first screen, so prepare it with care. So you need to make three decisions during preparation: size, format, and compression level.

The rule for size is simple. Produce the image for the widest size it will appear at on the page. Double that is enough for high-density screens. Anything more only bloats the file.

• Format: use WebP or AVIF for photos and SVG for simple graphics.
• Compression: lower quality while comparing on screen, and do not trust a number blindly.
• Fallback: offer a JPEG alternative in a picture element for older browsers.
• Dimensions: set width and height so the layout does not shift.

Also ask whether the image is truly needed on the first screen. For example, a decorative background photo often slows the page without bringing conversions.

In other words, the best optimization is sometimes simplification, not compression. Design and speed decisions meet at this point.

How does server response time (TTFB) affect LCP?

TTFB can make up about 40% of LCP. If the server sends the first byte late, everything else stacks on top of that delay. Therefore, even perfect images cannot save a slow server.

Several factors influence TTFB:

• Slow or crowded shared hosting.
• Dynamic pages that run database queries on every request and have no caching.
• Unnecessary redirect chains.
• A server far from the visitor and no CDN.

To fix it, use page caching and server-side caching. Our article on how caching works explains the background. Hosting quality matters as well, and we collected the criteria in our guide on choosing web hosting.

The web.dev guide also notes that server-side rendering makes resources discoverable in the first HTML. It may raise TTFB, but for most sites the trade-off is worth it.

Does a CDN help improve LCP?

In most cases, yes. A CDN serves your files from servers close to the visitor. As a result, both TTFB and resource load duration get shorter.

However, a CDN does not solve every problem. For example, if the image is discovered late, a CDN only downloads the late image faster. So you must fix discovery first.

• A CDN is ideal for static files such as images, CSS, JS, and fonts.
• Set cache headers correctly, or the CDN benefit shrinks.
• If your CDN offers image conversion, let it produce WebP or AVIF automatically.
• If your visitors live in one country, the gain may be smaller.

In practice, think of a CDN as a complement. Keep the main order: discovery and render delay first, file size second, infrastructure last.

How do render-blocking CSS and JavaScript delay LCP?

Even if the image downloads fast, the browser may not paint it right away. The cause is render-blocking resources. They inflate the element render delay subpart.

CSS blocks rendering by default. Until a large stylesheet arrives, the browser paints nothing. JavaScript can also pause parsing.

• Inline the critical CSS and keep the remaining CSS small.
• Remove unused CSS.
• Load non-essential scripts with defer or async.
• Push third-party widgets, such as chat, comments, and tracking tags, after the first load.

Another trap is pages that draw their content with JavaScript after load. In that case, the LCP element only exists once the script runs. Therefore, generating HTML on the server is an advantage.

For more detail, see our article on how JavaScript affects site speed.

When do web fonts hurt LCP?

If the LCP element is a text block, the font becomes part of the process. The browser may hide text until the custom font downloads. This font block period delays LCP.

The fixes are simple, but teams often skip them:

• Use font-display: swap so text first shows in a fallback font.
• Load only the weights you truly use. Two weights may be enough instead of six.
• Serve your main font from your own server to avoid a third-party connection.
• Preload the critical font file.
• Remove language subsets you do not need.

There is a balance, though. A size difference between the fallback and the real font can cause layout shifts (CLS). CLS is not the topic here, but you can read about it in our Core Web Vitals article.

Still, we recommend thinking about both metrics when you choose a font.

Why is LCP worse on mobile than on desktop?

On mobile devices, LCP is usually higher. There are a few clear reasons. First, processors are weaker, so JavaScript and rendering take longer. Mobile network latency is also higher.

Moreover, we often see a common mistake in responsive images: the mobile device receives a desktop-sized file. As a result, extra megabytes are downloaded for nothing.

• Serve small images to small screens with srcset.
• Do not load large components that mobile hides anyway.
• Test the mobile home page LCP element separately.
• Try a slow network simulation, such as the Lighthouse mobile profile.

Google assesses mobile and desktop data separately, so do not mix the two reports. In short, fix mobile first. Desktop usually improves along with it.

In what order should you optimize LCP?

Random optimization wastes time. The web.dev guide on optimizing LCP suggests a priority order. It puts the cheapest and most effective steps first.

1. First, bring resource load delay close to zero so the LCP resource is discovered immediately.
2. Second, reduce element render delay by removing everything that blocks rendering.
3. Reduce resource load duration with compression, the right size, and the right format.
4. Finally, improve TTFB with caching, hosting, and a CDN.
5. Measure the result with field data.

Web.dev also reminds us that load duration is not a big bottleneck on most sites. So your first reflex should not be to shrink the image even more.

For this reason, we look at delays first. Then we move to file size. Finally, we deal with the server.

In practice, change one thing at a time and measure again after each step. Otherwise, you cannot know which change worked.

How do you improve LCP on WordPress and ecommerce sites?

On ready-made platforms, LCP problems follow patterns. Whether it is WordPress, Shopify, or a custom store, we see similar mistakes.

For instance, on product detail pages, the LCP element is usually the main product image. On category pages, the first row of product images becomes the candidate. These pages are tied to revenue, so they deserve priority.

Platform choice also affects the outcome. A site planned for speed costs less effort than one patched later. This is why our web design service considers performance during the design phase.

Which pages should you prioritize for LCP?

However, you do not have to optimize every page at once. Setting a priority order helps you invest limited resources in the right place.

Ask these questions: Which pages get the most organic traffic? Which ones receive ad traffic? Which ones are closest to a conversion?

1. Landing pages that your ads point to.
2. The home page and the top category pages.
3. Product or service detail pages.
4. High-traffic blog posts.

This order is a starting approach from our audits. It may change by industry, and it is not a guarantee.

Also, pages that share a template improve together. A single template fix can lower LCP on hundreds of pages at once. For example, fixing the cover image in the blog template affects every post.

How do you monitor and report LCP?

However, fixing it once is not enough. New images, new plugins, and new ad scripts can break your score again. So set up regular monitoring.

You can use these sources:

• Google Search Console: the Core Web Vitals report shows field data by URL group.
• PageSpeed Insights: gives both field and lab data for the same page.
• Lighthouse: ideal for debugging and diagnostics.
• Chrome DevTools: inspect the LCP element and its subparts.

When you report, look at page groups instead of a single number. For example, track blog posts, product pages, and the home page separately.

If you want performance tracking as part of your SEO strategy, our SEO consulting service includes technical audits.

What are the most common LCP optimization mistakes?

The mistakes we have seen for years do not change. Knowing them also saves time and budget.

• Optimizing the wrong element: compressing images before finding the LCP element.
• Looking only at the lab score while the field result differs.
• Adding lazy loading to all images, including the hero image.
• Setting fetchpriority high on every element, which makes priority meaningless.
• Fixing desktop and forgetting mobile.
• Installing a speed plugin and calling it done without measuring.
• Measuring once and ignoring the natural variation.

What these mistakes share is treatment without diagnosis. Yet measuring the four subparts takes about twenty minutes.

Also, do not misread the target. Under 2.5 seconds is a good threshold, but if you skip the percentile logic, you can be fooled by an average. Most of your users need to be under that threshold.

The easiest prevention is a checklist. Before every new page or campaign, check the first image for size, priority, and loading method. That way, problems are caught before they go live.

What does a sample LCP improvement plan look like?

The plan below is not a sample calculation. It is a checklist order you can apply. It reflects a starting approach from our field experience, not a guarantee.

1. Identify poor LCP groups in Search Console.
2. Open a representative page from each group in PageSpeed Insights.
3. Note the LCP element and the four subparts.
4. Choose an action based on the subpart with the biggest share.
5. Apply the change alone and measure again.
6. Confirm the result when field data updates.

For example, if resource load delay is high, first try making the image discoverable in the HTML and add fetchpriority. If TTFB is high, hosting and caching come first.

Also, many fixes are simple. Compressing an image, removing a lazy attribute, and cleaning up plugins need no deep technical skill. If your page renders on the client, hosting changes do not help, or ad scripts weigh the page down, you need a deeper review. Our team runs these audits together with SEO and design work. To start, get in touch with us.