Current time: 12-09-2019, 01:38 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Long first byte time in Resource #1
08-18-2013, 06:04 AM
Post: #1
Long first byte time in Resource #1
http://www.webpagetest.org/result/130817_DG_MPR/

I am getting a lengthy time to first byte on resource #1. This wait accounts for something like 3/5 of the page load time. It's a WP 3.6 site running a Genesis 2.0 child theme on shared hosting. gzip, expires and caching are all enabled through htaccess and there's not much left to optimize.

I am dealing with support at the host, who is refusing to admit any possibility of server-side issue and keeps saying it's caching, or this, or that. Anything but them, of course.

Any suggestions from looking at the test?
Find all posts by this user
Quote this message in a reply
08-24-2013, 07:56 AM
Post: #2
RE: Long first byte time in Resource #1
Caching can help mask the issue (W3 Total Cache or Supercache) but fundamentally it is most likely a database performance problem with your hosting provider. It's not something that you're going to be able to see/inspect from the outside and since it's shared hosting you aren't going to be able to use tools like New Relic which could tell you what is going on (but require root access to be installed).

You can try some of the caching plugins and try disabling plugins to see if there is something particularly painful but ultimately you might be better off finding a better host (WP Engine is good for WP-specific hosting).
Visit this user's website Find all posts by this user
Quote this message in a reply
08-26-2013, 02:03 AM
Post: #3
RE: Long first byte time in Resource #1
Thanks!

I was able to reduce the TtFB to an acceptable amount using W3TC, but I agree that it looks like a database performance issue at the host, especially since it started happening at the same time on seven different websites. The host was acquired by another company and recently migrated everything to servers in Provo, UT. Based on their support forums, I am far from the only person having the problem. They either don't know what to do about it, or can't, or no longer care, which is too bad.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)