November 28, 2022

NGINX Tuning and Time To First Byte: A Real Case Study on TTFB

A real case study on TTFB benefits after NGINX web server tuning

The subject of this article was born to perfection, after several weeks of "lack of inspiration" on topics related to web performance. Either because Black Friday absorbed the energies for customer e-commerce scaling, or because we are putting a lot of meat on the fire with the development of plugins for Prestashop and Magento, as well as our dedicated CDN solution for adaptive images, but above all because we talked a lot about the technologies at work and in use in our specific software stack for WordPress.

Anyone who has read and followed the articles and posts published over time has certainly noticed how there are regular recurrences on technical articles when it comes to WordPress Hosting or Linux Hosting in a more general way.

We always end up talking about NGINX and Varnish as the ultimate combo when it comes to performance and speed, often forgetting how important painstaking tuning is to obtain adequate values ​​such as the best possible TTFB.

We talked for a long time the importance of a TTFB as low as possible, and how important it is to get low latency; however, we have never been able to document with a differential analysis two identical sites with the same stack and a further optimization of the software stack and a specific tuning for NGINX Web server.

The specific case born by chance.

Last evening we posted a post on the private Facebook wall where TTFB was measured using the utility, an online service that allows you to measure TTFB from multiple locations around the world.

From what was initially a "sterile" post, written on a gloomy Sunday and without too many goals, other than to externalize a small Vanity Metrics and "make us beautiful", several comments arose from there until late in the evening in which many they responded by posting their scores and the evaluations that this online tool returned.

Facebook Post Marco Marcoaldi SpeedVitals

Among the 26 comments that you can see at the bottom right of the image above, we were particularly struck by the comment of one of our customers who showed a particularly high TTFB when compared with the one posted in the screen above.

In particular, it was highlighted that the evaluation returned was of grade B and that the scanning time of the Google spiders was not exactly very low, reaching 141ms.

Considering that the underlying software stack was practically the same, it was certainly necessary to go and review what the specific problems of the configurations of the Varnish and NGINX services were to try to improve and optimize everything as best as possible.

Analysis of the metrics of the site in question.

By chance, the problem raised was under our total control and therefore, even if on Sunday, we wanted to go into a "file job" aware that it would have been a tempting and unrepeatable opportunity to show and demonstrate how a superfine tuning would have been able to bring tangible benefits and end up documenting everything with this post which is nothing more than a differential analysis between the pre and post tuning situation.

We have therefore decided to use a utility called ByteCheck ( which allows us to measure the Time To First Byte and break down the total time into the various steps that make up the total TTFB.

Byte Check

Starting from the DNS resolution, to the connection time, to the establishment time of the encrypted connection, up to the waiting and delivery times of the contents, as we can see in the following image, in which it is evident in a rather evident and indisputable way that there is a particularly high waiting time of 240ms.

Objectively one wonders what the webserver (or the entire stack) does in those 240ms, too low a time to assume that the Varnish static cache is not working correctly, and at the same time, too high a value to assume that the software stack is functioning normally as best as possible.

We therefore wanted to test that the static cache was working correctly, using the Linux CURL utility, and examining the response from the HTTP headers.

[root@lawebstar ~]# curl -I HTTP/1.1 200 OK Server: nginx Date: Mon, 28 Nov 2022 00:26:46 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Vary: Accept-Encoding Strict-Transport-Security: max-age=86400; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Links: ; rel=preload; as=script Links: ; rel=preload; as=script Links: ; rel=preload; as=script Links: ; rel=preload; as=script Links: ; rel=preload; as=script Links: ; rel="" Referrer-Policy: no-referrer-when-downgrade X-Cacheable: YES X-Varnish: 2.2.0 12 Age: 2 Via: 32853419 varnish X-Cache: HIT

The answer in question left no doubt that the Varnish Static Cache was working correctly, having cached the response for 4656 seconds and that the static cache returned a HIT and not a MISS and therefore found (and delivered) the already stored response in the cache.

The problem, therefore, must have been upstream, according to the "sandwich" logic in which NGINX is both the webserver on which the website runs, and the reverse proxy terminator of the HTTPS connection, considering that Varnish does not support HTTPS and needs of an HTTPS terminator according to the following scheme.

We have therefore completely revised the NGINX configuration both globally and for individual Virtual Hosts, and by meticulously adjusting parameters such as buffers, as well as enabling some well-documented features in the latest NGINX versions starting from 1.22 onwards, we have obtained a decidedly optimal value. bringing the waiting time from 247ms to 124ms, or effectively halving the final TTFB.

mydoglegend TTFB Improved

Obviously, being a hosting company, we apologize in advance if we do not show the specific configuration files and document the changes made in detail, being in fact know-how that we tend not to disclose for obvious business reasons.

The importance of low TTFB and the benefits you will get from this tuning.

We have already talked about the importance of TTFB as we initially mentioned in this article: What is TTFB? How to improve the Time To First Byte, however it is good to highlight how Google with its parameters Core Web Vitals, has decreed that a TTFB below 200ms can be considered good, and a higher TTFB that needs improvement.

Someone could object or ask what are the real advantages of a TTFB that is compliant with Google's expectations, and if it is really so important to have a TTFB below 200ms.

What is certain, and which you will need to pay close attention to, is that the scanning frequency of Google spiders and TTFB are directly related.


You can see it from a history like above of Search Console.

You can understand from the two blue and orange lines, that as the response time increases, (TTFB orange line), crawl requests from Google decrease (Blue line).

Conversely, as TTFB response time decreases, Google crawl requests increase.

If you're looking to know Google's crawl stats, in Search Console, go to "Settings" at the bottom of the left column. In the Scan section, you will find the “Open Report” button for the scan statistics. When the report is open, you can select the “Average Response Time (ms)” checkbox to add the metric to the graph.

Google uses 200ms as the cutoff value in other tests and reports, before they display a warning that the response time is high. Response time varies depending on your hosting, site quality and general configuration of cache, CDN, ed in this case the tuning of the webserver.

Conclusions and observations

From this real and well-documented case, we can observe how the use of the right tools may not be sufficient to obtain the best results, which can instead be obtained by using the right tools, but also and above all by using the right configurations.

It is also useful to understand how the right configurations of months or years ago can suddenly be deemed no longer adequate or even surpassed by new metrics and new requirements that require a continuous cycle of adaptations to new requirements.

We will keep this case study under observation to evaluate also in terms of indexing with the SeoZoom utility, how this optimization may have impacted positioning and indexing, evaluating the graph before and after November 28th, the date on which we worked to improve the response of the two sites in question on the same server ( and and respectively evaluating the trend of the two sites in a future differential analysis.


Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.


Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top