Edgio

Cache Management

Managing your caching policy and cached content is critical for achieving optimal website performance.
Key concepts and procedures:

Caching

Caching creates a copy of the requested content within our edge and Origin Shield POPs. This improves your site’s performance by allowing clients to retrieve your content from the POP closest to them instead of your origin servers.

Environments and Caching

Each environment has a separate edge cache. The Caching page’s Preserve cache between deployments option determines whether this edge cache persists between deployments.

Edge and Origin Shield Caching

Edgio may cache your content on our:
  • Edge Points-of-Presence (POP): An edge POP handles receives and responds to requests for your content.
  • Origin Shield POP: An Origin Shield POP improves cache efficiency, reduces the load on your servers, and reduces network bandwidth. If you have assigned at least one Origin Shield POP to your origin configuration, our edge POPs can funnel cache misses through an Origin Shield POP.
There is very little difference in time to first byte (TTFB) for responses served from an edge or Origin Shield POP. In either case, the response is served nearly instantly (typically 25-100ms). Concurrent requests for the same URL on different POPs that result in a cache miss will be coalesced at the Origin Shield POP. An Origin Shield server only submits a single request at a time to your origin servers for each cacheable URL.
Learn more about Origin Shield.

Default Caching Policy

Edgio only caches eligible responses when either of the following conditions are met:
  • An origin server provides cache instructions (aka cache directives).
  • A rule defines a caching policy.
By default, a response is eligible for caching when it satisifes all of the following requirements:
RequirementDescription
HTTP MethodGET
HTTP Status Code200 OK
Number of RequestsVaries by content type.

A POP considers requests for the following content types eligible for caching after a single request:
  • text/html
  • text/css
  • text/xml
  • application/json
  • application/javascript
  • application/xml
It requires 2 requests for all other content types.
Edgio can serve cached content until its time to live (TTL) expires. After which, it will need to revalidate to find out whether the response has changed.
View the request flow for determining whether to serve a response from cache.

Caching a Response

Define a caching policy through:

Cache Directives (Response Headers)

An origin server or the Edgio cloud may include headers in the response that contain cache directives. These cache directives may determine how long our servers will cache that response. By default, our servers honor the following response headers:
  • Cache-Control: private: Prevents our servers from caching the response.
  • Cache-Control: no-store: Prevents our servers from caching the response.
  • Cache-Control: no-cache: Requires our servers or the client to revalidate cached content.
  • Pragma: no-cache: Requires our servers or the client to revalidate cached content.
  • Cache-Control: s-maxage: Determines the requested content’s time-to-live (TTL) on our servers. TTL identifies the amount of time that cached content can be served without revalidation.
  • Cache-Control: max-age: Determines the requested content’s TTL on the user agent and our servers.
  • Expires: Defines an expiration date for the requested content’s TTL. The requested content will be considered stale after the specified date/time.
    If this directive has been assigned an invalid value, including zero, then it will be ignored for the request in question.
Key information:
  • The above directives are ordered according to precedence. Directives that appear higher in the list take precedence over lower ones. In other words, if an asset contains both a Cache-Control and an Expires header, then the Cache-Control header will take precedence.
  • Refer to your web server’s documentation to learn how to define response headers.
  • You may override a web server’s cache policy by creating a rule or route.

Defining a Caching Policy through Rules

Set or override a cache policy by creating a rule that identifies the desired set of requests and the caching policy that will be applied to them.
By default, certain cache directives take precedence over a cache policy defined within a rule. Allow Edgio to override those directives by also enabling the Ignore Origin No Cache feature (ignore_origin_no_cache) for the desired status code (e.g., 200 OK) within that rule.
Commonly used features for defining a caching policy are listed below.
FeatureUsage
Bypass Cache (bypass_cache)Use this feature to disable caching on our network.
Bypass Client Cache (bypass_client_cache)Use this feature to instruct the client to bypass cache.
Ignore Origin No Cache (ignore_origin_no_cache)Use this feature to allow Edgio to override no-cache directives.
Set Client Max-Age (client_max_age)Use this feature to define how long a client must wait before revalidating cached content with our servers.
Set Max-Age (max_age)Use this feature to define how long an edge server must wait before revalidating cached content with the origin.
View all caching-related features.

Defining a Caching Policy through CDN-as-Code

Add the caching feature to your route:
JavaScript
1router.get('/some/path', {
2 caching: {
3 max_age: '86400s',
4 stale_while_revalidate: '3600s',
5 service_worker_max_age: '3600s',
6 bypass_client_cache: true,
7 },
8 headers: {
9 set_response_headers: {
10 'x-sw-cache-control': 'max-age=3600',
11 },
12 },
13});

Cache Key

Our servers use cache keys to determine whether a cached response exists for a specific request. Specifically, they calculate a cache key for each request. They then use this cache key to check for a cached response.
Learn more about cache keys.

Caching Responses for POST and PUT Requests

By default, Edgio only caches responses for GET requests. Cache the response for POST, PUT, or both HTTP methods using either of the following methods:
  • Rules: Create a rule that sets the Enable Caching for Methods feature to POST, PUT, or both HTTP methods.
  • CDN-as-Code:
    JavaScript./routes.js
    1router.match('/some/path', {
    2 caching: {
    3 "enable_caching_for_methods": ["POST", "PUT"],
    4 }
    5});

Caching Private Responses

By default, Edgio does not cache the response when it contains certain cache directives (e.g., Cache-Control: private). Instruct our CDN to ignore these cache directives through either of the following methods:
  • Rules: Create a rule that enables the Ignore Origin No Cache feature.
  • CDN-as-Code:
    JavaScript
    1router.get('/some/path', {
    2 caching: {
    3 ignore_origin_no_cache: [200],
    4 },
    5});

Client Caching

Content can be cached on our network or the client’s machine. Define how long content is cached on a client’s machine through:
A user may clear a web browser’s cache to force the web server to request a new version from our network.

Revalidation

Revalidation is the process through which an edge server checks the origin to find out whether a newer version of the requested cached content exists. If the origin indicates that the requested content has not changed, then our servers will serve cached content to the client and then update its TTL according to the provided cache instructions.
Our servers can only perform a revalidation when the following conditions are true:
  • The requested content is stale.
  • The cached response contains one of the following headers:
    • Last-Modified (preferred)
    • ETag header
    If either response header is not found, then our servers will perform an unconditional GET request to the origin.

Preventing a Response from being Cached

There are certain cases under which you may wish to disable caching. For example, caching should be disabled for requests that typically generate unique responses. You may disable caching for these types of requests using either of the following methods:
  • Rules: Create a rule that enables the Bypass Cache feature for the desired set of traffic.
  • CDN-as-Code:
    JavaScript./routes.js
    1new Router()
    2 .get('/random-numbers', {
    3 caching: {
    4 "bypass_cache": true,
    5 },
    6 })

How do I know if a response was served from the cache?

Responses served from cache contain the x-cache: HIT response header.

Caching During Development

By default, caching is disabled during local development. This configuration prevents stale responses from being served after making changes to your code or upstream APIs. Enable caching during local development by passing the --cache option when running the Edgio CLI in development mode:
Bash
1edgio dev --cache
The cache will automatically be cleared when you make changes to your router.