Manual Browser Refresh Required to Run Latest Code

Manual Browser Refresh Required to Run Latest Code.


Enhance the user experience by improving the server configuration to serve newest build files whenever possible.

Currently, web builds are cached in the disk space or memory, which can have negative implications for the user experience. These cached files are served to the client when the website is accessed, potentially issues like absence of the latest features and functionality, data corruption, and an overall degradation of the user experience because to run new feature, user has to hard refresh the browser. To overcome these challenges and provide an enhanced user experience, it is important to implement mechanisms that guarantee the most recent build whenever a user opens a website.

o ensure that the client always runs with the latest build, we can establish and control the browser’s behavior by implementing mechanisms that verify the availability of the latest build on the server. This can be accomplished by setting up and managing cache-control headers and providing sequential instructions to the browser. It’s important to note that different values exist for request and response cache control.

Browsers cache both the incoming requests and outgoing responses in various storage:

  1. Browser Cache: This directory stores the cached files retrieved from the server in response to previous requests. The browser checks this cache before making a request to the server, serving the cached version if available.
  2. Disk Cache: The disk cache is a storage location on the user’s hard drive where the browser stores frequently accessed files. It allows for faster retrieval of these files, reducing the need to retrieve them from the network.
  3. Memory Cache: The memory cache, as the name suggests, stores cached files in the browser’s memory. This cache is typically faster to access than the disk cache but has limited capacity.

The Cache-Control HTTP header field holds directives (instructions) — in both requests and responses — that control caching in browsers and shared caches (e.g. Proxies, CDNs). Here are the list of important directory that we used to implement the solution.

  1. max-age (cache-Control: max-age=604800)
    The max-age=N response directive indicates that the response remains until N seconds after the response is generated.
    Indicates that caches can store this response and reuse it for subsequent requests

  2. no-cache (Cache-Control: no-cache)
    The no-cache response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.
    If you want caches to always check for content updates while reusing stored content, no-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.
    Note that no-cache does not mean “don’t cache”. no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of “don’t cache” that you want is actually “don’t store”, then no-store is the directive to use.

  3. must-revalidate (Cache-Control: max-age=604800, must-revalidate)
    The must-revalidate response directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse.
    Typically, must-revalidate is used with max-age.
    HTTP allows caches to reuse stale responses when they are disconnected from the origin server. must-revalidate is a way to prevent this from happening - either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated.

  4. no-store (Cache-Control: no-store)
    The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.


We can provide multiple value in cache-control with comma separated. It will helpful in case browser does not support first option then it can fallback to next option.

Steps to Implement:

  1. Required response header:
    2.cache-control: no-cache, no-store, max-age=0, must-revalidate*
  2. To add the following header to the server’s configuration file, whether it’s nginx.conf or an ingress configuration, you can follow these steps:
  3. Locate the server configuration file: Depending on your setup, the server configuration file could be nginx.conf or a specific configuration file for the ingress controller. Determine the appropriate file to edit.
  4. Open the configuration file: Use a text editor or command-line tool to open the server configuration file for editing. For example, you can use the vi or nano command-line editors.
  5. Locate the folder: Look for the folder that corresponds to the specific pod or the top-level server configuration folder that applies to all pods.
  6. Add the header: Inside the server block, add the following line to include the desired header

add_header Cache-Control "no-cache, no-store, max-age=0, must-revalidate" always;

This line adds the Cache-Control header with the specified values, instructing the browser to not cache the resources, set the maximum age to 0, and require revalidation on every request.
5. Save the configuration file: After adding the header, save the changes to the server configuration file.
6. Restart or reload the server:

sudo service nginx reload

Alternatively, you can use restart instead of reload to perform a full server restart.
4. Now, Whenever website launch, It will run with the latest build.