0.4 Secs Load Time Nationwide w/ FastCGI Cache

We recently announced that FastCGI Cache was successfully activated across our entire managed hosting network, on every single plan that we offer — accordingly, our system now auto-deletes any WordPress cache plugins it finds.

FastCGI Cache, an open source cache that comes packaged inside the Nginx server, has been steadily gaining popularity over the last few years as more sysadmins abandon the older proxy_pass caching method in Nginx, and as more websites realize the performance benefits of dynamic caching at the server level rather than at the application level (e.g. ditching WordPress page cache plugins, which usually require PHP processing to deliver cache files).

WITHOUT FASTCGI CACHE:  Request ===> DNS ===> Nginx ===> PHP/WordPress ===> Cache File

WITH FASTCGI CACHE:  Request ===> DNS ===> Nginx ===> Cache File

We are pleased to say that we’ve seen no issues so far with this new configuration, and in fact have seen a jump in the number of client websites responding with cache headers. Our centralized bash script library that controls our hosting network is also running better than ever before, and with recent additions it now allows us to rapidly tweak the configuration of hundreds or thousands of servers at the same time, including things like Nginx server blocks or FastCGI Cache settings.

Loads Consistently “Fast” In Multiple Geographical Locations

If you’ve followed LittleBizzy for the last few years, you may have noticed that we used to “advertise” our website’s loading speed at the top of each page as part of our sales pitch, which stood around 0.3 or 0.4 seconds when selecting a “nearby” speed test location on Pingdom.com. Although our site’s design has evolved and we’ve subsequently removed those banners, we wanted to re-visit our own loading speeds in this blog post since activating FastCGI Cache; it is especially relevant as our website is running on the exact same LEMP stack configuration that we sell to our customers (we run on the Business plan).

Previously, we were only able to achieve the 0.3-0.4 seconds load time when testing from a nearby city. In other words, while hosted on DigitalOcean’s New York datacenter, we were able to achieve the 0.3-0.4 seconds result on Pingdom only when testing from their New York testing zone. (Without getting into the TTFB debate and things like network latency, consider tools like Pingdom a good prediction of load time only if you were in that city on a “very good” computer and a “very good” internet connection… because of things like latency, you will rarely see the same result when testing speed from e.g. your iPad while browsing from the local Starbucks WiFi connection.) Prior to using FastCGI Cache, when testing from “other” cities in the United States such as Dallas or San Jose, we usually showed load times closer to 0.9-1.2 second load times, for example.

After adding FastCGI Cache to our stack, however — along with PHP 7 and MySQL 5.7 — we are now able to achieve rather impressive load times across the country, and beyond. For example, with our homepage currently hosted in a Dallas datacenter managed by Vultr, we still achieve around a 0.3 seconds load time when testing from Dallas area datacenter tools, BUT we also now achieve around a 0.4 second load time from all the way in San Jose, too.

It doesn’t stop there. We are now also seeing 0.7 second load times from as far away as Stockholm, and if we test from all the way down under in Melbourne, Australia we can still achieve times of less than 1.2 seconds.

If you happen to be in the “Pingdom isn’t accurate” camp, GTMetrix also gives us a 1.0 seconds fully loaded score from London, along with a 0.7 seconds score from Vancouver, and finally a 0.3 seconds score from Dallas itself.

Even if we change to Sao Paolo, Brazil, and throttle the connection to a DSL-level speed cap, we can still achieve a fully loaded desktop speed time of less than 3.9 seconds. Not so bad, eh?

All of this is possible with our standard LEMP configuration, without any Redis/Memcached or object caching, and without any custom tmpdsk (RAM) based delivery system — just good old fashion Nginx cache files stored to the SSD drive. And for the record, our website runs WooCommerce, loads various Google Fonts, Material Icons, and even Google Analytics… and we don’t use any janky minification or javascript async plugins either! Of course, smart coding is still a large part of loading speed, so if your website suffers from severe “bloat” then keep an eye out for our upcoming free Starter Theme.