Understanding X Cache and X Time Headers in VergeCloud CDN Responses

VergeCloud’s X-Cache and X-Time Headers Explained

When VergeCloud CDN is enabled for a website, the platform automatically adds certain response headers that help developers and administrators understand how content is delivered to users. Two important headers that appear in these responses are the X Cache header and the X Time header.

These headers provide insight into whether the requested content was served from the VergeCloud edge network or retrieved from the origin server. They also indicate how long it took to process the request. By examining these values, website owners and engineers can quickly identify caching behavior and performance characteristics of their applications.

This article explains what these headers mean, how to interpret them correctly, and how they can be used to optimize content delivery.

Why CDN Response Headers Matter

Content Delivery Networks improve website performance by caching static and sometimes dynamic content closer to end users. Instead of every request reaching the origin server, cached responses are served from geographically distributed edge servers.

However, troubleshooting CDN behavior requires visibility into how requests are handled internally. Response headers provide this visibility. They reveal whether the request was served from cache, fetched from the origin server, or intentionally bypassed from caching.

The X Cache and X Time headers make it easier to understand how VergeCloud handles each request and how efficiently content is delivered.

What the X Cache Header Indicates

The X Cache header shows how the CDN handled a specific request. It reflects the caching status of the requested content at the time the response was generated.

The header can return several values.

MISS

A value of MISS indicates that the requested content was not available in VergeCloud’s edge cache at the time of the request.

This situation usually occurs when a user requests a resource for the first time from a particular edge location. Since the content does not yet exist in the cache, VergeCloud retrieves it directly from the origin server. Once the response is received, the content may be stored in the edge cache depending on the configured caching rules.

Example
X Cache: MISS

In practical terms, a MISS simply means the CDN needed to fetch the resource from the origin before delivering it to the user.
After this first request, the same resource may be served directly from the cache if it is eligible for caching

HIT

A value of HIT indicates that the requested resource was already stored in VergeCloud’s cache.

When a HIT occurs, the CDN serves the cached version of the content directly from the nearest edge server without contacting the origin server. This significantly reduces latency and improves overall website performance.

Example
X Cache: HIT

Cache hits are desirable because they reduce the load on the origin infrastructure while improving response times for users.
A high percentage of cache hits generally indicates an efficient caching configuration.

BYPASS

A value of BYPASS means that VergeCloud intentionally did not cache the requested content and instead forwarded the request directly to the origin server.

Example
X Cache: BYPASS

There are several reasons why a request might bypass the cache.
  1. Dynamic content that changes frequently
  2. Cache control headers from the origin that disable caching
  3. Authentication based responses
  4. Specific CDN configuration rules that prevent caching
When BYPASS occurs consistently for content that should be cached, administrators can adjust caching policies through the VergeCloud dashboard.

Within the VergeCloud panel, page behavior can be modified through the Special Rules section. These rules allow administrators to control caching policies for specific URLs, file types, or request conditions.

Understanding the X Time Header

The X Time header represents the time taken to generate the response.

This value helps administrators understand how long a request took to process. It also reveals whether the response time came from the origin infrastructure or the VergeCloud edge network.

Example
X Time: 0.123

The interpretation of this value depends on the X Cache result.

Response Time When X Cache Shows MISS or BYPASS

When the X Cache header shows MISS or BYPASS, the X Time value reflects the response time between VergeCloud and the origin server.

In this situation the request flow is as follows.
  1. User sends request to VergeCloud edge server
  2. Edge server forwards the request to the origin server
  3. Origin server processes the request and returns the response
  4. VergeCloud delivers the response to the user
Because the origin server is involved, the response time may be higher depending on backend performance and geographic distance.

Response Time When X Cache Shows HIT

When the X Cache header shows HIT, the X Time value represents the response time between VergeCloud’s edge server and the end user.

In this scenario the request does not reach the origin server at all. The cached resource is served directly from the CDN edge location closest to the user.
This typically results in much faster response times.

The request flow looks like this.
  1. User sends request to VergeCloud edge server
  2. Edge server retrieves cached content locally
  3. Response is delivered directly to the user

Since the request stays within the CDN network, latency is minimized.

How to Check X Cache and X Time Headers

These headers can be inspected using browser developer tools or command line utilities.
Using a command line tool such as curl can quickly reveal CDN behavior.

Example request
curl -I https://example.com

The response headers will include values similar to the following.
X Cache: HIT
X Time: 0.045

This indicates that the resource was served directly from the CDN cache and delivered quickly.

Improving Cache Performance in VergeCloud

Monitoring X Cache values helps administrators identify opportunities to improve caching efficiency.

If many responses show MISS or BYPASS, it may indicate that caching policies need adjustment.

Some common optimization techniques include
  1. Configuring appropriate cache control headers at the origin
  2. Using CDN page rules to cache static content
  3. Allowing caching for images stylesheets scripts and media assets
  4. Avoiding unnecessary no cache directives for static files
Optimizing caching rules can significantly increase the number of HIT responses, which improves performance and reduces origin server load.

Conclusion

The X Cache and X Time headers provide valuable insight into how VergeCloud delivers content. These headers allow developers and administrators to quickly determine whether resources are served from cache or retrieved from the origin server.

Understanding these values is essential for troubleshooting CDN behavior, optimizing performance, and ensuring efficient resource delivery.

By regularly reviewing these headers and adjusting caching policies when necessary, organizations can maximize the benefits of the VergeCloud CDN network while providing faster and more reliable experiences for users worldwide.
    • Related Articles

    • Understanding VergeCloud CDN Headers

      Intoduction When a website utilizes VergeCloud CDN for performance enhancement and security, visitor requests are directed to VergeCloud’s CDN servers instead of directly reaching the website's main server. In return, the CDN edge server sends ...
    • Understanding Browser Caching and HTTP Cache Headers with VergeCloud

      Website performance plays a critical role in user experience, SEO rankings, and bandwidth efficiency. One of the most effective ways to improve performance is through browser caching. Browser caching allows frequently used website resources to be ...
    • What is the Cache-Control Header?

      The Cache Control header is one of the most important HTTP response headers used to manage how web content is cached and delivered. It defines how browsers, intermediate proxies, and content delivery networks should store and reuse resources. Proper ...
    • Time to Live (TTL) and DNS Record Configuration in VergeCloud User Panel

      Time to Live (TTL) Time to Live (TTL) is a fundamental parameter in the Domain Name System (DNS) that specifies the duration (in seconds) that a DNS record is allowed to be cached by a recursive resolver. Essentially, TTL determines how long DNS ...
    • Understanding VergeCloud’s DDoS Challenge Modes

      Distributed Denial of Service attacks are one of the most common threats faced by modern websites and online services. Attackers attempt to overwhelm servers with massive volumes of traffic or exploit application behavior to exhaust resources. If the ...