Huge first time to bytes

I ran a test and the time to first bytes is about 3.5 seconds.

test results

Any reason why?

Looks like you’re on WordPress. it’s not uncommon to see really long first byte times, particularly if you are on shared hosting. It’s largely a database performance issue but the most common way to fix it is to install the W3 Total Cache plugin and turn on page caching. That will cache the assembled html on the server so it doesn’t have to query the database to assemble the page for every visitor.

I ran the 5 test and FTTB went up as far as 8 seconds.
Thanks, Pat. It is a ded. server and is heavily modified WordPress. I’ll try W3TC. I’m trying to find extensive documentation on it that explains it as IT is peculiar on adding plug-ins.

BTW, I used WePageTest on another site and found by changing some code to JavaScript (an ad) I brought down FTTB by 3 seconds. This site is fantastic!

If it’s dedicated, make sure you have APC installed and when you try W3TC use it in APC mode (and enable page, database and object caching). I got my server response times down to 10ms on my test Wordpress site with that config.

Thanks,

-Pat

Hi Pat,

Digging up an old thread, but as I have a similar time to first byte and a Wiredtree hosting account I thought it best to keep the query’s together.

I have read many threads here on the forum regarding CDM’s and W3TC etc. but as many of my websites are affiliate sites that pull the content dynamically (real time), caching isn’t an option.

Have you any advice in how best to reduce the time to first byte on WordPress websites that have dynamic content at all?

Thank you,

Rick.

The best option is some good old-fashioned profiling to see where the time is going. There is a Debug Queries plugin or W3TC in non-caching mode can also dump a whole lot of information about each query and how long it took. You might be able to improve things by adding indexes and tuning the database (or eliminating some of the really expensive queries).

Do they pull the content “real time” from your database or from another source? That would be another place where time could be going.

Thanks for the information.

The affiliate sites in question pull content from another source rather than a local database, however this doesn’t appear to be the problem (of course occasionally there are problems) - it’s the time to first byte that’s the main issue.

I’ve attached a typical waterfall view so you can hopefully see the problem.

Will the advice given above (Debug Queries plugin or W3TC in non-caching mode) still help me with the TTFB problem as it’s not a database issue, or are there other things I can try to reduce the load time?

Thanks again for your help with this. As you can see I’m at a loss how to reduce this initial load time (in fact I don’t know where to start!) so any pointers would be appreciated,

Rick.

But do the affiliate sites pull content on the back-end (directly from your server) to build the page? If so then you server is making calls out to different services and that is included in the first byte time.

Ah, I see. Is there a way to know/monitor these calls to see whether they are part of the first byte time? I have various affiliate sites but I presume the Wordpress sites running affiliate plugins (such as the PhpBay plugin) would be easiest to monitor initially…

Thanks again Pat.

The only way I know of would be to instrument the page code (or plugin code) to log the times for the calls. The other thing you could do would be to try turning them on and off and see what the impact is but that’s quite a bit more intrusive.

Thanks Pat.

On my WordPress site’s it is indeed the affiliate plugin causing the long first byte time (simple disable/enable plugin test as you suggested). I take there is nothing I can do my end to increase these calls as the bottleneck is the affiliate site end?

Not unless you can cache the results of the calls or work with the affiliate to make them faster. Depending on where the affiliate site is hosted you might be able to speed things up by moving closer to their servers (if a lot of calls are made) but there aren’t a lot of good options.

Thanks for the quick reply.

I guess I’m at the mercy of the affiliate sites. Many of these are eBay affiliate sites, so caching the results isn’t an option.

Thanks for all of your help too - your speedy and knowledgeable replies are second to none…

Rick.

You might still be able to do something, depending on what the plugin is doing and how much work you want to do. If the plugin is making more than one request out to a given affiliate site you might get some benefit from routing the requests through a proxy that maintains a pool of persistent connections to the affiliate (odds are the requests from the plugin itself each set up a new connection).

You can also go further and build something that makes the requests in parallel and then gathers the results but that’s quite a bit more involved (right now it probably makes each request individually and serially).