HTTP cache configuration¶
Content view configuration¶
You can configure cache globally for content views in
1 2 3 4 5 6 7 8 9 10
You may want to set a high default time to live (TTL) (
default_ttl) to have a high cache hit ratio on your installation.
As the system takes care of purges, the cache should not become stale with the exception of grace handing in Varnish and Fastly.
Cache header rules¶
A few redirect and error pages are served through the content view system. If you set a high
default_ttl, they can also be served from cache.
To avoid this, the installation ships with configuration to match these specific situations and set a much lower TTL. FOSHttpCacheBundle matching rules enables you to specify a different TTL:
1 2 3 4 5 6 7 8 9 10 11 12
Similarly, by default the performance tuning is applied to avoid crawlers affecting the setup too much, by caching of generic 404s and similar error pages in the following way:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Set time-to-live value for Page blocks¶
For the Page Builder, block cache by default respects
However, if the given block value has a since or till date,
it is taken into account for the TTL calculation for both the block and the whole page.
To overload this behavior, listen to
and set priority to
-200 to adapt what Page Field Type does by default.
For example, to disable cache for the block, use
When to use ESI¶
Edge Side Includes (ESI) can be used to split out the different parts of a web page into separate fragments that can be freely reused as pieces by reverse proxy.
In practice, with ESI, every sub-request is regenerated from application perspective. And while you can tune your system to reduce this, it always causes additional overhead in the following situations:
- When cache is cold on all or some of the sub-requests
- With Symfony Proxy (AppCache) there is always some overhead, even on warm cache (hits)
- In development environment
This may differ depending on your system, however, it is recommended to stay below 5 ESI requests per page and only using them for parts that are the same across the whole site or larger parts of it.
You should not use ESI for parts that are effectively uncached, because your reverse proxy has to wait for the back end and cannot deliver cached pages directly.
ESI limitations with the URIElement SiteAccess matcher
Is is not possible to share ESIs across the SiteAccesses when using URI matching as URI contains the SiteAccess name encoded in its path information.