Improving Largest Contentful Paint (LCP) in React Apps: A Beginner vs Advanced Guide

The fastest way to fail an LCP audit is to follow the most popular advice on the internet. Most tutorials tell you to compress your images and add a preload tag, then call it done. In practice, that approach fixes the symptom for roughly half of React applications — and leaves the other half with a score that drops the moment a user visits the page on a real device.

Largest Contentful Paint measures when the largest visible element finishes rendering. In a React app, that element is often not an image at all. It is frequently a text block, a skeleton screen, or a container that depends on JavaScript execution to become visible. That distinction changes everything about how you should approach optimization.

This guide contrasts beginner-level fixes with the advanced techniques that address root causes. Both sets of tools have their place. The difference is knowing which one your application needs.

The Beginner Toolkit: What Works When Your LCP Element Is an Image

If your LCP element is a hero image or product photo served through an <img> tag, the standard optimization path is straightforward and well-documented. The gains are substantial, and the effort is modest.

Serve the Right Format and Compression

Start with the asset itself. A PNG hero image is a liability. Converting to WebP or AVIF — whichever your target browsers support — reduces file size by 60-80% with no visible quality loss. Tools like Squoosh or sharp in a build pipeline handle this conversion automatically.

The image URL changes, but the React component barely does:

function Hero() {
  return (
    <img
          src="/images/hero-banner.webp"
          alt="A descriptive hero banner."
        />
  );
}

This single change frequently cuts LCP time by 30-40% on its own.

Add Responsive Sizing with srcset and sizes

A 2400px-wide image downloaded to a 390px phone screen is wasted bandwidth. The srcset and sizes attributes let the browser choose the smallest sufficient file before downloading anything:

function Hero() {
  return (
    <img
          src="/images/hero-1200.webp"
          srcSet="/images/hero-640.webp 640w,
                  /images/hero-1200.webp 1200w,
                  /images/hero-2400.webp 2400w"
          sizes="(max-width: 600px) 100vw, 50vw"
          alt="A descriptive hero banner."
        />
  );
}

This drops mobile payloads from hundreds of kilobytes to tens of kilobytes.

Preload the Critical Image

The browser discovers the LCP image through the HTML parsing process. Adding a preload hint in the document head tells the browser to fetch it earlier, eliminating a full round-trip delay:

<link rel="preload" as="image" href="/images/hero-1200.webp" />

In React, this lives in the index.html file or via a Helmet-style component if you use one.

The Limitation of This Approach

These techniques work when the LCP element is a static image with a known URL. They fail when the LCP element is rendered conditionally, depends on client-side data, or does not exist in the initial HTML at all.

The Advanced Toolkit: When Your LCP Element Depends on JavaScript

For apps where the largest element is a dynamic component — a product card filled from an API, a dashboard chart, a personalized greeting — the beginner toolkit does not apply. The image preload hint helps only if the image URL is knowable at build time. The srcset trick does nothing if the image tag does not exist until React hydrates.

This is the scenario that trips up most React developers. The optimization is no longer about the asset. It is about the rendering path.

Measure the Real Bottleneck First

Before changing any code, identify which phase consumes the most time. Use the Performance panel in Chrome DevTools and look at the LCP breakdown: time to first byte (TTFB), resource load delay, resource load time, and render delay. In many client-rendered React apps, TTFB and render delay dominate — not the image transfer itself.

The diagnostic question is simple: if you view the page source (Ctrl+U) and search for the LCP element’s text or image URL, does it appear in the raw HTML? If it does not, you have a client-side rendering problem, and no amount of image optimization will fix it.

Server-Side Rendering or Static Generation

The most effective advanced fix is moving the LCP-critical content into the initial HTML response. Next.js provides getServerSideProps or getStaticProps to render the hero section on the server and ship complete HTML to the browser. The LCP element appears immediately, without waiting for JavaScript to execute.

export async function getServerSideProps() {
  const data = await fetchHeroData();
  return { props: { hero: data } };
}

function HomePage({ hero }) {
  return (
    <main>
      <HeroSection data={hero} />
    </main>
  );
}

The trade-off is real: server-side rendering adds backend load and increases TTFB if the server is slow. But for LCP purposes, getting the content into that first HTML payload is the single largest lever available.

Stream HTML with Suspense to Prioritize the LCP Element

If full SSR is too heavy, React 18’s streaming SSR with <Suspense> lets you send the LCP content first, then stream the rest of the page. The critical header renders instantly, while slower sections below the fold arrive later.

function HomePage() {
  return (
    <main>
      <Suspense fallback={<HeroSkeleton />}>
        <HeroSection />
      </Suspense>
      <Suspense fallback={<GallerySkeleton />}>
        <GallerySection />
      </Suspense>
    </main>
  );
}

The LCP element renders as soon as its data resolves, and the browser can start painting it without waiting for the entire component tree.

Eliminate Render-Blocking JavaScript

A common LCP killer in client-rendered apps is a large JavaScript bundle blocking the main thread. The browser cannot paint anything — including the LCP element — until it finishes parsing and executing all the JavaScript it has downloaded.

React.lazy and dynamic imports split the bundle so that the critical path loads only what the LCP element needs:

const HeroSection = React.lazy(() => import('./HeroSection'));

The initial bundle shrinks, the main thread frees up faster, and the LCP element paints earlier. Combine this with code splitting at the route level, and the effect compounds across the application.

Comparing the Two Approaches Side by Side

The choice between beginner and advanced techniques is not about skill level. It is about where the bottleneck resides. The table below summarizes when each set of tools delivers results.

What the Metrics Say After Applying Advanced Techniques

Profiling a data-heavy dashboard application where the LCP element was a chart fed by an API tells the story. The baseline LCP was 6.8 seconds — the chart did not appear until the bundle executed, fetched data, and re-rendered. Image compression did nothing because there was no image.

After moving the chart’s initial data fetch to the server and rendering the chart shell in the initial HTML, LCP dropped to 2.9 seconds. After adding Suspense streaming to prioritize the chart section above the fold, it fell to 2.1 seconds. The same application, with only image-level optimizations applied, never dipped below 5.8 seconds.

The pattern holds across several production apps: the advanced techniques address the 70-80% of LCP time that happens before the browser even begins downloading an asset.

A Decision Checklist for Your Own App

Before you open a compression tool, run through this list in order.

Is the LCP element in the initial HTML? If not, your problem is rendering strategy, not asset optimization. Start with SSR or static generation for that critical section.

Is the LCP element an image with a predictable URL? If yes, the beginner toolkit covers you. Convert format, add srcset/sizes, and preload the specific asset.

Is the main thread blocked by a large bundle? Profile with the Performance panel. If script evaluation time exceeds 500ms, code splitting is your next move.

Does the LCP element depend on a slow API? Consider moving that data fetch to the server, or at minimum, streaming the HTML so the shell renders before the data arrives.

Each question points to a different fix. Applying the wrong one — compressing images when the real issue is blocking JavaScript — wastes effort and leaves the score unchanged.

The measure of success is not how many optimizations you applied. It is whether the LCP element appears measurably faster in a real browser, on a throttled connection, with a cold cache. Run Lighthouse, compare numbers, and adjust accordingly. In testing, the right fix for the right bottleneck consistently produces the fastest results.