
The speed at which your website loads in the browser matters a great deal. Both how users perceive it and its impact on the server mean this cannot be left to chance. To understand how important it is, we first need to look at what depends on whether a website works quickly and smoothly.
Users
If your website loads slowly in the user’s browser, there is a good chance they will abandon it and search Google for something else. As you can easily predict, this leads to lost potential customers. Of course this is a bad scenario, but it should not be underestimated, because research shows it is one of the most common reasons users leave websites.
Impact on search results
We have known for a long time that search engines look favourably on websites that are properly optimised, including for loading speed. If we want to compete for the top positions in Google search results, we must take care of our website’s speed.
There are several tools that help developers analyse and eliminate problems invisible to the naked eye. The most popular of them is Google PageSpeed Insights.
The server environment
It is important to be aware that even the most efficient runtime environment for our website will not cope if the application is written without regard for speed. If our application makes the server’s response time long, it can lead to a number of problems which, in extreme cases, can even take the service down completely.
Now that we know how important it is for our website to work quickly and smoothly, we can move on to what we can do to achieve it.
Page generation time and server response
These two are related, but they do not mean quite the same thing. From the user’s point of view, page generation time is part of the server response time, which is probably the cause of frequent misunderstandings. It is worth knowing that page generation time is the period during which the request is processed by the application. In PHP, this is the time the interpreter spends generating the resulting HTML. Server response time is longer, because it includes additional work the HTTP server has to do before returning the response to the browser. There can be a lot of these tasks: queue handling, encryption, compression, redirects, proxying and so on.
What can be done to shorten the time the server takes to generate a page?
The first and most important thing is to optimise the application. The code should be free of elements that take too long to execute. If our system has such places, they must be refactored. If a long-running task is really important, you can try moving the critical part somewhere it can be processed in the background, or use some kind of asynchronous solution.
Once our website has been stripped of problematic fragments, we can consider storing the results of some operations in a cache. This is where the key word appears for the first time: caching. It is a fairly general concept, used in various places in web development. At this stage, however, we are talking about keeping in memory temporary information that is time-consuming to calculate or build. These can be complex mathematical operations, slow database queries or rendering some part of the page. There are practically no limits to the uses. A popular practice is to store this temporary information in the server’s memory, which can be done in different ways. The most popular mechanisms are:
- Redis
- Memcache
- Files
Today the most widely used solution is Redis, a service installed on the server that you communicate with over TCP. It is extremely capable and could essentially be called a database. It can store information in RAM as well as on disk. Memcache, which also kept data in the server’s RAM, used to be more common, but today it has been practically replaced by Redis.
Many systems used to build modern websites already have mechanisms for caching certain elements. The most popular CMS today, WordPress, also has a built-in caching module. There are many plugins that can make full use of these capabilities and even extend them. An interesting extension worth a look is WP Rocket. It is a paid add-on, but its capabilities for optimising a WordPress web application are huge, and not only when it comes to caching.
Frameworks, which are more general-purpose systems, also implement caching mechanisms. Most of them store at least their configuration and many other elements needed to run. They also include various interfaces that help developers build caching at different levels.
Another approach to caching is storing the whole generated output in memory, so that an HTTP request does not require querying the application every time. This approach is extremely effective at shortening server response time. Implementing it is complicated, though, because it requires advanced tools and considerable knowledge, not only of building websites but also of network protocols and systems administration.
When our website is built on WordPress, we can use a hybrid solution, one that caches the entire resulting HTML sent to the browser but does not require advanced tools. This is where the authors of various plugins with the word “cache” in their name come to the rescue. The most popular of them are WP Super Cache and LiteSpeed Cache. With them we can configure our web application so that the page code, once generated, is stored (usually as plain files). When the application receives another request for the same resource, instead of processing it in full, the stored code is sent to the browser.
We can build this setup not only for WordPress. Websites built on custom solutions, created specifically for a single client, can also implement this kind of solution. To do so, use output buffer control, the buffer to which the server sends content for the browser. The application can be configured to keep the content intended for the client in the buffer. Once all the content is in it, save it somewhere, for example in a text file. Then flush the buffer, that is, deliver its data to the user. The next request to the server can then be served with the previously generated file.
This mechanism also provides an extremely efficient solution that we can successfully run ourselves. With this approach we can very easily reduce the cost of maintaining a website. Website growth and increased traffic can then be handled with the same resources.
When that is not enough
Larger websites, those serving a huge number of users, need more advanced content caching solutions. The most popular technology here is Varnish Cache. In its creators’ words, it is a web application accelerator that works as a reverse proxy. What does that mean? It is a network service that sits between the user’s browser and the application server. Varnish can do more than caching; it can be used for other tasks too. For example, it can act as a load balancer, although this configuration is not used very often.
What this model gives us
So what do we gain from implementing caching at the reverse proxy level in our project? It may not be obvious from the perspective of a small topical blog or a local company’s website. But with huge traffic, the benefits of this model are clearest. The machines running the application do not need huge hardware resources. Sometimes a single backend server is enough to generate content, because all the traffic, and therefore the load, is stopped earlier, at the reverse proxy level. It is easy to see why everyone would like to aim for this solution because of the costs.
Summary
Not everyone is responsible for a website serving millions of users. But everyone should take care of caching their website. If not to optimise costs, then certainly for a better experience for end customers, and therefore for search engines.



