As said, it is interesting that in the Waterfall charts we’ve seen so far, is that it takes more than 1 sec between the page request being sent and the page being rendered. While can be due to the rendering process itself, I believe it has to do with the speed the HTML is generated and sent. With some more testing I saw the HTML rendering sometimes take up to 4 sec. To put that in perspective, when a web-server takes more than 0.2 sec to 0.4 sec, this is considered slow. So, where is this delay coming from? Well, this is not so easy to say, for there are different possible reasons. For example, it may well be that the response time is dominated by network lag. The request data travels in our case from Nijmegen through a series of nodes to Amsterdam, the response has than find its way back. However, if we do a so called traceroute, we learn that that does not seem to be the reason:
The data traffic takes approximately 40-50 msec for a round trip. This may mean that the delay is somewhere in the web server and/or the WordPress blog software that generates the HTML data. The Web server hardware, configuration and tuning are the responsibilities of the hoster, Versio, and we cannot do much there. We can, however, see if we can optimize WordPress.
From the moment the page request reaches WordPress, the following steps are broadly followed to generate a Web page:
- Creating the executable (byte) code from the WordPress software
- retrieval of articles and other data from the database
- translating this data into software objects
- presenting these objects as a Web page
All these 4 steps can be buffered. For the first, we would need a PHP accelerator, unfortunately Versio has not installed this, nor does it allow users to do so. buffering the other steps we can do ourselves, and in fact we can bypass all 4 steps by generating the pages once, store them as static pages, and redirect the browser to these pages.
Caching and other types of optimizing are made much easier by plugins for WordPress. Super Cache is a good plugin, but I’ve opted for W3 Total cache because, well, it has the more options to play around with. The options that I’ve used are:
- Page Cache- create static pages as cache
- Browser Cache – instruct the user’s Web browser to buffer certain data
- CDN – move data to a Content Delivery Network
The first and most important option of W3 Total cache is Page Cache. With Page Cache static pages can be created for each page that is requested, and is dynamically generated by WordPress. For a subsequent requests of the same page, nothing else needs to be done, other than sending this static page. This strongly reduces strain on the server and has a very good chance of improving results.
Below is an example: If we are the first time the start page of this Web site is created by WordPress and then return this _index.html if the page is buffered. I fact, the buffered page is even compressed to _index.html.gzip. This gives another 20 KB size reduction and every little bit helps.
The plug-in also supports database buffering and object buffering. This is particularly useful if some page aspects are relatively static, but other aspects change with every page load. In the case of this blog the pages usually remain fully static over for a certain amount of time, so this kind of intermediate caching is not useful in our case. Besides, performance gains of this type of intermediate caching are said to be less in shared hosting environments (such as I rent at Versio). I certainly did not see much improvement from some initial tests. Therefore, we will only look at static page caching.
Furthermore, W3 Cache also supports Content Delivery Networks. Now that we are this far, we might as well have a stab at setting up a CDN.