Overview
A CDN adds a delivery layer between visitors and the origin. It can reuse responses when policy allows, but cache correctness depends on both the content and its configuration.
Cache hits and origin requests
An edge can return a reusable cached response. A missing, expired or validation-dependent response may require contacting the origin. Origin latency still matters even when a CDN is in place.
Cache keys define which requests share a response
Identical paths do not necessarily produce identical responses. Query parameters, headers or identity may change the result, so define the relevant cache-key inputs and exclude private responses.
- Versioned scripts, styles and images suit deliberate long-lived cache policies
- Order, account and payment responses require user isolation
- Ignore a query parameter only after checking whether it changes the response
Updating content requires a cache strategy
Use new filenames, versioned paths or invalidation to update content. Coordinate HTML references with asset versions so a release does not mix incompatible files.
Measure the effect on your application
Review request counts, hit ratios, origin transfer, status codes and actual user experience together. A high hit ratio alone does not establish that login, payments or downloads work correctly.