Can CDN Caching Supercharge Your SSR Pages? A Practical Guide

Qi Yunlei, front‑end engineer at WeDoctor Cloud Services, focuses on Node.js ecosystem and web application solutions.

SSR is a resource‑intensive task; to handle higher traffic and faster service, caching is essential.

Can CDN caching, the primary support for static assets, be applied to SSR pages?

Before we start

Most readers are familiar with CDNs; for those less familiar, we’ll walk through a series of Q&A.

Why integrate a CDN?

Consider a simple request chain to understand CDN positioning.

Before integration:

User → Nginx → App Server

After integration:

User → CDN → Nginx → App Server

Although it seems to add a transmission layer, CDN actually reduces latency and increases bandwidth by routing requests to nearby nodes.

Why enable CDN caching?

Before enabling: Browser → CDN → Nginx → App Server1 → App Server2 → …

After enabling: Browser ↔ CDN

CDN caches resources and can include HTTP response headers, allowing subsequent identical requests to be served directly from cache, saving all downstream processing.

This effectively shortens the request chain.

How to enable CDN caching?

Without building your own CDN, the steps are simple:

Connect your domain to the CDN service and enable caching for specific paths.

Set Cache‑Control response headers on the origin server for finer cache control (optional).

Which services can enable CDN caching?

Most websites can use CDN, but SSR pages must meet certain conditions:

No user state.

Low timeliness requirements; minute‑level latency is acceptable.

How to determine if a request hits the cache?

Different CDN platforms use different methods, but they all rely on response header indicators. For Tencent CDN, the X‑Cache‑Lookup header shows:

Hit From MemCache: cached in CDN node memory.

Hit From Disktank: cached on CDN node disk.

Hit From Upstream: cache miss, origin fetch.

If the header is absent, the page is not configured for CDN caching.

CDN Cache Optimization

Key metrics include cache hit rate. Before setting up CDN caching, consider these points to evaluate suitability.

Extend cache duration

Increasing Cache‑Control max‑age is the most effective way; longer duration means fewer expirations and higher hit rates, even for low‑traffic pages.

Note that Cache‑Control only sets an upper limit; CDN may still evict low‑traffic resources early.

Ignore URL parameters

CDN treats different query strings as separate resources, which can lower hit rates when URLs contain tracking parameters.

CDN offers a “filter parameters” option to ignore the query string, treating all variants as the same resource.

In Tencent CDN, this option applies to the entire domain, not individual URLs, so use with caution.

Proactive caching

Active caching (pre‑warming) can achieve near‑100% hit rates for static files with known paths, but dynamic routes are harder to pre‑warm.

Code Evolution

After discussing CDN cache optimization, we turn to code‑level implementation.

1. Control cache via response headers

Ensure the CDN backend reads the origin’s Cache‑Control header, then set it globally:

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

In SSR, not all pages should be cached; add path checks.

2. Control paths

Use code to selectively cache paths, e.g., only /foo:

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

Be aware of trailing slashes; '/foo' and '/foo/' are distinct.

3. Supplement paths

Handle both variants:

app.use((ctx, next) => {
  if (['/foo', '/foo/'].includes(ctx.path)) {
    ctx.set('Cache-Control', `max-age=300`);
  }
});

4. Ignore degraded pages

If SSR fails and a fallback page is served, avoid caching it:

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

5. Cookie and state management

Cacheable responses must not set Set‑Cookie, otherwise all users share the same cookie.

Solutions: avoid setting cookies on cacheable pages or strip the header in the proxy (CDN may not support this).

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

Be careful with middleware order; some plugins may add cookies later.

6. Custom cache paths

Complex rules may require per‑page configuration, e.g., cache /foo/:id but not /foo/bar.

Note: CDN backend may only support a single /foo/ prefix, so set a default no‑cache rule first.

For varied durations, a configuration table is needed, but this increases maintenance complexity.

7. Cache invalidation

Invalidating CDN cache can temporarily increase load and cost, yet it’s sometimes necessary to publish updates.

Because CDN cache is opaque, a dedicated refresh service can help, though real‑time invalidation is limited.

For frequently changing pages, consider enabling CDN cache only after they stabilize.

Conclusion

CDN caching is a powerful tool that can offload almost all requests from the origin in high‑traffic scenarios, providing strong scalability.

Whether SSR applications should use CDN caching depends on factors such as path control, fallback handling, state management, and cache invalidation.

Path control

Page degradation

State governance

Cache invalidation

Ultimately, the decision rests with you.

In practice, only a few SSR page scenarios, like portal homepages, truly benefit from CDN caching.

Most business pages with low traffic and dispersed paths can rely on dynamic CDN acceleration and static file caching.