I love Cloudflare. Among other things, they are the largest CDN company in the world. They are massive. Almost every other developer or SysAdmin I know has at least one website on their network.
But nothing is perfect, and Cloudflare can actually increase your website’s TTFB in some cases.
What is Cloudflare?
Cloudflare markets itself as an all-in-one Web Performance company and they operate a CDN Network. They have the largest geo network of servers among the CDN providers. Setting up a site on CloudFlare is also extremely easy, you just need to change your nameservers.
Cloudflare is very performance-oriented, and they mostly deliver on their promise. Cloudflare automatically distributes your website’s static files through its CDN servers strategically positioned around the globe. They also have some advanced optimization options, like Image Optimizations and JavaScript asynchronous loading.
CloudFlare’s multi-layer optimizations can visibly improve your website’s loading time if you had a slower site. But things start to get a little strange when your website had already been fast.
Okay, now what is TTFB and why should we care?
TTFB means Time to the first byte. It’s a metric. According to Wikipedia –
Time to first byte (TTFB) is a measurement used as an indication of the responsiveness of a web server or other network resource. TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client’s browser.
Oversimplified, it basically means the amount of time your browser has to wait between sending a yo-send-me-the-page message to a website and before it starts to hear back from the website.
You should care about Time-to-first-byte because Google does. Google recommends that you have a TTFB lower than 200ms. That is 20% of a second.
If you have a high TTFB, you will also have a lower PageSpeed Score on Google’s PageSpeed Insights.
PageSpeed is the most important ranking signal Google uses besides high-quality content. If you have very original, plagiarism-free high-quality content but have a low PageSpeed score – your website will struggle to compete with other sites in the niche.
TTFB-wise, CloudFlare can make some websites even slower.
How Cloudflare impacts TTFB
General explanation
Cloudflare acts as a “reverse-proxy service”. Cloudflare sits between the user and the actual web server.
Let’s assume we have a website on Cloudflare. Say it’s example.com. The server that hosts example.com is its Origin Server.
If we visit example.com from a browser (call it browser1), the request flow would be like this:
browser1 requests example.com –> CloudFlare recieves that request –> CloudFlare looks for page on example.com Origin Server –> CloudFlare recieves page from example.com Origin Server –> CloudFlare prepares cached static files + uncached HTML –> CloudFlare finally returns to the user and sends the prepared request
Here, the time between the browser’s request and CloudFlare’s response is viewed as TTFB.
The ==Origin Server== also needs some time to prepare an HTML response. Because Cloudflare needs to 1. fetch up-to-date data from the Origin Server and 2. combine it with cached static files, it can actually make TTFB worse.
Technical explanation and other causes
CloudFlare’s geo-distributed Edge Nodes (their CDN servers) run a heavily modified version of the Nginx web server. By default, CloudFlare’s Edges does the following optimizations:
- Minifies JS, CSS, and HTML resources.
- Adds gzip or brotli compression to anything that goes through its Edge Nodes.
- Caches static contents.
#1 and #3 both are stored to and served from Edge Cache, so the initial processing time shouldn’t matter. But #2 is not cached.
Here the problem begins. Assume we have a LEMP (Linux+Nginx+MySQL+PHP) stack on our Origin Server. This is a fairly common setup. Suppose we are using the default settings on our Nginx.conf.
By default, Nginx adds a level 6 gzip compression to all static responses on the fly. This means any request that passes through this setup is gzip compressed, and gzipped versions are not cached for repeated requests.
Compression has a cost – time. As the Origin Server needs to compress every request, this further contributes to the latency. Gzip’s level 6 is too much in my opinion, as any saving beyond level 2 is mostly insignificant. If you are using gzip without caching, you are already stressing your server.
Now comes the real problem. Cloudflare also does gzip compression, and it does it on-the-fly. It does say though that it respects your server setting, and does not compress an already compressed gzip file.
That’s it. CloudFlare’s technical explanation for the types and methods of compressions does not exist.
But why doesn’t Cloudflare find a solution?
The attitude, apparently. Cloudflare acknowledges that the way its CDN acts can make a website’s TTFB longer, but they prefer to find an excuse rather than a solution.
But the users don’t quite agree…
What are the solutions? How do I make my TTFB faster on Cloudflare?
Despite Cloudflare increasing TTFB, there are still plenty of reasons to use Cloudflare. Cloudflare has a very robust network. They are trusted, and they have the largest CDN network, etc. With proper optimization and some workarounds, you can probably even have TTFB closer to your direct request to your ==Origin Server==.
Some possible workarounds might be:
1. Origin Server optimization: We can tune our origin server so it does not “over-compress” static files. We can also implement a system that caches repeated gzip requests. Cloudflare only skips compression if a proper gzip HTTP header is sent, so we need to make sure our Origin Server is sending the right header.
2. Full Page Caching: Origin Server needs time to serve HTML from PHP. It has to parse information from the database, and it has to make PHP calls. If you have a website that stays mostly static for visitors (most business sites), you can use a server-side caching solution like FastCGI Caching, Nginx Proxy Caching, Varnish Cache, or maybe even CMS-specific caching like W3 Total Cache.
The catch here is – you need to modify your caching mechanism to work with Cloudflare. Otherwise, you will have one set of cache on your ==Origin Server==, and another on Cloudflare.
3. CloudFlare’s Railgun: If you are on CloudFlare’s $200/mo Business Plan, you can use Railgun to reduce TTFB. Railgun is CloudFlare proprietary software that can be installed on the Origin Server to ensure highly efficient Edge caching.
I have successfully implemented and tested the above workarounds on numerous projects, and I tuned the TTFBs of these projects to exceed Google’s recommendations.
If you need some suggestions or want to work with me – just get in touch!
