Edge and CDN: how fast delivery works

How distributed delivery and caching reduce latency — and why not everything should be cached.

When a website serves visitors in different regions, physical distance and network hops can affect response times. CDN (content delivery network) uses distributed points of presence to serve suitable resources closer to users.

What an edge node does

When a static resource is requested, an edge node checks whether it has a fresh cached copy. If it does, it can respond without contacting the origin server. Otherwise it fetches the resource from the origin and, if policy allows, stores it for subsequent requests.

Good candidates for caching

  • Images and fonts with predictable URLs.
  • Versioned JavaScript and CSS assets.
  • Public static documents.

Personalized responses, private data, and pages with dynamic state require special care. Incorrect caching rules can expose stale information or even another user’s data.

How cache lifetime is communicated

One mechanism is the HTTP header Cache-Control. For example, a versioned immutable resource may use a long cache lifetime:

Cache-Control: public, max-age=31536000, immutable
Do not apply this example indiscriminately. Long TTLs are best for files whose URLs change whenever their content changes.

A CDN is not a universal speed boost

Performance depends on asset sizes, caching strategy, distance to the origin, and application behavior. If most requests cannot be cached, the edge layer may offer less benefit than expected.

Takeaway

Effective content delivery combines sensible headers, predictable URLs, and real performance measurements. Start by understanding which data can be cached and how it changes.

← Back to all insights