MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
WebPagetest Forums - Yet another time to first byte question

WebPagetest Forums

Full Version: Yet another time to first byte question
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I've tried optimizing various aspects of the site, with the exception of some stuff like image compression (I can't compress too much), and third party javascript (like the Disqus commenting system), everything is pretty much maxed according to my knowledge:
- caching objects, page, browser, database with APC cache
- setting up expiry headers for cache
- CDN implementation
- minifying CSS and JS

The site is a wordpress site on a dedicated server with a rackspace CDN and the W3TC plug-in. The only thing that I can't seem to shorten is the Time to first byte, as well as well as start to render time. One thing I just noticed is that static image files don't seem to be cached and I wonder why, since I've set them to be cached.

Here is a screenshot of one of the tests:

And here is one of the last tests I did:

Any help is appreciated. Thanks. Smile
Are you running the main site through the cdn ( or do you have a separate domain for the static content that is being routed through the CDN? It's possible that the CDN is adding to the first byte times for the non-cacheable HTML. If not then you should turn on the W3TC debugging because those times are way longer than what I'd expect to see for a site where the page, objects and database queries are being cached by APC.

It also looks like beyond the first byte time, the rest of the base page took longer to generate than it should (looks like there was an early flush and then another 1.5 seconds before the rest of the base page was actually sent).

You might want to look into turning on logging of the server-side processing time in your access logs which will help narrow it down a bit (it will let you know if the time is coming from something in front of the server or on the processing itself).

If is the cdn then you should move the timthumb, css and js requests to the CDN as well.
Thanks patrick, I don't run the main site through the CDN (is that possible to configure, would you recommend that?)

I've just edited the test results with the latest one, I don't know what is wrong with the ones I posted, like you said there is a flush.

As for the timthumb, I don't think it can be moved to the CDN. I'll try moving the CSS and JS to the CDN. I will also try turning on the W3TC debugging.

Patrick, here is the debug information:

<!-- W3 Total Cache: Minify debug info:
Engine: apc
Theme: dd8c9
Template: index

Replaced CSS files:
1. wp-content/themes/bigfeature/style.css
2. wp-content/themes/bigfeature/library/css/optionstyles.css
3. wp-content/themes/bfarea/style.css

Replaced JavaScript files:
1. wp-includes/js/l10n.js
2. wp-content/themes/bigfeature/library/js/image-maxwidth.js
3. wp-content/themes/bigfeature/library/js/superfish/hoverIntent.js
4. wp-content/themes/bigfeature/library/js/superfish/superfish.js
5. wp-content/themes/bigfeature/library/js/superfish/supersubs.js

<!-- W3 Total Cache: CDN debug info:
Engine: rscf

Replaced URLs: => => => => => => => => => => =>
<!-- Served from: @ 2011-09-12 21:48:33 by W3 Total Cache -->

I don't know why but JSS and CS minified files can't be served from the CDN now. I can't turn the checkboxes on.
Can you turn on debugging for the page, object and database caches? I'd expect to see something like this:

<!-- Performance optimized by W3 Total Cache. Learn more:

Served from: @ 2011-09-12 14:55:29 -->

<!-- W3 Total Cache: Object Cache debug info:
Engine:             apc
Caching:            enabled
Total calls:        800
Cache hits:         799
Cache misses:       1
Total time:         0.0519
W3TC Object Cache info:
    # |     Status      |     Source      | Data size (b) | Query time (s) | ID:Group
    1 |     cached      |   persistent    |             4 |         0.0007 | is_blog_installed:default
    2 |     cached      |   persistent    |           145 |         0.0002 | notoptions:options
    3 |     cached      |   persistent    |         20573 |         0.0004 | alloptions:options
    4 |     cached      |    internal     |           145 |         0.0001 | notoptions:options
    5 |     cached      |    internal     |         20573 |              0 | alloptions:options
  800 |     cached      |    internal     |         20573 |              0 | alloptions:options

<!-- W3 Total Cache: Db cache debug info:
Engine:             apc
Total queries:      3
Cached queries:     0
Total query time:   0.0027
SQL info:
    # | Time (s) |    Caching (Reject reason)     |   Status   | Data size (b) | Query
    1 |   0.0016 |  disabled (Query is rejected)  | not cached |             0 | SELECT SQL_CALC_FOUND_ROWS  wp_posts.* FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')  ORDER BY wp_posts.post_date DESC LIMIT 0, 10
    2 |   0.0006 |  disabled (Query is rejected)  | not cached |             0 | SELECT FOUND_ROWS()
    3 |   0.0005 |  disabled (User is logged in)  | not cached |             0 | SELECT comment_approved, COUNT( * ) AS num_comments FROM wp_comments  GROUP BY comment_approved

<!-- W3 Total Cache: Page cache debug info:
Engine:             apc
Cache key:          w3tc_wp.patrickmeenan.com_1_page_6666cd76f96956469e7be39d750cc7d9
Caching:            disabled
Reject reason:      User is logged in
Status:             not cached
Creation Time:      0.418s
Header info:
Expires:            Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified:      Mon, 12 Sep 2011 14:55:29 GMT
Cache-Control:      no-cache, must-revalidate, max-age=0
Pragma:             no-cache
Content-Type:       text/html; charset=UTF-8
X-Powered-By:       W3 Total Cache/

For timthumb, it looks like you might have to edit your template to get it working through a CDN but it's well worth it:
Thanks Patrick, I've done that and the text file of the debug is attached with the post.

Thanks also for the thumbs-up article. I will look into it.
You should also gzip your basepage! Apparently it currently is not gzipped. Gzipping it would drop its compressed size down to 11kb, compared to its current size of 49kb. This should improve Time-to-Render quite a bit.

Best wishes,
Thanks Leptien,
I have set the gzip compression on for html & xml, css & js, and media and other files through W3TC, but apparently they still don't gzip the basepage. Then how can I gzip the basepage?

By the way I have page cache turned on for everything except the basepage, as I need the banner ads to rotate and I can't do that if the page cache is turned on.

Also another weird thing that I notice is that I've set W3TC to load from CDN small graphic files that is used by the theme (such as search icon, loading graphic, arrows, etc) but the test reveals that those graphic files are still fetch from my server. These are one of the files I am talking about:

Patrick, here is what my hosting support staff said about the slow time to first byte:

The delay looks to be coming up due to the number of DB queries that the
main page is making to load. In my test this morning, a single request to needed 128 queries on the DB before it loaded.
You may want to check to see if any of that content could be cached, or
otherwise if there are any plug-ins or features for WP that are requiring
heavy DB interaction that could be removed or perhaps just moved to
sub-pages off of the main index page. Otherwise, the server load, RAM usage
and disk I/O all appear to be fine. The site isn't hitting hardware

I don't understand why this is since database cache is supposedly on with W3TC.
It doesn't look like the database queries are actually getting cached:

Engine: apc
Total queries: 127
Cached queries: 0
Total query time: 0.4854

Try connecting to the site with a browser that isn't logged in just to make sure (cache is usually bypassed for logged in users).

With the size and number of things that it looks like your site needs cached you may also need to take a look at the APC diagnostics - if you're just using the default 32MB cache then I wouldn't be the least bit surprised if you've blown right through it.

By FAR, the most expensive queries to the database look to be the ad rotation tracking (the log has the time for each of the queries). Looks like every query that hits wp_adrotate_tracker takes 30ms and there are quite a few. Indexes might help but you might also be better off if you can move the ad rotation off of the back-end and have that be completely separate (a front-end-initiated request to dedicated code either as an iFrame or javascript ad code). If you move the ad rotation code off of the back end you will also be able to enable page caching for the base page.
Thanks Patrick,
Yes that is weird how the database isn't cached. I just made a post in the wordpress support forums regarding that, we'll see what Frederick says about it. (I've tried doing the logs again from a different browser that is not cached -- still the same result). Also the size of the APC cache is 128kb and last time I check it was on 50% free (which explains it since the database is not cached).

As for the ad rotation thing, I don't know, moving it to a different system, that sounds REALLY complicated and way beyond my skills. Although now that I've seen the debug pages, I think yes you are right on that.

Okay I did a few tests and I think I sort of understand why things aren't cached. On the front page, most of the queries seem to be from:
- adrotate plug in (lots of them)
- the theme itself that lists a number of posts in a thumbnail format -- they ask for a new query every single time.
- the popularity posts plug in which lists the most popular posts.

At the moment I need to find a way to eliminate these problems, but at the same time I probably can't start stripping off features off the site. This is not going to be easy.

I will try talking to the theme and plug in creators and see what they say about this.
Reference URL's