WebPagetest Forums
TTFB issues with WPT - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: WebPagetest (/forumdisplay.php?fid=7)
+--- Forum: Bugs/Issues (/forumdisplay.php?fid=10)
+--- Thread: TTFB issues with WPT (/showthread.php?tid=10783)

TTFB issues with WPT - ExpertDan - 03-21-2012 04:01 AM

One of my clients is seeing high time to first byte intermittently when testing with WPT but not with other tools. I optimized the site about a month ago and have seen this happening ever since. TTFB ranges from 150ms to 3+ seconds. When this happens usually the first request will be 2+ seconds and repeat view will be <200ms but on some occasions this is reversed.

We're only seeing this issue with WPT. I have Pingdom monitoring the site every minute. Avg is 370ms and <300ms to most US locations. Even from European locations the response time never hits 700ms. Also tested locally from 2 locations, 200-300ms times. Yottaa reports <700ms for full page download.

Site is running highly optimized WordPress w/ W3TC and CloudFlare.

Here's a sample of tests with high TTFB:
http://www.webpagetest.org/result/120221_G2_3AFHZ/ (one of the worst)

Tests with low TTFB:

My first thought was stale cache somewhere. It shouldn't be an issue with W3TC though since Pingdom hits it every minute. Maybe a problem with CloudFlare? Problem in the route between CloudFlare and WPT (unlikely since it's happening from multiple locations)?

Anyone have other ideas?

RE: TTFB issues with WPT - pmeenan - 03-21-2012 06:10 AM

Couple of possible thoughts:

- Check the access logs and make sure all of the pingdom hits are actually making it through to the server. It is theoretically possible that cloudflare is special-casing some bots/agents and serving directly from cache.

- Can you enable server-side times in the access log (%D for apache)? That would let you check to see if it is an issue on the back-end or somewhere between cloudflare and the server.

- WebPagetest has an option in the advanced settings to capture response bodies. If you can capture a body for a test that is slow you should be able to see the W3TC timing information at the end of the HTML (as well as hit/miss).