This page discusses the Cloud Storage built-in cache. Cloud Storage is also compatible with third-party CDNs.
Overview
When a Cloud Storage object is cached, copies of the object data are stored in a Google or internet cache so your object can be served faster in future requests. While caching can improve performance, you also risk serving stale content if you make updates to your object but a cache continues to serve the earlier version of the object.
Built-in caching for Cloud Storage
Cloud Storage can behave like a Content Delivery Network (CDN) with no
work on your part, because an object's data is cached in the
Cloud Storage network if its Cache-Control
metadata is set to
allow caching and the following criteria are met:
- The object is publicly accessible.
- The object is not stored in a bucket that has Requester Pays enabled and does not reside within a Virtual Private Cloud service perimeter.
- The object is not encrypted using customer-managed encryption keys or customer-supplied encryption keys.
Cloud Storage respects standard values for
Cache-Control
, such as the following:
public
: the object can be cached.private
: the object won't be cached by Cloud Storage, but can be cached in a requester's local cache.no-cache
: the object can be cached, but cannot be used to satisfy future requests unless first validated by Cloud Storage.no-store
: the object can't be cached.max-age=TIME_IN_SECONDS
: the length of time an object can be cached before it's considered stale. You can setmax-age
to any length of time. Stale objects are not served from caches, except in special circumstances.
To set the Cache-Control
metadata for an object, see
Editing object metadata.
Built-in caching behavior with IAM Deny policies
When there's an organization-level IAM Deny policy that
restricts read access for an object from the principal identifier allUsers
,
built-in caching is disabled for the object, even if there's a bucket-level
IAM policy that grants read access for the object to allUsers
.
However, if the IAM Deny policy only restricts individual users,
built-in caching remains enabled for the object.
Performance considerations
Performance can be much better for publicly cacheable objects. If you have an object being used to control many clients and thus want to disable caching to provide the latest data:
Consider instead setting the object's
Cache-Control
metadata topublic
withmax-age
of 15-60 seconds. Most applications can tolerate having an object be out of date for a few seconds, in exchange for performance improvements.Use
Cache-Control: no-store
for an object to indicate that the object must not be cached for subsequent requests in any cache.
What's next
- Read more about the
Cache-Control
metadata. - Learn more about the RFC
Cache-Control
directives.