How We Cut LCP by 73% for a Billion‑User Membership Site

Introduction

In the era of saturated internet traffic, enterprises must balance user retention and acquisition. When promotion, conversion and other factors stay constant, user experience becomes the key driver of growth, especially for a membership system with hundreds of millions of users.

Article Structure

1. Importance of front‑end performance, measurement system, and performance standards for the SF membership.

2. Core part – four categories of optimization strategies, with Section 2.4 focusing on SSR and SPA pre‑rendering.

3. Before‑and‑after performance comparison.

4. Summary emphasizing continuous, iterative optimization.

1.1 Background

Page load time directly impacts user experience, retention and conversion.

75% of users consider crash rate and load time as core factors for app attractiveness.

Pinterest reduced load time by 40% and increased searches and registrations by 15%.

BBC reported a 10% user loss for each additional second of load time.

DoubleClick found that 53% of users abandon a mobile site if load time exceeds 3 seconds.

1.2 Performance Metrics

If something cannot be measured, it cannot be optimized. The front‑end performance metrics follow Google’s Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). LCP is the primary indicator of user retention, measuring the time from navigation start to the rendering of the largest text block or image.

1.3 SF Membership Front‑End Performance Challenges

The SF membership ecosystem hosts over a hundred million users with daily active users exceeding ten million. Such scale makes front‑end performance critical for user experience and business efficiency.

2 Optimization Strategies

Performance can be improved along four dimensions.

2.1 Resource Slimming – Reduce Asset Size

• Image compression using TinyPNG, MozJPEG, Zopfli PNG, achieving 60% size reduction while keeping visual loss under 5%.

• Choose optimal image formats (WebP) and leverage CDN automatic conversion.

• Compress other assets (JS, CSS) and remove unused code.

# webpack configuration for contenthash
module.exports = {
  output: {
    filename: 'js/[name].[contenthash].js',
    assetModuleFilename: 'images/[name].[contenthash][ext]'
  },
  plugins: [new CleanWebpackPlugin()]
};

2.2 Reduce Quantity – Load Less

• Lazy‑load images and modules using IntersectionObserver.

<img data-src="real-image.jpg" src="placeholder.jpg" alt="Lazy Image">
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
});
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

• Use Service Workers for offline caching and long‑term static asset caching with hash‑based filenames.

# nginx long‑term cache
location ~* \.(css|js|json|jpeg|jpg|webp|png|mp3|gif) {
  add_header Cache-Control "max-age=315536000";
}

2.3 Transmission Optimization – Faster Network

• Deploy CDN with intelligent routing (geo‑based DNS).

# smart DNS routing example
geo $nearest_cdn {
  default        oss-cn-shenzhen;
  113.*.*.*     oss-cn-guangzhou;
  61.*.*.*      oss-cn-shanghai;
}

• Upgrade to HTTP/2 or HTTP/3 to benefit from multiplexing, binary framing and QUIC.

# enable HTTP/2 in nginx
server {
  listen 443 http2 ssl;
  ssl_certificate /path/to/cert.pem;
  ssl_certificate_key /path/to/key.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
}

• Use dns‑prefetch to reduce DNS lookup latency.

<link rel="dns-prefetch" href="//a.com">
<link rel="dns-prefetch" href="//b.com">

2.4 Rendering Revolution – Pre‑render & SSR

• Preload critical SPA chunks to enable parallel loading.

<link rel="preload" as="javascript" href="/static/js/react.js">
<link rel="preload" as="javascript" href="/static/js/chunk-a.hash.js">
<link rel="preload" as="javascript" href="/static/js/chunk-b.hash.js">

• Server‑Side Rendering (SSR) delivers fully rendered HTML without waiting for all JS to download, improving LCP for slow networks and devices.

SSR workflow: server renders HTML → client receives ready content → hydration of interactive parts.

// progressive hydration example
const hydrateRoot = createRoot(container, {
  hydrate: true,
  hydrationOptions: {
    onHydrated: () => {
      requestIdleCallback(loadSecondaryModules);
    }
  }
});

• BFF layer can aggregate multiple APIs to reduce request count.

# example API aggregation in BFF
app.get('/api/combined', async (req, res) => {
  const [user, orders] = await Promise.all([
    fetchUser(req.query.id),
    fetchOrders(req.query.id)
  ]);
  res.json({user, orders});
});

Performance Results

# Performance detection result
LCP: 2.1s | CLS: 0.399 | TTI: 2.5s

After two years of iterative optimization:

Member center LCP reduced from 2.5 s to 1.2 s (52% improvement).

Overall site LCP improved by 28%.

Second‑open rate increased from <10% to 51% (400% boost).

SSR LCP 0.766 s vs CSR 1.324 s – a 73% speed gain.

SSR member‑center second‑open rate rose to 80%.

Conclusion

Performance optimization is a continuous, multi‑stage process covering resource slimming, request reduction, network upgrades, and rendering innovations such as pre‑rendering and SSR. By establishing a measurement system, instrumentation, and a systematic toolbox, we built a repeatable methodology that dramatically improves user experience for a billion‑scale membership platform.