| 开发者 | geekysoft |
|---|---|
| 更新时间 | 2019年8月30日 19:50 |
| 捐献地址: | 去捐款 |
| PHP版本: | 4.4.1 及以上 |
| WordPress版本: | 5.2.2 |
| 版权: | GPLv3 |
| 版权网址: | 版权信息 |
Cache-Control headers.
This is not a caching plugin in itself, but will enable you to leverage existing standard compliant caching systems better. You can set different policies for different kinds of pages to suite your website’s needs. The Cache-Control for WordPress plugin allows you to set different policies for shared/intermediary and private caches. The plugin sets some sensible defaults for a medium traffic blog that publishes an update or two per week.
You can safely set long Cache-Control times as the max-age values is lowered automatically before a scheduled post is about to be published.
Private pages (logged in users, the admin interface, etc.) will not be cached.
The plugin has extensive documentation.
/wp-content/plugins/cache-control directory, or install the plugin through the WordPress plugins screen directly.Please refer to RFC 2616 Section 13. If you’re unfamiliar with this header, you’ll want to disable this plugin until you’ve read up on caching in general. Apache’s caching guide is a great resource to get better acquainted with caching. This plugin should be used with great care as it breaks assumptions set by WordPress core and most plugin authors that every page will be regenerated for every request.
You can use your web browser’s developer tools, or a web utility for inspecting headers like Redbot.
These fields can be configured individually:
max-ages-maxagestale-if-errorstale-while-revalidateno-cache, no-store, must-revalidate.
No, but it tells caching reverse proxies like Apache’s mod_cache, Varnish, Squid, that it’s okay to cache the content generated by WordPress for the specified intervals you define in the header.
These pages are always set as non-cacheable. Whether caches respect this is up to their configuration. By default, this shouldn’t be an issue.
Yes, the stale-if-error and stale-while-revalidate headers from RFC 5861 are supported. Please verify with your reverse proxy, content distribution network (CDN), or web accelerator whether RFC 5861 is supported there too. Setting the headers doesn’t help when your deployment doesn’t support them.
Yes, there is a separate setting for feeds. It’s recommended to set it to a few hours to preserve device battery and network bandwidth on users’ devices even if your site is updated very frequently.
Caching means pages will be static (non-changing) in caches that store them. Dynamic themes that modify page content will generate one variant that is served to all users for as long as a cache consider the response “fresh”. You can use client-side scripting to make some elements (ad banners, recent posts, etc.) update more frequently than the rest of the page.
Any plugin that require dynamic content will be negatively affected. For example, many anti-comment spam plugins will not work when served statically from a cache. Make sure to test every feature on your website after enabling caching. Plugins that produce texts, images, ads, and the like will produce one output and potentially have that served to all users until the cache expires.
stale-if-error and stale-while-revalidate fields. (RFC 5861)s-maxage value is no longer set by default.