Performance Optimization

[jaspervalero]

I've always noticed some very slow load times and have meant to run some performance tests for some time now. I've finally had the time tonight to run them, and the findings are quite alarming. We can discuss in more depth, but here's the quick overview of the tests ran.

As you can see from the image, there is a load time of almost 15 seconds. There is almost a 3 second wait time before the site even begins to receive data back from the backend, about 11 seconds before the site even begins to render the first thing onto the screen. 49 HTTP requests made, 2MB page size and a very high speed index.

You can see that the majority of the upfront delay is found in this part of the waterfall:

There appears to be a significant delay on row 1 which at first glance looks like crap performance from CloudFlare (CDN). The worst has to do with the main css file style.css. I think we may be doing way too much there. A 8.5s delay from CSS, is about as bad as it comes.

The tests I ran were best case scenario too, meaning performant browser set for the test engine, as well as a cable connection used. 9 first view and 9 repeat view tests were ran for a total of 18 tests. All of which showed the same type of performance.

So I think we should continue on the new version of the theme, but we'll need to set up a staging environment before going fully live so we can test and optimize. I also think that we need to take a heavy look at the CSS file and clean things up there.

[jaspervalero]

Took a deeper look at the performance issues. I ran a few different series of tests and noticed quite a bit of fluctuation on what files were causing issues or were delayed. So I really think it is something wrong with CloudFlare, either in configuration or just some issue with your account. So first things first. Submit a ticket to CloudFlare and let them know there are some serious delays happening. The one thing that didn't fluctuate is that it took about 14s for a page load each time, give or take a few milliseconds.

Here's some data from the most recent series of tests I ran that may be helpful in filling out your ticket:

Here's the connection view, so you can see that it takes 7 seconds just to get the DOM loaded, only then do the images start loading:

So I'd love to have them take a look on their end. Hopefully the can find the issue and we can then retest and address any remaining issues.

The good news is that, outside of CloudFlare, in looking at the content breakdown, I know that we should be able to see big gains off the image optimization I did on the images. We'll also see more gains by cutting down on the number of HTTP requests for images, by creating a master sprite sheet for all the PNGs. As you can see currently images make up the majority of the content and requests.

[aaclayton]

Hey man, thanks for digging deeper. I'll definitely have to take some time reviewing this data. In the short run, I suppose my main lingering question is the following:

How much of the delay before the DOM is loaded is due to PHP building the page itself? I know once WP recieves a page request, it has to load a TON of functions and classes before it actually generates the page-view. Is there a way to tell how long this process is taking?

But yeah.... 5 seconds for JavaScript and 7 seconds for CSS seems really terrible. Let's try to figure out what is causing it.

[jaspervalero]

There are PHP web apps that deal with truly massive data sets. TBH, there are a lot better programming languages for dealing with big data, but point WordPress is completely off the radar with this. The PHP should load instantaneously on the server side. I truly believe the issue is at the CloudFlare level. I'm sure there is some optimization that can be done in the JavaScript, for example you create a new jQuery factory for almost everything. That can be very expensive, but let's not focus on anything until we can see what can be done with CloudFlare and test again after changes are made there.

[aaclayton]

I want to do some before/after testing on the current theme so we can get an idea of what CloudFlare might (or might not) be doing. I've changed the Tamriel Foundry nameservers to not use CloudFlare for a little while. If you get a chance later could you look at some similar tests and see how it looks when we cut CF out of the DNS resolution?

If it's not CloudFlare, I think we should look into what might be happening with a http vs www resolution, if there's maybe a loop there.

[jaspervalero]

Well... I've got some good news for you! Just reran the test, with CloudFlare disabled and without the www. So same test as the latest results above, minus CloudFlare in the mix.

Here's the results:

Stats are better across the board, but summed up by the fact that "Visually Complete" dropped from 15.8s to 4.1s (11.7s shaved off). And as you can see from the connection view, all of the site loading (including the JavaScript), besides the images happens in less than a second which is pretty ideal. The biggest delay now is images, which we already know are unoptimized. I'm sure with the images saved out for the web, and then with the optimization I run we should hopefully be sitting in the 2-3s range. Obviously 2 seconds or less would be sexy, but with a graphical site like TF, even under 4 is pretty damn good.

So in summary, this without a doubt proves the issue was caused by CloudFlare. One place to look is to see if there is an issue with the domain name resolution which prevents CloudFlare from working correctly.

[aaclayton]

Thanks a bunch for re-running those tests. This definitely looks promising. We'll have to decide if we want to stick with CloudFlare, in which case I'll need to take a hard look at how they are handling DNS resolution.

Our other option would be to consider an alternative CDN, which would sacrifice CloudFlare's screening of "bad" IPs, but would probably be a bigger win in terms of delivering site content. Let's talk about it later!