How We Boosted Vue SSR Performance with Multi‑Level Caching and CDN

1. Practice Background

Qi Yunlei, a front‑end engineer at WeDoctor, presents a case study from the "Second Colorful Front‑End Technology Salon" focusing on Vue SSR performance under rapid business growth.

The COVID‑19 pandemic caused a traffic surge, exposing two main challenges: unpredictable traffic spikes and poor latency for nationwide users accessing services hosted in a single data center.

Business Background

WeDoctor provides integrated online and offline medical services. Before 2020, medical traffic was modest, but the pandemic dramatically increased demand.

Technical Background

Server‑Side Rendering (SSR) offers faster First Contentful Paint, better SEO, and reduces client‑side white‑screen time, but it also increases server CPU load, can be hard to scale, and may affect developer experience.

SSR Advantages

Directly rendered pages shorten content delivery time, improve SEO, and combine the benefits of client‑side rendering.

SSR Disadvantages

SSR puts heavy CPU pressure on the server, especially with complex component trees, and can complicate development for teams lacking back‑end expertise.

2. Solution Discussion

The SSR request lifecycle is divided into three phases: request arrival, rendering computation, and response handling. The core performance bottleneck lies in the CPU‑intensive rendering phase.

FCP: First Contentful Paint, TTI: Time to Interactive

Vue 3 can improve rendering speed by 2‑3×, but before its adoption the team explored other optimizations.

3. Conventional Optimizations

Pre‑Render

Key techniques include multi‑level caching (data, component, page), request reuse with keep‑alive HTTP agents, and graceful degradation/circuit‑breaker strategies.

Challenges: page‑level caching can consume large memory; degradation shifts load to the client and may not relieve server pressure if not timed correctly.

Post‑Render

Utilize CDN for static assets and ensure proper gzip compression; misconfiguration can add hundreds of milliseconds to response time.

4. Deep Practices

Network Tuning

Switch from public DNS to direct host IPs, use internal domain names with HTTP, and apply weighted round‑robin load balancing (e.g., Nginx) to distribute traffic and avoid single points of failure.

Extended Multi‑Level Caching

Enable CDN caching for SSR pages when content is not highly dynamic, set appropriate Cache‑Control headers, and manage path‑specific caching via middleware.

app.use((ctx, next) => {
  ctx.set('Cache-Control', `max-age=300`);
});

Handle degradation by disabling cache for degraded pages and removing Set‑Cookie headers to prevent state leakage.

app.use(async (ctx, next) => {
  if (['/foo', '/foo/'].includes(ctx.path)) {
    ctx.set('Cache-Control', `max-age=300`);
  }
  await next();
  if (ctx._degrade) {
    ctx.set('Cache-Control', 'no-cache');
  } else if (['/foo', '/foo/'].includes(ctx.path)) {
    ctx.res.removeHeader('Set-Cookie');
  }
});

Complex cache rules (different TTLs per path) are better expressed in code than in CDN configuration.

Cache Invalidation

Balance between cache freshness and server load; use proactive cache warm‑up and consider disabling CDN cache for frequently changing pages.

Page Staticization

For pages unsuitable for CDN cache, pre‑render them to disk or cloud storage, providing a low‑cost fallback and improving disaster recovery.

5. Summary

The presented optimizations—multi‑level caching, CDN integration, network adjustments, and careful state management—offer a practical roadmap for small‑to‑medium teams handling SSR workloads. However, each technique has trade‑offs, and CDN caching should be applied only when page content is sufficiently stable and cache‑friendly.