Tuning performance to improve TTFB

I’m using the Cloudflare free plan and hosting on Cloudways. Performance is pretty good, but, it seems like the lag before the landing page starts to paint is longer than it should be. Waterfall charts show a server wating time of 250 to 375 milliseconds. This is slightly shorter with Cloudflare bypassed (but Cloudflare generally speeds the overall page load time).

I would think this wait time for the server could be much less than this, especially because my site is mostly cacheable (it’s a photography site without any kind of blog or forms) and because I have caching up the wazoo on my server: WP Rocket plugin (a lot of work gone into the settings), redis cache, Varnish.

In addition, I’ve tried to create a page rule to get Cloudflare to cache all content on the landing page. It’s hard to know if my page rule is working. If it did work, shouldn’t TTFB be very very fast?

What else should I be looking at?

Thank you for any thoughts.

Hi there. This article is somewhat old but may provide a little insight.

I’m curious what your TTFB is (250-375ms?) and what you’re trying to get it down to? I also run a photography site, thought it’s not wordpress - it’s a static site hosted via AWS S3. My TTFB is ~85ms, which is acceptable to me.

Thanks. I’m not specifically chasing TTFB numbers … I’m more concerned with the lag before 1st paint. You click the URL, there’s a conspicuous lag where nothing at all happens, and then BANG, the site appears. The waterfall charts show that most of that lag is the wait for the server’s response. So in this case, I think TTFB is a pretty decent metric.

And I’m not sure what I’m waiting for. Some of that time is going to be from Cloudflare acting as a proxy, but once my server gets the request, I’d think that everything should be cached and almost instant. Clearly I’m missing something.

Are you willing to provide your URL for deeper analysis? If not that’s ok too.

Since you mentioned this is a wordpress site, my first inclination is that there’s some render-blocking JS. Without seeing the waterfall it’s hard to confirm though… Is there a considerable difference between TTFB and First Paint? For my sites TTFB is <100ms and First Paint is <300ms, which seems reasonable to me (i’m not running wordpress though).

Sure. Here’s the url.

And here’s a waterfall chart that shows speed that’s on the fast side, so there probably aren’t any spurious things interfering.

Thank you. I ran some analysis with GTmetrix, Pingdom, Google, Varvy and Uptrends. I’m no expert, but the results lead me to believe that your external google fonts are render-blocking and attributing to your increased first paint time (~1 second).

FWIW, GTmetrix lists total page load at 1.4s (from Vancouver), Pingdom 1.7s from Stockholm, and Uptrends ranges from 0.0 - 0.9s (though i’ve never really been confident in their numbers).

It’s possible to download the google fonts and serve them from your origin server in order to cache them and reduce HTTP requests - I’ve done this with varying levels of success (close to negligible page-load reduction). But it’s something to consider. I understand you’re not chasing numbers, but on the other hand, everyone wants their site to be as fast as possible - myself included - so I can’t fault you for that.

P.S. you’re photos are really great :star_struck:

Thanks so much! I was just thinking about fonts today. They do seem to be a part of the problem. But I’m not completely convinced the time saved would be worth the complication of trying to serve them myself.

I still have my eye on that 300ms or so wait time at the beginning. I’ve seen wp sites on slower servers with 1/10th that.

And I’m curious about that favicon at the end, that straggles in long after everything else. This doesn’t really matter, because the important stuff is loaded by then, but I don’t know what that’s about. It’s just a blank file that wp throws in there.

Yes, there’s some debate over serving fonts locally vs. having google do it. Some would say google can serve them faster, but that’s just more external (uncachable) HTTP requests.

I used this guide to do it on one of my sites. localfont.com is a great way to easily download the files and associated CSS. The process is actually not that bad but you’ll have no way of appreciating any speed improvements until you fully complete the process - and even then, there may not be any increase in speed, so YMMV.

For the favicon, you can set this in wp-admin > appearance > customize > site icon (if you don’t have one already).

Yeah, I tried adding a tiny empty image as the site icon, but it actually slowed things down slightly. Now there’s no favicon selected, but wp (or the theme) is throwing in an invisible one as a default.

Problem solved. Some configuration problem was causing Varnish to quit without warning, and it took me a couple of days to catch. it.

I turned it on, browsed through the site to load up the cache, and now that wait time is down to 28ms(!). About a 1000% improvement. Page load speed in GT Metrix now below 450ms. Finally a problem that can be solved with a click.


I’m showing 17ms ttfb here in firefox and cache disabled. Good work!
If I hold down shift to reload, it’s closer to 50ms. That’s for DNS and TLS setup time.

1 Like

Hi. I have the exact same problem. I have a site on cloudways and my TFFB time after i was switching to Cloudflare just went up. So my waiting time is 350ms. I have varnish set up on cloudway server so I am very interested if you could share what changes you have done to varnish configuration. Thanks a lot. Kind regards.

Can you take a look on my post showing how this website itself lacks even basic optimization, and how everyone would appreciate if you guys pushed a fix to the discourse repo ( the backend that runs this website itself ).

It’s currently impossible to use discourse + Cloudflare CDN, as the SEO penalties will be too big.