Technical case study: working around an intensive site cache

No matter how simple or how complicated a website can be, it can always benefit from a caching system to make it faster. There are many ways to “cache” a website, but the principle is the same: create the pages which are stored in the database and then deliver the prepared page to the visitor directly. Loading a page from a database every time – especially one which isn’t optimized – can quickly lead to performance issues and even outages when large numbers of people visit.

A common server-side solution for caching websites is Varnish: a server which stands between the visitor and the website server and which delivers these pre-prepared pages much more quickly. That’s the solution which has been implemented by a large sports organisation in Bern for a long time, which works well in most situations.

The problem with caching pages is that the editors sometimes need to change the information on a very regular basis. This can make it difficult to cache the pages effectively. After experiencing some issues with the actuality of the opening times — especially those which were out of the usual pattern — a more efficient and modern solution presented itself. Instead of trying to find a way to customise the caching of some parts of the site, why not decouple the opening times and statuses, and deliver them on-the-fly?

In order to achieve this, the obvious solution was to use the powerful yet simple WordPress REST API to fill the appropriate parts of the pages on demand. I removed the static elements — like the special opening times tables — and loaded the information via AJAX request, placing the result in the cached page almost instantly.

The advantage of using the REST API for such tasks is that it’s possible to optimize the data delivery to a fine degree, just for that specific piece of information. Although there are several standard API “endpoints” to work with, it’s a fairly simple piece of programming to provide a custom, specific “endpoint”, which in this case delivers a compete HTML snippet for insertion to the page.

The visitor won’t notice the difference if the data is loaded within a second, and the people responsible for managing the facilities can be sure that an amendment to a piece of information is instantly reflected on the website, without needing to clear caches of other, longer-standing content.

As an added extra, I also built a new backend view for the administrators, through which the generated data is loaded (again from the REST API) to show them a global overview, in which the facilities with each status are grouped together.

Leave a Reply

Your email address will not be published. Required fields are marked *