Fast, reliable web and video content delivery with global scale and reach.
Brings consistently great web and video experiences to users anywhere
Provides privacy and data security
Activates with a single click for Cloud Load Balancing users
Global distribution with anycast IP
With edge caches peered with nearly every major end-user ISP globally, Cloud CDN offers connectivity to more users everywhere. Thanks to anycast architecture, your site gets a single global IP address, combining consistent performance worldwide with easy management.
Optimized for last-mile performance
As a complement to Google Cloud’s high-performance private network, Cloud CDN supports modern protocols originally developed at Google, like HTTP/2 and QUIC, to improve site performance for mobile users and/or users in emerging markets.
Integrated with Google Cloud
Cloud CDN is tightly integrated with Cloud Monitoring and Cloud Logging, providing detailed latency metrics out of the box, as well as raw HTTP request logs for deeper visibility. Logs can be exported into Cloud Storage and/or BigQuery for further analysis with just a few clicks.
Best practices for Content Delivery
This page provides best practices for optimizing and accelerating content delivery with Cloud CDN.
Cloud CDN uses HTTP(S) Load Balancing as the origin for cacheable content. An external HTTP(S) load balancer can deliver a mix of static and dynamically-created content to users through one global IP address from the following types of backends:
Because of the seamless integration with Google Cloud, you have several options for deploying Cloud CDN and managing content. Use the best practices listed here to plan and refine your deployment. For more information, see Using Cloud CDN.
Automatically caching static content
As a best practice to improve performance, when you enable Cloud CDN, you can allow Cloud CDN to automatically cache static content.
To automatically cache static responses from your origin, you can use the --cache-mode=CACHE_ALL_STATIC setting (default). This setting lets Cloud CDN cache common static content types.
Setting the expiration for time-sensitive content
Each piece of content in a Cloud CDN cache has an associated expiration time, and it’s important to set an expiration that is appropriate for your use case. Because origin servers must resend content that expires on cache servers, you need to choose the expiration carefully.
One method for choosing the expiration is to categorize content based on how often you update the content; for example:
Near real-time updates such as live feeds for sporting events or traffic
Frequent updates such as weekly, daily, or hourly weather information or front-page news images
Next, choose the expiration by content category. For example, a five-second expiration might be appropriate for near real-time sports scores, and a one-hour expiration could be used for weather updates. For content stored in Cloud Storage, set the expiration times by using Cache-Control metadata. When content is served by Compute Engine, you control expiration times by configuring your web server software.
Expiration times are specified by the max-age and s-maxage values in the Cache-Control header. This header is defined by the HTTP specification. For example, the following Cache-Control header makes the associated content publicly readable and cacheable with a cache expiration of 72 hours (259200 seconds):
Cache-Control: public, max-age=259200
To maximize caching, follow the guidelines in the Caching overview. Remember that max-age and s-maxage values in the Cache-Control metadata field work together in the following ways:
The max-age and s-maxage values are measured in seconds.
The s-maxage value applies only to shared caches, not browser caches.
The max-age value applies to all caches unless s-maxage overrides it.
For content that changes infrequently or that must change along with related content, it’s often appropriate to use a long expiration time in combination with versioned URLs.
Optimizing cache TTLs
You can set or override the TTLs to fine tune how long Cloud CDN caches your responses and when Cloud CDN revalidates your responses.
You can also define a client-facing TTL to make the most of browser caches.
Using custom cache keys to improve cache hit ratio
By default, Cloud CDN uses the complete request URL to build the cache key. For performance and scalability, it’s important to optimize cache hit ratio. To help optimize your cache hit ratio, you can use custom cache keys .
You can customize cache keys to include or omit any combination of protocol, host, and query string. For example, suppose you have two websites on different domains that use the same logo. To show the logo, use custom cache keys, as follows:
The website content is different, but you use the same company logo on both domains. When you turn on Cloud CDN and customize the cache keys for the backend service that holds the logo, clear the Host checkbox so that the cache ignores the domain but caches the logo.
The logo needs to be cached whether displayed through HTTP or HTTPS. When you customize the cache keys for the backend service that holds the logo, clear the Protocol checkbox so that requests through HTTP and HTTPS count as matches for the logo’s cache entry.
Versioning content serves a different version of the same content, effectively removing it by showing users new content before the cache entry expires. Because versioning is free and easy to use, we recommend that you use versioning as the default approach for updating cacheable content.
To version content, add a parameter to the URL, such as a version number. There are various ways to include parameters in URLs, such as:
Add a query string: file.ext?v=100
Alter the file name: file.1.0.0.ext or file_v100.ext
Alter the file path: /v100/file.ext
When you add the parameter, you change the name of the file and the URL. This change forces the cache to ignore any existing cache entry.
Using invalidation sparingly to remove content
Invalidation removes content from the Cloud CDN distributed cache servers before the cache entry expires. Invalidation is eventually consistent.
We recommend that you use invalidation sparingly and only as a last resort. For example, invalidation is useful when you must remove content for legal reasons or because of an accidental upload. Otherwise, we recommend that you use versioning whenever possible or wait until the content expires normally. Cloud CDN cache servers routinely evict infrequently accessed content to make room for new content. Content that is not accessed for 30 days is removed unconditionally.