Boost Your Page Speed: Practical LCP Optimization Techniques for Faster Load Times

Background

In real projects, testers or business colleagues often report long white‑screen times or slow page rendering, while overall project scores appear normal. Checking the LCP metric of the affected pages can reveal low scores, prompting a performance optimization investigation.

What is LCP

Largest Contentful Paint (LCP) is a core Web Vitals metric that measures the time when the largest visible content element (image or text block) is rendered, reflecting perceived loading speed. A good user experience aims for at least 75 % of pages to have LCP ≤ 2.5 s.

It reports the render time of the biggest visible image or text block relative to the first navigation, approximating visual completeness.

How to Measure LCP

A reliable measurement tool is essential. In production you can use the PerformanceObserver API or the web‑vitals library to collect real‑user LCP data.

Production Environment

Example using PerformanceObserver:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Example using web‑vitals:

import { onLCP } from 'web-vitals';
onLCP(console.log);

Tools like PageSpeed Insights or WebPageTest can simulate devices and networks for single‑page analysis, while web‑vitals enables collection of real‑user metrics for project‑wide optimization.

Development Environment

During development, Chrome DevTools Performance or Lighthouse can analyze page load details. Lighthouse often shows higher LCP because it throttles network and CPU by default.

Reference: https://stackoverflow.com/questions/64791933/lcp-time-between-lighthouse-and-performance-google-chrome

Case Study: Optimization Practice

We examined a client‑rendered project where LCP bottleneck was in the Load Delay stage. Network analysis identified four phases: A (HTML 850 ms), B (JS & CSS 1300 ms), C (API 950 ms), D (LCP resource 100 ms). The LCP image took 3.38 s; the goal was ≤ 2.5 s.

Since HTML loading is out of scope, we focused on B and C stages, which correspond to Load Delay in Lighthouse.

The project uses the Umi framework. After HTML load, JS and CSS loading lasted about 1.3 s. Two approaches were tried: reducing bundle size (splitting or compression) and optimizing the network path for the LCP image.

Umi can externalize libraries to load from CDN and preload critical CSS/JS.

{
  externals: {
    react: 'window.React',
  },
  scripts: [
    'https://static.xxx.cn/libs/react/17.0.2/umd/react.production.min.js',
  ],
}

{
  links: [
    { href: '/xxx.css', rel: 'preload' }, // css preload
    { href: 'http://localhost:8000/xxx.js', rel: 'preload', as: 'script' }, // js preload
  ],
}

Compressing large images, serving them via CDN, and applying lazy loading (except for the LCP image) reduced the B stage from ~1300 ms to ~650 ms.

The C stage originally involved serial API requests, adding about 1 s before the LCP image could load. Parallelizing independent requests cut the C stage to ~400 ms, bringing overall LCP to 1.78 s.

Further gains can be achieved by preloading the LCP image or, in server‑side rendering scenarios, moving the LCP resource to the A stage.

How to Make Your Element the LCP Resource

The most impactful factor is the Load Delay stage, where the LCP image often depends on business API responses. Ideally, the LCP element should load early, independent of network‑bound logic.

Elements that can become LCP include img, video, svg images, background‑image URLs, and block‑level elements containing inline text.

The size is based on the portion visible in the viewport; off‑screen parts are ignored. Reporting occurs from first contentful paint until user interaction.

Element type: img, video, svg image, background‑image, or block‑level text element.

Size determination: visible area within the viewport.

Reporting window: from first contentful paint to first user interaction.

While some suggest using text‑based LCP for speed, the key is to avoid LCP resources that depend on lengthy business logic. Choosing the right element and loading strategy is essential.

Experiments with different image loading methods show minor differences in extreme conditions, but CDN and caching usually dominate performance.

Conclusion

Optimizing LCP can be more challenging than FP, FCP, or FID due to project‑specific factors, but the principles align with overall user‑experience improvements. A practical hands‑on approach yields the best results.

Key Factors

Server response time, render‑blocking JS/CSS, resource load time, client‑side rendering.

Optimization Strategies

Optimize the critical rendering path.

Load and render the largest visible element as early as possible.

Remove unused CSS/JS and reduce bundle size.

Compress and optimize resources (CSS, JS, images).

Adopt PRPL pattern for instant loading.

Consider server‑side rendering.

Pages may not become faster, but you can make users feel faster.

References

[1] Core Web Vitals: https://web.dev/articles/lcp?hl=zh-cn

[2] PageSpeed Insights: https://pagespeed.web.dev/?hl=zh-cn

[3] WebPageTest: https://webpagetest.org/

[4] Image loading experiments: https://csswizardry.com/2022/03/optimising-largest-contentful-paint/