WPEngine TTFB problem

I am a WordPress developer and I moved all of my themes to WPEngine Professional.

I have a problem with my themes that TTFB takes too long on first visits. I never had this problem before.

WPEngine Support has been great, but they can’t find any solution to this matter.

The site in question, skillful.fuelthemes.net, occasionally have fast load times, but usually has slow load times due to TTFB.

First byte usually takes around 4 seconds, resulting in 9 second First View:
http://www.webpagetest.org/result/140909_EE_90F/

There are several possible culprits. I’ve seen this over + over with clients who have left WPEngine to work with me.

Unfortunately, since WPEngine is a black box, some of this an only be fixed by leaving them.

Here are the culprits in order of precedence + which ones you can change.

  1. Test raw file speed. Here’s how

Create an empty foo.html file in your root wordpress directory + run a WPT test.

This will tell you how well the Operating System + File System is tuned. This test should run at subsecond speed. If not, you’ll either have to leave WPEngine or open a ticket with them to tune their OS + Filesystem.

  1. Have WPEngine provide you with an XPROF graph of your site.

On any sane system, you could do this yourself. Not WPEngine, it’s a black box.

Once you have the graph you can see the bottlenecks, which will tell you if your speed problem relates to your theme or your database.

A Ghetto test you can do is to just switch from your theme to Twenty Fourteen + run a WPT report.

If this fixes the problem you’ll have to optimize your theme + here’s how.

Make a BackupBuddy copy of your site + drop it on a sane system, where you can run a PHP IDE like NetBeans + just run through the code.

Fix all errors + bottlenecks + make a zip file of your fixed theme + reinstall your new fixed theme on your WPEngine install.

If you get stuck on any of these steps, google David Favor + be in touch + I’ll see if I can assist you.
[hr]
In most cases, the culprit is a combo of incorrectly tuned OS + Filesystem mount options.

Also, another huge culprit is putting /tmp on disk instead of in memory.

Here’s how the /tmp problem deteriorates speed.

Anytime MySQL/MariaDB does a SELECT which exceeds memory, temporary files are created in /tmp + if this is on disk + you have any traffic, your site will slow to a crawl.

Also, for logged in users, session credentials are kept on /tmp + when a logged in user goes from one page to another, the credentials are read from disk + tested.

The best way to handle all this massive file i/o is just setup every server with /tmp in memory + this will solve the database + session disk trash.

To add to dfavor’s comments, you are already serving a few static files from the root domain so #1 isn’t necessary. The css served from the main domain is right around the RTT to the server so raw file serving isn’t a problem.

It looks like in addition to the base page there is another php call to “selection.php” that takes a really long time to reply. It could still be database or something application specific.