WebPagetest Forums

Full Version: W3TC and load times
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
In an effort to speed up my site's load times, which are in the lowest 20% according to google, I thought I would try W3TC since it offered minify and a Content Delivery Network (CDN) interface. I was hoping that with W3TC I would see a speed increase. Well, there were lots of problems:

** It killed the font choice for the header
** It killed the logon. The item was still on the page, and changed the pointer to indicate click able, but it went nowhere. The URL changed to the logon URL, but logon never appeared. I was locked out of the site. When I was in the dashboard, installing W3TC, I could load, install, configure W3TC, and work the dashboard, but once I logged off, I could not get back in.
** Worst of all the load times INCREASED by 10 secs.

Well, thank god for backups. I simply restored the WP site (left the SQL as is) from an earlier backup to before I loaded W3TC.
FYI: this is on a shared server, not a VPS.

But, I just gave up on W3TC and yanked it. The site is now running on WP Super Cache. If the glowing reviews are to be believed I might consider going back to W3TC but I have no confidence in it. This is the second time I've had a problem with it. About 8 months ago I tried it and something similar happened. In that case the site would not even come up. I had lost control completely, and had to call the hosting outfit to load a backup.

But WPSC has not given me much of a load advantage either.

I'm currently getting (with WebPageTest):
F-A-F-C-F (with no CDN)

I would do CDN last, as there are too many other issues to address first.
eg poor first byte times

It manages a C for compressed images. (I don't want to compress the images any further, but I will be moving to PNG form JPG, as I want to keep the image quality up) and there is more to be gained by tuning elsewhere.

Even more importantly is what I see on first load… 6 to 9 secs for a usable page. I truly believe it is affecting my google rankings as they take load times into account with their algorithm.

I registered for some space on amazon's cloud, but have not utilized it yet. I don't want to use CDN until the other issues are solved.

I have turned on GZIP but webpagetest tells me that I have 12 files that could be zipped, are not and if zipped would save about 133kb of download.

Any ideas anyone, I'm here to learn.

bc
I'm not sure if you can get the debug info from Wordpress proper (I'm used to just turning it on in W3TC) but you should generate a trace of the database calls and see which are the slow ones. It could be that there's a specific plugin that is causing the slowness and a database index (or removing the plugin) could fix it.

It might also be worth trying out these guys if you're open to moving the site off of your current hosting: http://wpengine.com/ - My wordpress test site is running on a web server that uses a cheap SSD for the main filesystem (and database) and the speeds are ludicrous (7ms response times for uncached base page). The caching plugins are generally just hiding poor database performance (and you still see the real performance periodically).
pmeenan Wrote:It might also be worth trying out these guys if you're open to moving the site off of your current hosting: http://wpengine.com/ - My wordpress test site is running on a web server that uses a cheap SSD for the main filesystem (and database) and the speeds are ludicrous (7ms response times for uncached base page).

If I were Bart and/or if I owned a WordPress-based site, I'd seriously consider the above mentioned hosting company. Out of curiosity, I ran a few tests on the home page of their blog. I tested in Dulles VA, San Francisco CA, London, Australia, New Zealand. In all of these test centers, the First Byte Time was lower than Target First Byte Time! I wish I could achieve this! Is this the result of the fast SSD? I'm caching html pages for guests, but I'm not able to achieve First Byte Time lower than Target First Byte Time.
Yes - the target is the round trip time + 100ms (basically allows for 100ms of server processing time). SSD's give an insane performance boost to anything that touches disk (and wordpress touches disk a LOT).

Artur Bergman from wikia gave an epic rant during his keynote talk at velocity about it this year (warning, the language is a bit harsh): http://www.youtube.com/watch?v=H7PJ1oeEyGg

I moved WebPagetest to a combination of Nginx + SSD a few months back and the base page response times (measured on the server) dropped from 200ms to ~8ms (and that is with minimal disk activity). It's a shame that there aren't any shared hosting providers that provide less space but do it at a cheap cost and on a really fast platform. Most websites don't need a lot of storage but could benefit greatly from wicked-fast storage.
Quote:the target is the round trip time + 100ms

Pat, where in the test can I find out the length of the round trip time?

Quote:I moved WebPagetest to a combination of Nginx + SSD a few months back and the base page response times (measured on the server) dropped from 200ms to ~8ms

That's very impressive!

I've seen hosting companies offering SSDs as an option for dedicated servers, but only very few hosts offer VPS based on SSDs. If by any chance you are on a VPS, please do share with us who your current host is.
I use the socket connect time as a proxy for the round trip time (it's usually a good approximation).

I'm running in the Meenan Data Center: http://blog.patrickmeenan.com/2011/01/to...enter.html :-D
Cool! Even though you are likely paying around $200/mo for your FIOS Internet connection, you don't have to pay monthly for a dedicated server to a hosting company, so you are better off in the long term.

Pat, where in the test results could I look up the socket connect time? I only see DNS look up time and initial connection. Do you add these two together? I don't think that's how you do it because Target First Byte Time - 100ms is usually a smaller value than the sum of DNS LOOK UP + INIT. CON.
Socket Connect time = Initial Connection and it's usually 1 round trip (unless there is packet loss or the server is having serious issues)

It looks like the target is actually 3 * RTT + SSL time (the 3 * RTT is to allow for DNS, Socket connect and the round trip for the actual request). The 100ms actually comes from my grading buffer where it drops by a letter grade for each 100ms beyond the target.

The socket connect is used for the RTT so if you have a fast DNS you can come in under the target.
Quote:target is actually 3 * RTT

Now I understand. Thanks!

But I'm not sure if this all makes sense to me, because my connect times are usually around 50 to 55 ms, no matter if I test in the nearby Dulles, or in far away Australia. So the resulting Target is always around 150 to 165 ms. But my actual First Byte Time varies depending on distance, in Dulles it may be just over 200ms, but in Australia it may be just over 800ms.
That's because you are fronting your dynamic pages with a CDN, isn't it? ;-)

The actual round trip time to your server is a lot longer than it appears but if your HTML was cacheable by the CDN then the response times would be closer to the target.

It's kind of an atypical case but still appropriate.
Pages: 1 2
Reference URL's