For static resources that don’t change in web pages, we hope the browser won’t request the backend again once it gets them, until these resources are updated. The essence of this requirement is that we need to add version management to frontend resources.
Benefits of frontend caching
- Reduce the number of client requests for resources, thereby improving page load speed
- Reduce server load pressure
It seems everyone benefits. So how to implement frontend resource version management for caching? There are actually many methods.
Cache-Control/Expires, Last-Modified/ETag
After setting Cache-Control/Expires, the browser won’t send requests for resources during normal page visits and will directly read from the browser cache. If the user clicks the “Refresh” button or the cache time expires, the browser will send a request and use Last-Modified/ETag to determine if the content has been updated. If the content hasn’t changed, the server returns a 304 status.
Problem
After a new release, when accessing the page, resources will still be cached. Users need to refresh or re-visit to request the backend for ETag verification.
Version numbers
Adding version numbers makes previous frontend resources invalid with each release, thus requesting new resources. However, this brings problems.
Problems
- Version numbers must be applied to a batch of resources, such as all frontend resources (JS, CSS, IMG) of a project. For example, if an emergency release only changes a CSS style, the release will invalidate all resource caches.
- Version numbers need to be maintained. You have to remember to update the version number for each new release (including minor patches), and the maintenance cost is actually not low.
Hash fingerprints
If the content changes, the fingerprint changes; otherwise, it remains the same. This ensures that only the cache of the changed content file is invalidated.
Pros
- When a specific file is updated, it won’t invalidate other files’ caches like version number management does
- Non-overwriting updates: new versions have different names from old versions, so there’s no conflict. This prevents the problem of new HTML using old JS.
Cons
To add hash fingerprints, you need to add processing steps during the build phase, which will increase the build time. But this overhead shouldn’t be a big problem for build servers or even personal development machines.
Final Thoughts
The above methods represent the development history of frontend resource management in web development. Currently, the relatively optimal solution is hash fingerprinting. So let’s implement it quickly, allowing us to release anytime, 7x24.
