You should test and verify that stale-cache handling works on your infrastructure before deploying it.
Note that you can likely benefit from decreasing the maxage option in favor of a longer stale-while-revalidate duration when using a reverse proxy or content distribution network. This should be set to minutes, hours, or even days depending on how fresh you need your content to be. This can greatly improved page loading times for visitors won’t have to wait for pages to be updated. This option allows shared caches to keep serving cached copies to visitors for a number of seconds while updating the cached copy in the background. Like the stale-if-error option, but doesn’t depend on the original web server returning an HTTP error code. You must also specify a private or shared cache duration to use this option. This option is typically only desired when using a reverse proxy or a content distribution network. This can be set to hours or even days to help ensure your website remains available. For many websites, it’s undesirable to return an error message when an older cached copy of a page can be served instead.
Sets an additional number of seconds after a cached page has expired in the cache which stale copy of a page can be returned from the cache if your web server returns an HTTP error. If no shared cache duration is set, then the configured private cache duration is inherited for use by shared caches.
SHARED CACHE VS PRIVATE CACHE UPDATE
In many situations, you may want a shared cache to update more often than a private cache. This option allow you to instruct intermediary caches to refresh cached resources more or less often than a private cache. A shared cache is a cache designed to be used by more than one device or visitor, such as a reverse proxies, content delivery network ( CDN), or a web accelerator. Sets the number of seconds a shared cache can store a page in its cache. This is the simplest field required for caching to work in most clients, and the only field which is set by default. Sets the number of seconds a page can be cached before it should be refreshed. Each field matches the corresponding Cache-Control HTTP header as defined in RFC 7234 Section 5.2. The following fields can be configured within the plugin administration page. See the HACKING file in the plugin installation directory for details. You can override the plugin and do entirely custom handling for specific request or type of pages using your criteria using the cache_control_cachedirective filter hook. Uncachable pagesĮach type of page must be configured separately. Setting all options for a given type of pages to 0 seconds will make it uncachable. Any option set to 0 seconds will omit the given omitted the given field from the Cache-Control header. Go to Settings: Cache-Control to see the options page.Īll options within the plugin is set in seconds. The plugin can be configured for your WordPress administration area. For stale cache handling specifically, you should also refer to RFC 5861. Section 5.2 in or the whole of RFC 7234 can get you up to date. Some familiarity with caching in HTTP will be required. However, you must balance that between how frequently content is updated and how acceptable it’s for visitors to see cached and potentially old pages.Īdditionally, you can set error and cache-updating behavior in modern caches by configuring stale-cache handling. A longer freshness duration can save you bandwidth costs and money, and it can also help speed up your website. The desired freshness duration will vary from page to page within a given website, but also from website to website. You set the cache freshness as the most number of seconds from the page was initially loaded that it’s acceptable for website visitors to be served a cached version of a page. The plugin isn’t a cache plugin in itself, but can be used to control the behavior of standard HTTP caches such as browser caches, reverse proxies, content delivery networks ( CDN), and web accelerators. The Cache-Control plugin for WordPress lets you set the cache freshness duration for dynamically generated pages on a WordPress website through the use of the Cache-Control HTTP response header.
0 kommentar(er)
