Posts Tagged ‘performance’
December 7th, 2009
A few days ago Frederick Townes, author of the W3 Total Cache for WordPress has released an update to this wonderful plugin, and yes, it now fully supports Amazon S3 and CloudFront as the Content Delivery Network! This is a major one for me as I manually upload most of the static assets to my CloudFront account which may take quite a lot of time. The W3 Total Cache plugin does that for you in seconds! Post attachments, images, javascript, css.. All those could go to CloudFront in just 4 clicks. Frederick also mentioned that the upcoming update will also be surprising, which keeps me wondering.
WordPress: Now with Amazon S3 & CloudFront!
I also tried out the other options for page and database caching. A few tests showed up that memcache is faster than APC, so that’s where I stopped at database caching. Page caching was switched to enhanced, which I believe is a new option. The site performance graph at Google Webmaster Tools shows pretty good performance for Novermber and December (very close to 1.5 seconds) although the overall average is still up at 3.5 seconds, which in terms of Google is slower than 59% of sites. This is probably caused by the force majeures in September and October. Page load time peaked at over 7 seconds there.
One more funny fact about Google’s Site performance and Page Speed tools is the “Minimize DNS lookups” section, which most of the time shows up a single entry:
The domains of the following URLs only serve one resource each. If possible, avoid the extra DNS lookups by serving these resources from existing domains: http://www.google-analytics.com/ga.js
Interesting. Perhaps I should copy that javascript file and serve it from my CDN, I wonder if that will work. Oh and then I’ll be missing all the nifty updates to Google Analytics, like the most recent one called Asynchronous Tracking – very neat by the way!
November 13th, 2009
This may seem like an easy task to do but is quite tricky in WordPress. Using a CDN these days is very popular, cheap and helps speed up your website taking the load off your web server. I personally love Amazon CloudFront! The tips at Google Code suggest you serve all your static content from different domains, preferably ones without cookies, so CDNs are perfect.
Serving Static Content From CDNs
All the problem with WordPress is script dependancies, and this applies not only to jQuery but to all the other predefined javascript libraries (prototype, scriptaculous, thickbox, see wp_enqueue_script for more info). It’s all about the handles and plugins that use jQuery will probably use the jquery handle in their dependency lists, which will automatically make WordPress include the standard jQuery from its wp-includes directory. This means that using the code:
1
| wp_enqueue_script("my-handle", "http://s.kovshenin.com/jquery.js"); |
You might end up including two instances of the jQuery library, one from your CDN (s.kovshenin.com) and another one from the WordPress wp-includes directory, which will end up in a total mess. Strange though, that you cannot redefine an already known handle, such as jquery like this:
1
| wp_enqueue_script("jquery", "http://s.kovshenin.com/jquery.js"); |
The javascript library will still be loaded from the default location (wp-includes on your local web server). So the right way to do it is with a little hack in your functions.php file (in case you’re doing it within your theme) or any other plugin file (in case you’re doing it within your plugin):
1
2
3
4
5
6
7
8
| add_filter('script_loader_src', 'my_script_loader_src', 10, 2);
function my_script_loader_src($src, $handle)
{
if ($handle == "jquery")
return "http://s.kovshenin.com/js/jquery.1.3.2.min.js";
return $src;
} |
Then any call to wp_enqueue_script with the jquery handler will output the correct path to your CDN version of jQuery. Oh and please, try not to use generic function names like my_script_loader_src, I used that just as an example, we don’t want any function name conflicts and can’t expect other plugin/theme developers to use non-generic names ;)
November 12th, 2009
Here’s a little video that we’ve seen at Arvind’s and Sreeram’s presentation about speeding up the web at the Google Developer Day 2009 conference in Moscow. Inspiring isn’t it?
Arvind and Sreeram talked about a very nice plugin for Firefox (built upon Firebug) which is called Page Speed, developed and maintained by the Googlers. You may read more about the plugin on the official page at Google Code: Page Speed for Firefox/Firebug plus a bunch of cool tips and tricks right here: Let’s make the web faster. I used to run with one called YSlow by Yahoo, but the Googlers seem to have made a better job.
I ran the speed tests on my homepage and got quite a few sweet suggestions, mainly about combining and minifying my CSS and JavaScript files, distributing static content to different cookie-less domains and a couple more. Well combining and minifying CSS and JS would have been quite difficult in WordPress due to the series of plugins that use their own, if it weren’t of course for the W3 Total Cache plugin. In only a few minutes I managed to combine all javascript and stylesheets into single minified versions, which were recreated whenever a plugin was updated. After doing that, running the same test didn’t yield out that problem anymore. Distributing static content to different domains, well that’s one more issue that would have been solved by that brilliant cache plugin and its CDN features, but I guess I’ll have to wait for Amazon CloudFront compatibility.
One more thing I love about Page Speed is that not only they state the problem, but also provide the solution, or at least an easy guide to the solution. Now with a few warnings left, my Page Speed overall performance is okay. I hope to optimize that later this month for even faster access, and perhaps sign up with a PubSubHubbub service (Brett Slatkin had a fantastic presentation on that one at GDD too), and I can finally pronounce that correctly, Hubbub for short.
July 31st, 2009
This is early experimental. And, I’ve also marked this post into the “personal” category, because you wouldn’t want your clients to have too much access, especially if they share a single WordPress installation. Now I know there’s the WordPress MU project, but I guess I can’t use it in this case, because WordPress MU assumes your URLs will be within the same domain (either subdomains or directories).
Creating A Multiblog WordPress
The reason I want multiple sites to be driven by one single WordPress installation is because I’m really tired of upgrading everytime. Upgrading the WordPress Core once in a while is okay, but when you’ve got a list of 30 plugins, it’s a pain in the neck upgrading two or three every day on every single blog and website you run. Automatic updates is not a choice, as I want to take a look at what I’m updating to before actually doing it, at least once.
I won’t be doing this from scratch. I’ll start by merging this blog and the Foller.me blog into a single installation. Single doesn’t mean they share the same database, all they share is the WordPress core files, plugins and themes. Yes, this may be dangerous, because not all the plugins store the data in the database (though I believe they should, at least when they’re capable of doing that). Now imagine the Next Gen Gallery (or perhaps any other gallery plugin) being shared over two websites within one WordPress installation. The albums are stored in one folder called gallery. So there might be a conflict if two albums have the same name. There might be an option to store the files in a different directory, and hope that option is stored in the database, will check on that later.
One more issue.. Remember I said personal projects? And assigned the post to the personal category? If you’ve got some clients who are hosted on WordPress, and you’re doing some admin things for them but they DO have admin rights in their admin panels, then I wouldn’t go with this stuff, as it’ll be quite difficult to restrict them from changing eachothers themes and plugins that they share. Get my point?
kay, now the trick will be in the wp-config.php file. We’ll basically look at the incoming address using some regular expression or whatever. If it’s based on kovshenin.com, then we connect to database 1, otherwise, if it’s based on blog.foller.me we connect to the 2nd database, and so on. Pretty simple, huh? If you’re a total freak you might wanna try changing just the prefix, thus having multiple websites, one WordPress installation, one database and a bunchload of tables ;)
I’ve no idea if this will alter the overall performance, but keeping total visitors under ~ 20,000 per day should be just fine ;) I’ll get back at you with another post next week, hopefully with some tests and some results. Cheers!
