Delivering Static Assets with Long Runtimes and Version Parameters
CSS, JavaScript, and media can be cached long-term and immutably if every content change generates a new addressable version.
"Long-term caching of static assets" is discussed here from the perspective of "HTTP and CDN caching." For system administrators and web developers, "unchanging address" and "stale file" are particularly important.
Published: 3 min read · Author: Sebastian Geier
How to combine long cache lifetimes with immediately visible changes to static assets?
CSS, JavaScript, and media are assigned content-related filenames or reliably updated version references. Long cache control lifetimes are then ensured, while HTML remains valid for a shorter time and references the current asset state.
Immutable Address
Test criterion
Immutable Address
The asset content under the same URL never changes retroactively, so a long-stored response always refers to the same file.
Test criterion
Reliable Version
Every content change automatically generates a new reference value without requiring manual updates from editors or developers.
Current Reference After release, the HTML and manifest only point to existing new assets.
Case Check: "Stale File"
A CSS change generates a new hash filename. The new HTML references this new filename, while the previous asset remains available for cached HTML pages. A rollback reactivates the old reference without clearing the cache.
Current Reference
Control signal
Signal 1
Asset responses with long runtimes but variable content at the same URL.
Control signal
Signal 2
404 responses to versioned assets after release or rollback.
Reliable Version
Switch the asset pipeline to static filenames or content versions.
Reduce HTML runtime and preserve old assets via the transition window.
Test releases, rollbacks, and old HTML responses against existing references.
Stale file
Stale file The same URL delivers new content that browsers don't retrieve for a long time.
Missing file – An old HTML response references an asset deleted during deployment and therefore cannot fully render its interface.
Manual parameter – A change forgets its version number and remains invisible until the cache runtime or manual intervention overrides the old version.
Questions that remain after "Long-term caching of static assets"
A relevant follow-up question answered Choosing PHP-FPM process models for different load profilesWhen does PHP-FPM use static, dynamic, or on-demand for the actual load profile?
A second link for "Long-term caching of static assets" leads to Define cache runtimes based on file type and change risk.This article remains focused on the question "How do you determine cache runtimes based on file type and change risk?"
If you want to practically implement "Long-term caching of static assets," you can refer to Robust Website Systems This article focuses on "HTTP and CDN caching" and "Immutable addresses."
Conclusion: Long-term caching of static assets
Long runtimes require immutable addresses. Versioning shifts the focus from deletion to unique references.
Sources and Further Information
The following sources document the technical and methodological guidelines used for "Long-term caching of static assets."
RFC 9110: HTTP SemanticsThe standard provides the semantics for methods, status codes, fields, validators, variants, and intermediaries.
RFC 9111: HTTP CachingThe Internet standard defines storage, freshness, revalidation, directives, and security requirements for HTTP caches.
Key Thesis
Assets are assigned a content-related filename or a reliably updated version reference and long-term cache control. HTML has a shorter lifespan and points to the new asset address with each release.
What This Is Not About
A long cache duration becomes unreliable if the same asset address later delivers different content.
What it's about
Immutable, versioned addresses can be stored for extended periods; HTML points to the new version with each change.
Hosting, servers, CDN & caching
Plan DNS changes during migrations without unnecessary downtime.
"Long-term caching of static assets" includes, as a separate check, the question: How are DNS changes planned if cached responses are not immediately deleted?
Hosting, servers, CDN & caching
Performing server migrations with a reproducible checklist
Adds a separate decision to "Long-term caching of static assets": Which checklist ensures that a server migration is reproducible and reversible?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Immutable address: Path to testing
A release is checked for asset names, HTML runtime, and the retention of old files. A lack of immutability is the first point of correction.