Understanding Browser Caching and HTTP Headers with VergeCloud

Browser caching involves storing certain website resources on a user's browser, so they don't need to be downloaded every time they visit. Resources are stored in the browser's local cache for a specified duration, after which they must be re-downloaded based on the caching policy set by the server.

HTTP headers facilitate the exchange of caching policies, dictating how resources are cached either by the browser or by CDN edge servers. These headers determine whether resources should be re-downloaded after expiration.

Using ETag Headers to Validate Cached Responses

ETags are validation tokens sent by the server, allowing the browser to check if the cached resource needs to be re-downloaded. For example, a resource cached for 60 seconds will prompt the browser to request a fresh version from the server after that time. However, if the resource hasn’t changed, ETags allow the server to send a "304 Not Modified" response, signaling the browser to use the cached resource without re-downloading it.

This automatic process saves bandwidth and reduces latency. Developers must ensure the server supports ETags, which VergeCloud edge servers fully support.

Expire Header

The Expire header defines a specific expiration date and time for resources. While it’s now less commonly used due to its limited flexibility, some systems still rely on it for resource expiration.

Cache-Control Header

The Cache-Control header is the most important for configuring caching policies. It’s used to specify how and where resources can be cached, their expiration time, and revalidation conditions. Multiple commands can be used within the Cache-Control header, including:

• no-cache: Forces revalidation before using a cached resource.
• no-store: Prevents caching altogether, ensuring resources are fetched from the server every time.
• public: Allows caching by both browsers and CDN edge servers.
• private: Restricts caching to the browser, not CDN edge servers.
• max-age: Defines the cache duration in seconds (e.g., max-age=60 for 60 seconds).
• s-maxage: Overrides max-age for CDN edge servers, but not browsers.
• must-revalidate: Requires validation with the server before using expired resources.
• immutable: Indicates a resource doesn’t change, removing the need for revalidation until the cache expires.

Examples of Cache-Control Settings

• Static resource caching: Cache-Control: public, max-age=86400
• Prevent caching: Cache-Control: no-store
• Caching in the browser but not CDN: Cache-Control: private, max-age=3600
• Revalidation in both browser and CDN: Cache-Control: public, no-cache
• Cache in CDN edge servers with revalidation: Cache-Control: public, s-maxage=0

Implementing Cache-Control

Cache-Control headers can be set directly on the server or through code. For example:

• Apache: Header set Cache-Control "max-age=84600, public"
• Nginx: location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { add_header Cache-Control "public, no-transform"; }
• PHP: header('Cache-Control: max-age=84600');

VergeCloud’s Caching Policies

Request Phase

When a user makes a request, VergeCloud first checks its edge servers for the requested resource. If the resource is cached and valid, it is served directly from the edge server. If it’s expired, VergeCloud will revalidate it with the origin server before responding.

Response Phase

If the resource is cacheable, VergeCloud edge servers will serve it to the user. If it’s not cached, VergeCloud fetches it from the origin server and caches it for future requests.

Configuring Browser Cache Settings in VergeCloud Panel

To configure browser caching settings for your website’s resources, navigate to the VergeCloud panel. Select “Caching settings,” then “Advanced Settings,” and enable the “Cache Information in Browser” option. This will ensure that resources are cached in the user’s browser, but note that users will be responsible for clearing their cache.