I was having a very large (500-1500ms) TTFB with nginx, wordpress, PHP 7 (php-fpm), and SSL. This was not the case on non-PHP sites, so it was safe to assume that PHP and SSL each could use some tuning.

2 things got me great improvement (<100ms TTFB):

1. Enable http2 in all of my SSL server blocks (needs nginx 1.9.5+)

   server {
     listen 443 ssl http2;
     #rest of your config here
   }
   

2. Set up fastcgi_cache

   In /etc/nginx/nginx.conf:

   fastcgi_cache_path /etc/nginx-cache levels=1:2 keys_zone=phpcache:100m inactive=60m;
   fastcgi_cache_key "$scheme$request_method$host$request_uri";
   

   In your server’s .conf file likely in /etc/nginx/conf.d/modify the php handling block

   location ~ [^/]\.php(/|$) {
   fastcgi_cache phpcache; # The name of the cache key-zone to use
   fastcgi_cache_valid 200 30m; # What to cache: 'Code 200' responses, for half an hour
   fastcgi_cache_methods GET HEAD; # What to cache: only GET and HEAD requests (not POST)
   add_header X-Fastcgi-Cache $upstream_cache_status; # Add header so we can see if the cache hits or misses
   
   # the rest of your existing stuff to handle PHP files here
   }
   

3. restart nginx sudo nginx -s reload

This reduced my TTFB to under 100ms consistently, and everything seems to be pretty happy :)

Yes, the results for domain name and IP address are the same.

I’m also not referring to the time for DNS lookup, Initial Connection and “Content Download” those all take as long as they take. I’m only referring to the time Nginx needs to send a response.

Is there anything I could do to make the machine respond faster?

OP right TTFB are very important but people don’t read between the lines
I have website Google lower it rank after I move it to another host TTFB was horrible and alot of page failure load .
In fact even VPS provider cheating about real resource you get Pleas read this

“” Also, be wary of virtual or “on-demand” hosting systems. These systems will suspend or pause your virtual server if you have not received traffic for a certain period of time. Then, when a new user accesses your site, they will initiate a “resume” activity to spin that server back up for processing. Depending on the provider, this initial resume could take 10 or more seconds to complete. If that first user is the Google search bot, your TTFB metric from that request could be truly awful. “”

http://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte
I think the only solution is using Low End Decided Server Or Xen VPS As it are Hardware Virtualization

setting up fastcgi_cache did a good job of shortening ttfb

Many think that time-to-first-byte isn’t the most important metric, and I tend to agree. From the end user perspective TTFB doesn’t really matter. They care about when the site is usable.

Nginx is unlikely to be the culprit. Often TTFB has more to do with DNS lookup than your server. Are you seeing similar results using both your domain name and IP address? For instance, on a site I run total load time on first view is identical when accessed via IP or domain, but the TTFB is nearly double when using the domain name.

This is an old thread, but I can’t seem to find a suitable answer from DO on this matter.

using pingdom speedtest tool, I get a consistent wait time of around 1 and 1.5 seconds. DNS and connect is about 75 ms.

I would like to understand why this is happening. what can cause this long wait time. everything else is super fast.

I’ve been seeing this for the past few months, but I remember having total page loads under 500 ms but that is not happening anymore.

any input on this would be great

I also would like to see some more comments on this!

I am using 1GB in Frankfurt.

I did a test with a replicated website and TTFB from DO is failing behind the LightningBase shared hosting. I made the test with the main domain loading from LightningBase and the same site on a subdomain loading from DO with ServerPilot.

I need to knock this one down.

Last inputs after some more testing.

TTFB gets tiny when we use PHP 7, WP Rocket and CloudFlare (freeplan).

Small sites are loading from the closest test location in less than half a second (pingdom) and a bit heavier ones 1-1.5 sec. We get pingdom results as generally fastest than 96%-99% of all tested websites.

Give it a try and make some tests. Let me know if guidance is needed for newbies. We can make a short tut/article about it.

i just posted a reply here and this stupid DO has rejected my answer for spam%% What?
i was gonna say enabling/configuring fastcgi_cache helped me alot (nginx, yes)

Your solution is awesome and working fine but We are facing an issue with our Magento 2 Application
and it gets cached everything.

TTFB for our application is always keep between 1s to 2s. I have checked the Magento application execution time which keeps around 400-600ms to complete the execution of the request.

Please find the details about application.

1. Magento 2.1.7 Application
2. Our application is hosted on Google Cloud with load balancer, varnish container for full page cache, Redis container for session storage, RDS (mysql) and two instances with nginx
3. SSL integrated site
4. CDN: Cloud Front for static content (media and assets files)

I am working to resolve the issue since last 2 months but not able to find any such solutions for the same.

Please provide any suggestions for the same.

Thanks.
Paresh

That helped me!

Thanks!!!

Be ware, that caching will also cache the simplest dynamic content, like:

<?php echo date('Y-m-d H:i');?>

will be displayed as cached content (that exact minute, when the current page was last time cached) and not change until cache expire