Time to first byte strangeness
I've posted here a few times already - once for this exact issue, and W3C turned out to be the culprit. After implementing the correct server rules, the issue was resolved. Well, as of recently, the site (seemingly sporadically) reflects an extremely slow (4-8 secs) TTFB as evidenced by observation as well as testing it with a service like
Now, it isn't consistent, which is good and bad. Usually I observe it when I haven't visited the site for some time (12+ hours?), which made me suspect that it was W3C again. I checked it out, and the W3C config seems correct and the server response headers sane. Of course, this could be being caused by one of the many plugins my client has installed since, but I wanted to get your guys' opinion first before settling on that as the cause.
The site is
Thanks fellas,
rawsted
3 Replies
@hoopycat:
If you take a look at the source code, it appears it's spitting out a buttload of debugging information. This probably isn't helping it.
I enabled that to try and track down the cause of some minify errors. The issue was present prior to that.
Edit:
For clarification, I think it has something to do with W3TC not writing /wp-content/w3tc/min/default.include.js and default.include.css
It's not a permissions issue (I su'd to the webserver user and was able to create both files in console), but the debug output says:
Bad file param format: "default.include.js"
Googling that turns up all kinds of stuff, from bugs in W3TC to issues with gzip. I disabled gzip and that didn't seem to do anything.
Although, I also disabled minify entirely (I think), and the issue remained, so perhaps it's something more fundamental? It's odd because on subsequent pageviews, everything is normal (fast). It only seems to happen when accessing the index directly.
I had it set for 10 seconds, then 5, and I just recently brought it down to 1.