[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[],[],null,["# Caching\n\nThis page discusses the options you have to control how your\nCloud Storage objects are cached. This page focuses on the\nCloud Storage built-in cache and [Cloud CDN](/cdn/docs), but\nCloud Storage is also compatible with third-party CDNs.\n\nOverview\n--------\n\nWhen a Cloud Storage object is cached, copies of the object data are\nstored in a Google or internet cache so your object can be served faster in\nfuture requests. While caching can improve performance, you also\nrisk serving stale content if you make updates to your object but a cache\ncontinues to serve the earlier version of the object.\n\nBuilt-in caching for Cloud Storage\n----------------------------------\n\nCloud Storage can behave like a Content Delivery Network (CDN) with no\nwork on your part, because an object's data is cached in the\nCloud Storage network if its [`Cache-Control` metadata](/storage/docs/metadata#cache-control) is set to\nallow caching and the following criteria are met:\n\n- The object is [publicly accessible](/storage/docs/access-control/making-data-public).\n- The object is not stored in a bucket that has [Requester Pays](/storage/docs/requester-pays) enabled and does not reside within a [Virtual Private Cloud service perimeter](/vpc-service-controls/docs/service-perimeters).\n- The object is not encrypted using [customer-managed encryption keys](/storage/docs/encryption/customer-managed-keys) or [customer-supplied encryption keys](/storage/docs/encryption/customer-supplied-keys).\n\n| **Important:** Proxies or browsers might cache object data and subsequently serve object data from their cache based solely on the object's `Cache-Control` metadata. Additionally, depending on the network path, once object data has left Cloud Storage, the `Cache-Control` value associated with it might be overwritten, for example by a CDN that the data passes through.\n\nCloud Storage respects [standard values](https://datatracker.ietf.org/doc/html/rfc7234#section-5.2) for\n`Cache-Control`, such as the following:\n\n- `public`: the object can be cached.\n\n- `private`: the object won't be cached by Cloud Storage, but can be\n cached in a requester's local cache.\n\n- `no-cache`: the object can be cached, but cannot be used to satisfy future\n requests unless first validated by Cloud Storage.\n\n- `no-store`: the object can't be cached.\n\n- `max-age=`\u003cvar translate=\"no\"\u003eTIME_IN_SECONDS\u003c/var\u003e: the length of time an object\n can be cached before it's considered stale. You can set `max-age` to any\n length of time. Stale objects are not served from caches, except in\n [special circumstances](https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.4).\n\nTo set the `Cache-Control` metadata for an object, see\n[Editing object metadata](/storage/docs/viewing-editing-metadata#edit).\n\n### Built-in caching behavior with IAM Deny policies\n\nWhen there's an organization-level IAM Deny policy that\nrestricts read access for an object from the [principal identifier `allUsers`](/iam/docs/principal-identifiers),\nbuilt-in caching is disabled for the object, even if there's a bucket-level\nIAM policy that grants read access for the object to `allUsers`.\nHowever, if the IAM Deny policy only restricts individual users,\nbuilt-in caching remains enabled for the object.\n\n### Performance considerations\n\nPerformance can be much better for publicly cacheable objects. If you have an\nobject being used to control many clients and thus want to disable caching\nto provide the latest data:\n\n- Consider instead setting the object's `Cache-Control` metadata to `public`\n with `max-age` of 15-60 seconds. Most applications can tolerate having an\n object be out of date for a few seconds, in exchange for performance\n improvements.\n\n- Use `Cache-Control: no-store` for an object to indicate that the object\n must not be cached for subsequent requests in any cache.\n\nUse Anywhere Cache with your buckets\n------------------------------------\n\nAnywhere Cache is a fully-managed, always consistent Cloud Storage\nfeature that lets you create caches in the same zone as your workloads. The\ncaches can then be used to complete data read requests instead of your\nmulti-region bucket, helping you control storage costs while running large,\ndata-intensive workloads that would otherwise incur multi-region data transfer\nfees and impact performance. To learn more about Anywhere Cache, its\nbenefits, and when you should use this feature, see\n[Anywhere Cache overview](/storage/docs/anywhere-cache).\n\nCloud Storage with Cloud CDN\n----------------------------\n\nFor the best performance when delivering content to users, we recommend using\nCloud Storage with Cloud CDN.\n\nTo use Cloud CDN, you must use an [external Application Load Balancer](/load-balancing/docs/https) with your\nCloud Storage buckets as a backend. For a tutorial on setting up an\nHTTP(S) load balancer with a Cloud Storage bucket, see\n[Hosting a static website](/storage/docs/hosting-static-website).\n\n[Cloud CDN cache modes](/cdn/docs/caching#cache-modes) allow you to apply a unified caching\nconfiguration across all your objects. Cloud CDN uses the\n`Cache-Control` metadata set on your objects to determine\n[how they should be cached](/cdn/docs/caching#cacheability), unless you override the `Cache-Control`\nmetadata using a cache mode or [TTL limit](/cdn/docs/using-ttl-overrides).\n\nWhen choosing between Cloud Storage built-in caching and\nCloud CDN, consider the\nfollowing:\n\n^1^The maximum cacheable file size for Cloud CDN is 100 GiB\nif the origin server supports byte range requests. If the origin server doesn't\nsupport byte range requests, the maximum cacheable file size for\nCloud CDN is 10 MiB.\n\n### Pricing considerations\n\nIn terms of pricing, the choice between Cloud Storage built-in caching\nand Cloud CDN depends on how much data you serve every month, which\ndetermines the amount of networking costs you incur.\n\n- If you serve less than a few GiB of cacheable data a month, it may be cheaper\n overall for you to rely on Cloud Storage built-in caching.\n Cloud Storage caching may incur higher networking costs than\n Cloud CDN, since cached and uncached objects are charged the same\n outbound data transfer cost (which means you pay full price for cache hits).\n However, you only pay for data storage and operations usage costs associated\n with Cloud Storage, instead of the combination of\n Cloud Storage, Cloud CDN, and Cloud Load Balancing.\n\n- If you regularly serve 100 GiB or more of cacheable data a month, or need to\n use per-request logging and custom headers, it may be cheaper overall for you\n to rely on Cloud CDN. You incur Cloud Storage outbound data\n transfer and Cloud CDN cache fill costs for cache fill, and\n Cloud CDN networking prices apply after the cache is full. The\n networking cost savings you gain from using Cloud CDN may be worth\n the higher operating costs associated with maintaining the external Application Load Balancer and\n Cloud CDN along with Cloud Storage.\n\nWhat's next\n-----------\n\n- Read more about the [`Cache-Control` metadata](/storage/docs/metadata#cache-control).\n- Learn more about the [RFC `Cache-Control` directives](https://datatracker.ietf.org/doc/html/rfc7234#section-5.2).\n- Read the [caching overview for Cloud CDN](/cdn/docs/caching).\n- Learn how to [create an external HTTP(S) load balancer to serve requests from\n your Cloud Storage bucket](/load-balancing/docs/https/setup-global-ext-https-buckets).\n- Read the pricing details for [external Application Load Balancers](/vpc/network-pricing#lb) and [Cloud CDN](/cdn/pricing)."]]
