The information in this blogpost may now be out of date. See the current GOV.UK content and publishing guidance.
We've seen a few cases recently of people misunderstanding or being unaware of the way pages are cached, and publications or announcements being inadvertently delayed as a result.
In the interests of helping you avoid that kind of thing, here's a quick reminder of how the cache works and how you can work with it.
1. Know your cache times
Like all major websites, GOV.UK uses a CDN to protect the infrastructure from malicious attacks and to cope with peak demand.
The default cache expiry on all existing pages in the government section is currently set to 15 mins. That means that an update to any existing page can take up to 15 mins to be served to end users, depending on when the CDN last requested the page.
Some pages have shorter cache times than the default:
- Organisation homepages are cached for 5 minutes (because they have the ability to feature content)
- Topical events are cached for 5 minutes (same reason)
Brand new pages are not cached. They appear immediately, then are cached for 15 mins. They will not, however, be listed on existing pages of the site until those pages' caches expire. Example: you publish a new news article. Accessing the news article by its URL directly will work immediately (provided nobody has tried to access it too soon - see 3, below). But the news article wil not appear on the announcements list or your topic or organisation homepage until those pages' caches expire.
2. Scheduled publishing is your best friend
If you schedule a page to be published at a specified time (either a new page or an update to an existing page), the cache expiry will be set to be that exact time. That means the page itself, and any pages around the site that will link to it, will simultaneously be refreshed on the CDN and served to users at that time.
It works very well, and has unit tests and monitoring in place to ensure it is reliable.
(...but even best friends can be annoying sometimes)
A slight niggle with scheduled publishing as it stands is that you have to prepare the content and schedule it at least 30 mins before it's due to be published, and you can't make edits in that 30 mins immediately before the scheduled time. We know that's a bit limiting, and we'll be investigating solutions as soon as we can. Here's the Pivotal story for that.
3. Beware the cached 404
We blogged some time back about the fact that sharing URLs for yet-to-be-published documents is a risky business. Anyone viewing a URL before it exists will cause a 404 to be cached for up to 5 mins.
You should consider giving out URLs for the places where you will feature the document, not the document itself.
4. Beware the consultation response document
When you add a response document to a consultation page and hit publish, it will take up to 15 mins to be visible on the site for the reasons above. If it's time-sensitive, you need to prepare it in advance and schedule it - that's the only way to get it out on time.
2 comments
Comment by Sarah Purssell posted on
Hi, the problem we've found with using scheduling as a solution to caching is not so much being unable to edit for half an hour but the inability to unschedule for that half hour in case of delays particularly when coordinating with WMSs. Is there anyway around this issue or is it part of your current investigations?
Comment by Neil Williams posted on
Hi Sarah - yes, that's related. The 30 minute cache time is why you can't edit it in that final 30 minutes. Stay tuned to that story, we'll be looking at it next sprint.