Caching with Cloud Storage built-in cache

This page discusses the Cloud Storage built-in cache. Cloud Storage is also compatible with third-party CDNs.

Overview

Control caching for your Cloud Storage objects to enhance application performance and help maintain content freshness. Caching object data stores copies of the data in Google or internet caches, which accelerates future data read requests. Cloud Storage offers built-in caching that behaves like a CDN. You manage this built-in caching through the Cache-Control metadata, which defines how and for how long caches store your objects.

For more advanced control, explore Anywhere Cache.

Caching with Anywhere Cache

Anywhere Cache provides a fully-managed, always consistent SSD-backed zonal read cache that can be created in the same zones as your workloads in compute. The caches are used to accelerate serving data for large, data-intensive workloads. Data that's read from a cache is charged reduced data transfer fees compared to data that's read directly from multi-region buckets, letting you optimize costs.

For more information, see Anywhere Cache.

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:

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 set max-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 to public with max-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