Save the Internet from WordPress speed abuse.
Updated: December 2017
Many sites we evaluate for speed testing are using free Cloudflare CDN services. A CDN (content distribution network) is a way to get servers geographically closer to user and thus reduce latency. That’s the goal anyway.
CloudFlare is a US-based website performance company founded in 2009. CloudFlare claims to improve page load times and performance.
In the recent past, we’ve used free CloudFlare CDN services and their plugin to bulletproof our WordPress websites. Testing the Codium Grid theme, we found CloudFlare doesn’t guarantee consistent load speeds. During this project, we saw unpredictable and random page load times from 10 to 25 seconds. That’s unacceptable even if the average time is one second.
CloudFlare uses a modified version of NGINX – a key Russian-created technology. Nginx (engine-x) is an optimized open-source server software used in the LEMP stack (Linux, Nginx, MySQL, and PHP).
We first thought there was traffic congestion on the shared-hosting server. We checked using yougetsignal.com and found only three domains resided on the shared server. One was inactive and the other two had benign, low-traffic content. The server wasn’t our offender.
After plugin testing, it was clear that CloudFlare was the culprit throwing in random delays. We canceled the account and removed the plugin. Then things stabilized. We also got better results in WebPagetest.org. Our cached time improved from 750 milliseconds to a 500 millisecond load. We’re giddy from this discovery.
Christian Nelson, ally and web critic, saw this weird, random, delay phenomenon years ago – but not on CloudFlare. He’s maintained a low opinion of CDN solutions since. He’s right on the money. CDN response times can be unpredictable.
One more bad thing about CloudFlare CDN.
CloudFlare’s Nginx servers cause failure on time-to-first-byte measurements (TTFB). Usually shown as a red “F” as in failure or flunk using WebPagetest.org. This negative flag generated a brouhaha, and Cloudflare responded with a special blog entry about the topic and why they think it not a real problem. We agree. TTFB isn’t a problem. CloudFlare flakiness is the problem.
CloudFlare’s claim is “Gzip compression of web pages reduces the time it takes a web page to download, but the compression itself has a cost. That cost causes TTFB to be greater even though the complete download is quicker.” But only on Nginx servers. Apache servers are just fine.
Nginx waits until compression has started before sending the HTTP headers; when compression (Gzip) is turned off it sends the headers immediately.
Our complaint: Who cares about TTFB when CloudFlare throws a monkey wrench into the running engine and randomly gives 10 second to 20 second page loads? Hiccups aren’t acceptable.
Stop worrying about Time To First Byte (TTFB)
05 Jul 2012 by John Graham-Cumming of CloudFlare. (A rebuttal).
Our experience is Cloudflare CDN is notorious for slowing down your site with 500 and 501 server errors. That’s probably where your TTFB errors are coming from. Cloudflare uses NGINX servers instead of Apache. This causes lazy loading of all Gzip compressed assets. Unnecessary delays. TTFB is the only metric Google uses in their SEO ranking algorithms.
Using Cloudflare would explain the reason for your speed fluctuations. We do not recommend them – nor any CDN for that matter. CDNs are band-aids for poorly optimized websites. It’s better to build quality into your site.
Cloudflare ran a test and concluded that time to first byte (TTFB) does not matter. Except, it absolutely does. As they say: if you’re experiment contradicts intuition, check your experiment.
—Ilya Grigorik, Web Performance Engineer at Google
Offsite link: CloudFlare Makes Websites Slower, Not Faster “I noticed that my CloudFlare-enabled sites became much slower and they would often time out.”
Mobile WordPress Speed – without coding!