Day 1 – how it started

For a few weeks I had my own server at my provider. Basically I could squeeze some Unix-experience out of my brain from times past and configured it. Testing from various sources showed load times of 700 ms for simple sites (not really that simple) up to 1.3s for one of the most complex single sites possible in wordpress. Overall I was content and didn’t feel the need for more Unix until …

Why speed is important

Lmgify – let me google it for you: “Why is website speed important?” results in 593 million hits. There are a myriad of reasons. The most simple reasons are: search engines, especially Google as well as site viewers don’t like to wait. Waiting times above 1.5s for the average user result in problems with either group. A long TTFB (see below), like 1+s shows severe problems and results in SEO downgrades by google for the website. TTFBs like that are actually common for several shared hosters during “rush hour”.

About Google and site speed (esspecially for TTFB – time to first byte) there is a nice article by Billy Hoffman: How Website Speed Actually Impacts Search Ranking.

A good starting point are the usual suspects – when trying those, always try to choose a site in reasonable distance to your server (network-wise). It makes no sense to test a server in Europe from Dallas. That being said, here are some for your testing needs:

And much, much more. Keep in mind to take those results always with a grain of salt. Some websites perform more complex tasks for testing, others like to “exaggerate” their results to sell you some hosting services afterwards ;). Personally I am a fan of pingdom. Their Amsterdam server has a reasonable distance to my servers, while also showing a good waterfall model of the site tested. Apart from that, their results in speed seem to reflect reality for my average users in Europe and America (depending which server of mine).

Next generation WordPress stack

That was until I saw a video of Mark Jaquith “Next Generation WordPress Hosting Stack” at WCEU 2014. Something like 26ms for a site with a next generation WordPress stack. Impossible? He got me cold.

It was all about nginx as web server and reverse proxy, HHVM, WordPress and Redis. Now, a few weeks later and after a lot of testing, compiling, installing, browsing the web, writing notes, retesting,… I got my answer: He is wrong and he is right.

He is wrong

“One Does Not Simply Walk into Mordor.”

Even if his web server is lightning fast, there is network latency, network nodes (routers, firewalls,..), time to render on the browser, hierarchic load order,… Even in “easy sites” this is not doable. Take for example a basic WordPress site:

  • One html-page
  • One CSS-file
  • About 10 images
  • Javascript and
  • Two custom fonts

In this example, the browser acts as follows (standard http) in the following order:

  1. Client: Hello, send me your first page!
  2. Server: Gotcha I give you index.html
  3. Client: index.html told me I also need a Javascript, 8 images and a CSS-file!
  4. Server: Yo man, here you are.
  5. Client: CSS told me I need two fonts.
  6. Server: Here you go man.
  7. Client: browser starts rendering the page, initiates Javascript…
  8. Client: Javascript tells me I need two more images.
  9. Server: Here! Are you done now?
  10. Client: browser finishes rendering the page … done.

So basically the Client-browser needs 4 or more trips to the server to retrieve all content and finally render the page (yes, there are a lot of optimizations possible here – up to inlining javascript and images, yet that is not the point here).

Judging from this simple example, Mark is wrong – it is impossible. Even worse: with complex WordPress themes with up to 90+ requests to the server such a speed is not feasible.

He is right

Now, weeks later after a lot of testing I do know what he “apparently” meant when Mark mentioned those 26ms. It is probably the time to request and download the “first page” locally on the server itself. Something which of course makes sense, since such a number leaves network latency and congestion out of the equation. Therefore making those numbers comparable as long as the page is of reasonable “normal” size ( size < 5MB ).

Or he referred to “time to first byte” (TTFB). Unfortunately this value is hard to pinpoint and compare with other sites. Simply since this value heavily relies also on network hops as well as latency of each hop (bandwidth shouldn’t be an issue since packet headers are of small size).

It was this time, where I went back to my “last generation WordPress stack” to find out, that my old stack did:

  • 40ms full page load on a seriously complex site in hierarchical load order (same machine).
  • 570ms full page load from a different machine.
  • 15ms time to first byte (TTFB) on the same server.

“Yeah, baby!”

Finally that speed didn’t look that frightening anymore. Testings with my current test site revealed “more” appealing numbers:

  • 1ms full page load on the same machine.
  • ~16ms full page load from another machine on the same network.
  • ?ms TTFB on same server. Time is definitly below 1ms, but of course above 0ms.

Right now it seems I have to standardize testing for me. Yet these results on my next stack look encouraging.


Time to first byte was some hype starting in 2012. Of course it got pushed by high-end, high-value hosting companies. After all it was one indication attesting quality of their service.  By that time TTFB was not as important as it is today. Yet nowadays less people talk about it (talk about beating a dead horse).

John at Cloudflare offered nice insights to TTFB in 2012. As long as you can ignore the underlying “marketing speak”, it is a nice read. What makes me wonder is Cloudflare’s inability at that time to have both: high compression and low TTFB. Guess by now they got the idea of dual NGINX stacks or NGINX sandwiches.

You can use for TTFB-testing. Just remember that network latency applies here also. As such the TTFB from Melbourne to Paris is on regular alot higher than from Lyon to Paris.

Bottom line

Above is a short summary of what got me started until today. After my tests I believe to have a sane understanding on how to squeeze the last ms out of my stack. I do believe once I am done, I approach the limit set by my server’s RAM and bus speed.

Yes, it is all about numbers. The basic issue for WordPress in speed is always about dynamic content versus caching. How can you cache your content in a smart way, while keeping your site dynamic?

This is, what this blog is all about.


Right now I am configuring servers and browsing notes from my many tests on speed. I have yet to decide, if I take my “last generation WordPress stack” notes first to put those together or if I jump ahead to write about the solution, which results from my tests (I still have to configure it for production – yikes).

Take the ride.

Until next time