What's causing 1762ms "First Byte Time" & is it something I can fix?

Hi. Can anyone help, please?

My test result:

We’re on WordPress and I’ve disabled all unnecessary plugins.
We use Wordfence Falcon Engine, plus caching.
We also use several settings on Cloudflare for security, plus “Aggressive” level caching. (Overkill? Counterproductive?)

UPDATE: First byte time is 2200+ ms with Cloudflare paused. ;( http://www.webpagetest.org/result/150520_QM_15M8/

Our Time to First Byte is a horrendous 1762ms. Thanks for any help you can offer.

Are you sure that caching works as it is supposed to? I really doubt it.

Well, actually no. ;} I do know that it’s working… but how would I test if it’s working “as it’s supposed to”?

Thanks for the question!

The setup that’s worked really well for me with wordpress is W3 total cache configured to work in conjunction with cloudflare. It’s worth your time trying it, it was the fastest config I could find.

Here’s a guide: http://www.bloggingspell.com/w3-total-cache-cloudflare/

More I look at this I dont think cloudflare is doing much for you as it’s setup right now. It may be caching (but with the high TTFB im not even sure of that). It doesn’t look like it’s minifying CSS and also doesnt look like rocketloader is enabled. At least not for your landing page. Sometimes rocketloader will break things, but when it doesnt, it helps a lot.

Make sure you add your stats/piwik subdomain to CF so your analytics js gets cached at the edge servers too.

I’d also recommend further reducing the (byte) size of some of your images. Of course this is not related to you TTFB but nonetheless affects the page size (around 4mb right now) and load time.
A quick win for images would be to convert you pngs to jpgs. Especially this one:

You mobile users will thank you for it especially.
A dynamic alternative would be to use cloudflare pro and enable mirage which optimizes images per device and connection on the fly.

I would look into the caching myself, maybe try a different caching plugin (W3 Total or ZenCache are the ones I would recommend).

Just because you have all the unnecessary plugins disabled doesn’t mean to say it isn’t still a plugin related problem - unless your saying your site is running on a WP install with a single plugin ;).

I would then disable ALL the plugins and see where the land lays then regarding TTFB. It would then be a process of elimination - of turning them back on, one by one until you find one that makes the TTFB jump dramatically.

It may not be a single plugin that is at fault, but may be a few that are misbehaving, so once you’ve got the one you think isn’t working, test it in isolation to see if it is a problem by itself and if it isn’t, try to figure out which other plugin is interfering and go from there.

If it is an errant plugin, then swap it out with another plugin that does the same job or develop it yourselves.


Although looking at the waterfall chart, once you’ve got the TTFB problem resolved, there are some things you should certainly pay attention to:
[]Merge all the JS and put them at the bottom of the body tag
]Optimise the images
[]Remove the 404’ing google font CSS
]Enable keep alive headers on your server
[*]Ensure that the google resources aren’t fetched from the HTTPS url - it’s only adding an extra HTTPS handshake for no gain

Wow, I didn’t realize I had all these replies; I wasn’t notified. Sorry!

You all have given me some ideas in troubleshooting this. I’ll tweak and report back.

I will say, though, that we’ve used numerous caching plugins and configs, but Wordfence has been the one that’s helped with load time most notably—and that hasn’t broken functionality along the way. (Rocketloader does break much functionality, for instance.)

Thanks for your help. This was really a temporary config until I had time to dig in again to further optimize.

Hello all!

Thanks to your awesome suggestions, I was able to accomplish the following:


  • Page load time 2.73s
  • Reduced repeat load time (1.81s)
  • TTFB: 0.281s!!!
  • Grades [B, A, A, B, B, check]

Namely, I:

  • Switched to W3TC and turned off Wordfence Falcon engine
  • Did everything in JAP’s article: http://www.bloggingspell.com/w3-total-cache-cloudflare/
  • CHANGED Cloudflare browser cache expire to at 1 month (5 days, JamesAtPulsate, gave an “F”)
  • Made all page images JPGs and progressive

I await PMs with rates for optimizing further, particularly for merging JS (which I don’t think I can
personally and easily do for all the plugins), for enabling Keep Alive (as I’ve never been able to figure
that out as quickly as needed, and for fetching Google resources from HTTP, not SSL.

BTW, when I add my Piwik subdomain to caching, it causes stats not to display—that’s why I excluded it
in CF a few months back. (It was tracking stats, just not showing them in admin, and I think all Piwik
images were also broken.)

Thanks again.

Nice job. Set browser cache as far out as you like depending on how often you change the content. You can always flush the cache after you make changes too.

Before you go about combining .js and so on, it might be worthwhile to test performance with SPDY+SSL as an iterative measure. You can do this without purchasing your own SSL cert.

To setup SSL + SPDY in cloudflare…
Under “crypto” set “SSL (with SPDY)” To Flexible.
Under page rules, add a rule as follows
Url pattern http://.excellentpresence.com/
Always uses http: ON
Play with the url patter and wildcards to your liking.

Longer term, yes you do have a LOT of objects coming down so it would be worth seeing what you can remove or combine.
You can also try https://wordpress.org/plugins/footer-javascript/ to move them to the bottom. Seems like you are definitely knowledgeable to understand that this can have varied results.
I’m assuming rocketloader broke a few things for you?

Some of the other pages need some love too: http://www.webpagetest.org/result/150528_YQ_4T5/1/details/

That’s interesting about piwik & cloudflare. You could try a page rule in CF (even though its not really a page, rather a subdomain) for it that turns off a lot of the acceleration features, but keeps it on the edge servers.

Hi James.

You’re right; there are definitely some load time issues. Once I get final versions of the pages,
sales copy, images, etc., I’ll focus on load times for all of those at once. ツ

Indeed, I’ve tried merging JS already and moving them to bottom, which broke things. Yes,
Rocketloader also broke most of the primary theme functions, though I can no longer
remember specifically which.

About SPDY + SSL, I’d never heard of that. I’m not using anything SSL intentionally, so I suppose
that’s something to investigate. Maybe the theme is the culprit.

I believe I know how to attempt “keep alive,” and will also try the CF page rule.

Would you mind giving a hint, though, on how to “ensure that the google resources aren’t fetched
from the HTTPS URL”?

You’ve been awesome, thanks!

[quote=“ThePrez, post:10, topic:9394”]
About SPDY + SSL, I’d never heard of that. I’m not using anything SSL intentionally, so I suppose
that’s something to investigate. Maybe the theme is the culprit. [/quote]

Now that you have your TTFB under control with page caching, I think looking at the theme is not a bad idea. The data payload of the pages isn’t that bad, but there are lots and lots of objects coming down and that’s holding up the show. Especially on mobile. So looking at some other themes and or a different form plugin won’t hurt.
Cognito forms accounts for 7 objects/files on this page: excellentpresence.com/improve-website-performance/
So depending on the exact functionality and ease of setup you need, you could accomplish capturing this information from people with zero objects. Something to think about.

Perhaps the developer of your existing theme can help trim the fat off the features you are not using.

Where did this spring up from?

Hi WebsiteSpeedExperts. Would you mind giving a hint as to how this might be possible?

JamesAtPulsate, I apologize; that wasn’t your recommendation! But if you do have suggestions, I’d certainly be open and very appreciative. Thanks much once again.

Indeed, the last major theme update has greatly sped things up, so say the devs; I just need to make time to switch over. I’ll report back here if I’m able to materially reduce load time or TTFB even more.

I hope you all have a relaxing weekend!

Ah. Yes if you’re not using https for the site, then there’s no point in pulling some objects over https if you don’t need to. Depending on what is calling them it may or may not be easy to do this. But if you can get to where those url’s are triggered, id reccomend you change the urls and NOT specify a protocol. By doing this they will pull down in either http or https depending on how the page is called down.

Lets go on the assumption that NON SSL + SPDY is not benefiting performance and you want to get rid of the other SSl handshakes.
Example URL in your site’s code would display say https://targetURL
Conventional wisdom would say change this to http://targetURL
What you SHOULD do is set it as simply //targetURL. No http or https

This gives you the maximum flexibility to swap back an forth between delivering over http and https without having to get back into the code each time.

Same to you.