5 Ways To Reduce Server Response Time (TTFB)

Firstly, a disclaimer: I am the biggest fan of improving server response time you will ever find. That being said, in no way am I a fan of cherry-picking trendy metrics or phrases when it comes to website performance, as ultimately everything is related. From DNS, to RAM memory, to SSL certificates, to a website’s layout, to content formatting… everything can effect everything else, and ultimately, your business reputation and customer conversions (whatever that may be).

More specifically, I rather despise the recently-popular term TTFB because it is nearly always misused. Instead of referring to its decades-old networking reference — which encompasses the combined time of network latency + first HTML packet response to a user’s browser from a given web server — it has been perverted in the last few years to mean something altogether different; i.e. either being inaccurately attributed to “HTTP headers” sent by a web server (i.e. 200 or 404), or to when any given file begins to “load” on a web page after DNS/socket connections are complete.

In short, neither is an accurate use of the term TTFB. For that reason, it makes much more sense to simply discuss ‘server response time’ as a more generic concept, meaning how fast a server is able to respond to HTTP requests in the absence of network latency. And, while I prefer to focus on the bigger picture when it comes to improving website performance (and therefore business success), I do recognize that initial server response time is a large part of that. Without further ado, here are the top ways you can improve the quickness of your website’s initial HTML packet responses:

1. Make sure your DNS supports Anycast. Although server response time doesn’t include network latency calculations, it still makes sense to include DNS optimization in this article as its something that is easily within the control of the webmaster and/or server administrator. Anycast is a far-too-often ignored technology that makes domain resolution impressively more fast and stable than other older DNS methods. Without delving into all the amazing benefits of Anycast, suffice it to say that it is rapidly becoming THE form of DNS resolution on the web, so be sure your domain is properly implementing it. One of the easiest ways to be sure of this is to point your domain’s nameservers at CloudFlare (and away from your domain registrar’s system) and use their free service to manage your domain’s DNS records from there on out. Choosing a cutting-edge web hosting datacenter that uses top notch hardware and that is located in the most well-connected internet hub cities across the world (i.e. DigitalOcean) also can help tremendously in cutting down on network latency.

2. Ensure your site has plenty of CPU/RAM. Ultimately, one of the biggest “causes” of slow server response time (remember, network latency aside) is the time it takes for the web server to process and send back the specific HTTP request to the user/client. Specifically, this is usually due to the dynamic nature of content management systems (CMS) such as WordPress, which literally must “build” the web page for every single request. In contrast with static HTML pages, dynamic pages use server-side preprocessors like PHP or ASP to process and create page content (usually while making database queries), meaning that the web server has to “think” and then “deliver” the final HTML, often with database “fetching” in between. Obviously, this is a lot more complicated than your basic HTML page, meaning that plenty of CPU power and RAM memory needs to be available. Making sure that no other websites or applications are hosted on the server is also very effective.

3. Caching (emulate static HTML content). By now, most attentive webmasters in the world have heard of caching, often available by way of free web cache “plugins” for platforms such as WordPress. While its common knowledge that caches can help speed up a website, perhaps its less commonly understood that the reason for this is because caching helps convert “dynamic” content into a form of “static” content using one of several methods. Anytime that you can reduce the amount of “processing” required to produce final HTML content for site visitors, the better, and that is exactly what these caching methods do: by taking a “snapshot” of a web page’s content and then storing it either in the server’s RAM memory, or as a small (temporary) file, or otherwise, these cache systems allow a visitor to load as much of a web page as possible without waiting for as much processing or database fetching as would otherwise be required. CDNs like MaxCDN also help to cache static files as well, such as images/JS/CSS/fonts etc, and serve them from third party servers that are physically nearest to the user requesting them (improves network latency AND server resources); some CDNs are now even experimenting with something called “dynamic caching” which aims to literally do away with previously non-cacheable dynamic data queries!

For simple websites, you could also enable the “cache all” feature in CloudFlare (article coming soon).

4. Disable GZIP compression on your server. Before you gasp, please recall the purpose of this article: improving server response times, NOT the overall page loading time. Like I said earlier, I don’t believe in cherry-picking or obsessing over niche concepts like TTFB, so I would NEVER disable GZIP on my own (non-SSL) servers (yet). That being said, as announced by CloudFlare back in July 2012, GZIP does in fact inadvertently result in a slower initial HTML packet being sent by web servers, despite its ability to greatly speed up the overall time it takes to fully load a web page. Now, if you are a douchey software programmer from Google, you might decide to publicly troll CloudFlare/Nginx for this fact, rather than appreciating the stellar performance and security that the setup offers users FREE of charge. In any regard, disabling GZIP will soon be a lot less controversial in the coming months and years now that HTTP/2 (SPDY) is being rolled out in Nginx and web browsers, which largely relies on an encrypted (SSL) connection in order to achieve its faster browsing speed, and since GZIP is already not recommended whenever an SSL connection is being used (due to security concerns). Plus, HTTP/2 includes its own HPACK compression method in lieu of GZIP, meaning that this entire discussion will likely soon be null.

It is important to note that HPACK only compresses HTTP headers, not page content, by default. However, the exceptional performance improvements of HTTP/2 and its ability to load simultaneous website resources using multiplexing and server PUSH methods may render GZIP page compression less relevant.

5. Consider ‘early flushing’ techniques. Ultimately, whether or not GZIP/Nginx is able to improve its “TTFB” issues, the truth is that GZIP will become less emphasized as HTTP/2 continues to develop along with other evolving acceleration techniques i.e. server PUSH, dynamic caching, etc. Still, there is one more lesser-known technique to speed up the initial HTTP data sent to a client’s browser known as early flushing, which involves sending out the HEAD section of an HTML document in the initial data packet so that a client’s browser can begin rendering a web page, faster (or so goes the idea). While Google’s PageSpeed module provides support for Flush Resources Early, there is currently no other user-friendly way to enable this feature sans serious programming ability — plus, it does have some potential compatibility issues. The CloudFlare team has mentioned publicly that they are working on a way to deliver initial HTML faster, although no specifics have been announced yet (but interestingly, the hosted version of Google PageSpeed shut down earlier this year, which CloudFlare was quick to leverage).

At the end of the day, improving your server response time can ONLY be a good thing, as long as you realize that there are many other items to keep in mind when it comes to the speed, stability, and security of your website. Google, among others, has specifically recommended a server response time of 200ms or less, so hopefully some of the above items help you achieve this. Unfortunately, my favorite 200ms testing tool 200please.com suddenly disappeared early in 2015 for unknown reasons, so for now you can try using alternatives like PageSpeed, Pingdom, or Webpagetest.