A content delivery network can reuse a website response closer to the next visitor instead of fetching every request from the origin. For a static website, the practical challenge is deciding which responses can be reused, for how long, and what should happen when you publish an edit. A cache policy that ignores publishing can leave readers with yesterday's article or a page that requests assets from an incompatible release.
Begin with a simple objective: visitors should receive a consistent page, and the team should know how an approved change reaches them. You do not need an elaborate network design to define that objective. You need an inventory of your files, a distinction between editable documents and versioned assets, and a repeatable way to inspect the deployed result. The Static Global CDN guide introduces the delivery concepts used here.
Understand the copies involved
The origin supplies a response. A shared cache, such as a CDN cache, may store it for reuse across visitors. A browser may also retain its own copy. Freshness determines when a stored response can be reused without checking its validity. These concepts and the relevant HTTP fields are defined in RFC 9111, the HTTP caching standard. A file being static does not determine its cache policy by itself.
Draw the actual request path for your site, including any additional proxy or service worker you operate. Keep the drawing small enough to explain during a deployment problem. If an editor reports old content, identify which copy they are seeing before changing settings. Replacing a file at the origin and removing a CDN copy are different actions; neither action directly deletes a file that a visitor's browser is still entitled to reuse.
Group files by how you change them
Documents with stable URLs
Your homepage and articles normally keep the same URLs when their text changes. Give these documents a deliberate freshness policy based on how quickly corrections need to appear. A site that publishes event instructions has different tolerance for old information than an archive of finished essays. Choose that tolerance with the editor, then configure and test it. Avoid giving editable HTML an extremely long freshness lifetime simply because every page is generated in advance.
Assets with versioned filenames
Stylesheets, scripts, fonts, and images can use filenames that change when their contents change. A release might reference a new stylesheet filename while keeping the previous file available. That makes replacement explicit. Reserve long freshness lifetimes and the immutable directive for resources whose contents will remain unchanged at that URL. Treat the filename as a promise: never quietly overwrite an asset that your policy tells visitors is immutable.
Some files need separate consideration. A downloadable handbook might retain a familiar URL while its contents change; a logo can appear across hundreds of pages. Decide whether readers should always receive the latest file or be able to retrieve a specific edition. Record that decision in the asset naming convention. Consistent conventions are easier to maintain than a collection of exceptions remembered by one developer.
Use cache directives deliberately
max-age sets a freshness lifetime in seconds. s-maxage addresses shared-cache freshness. An unqualified no-cache permits storage but requires successful validation before reuse, whereas no-store instructs caches not to store the response. The similar names conceal different behavior. Choose directives from the required outcome, and verify whether your host or CDN modifies them. Do not assume a dashboard rule and an origin header automatically produce the same result.
For a small public site, a reasonable starting exercise is to require validation for HTML and use versioned assets with longer freshness. This is a design to evaluate, not a universal configuration. Examine origin capacity, the consequences of delayed edits, and the capabilities of your host. Keep the rules in a short deployment document so the next maintainer understands why the documents and assets are treated differently.
Make validation work with the origin
An entity tag, sent in an ETag header, identifies a representation version. A client can send that value in a conditional request, allowing an unchanged representation to be acknowledged without sending the complete body again. This is different from an unconditional download. Check whether your host supplies useful validators and whether those values change when content changes. Do not manufacture a permanent validator for a file that is frequently edited.
Test with a page whose text you control. Capture the first response, request it again, then publish a visible correction and repeat the request. Save the returned headers alongside the release record. The useful evidence is that an unchanged page can be reused appropriately and an edited page is eventually refreshed according to your stated policy. A single fast request cannot establish either behavior.
Review cache keys and URL variants
A cache needs a way to distinguish responses. Query strings and negotiated response variants can affect that distinction, and CDN products expose different configuration choices. Review the rules for your deployed domain rather than relying on a generic expectation. Check whether campaign parameters create unnecessary copies, whether image transformation parameters change the file returned, and whether language variants are kept separate when the response actually differs.
Normalize only when the variants are truly equivalent. Ignoring a parameter that changes content can make the wrong response reusable for another request. Conversely, retaining every irrelevant tracking parameter may complicate the cache without adding value. Test a pair of URLs you expect to match and a pair you expect to differ. Keep this exercise tied to real site behavior instead of adding speculative rules for features you do not operate.
For a useful release exercise, keep one browser tab open on the previous version while another visits the updated site. Change a visible heading and a versioned stylesheet together. Confirm that the new visitor receives a coherent release and that the older page can still retrieve the assets it references. Repeat the exercise after restoring the previous release. This tests compatibility between releases, which a fresh browser screenshot cannot reveal. Record the filenames involved so a failure can be traced to a missing object, an old document, or a delivery rule.
Coordinate caching with release order
Prepare the complete output before publishing. Where an atomic release switch is available, verify what it covers. Otherwise, arrange the process so new assets exist before HTML begins referring to them. Keep assets from the previous release long enough for older documents to remain usable. Deleting every previous file immediately can break pages still held in caches or already open in a browser.
Write a rollback procedure that includes the cache policy. Restoring old HTML may also require restoring referenced assets and refreshing selected CDN entries. Practice this on a harmless content change. Note which steps are automatic and which require an operator. Our static hosting guide helps evaluate release controls, while choosing static and cloud hosting connects those controls to broader operational ownership.
Diagnose results without chasing one number
Use browser network tools and response inspection together. A browser test with its local cache disabled can help isolate that layer, but it does not necessarily bypass a CDN. Look at the response body, cache-control fields, age information when present, and provider-specific status headers. Interpret each header using the provider's documentation. A cache miss can be expected immediately after publishing or when a resource is requested for the first time.
A high hit ratio is useful only in context. It does not prove that content is current, assets are correctly versioned, or the whole page is lightweight. Compare representative pages with and without warm caches, and inspect unusually large transfers. Prioritize a correction if readers receive inconsistent content even when aggregate metrics look healthy. Record the conditions of each measurement so changes can be compared meaningfully.
Conclusion: make freshness part of publishing
A dependable cache strategy connects each resource to its update process. Keep editable documents fresh enough for their purpose, give immutable assets new filenames when they change, and verify the actual deployed responses. Rehearse a release and a rollback while the stakes are low. This turns CDN caching into a manageable publishing responsibility and makes stale-content reports much easier to investigate.
