How to improve LCP on blog and product pages

Blog posts and product pages usually have a slower Largest Contentful Paint than the homepage, because they carry oversized images, embeds, plugin scripts and fonts that nobody tuned. To fix it, find the LCP element on each template, work out which of its four subparts is slow, and change the template once so every post or product benefits.

Why blog and product pages are slower than the homepage

The homepage gets the most attention, so it is usually the best-optimized page on a site. Someone has compressed its hero image, trimmed its scripts and tested it in Lighthouse more than once. Blog posts and product pages are different: the template is designed once, then filled with content by many people over years.

That creates a few predictable problems:

• Editor-uploaded hero images. A writer uploads a 4000 px photo straight from a camera or stock library. The CMS may resize it, or it may serve the original.
• Embeds near the top. A video, social post or map at the top of an article loads its own scripts and iframes, which compete with the LCP resource for bandwidth.
• CMS plugins. Share buttons, related posts, comments, chat widgets and analytics often load on every inner page, sometimes as render-blocking scripts in the head.
• Product galleries. The main product image often sits inside a carousel that only renders after its JavaScript runs.
• Web fonts. Article pages are text-heavy, so when the LCP element is the headline, a slow font file can hold it back.

Because these pages share templates, the same problem repeats on every URL that uses them. Test only the homepage and you miss all of it, which is the core argument of Lighthouse only tests one page.

Start by finding the LCP element

You cannot fix LCP until you know which element it is. Largest Contentful Paint is the render time of the largest image, video poster or text block visible in the viewport. On a blog post it is usually the featured image or the headline. On a product page it is usually the main product photo.

To find it:

1. Run Lighthouse in Chrome DevTools or PageSpeed Insights on a representative page, on mobile.
2. Find the diagnostic that names the Largest Contentful Paint element. It shows the exact element and how its time breaks down.
3. Repeat on two or three other pages built from the same template. If the LCP element is the same kind of element each time, for example the post’s featured image, you have a template-level target.

The LCP element can differ between mobile and desktop. On a narrow screen a headline may fill more of the viewport than an image that sits beside it on desktop, so check both.

The four subparts of LCP

Every LCP time splits into four consecutive parts. Knowing which one is large tells you what to fix, so you are not guessing.

Subpart	What it covers	Usual cause when it is slow
Time to First Byte	Navigation start until the first byte of HTML arrives	Slow server, no page cache, redirects, distant origin
Resource load delay	TTFB until the browser starts downloading the LCP resource	Image found late: lazy-loaded, inserted by JavaScript, or a CSS background
Resource load duration	Time spent downloading the LCP resource	Oversized file, older format, no CDN, competing downloads
Element render delay	Download finished until the element is painted	Render-blocking CSS or JS, fonts, client-side rendering, hidden carousel slides

If the LCP element is text, there is no resource to download. Load delay and load duration are zero, and the time sits in TTFB and render delay.

Google’s guidance is that on a well-optimized page, most of the time goes to TTFB and resource load duration, while load delay and render delay stay small. If either delay is a large share of your LCP, that is usually the cheapest place to win. web.dev’s guide to optimizing LCP covers the breakdown in more depth.

Fix 1: Speed up the server response

If TTFB is slow, nothing else can start. Inner pages miss the cache more often than the homepage, because there are many of them and each one is visited less.

• Serve HTML from a page cache or CDN edge cache instead of building it fresh on every request.
• Remove redirect chains, such as http to https to www to a trailing slash.
• Confirm the cache actually hits on inner pages, not just the homepage. Response headers often show the cache status.
• Keep slow work, such as personalization or live stock lookups, out of the initial HTML response where you can.

Fix 2: Remove resource load delay

The browser should start fetching the LCP image as early as possible. The most common mistake is lazy-loading it.

• Never lazy-load the LCP image. Remove loading="lazy" from the hero or main product image. Many themes add it to every image by default, which is right below the fold and harmful above it.
• Put the image in the HTML. An <img> tag in the server-rendered HTML is found by the browser’s preload scanner straight away. An image inserted by JavaScript, or set as a CSS background-image, is found much later.
• Add fetchpriority="high" so the browser downloads the LCP image ahead of other images.
• Preload it when you have to. If the image must be a CSS background or is chosen by script, add <link rel="preload" as="image"> in the head, with imagesrcset and imagesizes for responsive images.

A hero image that follows all of these rules looks like this:

<img
  src="/img/hero-1200.avif"
  srcset="/img/hero-600.avif 600w, /img/hero-1200.avif 1200w, /img/hero-1800.avif 1800w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="1200" height="675"
  fetchpriority="high"
  alt="Description of the image">

Use fetchpriority="high" on one image per page. If every image is high priority, none of them is.

Fix 3: Shorten resource load duration

Once the download starts, make the file small and close to the visitor.

• Serve responsive images. Use srcset and sizes so a phone downloads a 600 px file instead of a 2400 px one. Generating these sizes is a job for the template and media pipeline, not for editors.
• Use modern formats. AVIF and WebP are usually much smaller than JPEG or PNG at similar visual quality. Most image CDNs and CMS image services can convert automatically.
• Compress sensibly. A mid-range quality setting is rarely distinguishable on screen from a maximum one.
• Serve images from a CDN with long cache lifetimes.
• Reduce competition. Fonts, scripts and other images downloading at the same moment slow the LCP image down. Defer anything not needed for the first view.

For example, a blog template that sends a 1.8 MB JPEG hero to every phone might send a file well under 200 KB once it serves a 600 px AVIF instead. On a slow mobile connection, that difference alone can be the gap between a poor and a good LCP.

Fix 4: Cut element render delay

Sometimes the image has finished downloading but still is not on screen, because something is blocking the render.

• Render-blocking CSS and JavaScript. Large stylesheets and synchronous scripts in the head delay the first paint. Inline the critical CSS, add defer to scripts that do not need to run first, and remove plugins the page does not use.
• Carousels and galleries. If the main product image sits in a slider that stays hidden until its JavaScript initializes, it cannot paint. Render the first slide as plain HTML and add the slider behavior afterwards.
• Client-side rendering. If the content only appears after a framework hydrates or fetches data, LCP waits for all of that. Server-render or statically generate the content above the fold.
• Fonts for text LCP. When the headline is the LCP element, use font-display: swap or optional, preload the one or two font files used above the fold, and self-host them to avoid an extra connection.
• Page-hiding test scripts. Some A/B testing tools hide the page until they choose a variant, which delays every paint.

Fix it once, in the template

The fastest way to improve LCP across hundreds of pages is to change the template, not individual posts. One change to the blog post template, such as removing loading="lazy" from the featured image component, applies to every post that uses it.

Good template-level fixes include:

• An image component that always outputs srcset, sizes, width, height and a modern format.
• A rule that the first image in the content area loads eagerly with fetchpriority="high".
• Automatic resizing or upload limits in the CMS, so nobody can publish a 6 MB hero.
• Loading plugin scripts only on the pages that need them.

This is the approach described in template-level fixes: find the issue once, fix it at the source, and check that it landed on every page.

How to check LCP across your whole site

Manually, run Lighthouse on mobile for a sample of pages from each template and note the LCP time, the LCP element and the slowest subpart. A spreadsheet with one row per URL and a column for its template is enough to spot patterns. Then check field data for the same pages in PageSpeed Insights or Search Console, since Core Web Vitals are judged on real users at the 75th percentile, where good means 2.5 seconds or less. The guide to running Lighthouse on every page covers the scripted version.

If you would rather not script it, AiroPages runs Lighthouse on every page of your site on mobile and desktop, groups identical issues by template, and shows CrUX field data next to the lab scores where Google has it. That makes it clear whether a slow LCP is one bad post or a problem in the whole blog template.

What good looks like

A healthy blog or product template has a predictable LCP element that is in the initial HTML, sized for the device, in a modern format, loaded eagerly with high fetch priority, and not waiting on carousels, test scripts or large bundles. Its HTML comes from cache.

Get that right once and every new post and product inherits it. Re-test after each template or plugin change, because one new script can quietly bring the problem back.