Thereafter, the browser will re-request the content from its source. The Expires header tells the cache (typically a browser cache) how long to hang onto a piece of content. For more in-depth information about how Fastly responds to these Cache-Control headers and how these headers interact with Expires and Surrogate-Control, check out our documentation on cache freshness.įor more information on the rest of the Cache-Control headers, see the relevant section in Mark Nottingham's caching tutorial. All other Cache-Control headers will not, but will be passed through to the browser. Only the max-age, s-maxage, and private Cache-Control headers will influence Fastly's caching. Cache-Control: s-maxage= - Same as max-age but applies specifically to proxy caches.Cache-Control: public, max-age= - Caches can store this content for n seconds.Cache-Control: no-store - Don't ever store this content.Cache-Control: no-cache - Re-validate before serving this content.Cache-Control: private - Don't store, this is for a single user.Cache-Control: public - Any cache can store a copy of the content.Cache-Control headersĬache-Control headers, as defined by section 5.2 of RFC 7234, include: Combined with Fastly's Purge API an entire collection of URLs can be expired from the cache in one API call (and typically happens in around 1ms). When Fastly processes a request and sees a Surrogate-Key header, it uses the space-separated value as a list of tags to associate with the request URL in the cache. With Fastly, one of the most useful Surrogate headers is Surrogate-Key. Simultaneously, a Surrogate-Control header can be sent with a longer max-age that lets a proxy cache in front of the source handle most of the browser traffic, only passing requests to the source when the proxy's cache expires. This makes sure that the user is getting the freshest possible content.
This causes the browser to re-validate with the source on every request for the content. One use of this technique is to provide conservative cache interactions to the browser (for example, Cache-Control: no-cache).
PRIVATE CACHE TYPE PLUS
Surrogate-Control accepts many of the same values as Cache-Control, plus some other more esoteric ones (read the tech note for all the options). These headers provide a specific cache policy for proxy caches in the processing path. Surrogate headers are a relatively new addition to the cache management vocabulary (described in this W3C tech note). You can use cache control headers to set policies that determine how long your data is cached.įastly looks for caching information in each of these headers as described in our documentation on cache freshness. Understand how cache control headers work See our Google Cloud Storage instructions if you're changing the default TTL for a GCS bucket. You can specifically set a fallback TTL (sometimes called a default TTL). TTL is set based on the cache related headers information returned from your origin server. The amount of time information can be retained in cache memory is considered its time to live or TTL. You can check your hit ratio by viewing the Stats page for your service. In general, you want your cache hit ratio as high as possible, usually in excess of 90%.
A high cache hit ratio means you've kept request traffic from hitting your origin unnecessarily. The number of requests delivered by a cache server, divided by the number of cacheable requests (hits + misses), is called the cache hit ratio. We also provide a variety of plugins to help you directly integrate Fastly with your content management system. For instructions, see our documentation on integrating third-party services and configuring web server software. You can optimize caching with Fastly by customizing your application platform settings. Integrate Fastly with your application platform To ensure optimum origin performance during times of increased demand or during scheduled downtime for your servers, consider the following best practices for your service's caching configurations.
0 kommentar(er)
