There is an easy solution to this problem, switch to our free version that will remain free, the WP Mobile Detector.

And if you need any support, feel free to send an email to support[at]websitez[dot]com.

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.

There are many of these tools available on the Internet, but most just simply return statistics about your website. Things such as page size, keyword counts, header tag counts, header output, and other miscellaneous facts about your website. But this tool provides specific instructions on how to improve your website. It tells you in lamen turns what it found and how to fix it with a link to a resource that will help you complete the suggestion.

For example, when we ran the tool for Websitez.com, it returned back this information:

As you can see, there are plenty of things that we need to fix here at Websitez.com!

Checkout the website tips and suggestions tool, it is like having a webmaster expert in your back pocket!

I find myself with that feeling again with mobile development. I have tried multiple libraries, each with their pros and cons. I recently decided to dive into Sencha touch to see if it could be my plug and play framework to create interesting effects.

While Sencha Touch has glimpses of genius, it still falls far behind where a viable mobile framework needs to be. Their own example site runs horribly on my iPhone 4 on a 3G connection. On the Sencha Touch demo page, not a SINGLE demo worked as expected 100% of the time.

And in all reality, not a single library performs well on a 3G connection. A compartmentalized version of jQuery is the only thing that I have found that is the proper file size and provides the proper user experience for all smart phone users.

The truth of the matter is, while the demos may work great in a native app, they just don’t work well in the real world. When you actually have to deploy something to tens of thousands of users on the mobile web, there really isn’t a framework that has the performance needed to give the visitors the experience they desire.

I have resorted to using a combination of CSS3 and jQuery on my projects because it is the only predictable solution that gives a great user experience every time.

As I look back at Sencha, they continue to approach their library as some sort of a comparison to everything that is out there and place the success of their company on constantly “one-upping” the competition. When in reality, if they just created a modularized framework that allowed the inclusion and exclusion of certain components with graceful degradation built in, they would have a framework that would not only work for a native app, but it would be the first that truly worked for the mobile web.

• The fastest way to select an element in jQuery is by the element ID.
• The second fastest way to select an element is by tags.
• var receiveNewsletter = jQuery(‘#nslForm input.on’);
• The slowest way to select elements is by class name.
• When traversing elements, use find instead of multiple items in a selector. It is slightly faster.
• var divs = jQuery(‘.testdiv’, ‘#pageBody’); // 2353 on Firebug 3.6
• var divs = jQuery(‘#pageBody’).find(‘.testdiv’); // 2324 on Firebug 3.6 – The best time
• Cache elements in jQuery that you use often.
• var header = jQuery(‘#header’);
• var divs = header.find(‘div’);
• Use the data() function to store information on your elements for later.
• jQuery(‘#head’).data(‘name’, ‘value’);
• //Later in the flow
• jQuery(‘#head’).data(‘name’);
• Always load the jQuery library from Google’s CDN
• https://ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min.js

If you need to do DOM manipulation for the mobile web, jQuery is a great option. Hell, even if you want to do DOM manipulation in a native app, jQuery is still a great solution.

My biggest complaint is the size of the library. Even when it is minified and GZIPPED, it is still 31kb. That is impressive for the desktop web, but in my opinion it is not sufficient for the mobile web where latency is priority #1. 

I found a great resource that has the vast majority of the functions that make jQuery great at the fraction of the file size. It is called jQuip and it is available on Github. It reduces the file size from 31KB to 6KB. Keep in mind this does not contain all of the functionality of the official jQuery, but 90% of it (what it actually contains is listed in detail on the link above). Their goal is to create modules that allow you the developer to include only the functions you need which will allow you to significantly decrease the file size of the included libraries.

This is one of those projects you will want to keep an eye on. They are onto something.

It seemed that almost every project we worked on we needed to modify the login form for WordPress. One project it was simply changing the logo from the default WordPress logo to a custom one. The next it was changing the colors to match the theme we developed for the customer. And the most recent projects we had to place the login form inside of the theme layout. By the second project, we decided to stop re-inventing the wheel and create a plugin.

The WP Login plugin, or the WordPress login plugin, allows you to insert the login form into your active theme. It also extracts out the login form and allows you to customize it through a simple file editor. If you’d prefer to keep the stand-a-lone login page but simply edit the style and change the logo, the plugin can do that as well.

This plugin was meant to handle any possible WordPress login form customization, and we hope that you will give it a try and send us any feedback you may have.

Download it here!

Recently a hack was found that exploited the Timthumb.php script. The WP Mobile Detector utilizes the Timthumb.php script, so it could potentially effect any blog running the WP Mobile Detector plugin.

I am happy to announce that this was fixed and an update was pushed to WordPress.org. As long as you have version 1.7 or higher you are all set.

The exploit had to do with how a version of Timthumb.php validated the domains that were authorized for the script. It performed a string comparison on an array that was incorrect.

For example, if this domain was authorized “domain.com”, then this domain would also be authorized, “mydomain.com”, since it contains the authorized domain. This is a pretty huge error in the script and has since been fixed in the most recent version.

If you use Timthumb.php with any of your projects, it is recommended that you update to the most recent version, which is version 2.8 as of writing this post.

You can find the most recent version here: http://timthumb.googlecode.com/svn/trunk/timthumb.php

Websitez.com is proud to announce our own javascript based mobile detection script that works with any website.

By including a snippet of javascript in your website, a visitor from a mobile device will be redirected to any mobile website you desire.

This script uses the same detection available in the WP Mobile Detector premium plugin.

Features

• Detects 5,000+ mobile devices.
• Install and configure in less than a minute.
• Instantaneous mobile detection.
• Backed by proven technology.

Get the script!

If you’re interested in being one of the first to use this script for your own website, please send an email to: estolz[AT]websitez[DOT]com