As with most solutions, a CMS presents further problems; most commonly, performance issues. Here’s a few ways to mitigate these issues and ensure your website loads quickly. There are a lot of guides on how to specifically speed up certain CMS platforms but I’ve taken a step back and provided solutions for general CMS optimisation problems.

1. Page caching

If you are running a site that serves thousands of visitors then these database queries, however much you have optimised them in step 1, are going to be intensive. It’s going to be a hit on your bandwidth (which could increase costs) and also slows down your site.

Solution. Page caching. When a page is first retrieved it is stored (cached) as a static page (e.g. HTML) and then further visitors will be served that static page. No database calls means the site is back on par with the speed of static sites. If you edit the content of the page in the CMS then the cache will be cleared so visitors still receive a up-to-date version of the site and not a cached one.

2. Clever coding

If you analyse a CMS template/theme you will see that there can be up to 20 database calls on a page. Whether this be the title of the page, the date an article was posted or the location of a stylesheet. The reasons why they are dynamic in the first place is to provide flexibility, often provided through options pages.

Solution. Have a look through your website. Are there any settings that are never going to change? If so you can hardcode these into your themes so they do not require an extra database hit, which in turn will load the pages quicker. Do you need the footer text to be driven by a text field on the options page? Probably not.

3. Using a Content Delivery Network (CDN)

Using a CDN such as Amazon Cloudfront is undeniably a way to speed any website up. When a request for a file (such as an image) is requested it is served by the CDN from the Amazon storage system (Amazon S3). Not only do you have the benefit of having your image stored on a more powerful server (Amazon S3) but whilst you are being served the image you can also be served the rest of the site simultaneous. It’s not only file sizes that are the problem but the amount of requests made on a server.

4. Optimise the database

Installing plugins not clearing up afterwards can cause problems. The larger the database the more the longer the search queries.

Optimise your database by clearing out tables and data that are not needed. If you’re searching through 10,000 entries, rather than 20,000 this will speed things up considerably.

5. Broken links

A user’s browser might spend time looking for that JavaScript or CSS file that doesn’t exist, or an image that has been deleted. It will retry a certain amount of times and it’s the times of, and in between, those requests that can increase the page load speeds.

Analyse your code and get to know it. Make sure that if the page has tried to load an image and if it hasn’t investigate as to why. Using Pingdom Tool you can check how long it’s taking to load a file and it ‘greys out’ the ones that it can’t find. Those are the ones that need your attention.

Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:

http://DOMAIN_NAME.com/wp-content/plugins/google-sitemap-generator/sitemap.xsl

The sitemap was created by the superb Google XML Sitemaps plugin for WordPress and after a quick bit of research on Google I came across this article at tutsarena.

It is important to mention that the error only occurs in the Firefox browser and not Internet Explorer (for a change). The error is not WordPress – specific but was actually related to the Apache server the client’s website was hosted on.

To fix the error add the following line of code to the bottom of your .htacces file (found in the root of your site):

This adds the MIME type for XSL, which was missing from the list of MIME types on the client’s server.

If you are still having problems try adding the below line of code as well as the above code into the .htacces file:

This should sort everything out nicely.

/*
Theme Name: WordPress Default
Theme URI: http://wordpress.org/
Description: The default WordPress theme based on the famous <a href="http://binarybonsai.com/kubrick/">Kubrick</a>.
Version: 1.6
Author: Michael Heilemann
Author URI: http://binarybonsai.com/
Tags: blue, custom header, fixed width, two columns, widgets

 Kubrick v1.5

http://binarybonsai.com/kubrick/

 This theme was designed and built by Michael Heilemann,
 whose blog you will find at http://binarybonsai.com/

 The CSS, XHTML and design is released under GPL:

http://www.opensource.org/licenses/gpl-license.php

*/

The Requested Theme Does Not Exist

I remember seeing this and immediately fearing the worst (that I had broken my WordPress blog somehow) but I had a think of what I had been changing on the site before I got this error (the CSS file) and after a quick look on Google I found this article.

The article mentions that the commented-out information at the top of the CSS file (containing the theme details) is used by WordPress to pull out the theme name:

At the time I wasn’t too familiar with WordPress and had just deleted the code to save about 15 lines in my CSS file. If you delete the code or use certain special characters in the theme name (such as an ampersand – &) WordPress cannot find the theme and display the templates or CSS in the admin section for you.

To fix this quite simply check the commented code at the top of the theme’s CSS for any characters which may be causing the error. Or if you did what I had done and delete the commented code completely, put it back in via ftp and WordPress will load up the editor section straight away.

I chose to upgrade my WordPress blog automatically, entered the correct ftp details and came across this error:

Unable to Locate WordPress Content Directory wp-content

I racked my brains for a while making sure that all the permissions to the necessary files were correct and after about 45 minutes I found a blog post by Hui Wang which provided the answer.

The problem may not necessarily be with WordPress or any of my files / permissions but actually my hosting company. My blog is currently hosted through byethost.com and quite a few people who have WordPress blogs get the same problem.

To fix the problem, add the following code to the bottom of your wp-config.php file:

The above code overides the default file system method to allow WordPress to upgrade, delete plugins directly (without using ftp details). It works for me and saves me from having to download .zip files and uploading them through my ftp client etc… which takes up a lot of time when you have a lot of plugins.

Let me know if it works for you or if you have any other problems or solutions let me know and I’ll write a post about it.