A while back, we blogged about the caching that's in place and the steps publishers should take to publish time-sensitive content exactly when they need to.
We also promised to look into how we might make improvements to reduce the risk and impact of cache-based misadventures.
After lots of thoughtful and thorough analysis (about which we will blog separately) we are happy to confirm we have now:
- reduced the cache times for 404 pages to 5 minutes, so the impact of a yet-to-be-published URL becoming inadvertently cached is now much lower. The previous advice still stands if publishers want to eliminate that risk altogether.
- reduced the cache times for documents to 15 minutes, so that updates to pre-existing pages will go live in half the time they did previously, and so that publishers can make edits to scheduled documents up to 15 minutes before they are due to go live.
Important note: these times are somewhat experimental. We will be keeping a close eye on what these changes cost us in terms of performance and resilience, and reserve the right to increase the cache times if necessary. We'll let you know if that happens.
Future iterations might include enabling edits on scheduled documents right up to the minute they go live, but we think these new shortened cache times go a long way to meeting publishers' needs and we should move on to other, higher priority things before we iterate on this further. Shout via the comments if you disagree with that decision.
1 comment
Comment by Cass Martin posted on
Thanks Neil, this is good to know and great news.
Just to check does the same 15 minute cache apply to page updates too (eg updating the text on a policy page)? It would be really helpful if someone could put together a quick table just showing the different cache times for different content types, as well as new vs existing content.