WebPagetest Forums
Long first byte time in Resource #1 - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: Web Performance (/forumdisplay.php?fid=3)
+--- Forum: Discuss Test Results (/forumdisplay.php?fid=4)
+--- Thread: Long first byte time in Resource #1 (/showthread.php?tid=12482)



Long first byte time in Resource #1 - ThatBadDog - 08-18-2013 06:04 AM

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?


RE: Long first byte time in Resource #1 - pmeenan - 08-24-2013 07:56 AM

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).


RE: Long first byte time in Resource #1 - ThatBadDog - 08-26-2013 02:03 AM

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.