The Zesty.io origin service, WebEngine, has changed two headers on request responses:
- "Cache-Control: max-age=300, public" changed to "Cache-Control: no-cache"
- "Pragma" has been removed
"Cache-Control" and "Pragma" headers exist to instruct browsers (e.g. Chrome, Firefox, Safari) to keep a copy of a page for X seconds, which it will then serve, instead of requesting the latest. On WebEngine this has historically been set to 300 seconds (5 minutes).
The reason for these headers on WebEngine request responses is that caching is an important factor in page speed and can have a positive effect on Search Engine Optimization (SEO).
Unfortunately, these headers have been negatively impacting customer experience. They create an unclear expectation for users when viewing web pages on a browser. Additionally they introduce inconsistent and uncontrollable behaviours within the Google App Engine (GAE) global load balancer which WebEngine deploys on. This has been affecting a handful of customers over the past 6 months who were part of the beta transitionary period in the rollout of this latest service. The headers will be removed for an indeterminate amount of time while we explore alternatives to allow their reintroduction.
When reading between the lines of the documentation for the Google App Engine standard environment, it appears that when the global load balancer sees the Cache-Control directive, it creates a "web-proxy" cache and describes a key caveat: "there is generally no way to clear ... web-proxy caches, even if the user clears their own browser cache."
Our lack of insight into the addition of this web-proxy introduced an unknown caching behavior. And that along with browser caching created esoteric problems that occurred intermittently due to the specific combination of cache invalidation at various caches within our request pipeline.
Therefore, to resolve this issue we will be removing them from WebEngine origin responses for all requests. These headers will remain removed until we can find an alternative solution to allow for the presence of these headers without triggering caching at web-proxies outside of our immediate control. Going forward content should consistently be available after publishing events.
If you do experience any issues around content changes not reflecting on your live domains or have any questions in regard to this change, please reach out directly or connect with your Zesty.io account manager.
Read our technical explanation for further details on why we have made these changes.