Cache-Control

These fields can be configured individually:

• max-age
• s-maxage
• stale-if-error
• stale-while-revalidate

Alternatively, uncacheable pages are served with no-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.