Last time we covered how slow server performance can have a negative, sometimes very negative, effect on your website load times. The causes of slow server responses are many, not necessarily tied to the server specification, and dealing with them can be difficult and time-consuming. One of THE most effective ways of reducing the impact of slow server performance is to look for opportunities where you can cache dynamic content.

What is Dynamic Content?

Content delivered by a webserver is categorised as either static or dynamic. Static content is the same for every user and is delivered without being generated or processed by the server. Static content is fast to deliver and does not tax a server's resources.

Dynamic content is generated by the server for every request, this can involve querying a database several times and executing a large amount of code. Depending on the amount of work required to generate the result, delivering dynamic content can be very resource hungry.

Traditionally CDNs have only cached and served the static content of websites, usually the images, CSS files, Javascript files, etc. They required the webmaster to upload these resources to the CDN's servers and to modify their website source HTML to access the resources from the CDN. For example,


would be changed to be something like


Modern CDNs, like Peakhour, act as a reverse proxy, which means they sit in-between the end user and the server of the website. This enables them to potentially cache a copy of anything being returned by the origin server.

Full Page Caching

Full Page Caching (FPC) is where the actual HTML document of a web page is cached rather than being generated.

Most modern websites are built using a Content Management Systems (CMS). Widely used CMS platforms are Wordpress, Drupal, Magento, etc. By default, every time a page is viewed the CMS system will have to generate the content from its database. However, most of the time this generation is completely unnecessary. The content is either the same for every user, very rarely changes, or the difference is a small bit of personalisation. In each case it is possible to perform Full Page Caching to improve page load times and to cut server load. Let's have a look at the difference full page caching makes to one of our clients, Magento 2 store savvysupporter.com.au.

Savvysupporter before Main document load before caching: 2.07s
Savvysupporter after Main document load after caching: 87ms

Caching the page has cut nearly 2 whole seconds from the download time. With a Magento 2 website, its possible to cache all full pages outside the checkout process and the customer/admin area. This can reduce load on the origin in the order of 60-70% and make the customer experience dramatically better.

API (Application Programming Interface) Caching

Many API calls used by web applications are for the retrieval of information to be displayed to the end user. Examples include:

  • Pricing and product information
  • Form auto completion
  • Product catalogue searches

These are all prime candidates for caching results instead of generating for every call.

Handling Stale Information

The one potential drawback of caching dynamic content is the possibility of returning out of date information to the end user. There are two strategies to deal with this risk.

  1. Setting a short Time To Live (TTL) with the caching provider. By only keeping content cached for a short time, eg 5 minutes, the cache will never be without up to date information for very long. Cached content will expire and the new version fetched from the origin server. The drawback with this method is that, unless your site is very busy, cache hit rates can be low, users can frequently get slow loading pages, serving stale content is still possible.

  2. Flushing content when it changes. Magento 2 and Drupal 8 have a framework for integrating caching providers and can automatically notify the cache (flush) when content has changed. This tells the cache to immediately expire/invalidate the current version they have and fetch a new version from the origin server. This method has the benefits of being able to set a very long TTL for a cached resource in the cache, eg 1 year, only when the origin server notifies the cache that content has changed does the cache fetch the latest version. This eliminates

Website Performance Website Optimisation