Caching overview

A cacheable response is an HTTP response that Cloud CDN can store and quickly retrieve, thus allowing for faster load times. Not all HTTP responses are cacheable. Cloud CDN uses HTTP response headers that your origin server sends to determine how to cache content at the edge. You can use standard Cache-Control headers to manage caching universally, or use targeted CDN-Cache-Control headers to apply specific caching rules to Cloud CDN without affecting how end-user browsers cache your content.

Cache modes

With cache modes, you can control the factors that determine whether Cloud CDN caches your content.

Cloud CDN offers three cache modes, which define how responses are cached, whether Cloud CDN respects cache directives sent by the origin, and how cache TTLs are applied.

The available cache modes are shown in the following table:

Cache mode Behavior

Cache mode	Behavior
`CACHE_ALL_STATIC`	Automatically caches successful responses with static content that isn't otherwise non-cacheable. Origin responses that set valid caching directives are also cached. This behavior is the default for Cloud CDN-enabled backends created by using the Google Cloud CLI or the REST API.
`USE_ORIGIN_HEADERS`	Requires successful origin responses to set valid cache directives and valid caching headers. Successful responses without these directives are forwarded from the origin.
`FORCE_CACHE_ALL`	Unconditionally caches successful responses, overriding any cache directives set by the origin. This mode might not be appropriate if the backend serves private, per-user (user identifiable) content, such as dynamic HTML or API responses. Note: When private bucket access is enabled on a bucket, you must set the `FORCE_CACHE_ALL` cache mode to cache private content from that bucket.

CACHE_ALL_STATIC

Automatically caches successful responses with static content that isn't otherwise non-cacheable. Origin responses that set valid caching directives are also cached.

This behavior is the default for Cloud CDN-enabled backends created by using the Google Cloud CLI or the REST API.

USE_ORIGIN_HEADERS Requires successful origin responses to set valid cache directives and valid caching headers. Successful responses without these directives are forwarded from the origin.

FORCE_CACHE_ALL

Unconditionally caches successful responses, overriding any cache directives set by the origin. This mode might not be appropriate if the backend serves private, per-user (user identifiable) content, such as dynamic HTML or API responses.

Note: When private bucket access is enabled on a bucket, you must set the FORCE_CACHE_ALL cache mode to cache private content from that bucket.

Error responses may be cached even in the absence of valid cache directives.

Before you set the cache mode to FORCE_CACHE_ALL, consider the following behaviors:

For signed URLs or signed cookies, FORCE_CACHE_ALL overrides the maximum age specified through the Cache entry maximum age setting in the Google Cloud console or the gcloud --signed-url-cache-max-age option.
FORCE_CACHE_ALL changes the time to live (TTL) of any previously cached content. This change can cause some entries that were previously considered fresh (due to having longer TTLs from origin headers) to be considered stale, and it can cause some entries that were previously considered stale to be considered fresh.
FORCE_CACHE_ALL overrides cache directives (Cache-Control and Expires) but does not override other origin response headers. In particular, a Vary header might suppress caching even if the cache mode is FORCE_CACHE_ALL. For more information, see Vary headers.

For setup instructions, see Setting the cache mode.

Static content

Static content is content that is always the same, even when accessed by different users. The CSS that you use to style your site, JavaScript to provide interactivity, video, and image content typically don't change for each user for a given URL (cache key), and thus benefit from being cached across Cloud CDN's global edge network.

When you set the cache mode to CACHE_ALL_STATIC, and a response does not have explicit caching directives in Cache-Control or Expires headers, Cloud CDN automatically caches that response for the following:

Web Assets, including CSS (text/css), JavaScript (application/javascript) and all web fonts, including WOFF2 (font/woff2)
Images, including JPEG (image/jpg) and PNG (image/png)
Videos, including H.264, H.265, and MP4 (video/mp4)
Audio files, including MP3 (audio/mpeg) and MP4 (audio/mp4)
Formatted documents, including PDF (application/pdf)

The following table provides a summary.

Category	MIME types
Web assets	`text/css text/ecmascript text/javascript application/javascript`
Fonts	Any `Content-Type` matching `font/*`
Images	Any `Content-Type` matching `image/*`
Videos	Any `Content-Type` matching `video/*`
Audio	Any `Content-Type` matching `audio/*`
Formatted document types	`application/pdf` and `application/postscript`

Cloud CDN inspects the Content-Type HTTP response header, which reflects the MIME type of the content being served.

Note the following:

Your origin's web server software must set the Content-Type for each response. Many web servers automatically set the Content-Type header, including NGINX, Varnish, and Apache.
Cloud Storage sets the Content-Type header automatically when you use the Google Cloud console or the Google Cloud CLI to upload content.
Cloud Storage always provides a Cache-Control header to Cloud CDN. If no value is explicitly chosen, it sends a default value. As a result, all successful Cloud Storage responses are cached according to Cloud Storage default values, unless you explicitly adjust the cache control metadata for objects in Cloud Storage or use FORCE_CACHE_ALL mode to override the values sent by Cloud Storage.
If you want to cache text/html and application/json content types, you must set explicit Cache-Control headers in the response, being careful not to accidentally cache one user's data and serve it to all users.

If a response is cacheable based on its MIME type but has a Cache-Control response header of private or no-store, or a Set-Cookie header, it isn't cached. To learn more, see cacheability rules.

Other content types, such as HTML (text/html) and JSON (application/json), are not cached by default for successful responses. These types of responses are typically dynamic (per user). Examples include shopping carts, product pages with user personalization, and authenticated API responses. Negative caching, if enabled, can still cause them to be cached for certain status codes, however.

Cloud CDN doesn't use file extensions in the URL path to determine whether a response is cacheable because many valid cacheable responses aren't reflected in URLs.

Cache policy configuration methods

Depending on how much control you need over caching behavior, you can configure caching behavior for Cloud CDN at the backend service, backend bucket, or at a more granular level in URL maps.

Backend service or backend bucket cache policy

Configure a cache policy on a backend service or backend bucket to apply a single caching policy to all requests that are routed to that backend.

Cache policies in URL maps

You can configure Cloud CDN cache policies at various levels of the URL map. This provides granular control over caching policies based on criteria like hostname, URL path, HTTP headers, and query parameters for specific routes.

Setting cache policies at different levels of the URL map, such as root, path matchers, path rules, and route rules, gives you granular control over caching different types of content served by the same backend.

For example, you can configure path rules to:

Cache static images in the /images/* path for 24 hours.
Cache HTML pages in the /pages/* path for 5 minutes.

You can configure cache policies in URL maps when:

a single backend serves different types of content
different paths require different caching behavior
you want to enable caching for specific routes only

For details on how to configure cache policies in URL map, see Configure a Cloud CDN cache policy.

Default values for caching

For caching parameters, Cloud CDN uses the following default values:

Parameter	Default value	Description
Cache mode	`CACHE_ALL_STATIC`	Automatically caches successful responses for common static content types.
Client TTL	`3600s`	Sets a 1-hour `max-age` for the client's browser cache.
Default TTL	`3600s`	Sets a 1-hour cache duration if the origin provides no headers.
Include Host	`true`	The request host is included in the cache key.
Include Protocol	`true`	HTTP and HTTPS requests are cached as separate objects.
Include Query String	`true`	The entire query string is part of the cache key.
Max TTL	`86400s`	The absolute maximum time (24 hours) an object remains in the cache.
Negative Caching	`false`	Error responses, such as, 404s are not cached by default.
Serve While Stale	`86400s`	Serves stale content for up to 24 hours if the origin is unreachable.

GKE controller feature support

The following table compares the availability of specific Cloud CDN features when managed through the GKE Ingress controller versus the GKE Gateway controller.

Feature	GKE ingress through backend configuration	GKE gateway using `GCPHTTPFilter`
Basic Caching (Modes/TTLs)
Cache Key Customization
Negative Caching
Serve While Stale
Dynamic Compression
Signed URLs & Cookies
Request Coalescing

Cacheable content

Cloud CDN caches responses that meet all of the requirements in this section. Some of these requirements are specified by RFC 7234, and others are specific to Cloud CDN.

Cloud CDN may periodically change the exact set of conditions under which it caches content. If you want to explicitly prevent Cloud CDN from caching your content, follow the guidelines in RFC 7234 to determine how to specify a guaranteed-uncacheable response. See also the non-cacheable content based on origin headers section.

Cloud CDN stores responses in cache if all of the following are true.

Attribute	Requirement
Served by	Backend service, backend bucket, or an external backend with Cloud CDN enabled
In response to	`GET` request
Status code	`200`, `203`, `204`, `206`, `300`, `301`, `302`, `307`, `308`, `404`, `405`, `410`, `421`, `451`, or `501`.
Freshness	The response has a `Cache-Control` header with a `max-age` or `s-maxage` directive, or an `Expires` header with a timestamp in the future. For cacheable responses without an age (for example, with `no-cache`), the `public` directive must be explicitly provided. With the `CACHE_ALL_STATIC` cache mode, if no freshness directives are present, a successful response with static content type is still eligible for caching. The `FORCE_CACHE_ALL` cache mode unconditionally caches all successful responses from the origin, regardless of origin-set cache directives. This setting can lead to the unintentional caching of private or per-user content. You must use `FORCE_CACHE_ALL` for backends that serve public, static content or for Cloud Storage buckets with objects intended for broad public access. Note: When private bucket access is enabled for Cloud Storage buckets, `FORCE_CACHE_ALL` is required to cache content from those buckets. If negative caching is enabled and the status code matches one for which negative caching specifies a TTL, the response is eligible for caching, even without explicit freshness directives.
Content	For HTTP/1 origins, the response must contain a valid `Content-Length`, `Content-Range`, or `Transfer-Encoding: chunked` header. For origins that use more advanced HTTP protocol versions (HTTP/2 and later), the response need not have such headers.
Size	Less than or equal to the maximum size. For responses with sizes between 10 MiB and 100 GiB, see the additional cacheability constraints described in byte range requests.

For Cloud Storage backend buckets, follow these additional suggestions:

Make your bucket publicly readable. This is the approach that we recommend for public content. With this setting, anyone on the internet can view and list your objects and their metadata, excluding ACLs. The recommended practice is to dedicate specific buckets for public objects.
Use managed folders to make a portion of your bucket publicly readable.
Make individual objects publicly readable. We don't recommend this approach, because it uses a legacy, Cloud Storage-specific permissioning system.
Don't store the object in a bucket that has Requester Pays enabled or resides within a Virtual Private Cloud service perimeter.
Don't encrypt the object by using customer-managed encryption keys or customer-supplied encryption keys.

By default, when an object is public and doesn't specify Cache-Control metadata, Cloud Storage assigns a Cache-Control: public, max-age=3600 header to the object. You can set different values by using Cache-Control metadata.

For an example that shows how to configure an external Application Load Balancer with a backend bucket, see Setting up Cloud CDN with a backend bucket.

Maximum size

Cloud CDN enforces a maximum size for each response. Any response with a body larger than the maximum size is not cached but is still delivered to the client.

The maximum size varies depending on whether the origin server supports byte range requests.

Origin server supports byte range requests	Origin server does not support byte range requests
100 GiB (107,374,182,400 bytes)	10 MiB (10,485,760 bytes)

Nearly all modern web servers (including NGINX, Apache, and Varnish) support byte range requests.

Non-cacheable content based on origin headers

There are checks that block caching of responses. Cloud CDN may periodically change the exact set of conditions under which it caches content, so if you want to explicitly prevent Cloud CDN from caching your content, follow the guidelines in the standard (RFC 7234) to determine how to specify a guaranteed-uncacheable response.

Cloud CDN doesn't cache a response if it does not meet the requirements for Cacheable content, or if any of the following is true.

Attribute	Requirement
Served by	Backend service or external backend that doesn't have Cloud CDN enabled
Cookie	Has a `Set-Cookie` header
`Vary` header	Has a value other than `Accept`, `Accept-Encoding`, `Access-Control-Request-Headers`, `Access-Control-Request-Method`, `Available-Dictionary`, `Origin`, `Sec-Fetch-Dest`, `Sec-Fetch-Mode`, `Sec-Fetch-Site`, `X-Goog-Allowed-Resources`, `X-Origin`, or one of the headers that are configured to be part of the cache key settings.
Response directive	Response has a `Cache-Control` header with the `no-store` or `private` directive (unless using the `FORCE_CACHE_ALL` cache mode, in which case the `Cache-Control` header is ignored)
Request directive	Request has a `Cache-Control: no-store` directive
Request authorization	Request has an `Authorization` header, unless overridden by the response Cache-Control.
Size	Larger than the maximum size

If Cache-Control: no-store or private is present, but the content is still being cached, this is due to one of the following:

URL signing is configured.
The Cloud CDN cache mode is set to force caching of all responses.

Prevent caching

To prevent private information from being cached in Cloud CDN caches, do the following:

Make sure that Cloud CDN cache mode isn't set to the FORCE_CACHE_ALL mode, which unconditionally caches all successful responses.
Include a Cache-Control: private header in responses that shouldn't be stored in Cloud CDN caches, or a Cache-Control: no-store header in responses that shouldn't be stored in any cache, even a web browser's cache.
Don't sign URLs that provide access to private information. When content is accessed by using a signed URL, it is potentially eligible for caching regardless of any Cache-Control directives in the response.
For origin (cache fill) requests that include the Authorization request header, Cloud CDN only caches responses that include the public, must-revalidate, or s-maxage cache control directives when the cache mode is set to USE_ORIGIN_HEADERS or CACHE_ALL_STATIC. This prevents accidentally caching per-user content and content that requires authentication. The FORCE_CACHE_ALL cache mode does not have this restriction.

Custom response headers

With custom response headers, you can specify headers that the classic Application Load Balancer adds to proxied responses. Custom response headers let you reflect the cache status to your clients, client geographic data, and your own static response headers.

For instructions, see Configure custom response headers.

Cache keys

Each cache entry in a Cloud CDN cache is identified by a cache key. When a request comes into the cache, the cache converts the URI of the request into a cache key, and then compares it with keys of cached entries. If it finds a match, the cache returns the object associated with that key.

For backend services, Cloud CDN defaults to using the complete request URI as the cache key. For example, https://example.com/images/cat.jpg is the complete URI for a particular request for the cat.jpg object. This string is used as the default cache key. Only requests with this exact string match. Requests for http://example.com/images/cat.jpg or https://example.com/images/cat.jpg?user=user1 don't match.

For backend buckets, the default is for the cache key to consist of the URI without the protocol or host. By default, only query parameters that are known to Cloud Storage are included as part of the cache key (for example, "generation").

Thus, for a given backend bucket, the following URIs resolve to the same cached object:

http://example.com/images/cat.jpg
https://example.com/images/cat.jpg
https://example.com/images/cat.jpg?user=user1
http://example.com/images/cat.jpg?user=user1
https://example.com/images/cat.jpg?user=user2
https://media.example.com/images/cat.jpg
https://www.example.com/images/cat.jpg

You can change which parts of the URI are used in the cache key. While the filename and path must always be part of the key, you can include or omit any combination of protocol, host, or query string when customizing your cache key. Using cache keys describes how to customize your cache keys.

URI part Customization Example URLs that have the same cache key

Protocol

Omit the protocol from the cache key.

URI part	Customization	Example URLs that have the same cache key
Protocol	Omit the protocol from the cache key.	`https://example.com/images/cat.jpg` `http://example.com/images/cat.jpg`
Host	Omit the host from the cache key.	`https://example.com/images/cat.jpg` `https://example2.com/images/cat.jpg`
Query string	Omit the query string from the cache key. Selectively omit or include portions of the query string.	`https://example.com/images/cat.jpg?user=user1` `https://example.com/images/cat.jpg?user=user2`

https://example.com/images/cat.jpg
http://example.com/images/cat.jpg

Host

Omit the host from the cache key.

https://example.com/images/cat.jpg
https://example2.com/images/cat.jpg

Query string

Omit the query string from the cache key.

Selectively omit or include portions of the query string.

https://example.com/images/cat.jpg?user=user1
https://example.com/images/cat.jpg?user=user2

In addition to including or omitting the entire query string, you can use portions of the query string by using include lists and exclude lists.