A recent project of one of our co-founders, WebsiteSuggestions.net, motivated us to take a look at our own WordPress installation and see if we could speed up our site. In this blog post I will outline a few issues that we had that I know many other people are having.

When we fired up Firefox to run Yahoo’s YSlow tool extension that will identify problems with your site, we scored a 68 out of 100. And when we ran our website through the WebsiteSuggestions.net tool, it identified additional problems as well. By the end of our adjustments, we scored a 90 out of 100.

What we found out is that even though we were running W3 Total Cache, it was not optimized properly. W3 Total Cache is a very powerful plugin, but needs to be setup properly in order to work to its full extent. Not only that, but W3 Total Cache can actually cause problems as well if it is setup incorrectly. An example of this is when it minified inline JavaScript, which did not have an end closing tag, it then threw a JS error on the page after it was minified. Technically this is not the fault of W3 Total Cache, but that of the minification service, but it goes to show that you may run into problems on this level.

I have had many friends ask for my configuration file for W3 Total Cache, but I always tell them that W3 Total Cache needs to be configured manually for your own blog. On some blogs, object cache and database cache are very important, but on others, you may not want to have that enabled at all. It all depends on the type of website you run. The same goes for page cache. Page cache can cause some negative effects such as tracking query string items, but again, there are ways to configure around that as well, but it is dependent on that site. So bottom line, you should have someone who is familiar with caching configure W3 Total Cache for you, and use the configuration export feature to save your configuration in case it gets overwritten or modified.

I should also note that occasionally I had to de-activate the W3 Total Cache plugin to completely get rid of the cache. The plugin provides an “Empty All Caches” button, but that does not appear to work under certain circumstances.

Another issue I ran into with W3 Total Cache is our server did not support the cache method “Disk: Enhanced”. I did not receive an error, but upon looking into the issue further by utilizing the page cache debug that the plugin offers, I noticed that the page was not being cached. I searched around the Internet and found a suggestion to switch the cache method to “Disk: Basic” and that fixed the issue. Which brings up another great point, you must use the debug feature that W3 Total Cache has to make sure that the plugin is performing the caching that you are expecting of it.

Common WordPress Performance Issues

• Inclusion of the same script, multiple times.
  I have witnessed this issue numerous times, and come to find out, it was happening on our own website. The cause was a plugin that we were using that was not written properly. It did not use the WordPress function to enqueue a script, it was basically hard coding it into the header. The inclusion of jQuery is usually the culprit. Having jQuery included multiple times on your website can have a major negative effect because the size of the library is 230kb uncompressed.
• Inclusion of the same code, multiple times.
  This is similar to the above issue, but it is more difficult to track down because different file names are used or the code is being included inside of a different file. Our website was including jQuery twice, two completely different versions, and one was being placed inline inside of a JS file dedicated to a plugin, which made it difficult to locate.
• Hard coded theme items.
  A few issues we found was that in our header.php file, a few of the items that WordPress generates for you, such as the RSS, language attributes, doctype, etc. were hard coded into the HTML elements or had a meta tag inserted. This causes a conflict and can hurt the way your website is presented to different browsers. This is generally a culprit in any free themes or any themes developed by someone who is not familiar with what the WordPress framework does for you.
• External Scripts
  We use a Facebook and Twitter widget that includes a JS script on each of these domains. Now I assumed that because they are large companies with brilliant engineers that this would not slow down my website. But, being public services that service millions of hits a day, occasionally they do slow down the page load. They also do not allow you to set an expiry header, nor control the minification.
• Location of JS Files
  I have found that the vast majority of JS files in WordPress themes and plugins are just simply enqueued and slapped inside of the HEAD of each page. The problem with this is that it causes a block for the page to render. Sometimes this is needed if the page has to call this JavaScript function before the page is completely loaded, but most of the time, the JavaScript can be deferred to lower in the page, right before the end BODY tag. W3 Total Cache can do this for you, and I highly recommend it. It will not reduce the size of your page, but it will give the appearance of a much faster page load to the end user. It is also important to note to pay attention to all dependencies, such as jQuery must be loaded before a jQuery plugin.
• Lack of Minification
  To minify something is to remove the whitespace, comments, and all other things that are not necessary for the element to work properly. This can be CSS, JS, HTML, or really any script that can be interpreted, those are the main three. The goal of minifcation is to significantly reduce the file size. Typically, a 20% reduction can be achieved. Using compression and minification, the latest jQuery library can be reduced from 229kb to 31kb, which is a massive reduction. The smaller your page size is, the faster it loads for people.
• Image Optimization
  When you upload an image using WordPress’ image upload feature, it does not optimize the image for you. Furthermore, if you upload a large image, and then use the WordPress’ feature to scale down the image, it is merely setting HTML attributes to scale down the image, instead of creating a new, smaller image with a smaller file size. There is a plugin called Smush.it that will take care of this for you.

There are ways around this such as a proxy script, but they are all kind of a pain. Most people are unaware of the fact that it is possible to create a JavaScript POST cross-domain, and it is fairly easy to do. It is true that not all browsers support this, but you will be pleasantly surprised to know that the following browsers do support it: Internet Explorer 8+, Firefox 3.5+, Safari 4+, and Chrome. Yes, IE8+ does support it. I was surprised too.

So the big question is, how does it work? Cross-domain ajax is achieved through a protocol called Cross-Origin Resource Sharing.

Cross-Origin Resource Sharing

Cross-Origin Resource Sharing is a W3C Working Draft that defines how the browser and server must communicate when accessing sources across origins. The basic gist is that the client and server use special headers to either deny or accept a cross-origin request.

For example, if a script such as http://www.websitez.com/list.js performs a POST request via AJAX to the website http://www.hosting.com/save_listings.php, it would normally fail due to cross-origin policy. However, if in the PHP script “save_listings.php”, you set a special header called “Access-Control-Allow-Origin” with the proper value, the POST will be successful.

In PHP, the proper code for the “save_listings.php” file would be:

header(“Access-Control-Allow-Origin: http://www.websitez.com”);

By setting that header value, it will allow the script located at http://www.websitez.com/list.js to perform POST and GET requests cross-origin to the http://www.hosting.com/save_listings.php script, which is on an entirely different domain.

There are additional headers that can be set as well:

Access-Control-Allow-Origin: http://www.websitez.com
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Headers: NCZ
Access-Control-Max-Age: 1728000

You can also specify a “*” as the domain to allow any domain to perform a POST or GET to the script in question. Obviously this is a massive security risk and should only be done if you know the exact ramifications of doing so.

Access-Control-Allow-Origin: *

For further information, please checkout this great post from NCZOnline detailing the proper way to perform the AJAX call to maximize support across as many browsers as possible as well as further details on the additional headers that you can specify to gain control over who, when, and what can access your script.

W3 Total Cache tried to address this with a section of their plugin that allows the blog owner to specify user agents. What this will do is not served a cached page to the user agent specified and will not cache the view from a mobile device. This is a great first step, but because mobile detection is such an advanced function, this is not a suitable solution. Some mobile plugins have a very limited list of mobile devices they target. So in these cases, the mobile plugin will give you access to a user agent list that you can copy and paste into this box. Recently, the mobile plugins have advanced the functionality of detecting a mobile device which makes this feature of W3 Total Cache obsolete.

To integrate W3TC with the WP Mobile Detector, you must perform the following steps:

1. Login to the administration panel, click on the “Performance” tab, and then click “User Agent Groups”.
2. Make sure that the groups “high” and “low” are present, enabled, and set to pass-through.
3. Open an FTP or your favorite editor and edit the “wp-content/plugins/w3-total-cache/lib/W3/Mobile.php” file.
4. UPDATE! For version 0.9.2.8+, find the “group_verifier()” function and replace it with the function below.
5. For all other versions, find the “get_group()” function and replace it with the proper function below.

As you can see from this function, it essentially uses the WP Mobile Detector to determine if it was a mobile device. Smart phones return the “high” group and feature phones return the “low” group.

For Version 0.9.2.8+

function group_verifier($group_compare_value) {
if(function_exists(‘websitez_get_mobile_device’)){ //Check to see if the WP Mobile Detector is installed
$mobile_device = websitez_get_mobile_device(); //Returns an array with mobile detection values
if(is_array($mobile_device) && $mobile_device['type'] == “1″ || is_array($mobile_device) && $mobile_device['type'] == “2″){
return true;
}
} //End WP Mobile Detector hook

return isset($_SERVER['HTTP_USER_AGENT']) && preg_match(‘~’ . $group_compare_value . ‘~i’, $_SERVER['HTTP_USER_AGENT']);
}

For Versions Below 0.9.2.8

/**
* Detects mobile group
*
* @return string
*/
function get_group()
{
static $mobile_group = null;

if(function_exists(‘websitez_get_mobile_device’)){ //Check to see if the WP Mobile Detector is installed
$mobile_device = websitez_get_mobile_device(); //Returns an array with mobile detection values
if(is_array($mobile_device) && $mobile_device['type'] == “1″ && array_key_exists(‘high’, $this->groups) && $this->groups["high"]["enabled"]){
return “high”; //Smart phone device
}else if(is_array($mobile_device) && $mobile_device['type'] == “2″ && array_key_exists(‘low’, $this->groups) && $this->groups["low"]["enabled"]){
return “low”; //Feature phone device
}
} //End WP Mobile Detector hook

if ($mobile_group === null) {
foreach ($this->groups as $group => $config) {
if (isset($config['enabled']) && $config['enabled'] && isset($config['agents'])) {
foreach ((array) $config['agents'] as $agent) {
if ($agent && isset($_SERVER['HTTP_USER_AGENT']) && preg_match(‘~’ . $agent . ‘~i’, $_SERVER['HTTP_USER_AGENT'])) {
$mobile_group = $group;

return $mobile_group;
}
}
}
}

$mobile_group = false;
}

return $mobile_group;
}

This allows the WP Mobile Detector to integrate flawlessly with the W3TC plugin!

That statement may surprise you. That means that within 5 years, the majority of visitors to your wordpress blog will be from a mobile device.

Unfortunately, most websites are not compatible with mobile devices. And if they are, they tend to offer a terrible user experience because the website was built for a device with a much larger screen.

And if you’re like most mobile phone users, if the page takes longer than 5 seconds to load, you’re going to give up and go somewhere else.

The average page size of a website on the Internet is 320kb.

It is recommended to have a page size of less than 20kb for most mobile phones. I don’t know about you, but it would take at least 10 seconds to load a page of that size on my iPhone.

1/5th of US adults access the mobile web each day.

As you can see, the current usage on the mobile web is already huge. That means that right now it is possible that 20% of your wordpress blog visitors could be from mobile devices.

If your wordpress blog is not mobile compatible, you could be losing up to 20% of your traffic right now as you read this!

In 2009, less than 1% of the websites on the Internet had mobile specific content.

It is safe to say that the Internet is lagging far behind in being compatible for the mobile web.

It is predicted that 22% of the world’s population will be mobile Internet users by 2013.

That is 1.5 billion mobile Internet users predicted in 2013.

Lastly, it is so easy to mobilize your wordpress blog!

By utilizing a wordpress mobile plugin such as the WP Mobile Detector, you can instantly make your wordpress blog mobile compatible.

This plugin will detect a mobile visitor to your website and automatically show a mobile compatible theme.

You can also checkout the WP Mobile Detector bundled with a number of premium wordpress mobile themes.

Sources

http://en.wikipedia.org/wiki/Website

http://mtld.mobi/resource/mobile-internet-facts-and-figures

http://searchengineland.com/google-web-report-average-page-size-320-kb-46316

http://searchengineland.com/top-10-reasons-your-website-should-go-mobile-32566

http://mobilementalism.com/2010/02/21/18-remarkable-facts-and-15-amazing-phones-from-mwc-2010/

It is no surprise that as mobile phones become more accessible and as the Internet experience on a mobile phone continues to improve that mobile phone usage will overtake desktop usage.

This means that your website must be compatible with a PC as well as a mobile phone.  Unfortunately, the majority of websites are not compatible with mobile phones.

Smaller screens and fewer capabilities are just a few reasons why websites need a mobile compatible version. And with hundreds of mobile phone handsets out there, it is extremely difficult to know what it will take to make your website display properly to each handset.

The beautiful thing about wordpress is that it contains two fundamentally powerful concepts. With plugins and themes, any wordpress blog owner can customize their website with limitless options.

One of these such customizations is the WP Mobile Detector, it will automatically convert your wordpress blog to a mobile friendly version when a visitor comes to your website on a standard mobile phone or a smart phone. If they visit from a regular PC it will show your website without any modification.

How does it work?

The WP Mobile Detector installs as a plugin and puts a check on your website to determine if the visitor is using a mobile phone. It also installs two themes that will be displayed depending on the type of phone. If the user visits from a standard mobile phone, a basic mobile theme will be shown to the user. If they visit from a smart phone, an advanced mobile theme will be shown to the user.

The core focus of a wordpress mobile theme is to reduce the page size significantly and to format the content for a mobile phone by utilizing white space, font sizes, reduction or removal of images, and reduction of content on the page to fit on the respective mobile phones.

Most mobile phones can be put into two categories. Basic functionality and advanced functionality. Because of this the WP Mobile Detector loads two themes to maximize the user experience.

What’s next?

Again, if you have a wordpress blog, it is extremely simple to make your wordpress blog mobile compatible. Simply download and install the WP Mobile Detector, and you can choose any number of mobile themes to show to your visitors.

You can also install the WP Mobile Detector bundled with two themes so that after installing and activating the WP Mobile Detector Bundle, your wordpress blog will be 100% mobile compatible.