Layout-sensitive caching

The Cook's built-in cache provides content-only caching. A rendered web page, however, consists of more than just the content. It also includes a lot of HTML, CSS and Javascript code, boilerplate content and so on. This layout-related content is added by the Waiter, and may also need to be cached. Many CUE Front installations therefore include a caching server such as Varnish placed in front of the Waiter.

The ETags generated by Content Store are not sufficient for such a configuration to work effectively, since they only change when the content changes, and take no account of changes to a publication's Twig templates, CSS and Javascript files. You can, however, make this caching layer sensitive to layout changes by adding an etagSuffix attribute to your Waiter configuration file, waiter-config.yaml.

This attribute, as its name suggests, defines a suffix that the Waiter appends to the ETag of every response it receives from the Cook before passing the response on to its client. The idea is that you configure your application deployment procedure to modify the etagSuffix every time changes are deployed. You could, for example, use a build number or a time stamp as an etagSuffix value. This means that the ETags seen by an external caching server will change not only when a page's content changes, but also when its layout may have changed, ensuring that out-of-date layouts are never served to the end user. Exactly what strategy you choose for updating the etagSuffix will depend on your requirements and your development procedures.

Since etagSuffix must be explicitly set each time your application is deployed (or at least each time a significant layout change has been made), there may be no risk of it being overridden by CUE Front upgrades. If, however, your chosen etagSuffix update strategy means this is still a risk, see Overriding Setup Defaults for general information on how to avoid it.