SilverPen Goes Mobile With WPTouch

As you may or may not know, I’ve been going ’round about mobile browsing on the web for some time. I was almost convinced once that I had found a mobile solution for my WordPress sites, but it just didn’t work that well. The main problem was caching: WordPress, for those unfamiliar with it, can become bloated pretty easily, which makes loading a site very slow. Using a plugin to cache your pages helps compress them to speed up load time. Unfortunately, sometimes the regular version would be cached and served up to mobile devices, and sometimes the mobile version would be displayed on the desktop. Admittedly, this was more an issue with the caching plugin I use, but if it’s got to be one or the other, caching is necessary and a mobile view is not.

And then I stumbled upon WPTouch. This WordPress plugin came completely out of left field for me. I had been looking, trying out, beta testing, and giving feedback on different mobile solutions for a while before I gave up, but I had never even heard about WPTouch. All of a sudden it was there, I installed it, and it worked. No real configuration needed, no tweaking, no fiddling with cached pages or having the mobile view show up in desktop browsers. Everything Just Worked.

So I’ve been using it for several months now. It’s on both my site and on our work site, and I am confident enough in it to recommend it to you. If you self-host WordPress, there is absolutely no reason your site shouldn’t have a mobile view, and WPTouch provides that free of charge and very simply. Now that I’m finally comfortable with it and settled, I’ll be making a donation to the fine folks at Brave New Code for their great work. Give WPTouch a try, and if it works for you, I encourage you to do the same.

A Bit More About WPTouch

SilverPen Publishing on an iPhone in Mobile Safari

Mobile plugins for WordPress have one primary function: serve up a different theme to cell phones than to regular web browsers. This means that if you visit my site in Firefox on your computer, you see one thing, but if you visit on your iPhone or other smart phone, you’ll see the mobile version. The mobile version is much simpler than the regular one, which makes it much smaller. This means it loads faster, which is important on mobile connections like Edge. Even on 3G, you’ll have significantly faster load times with a mobile version of a site. In addition, text and such is reformatted to fit better on a smaller screen.

The previous plugin I tried, WordPress Mobile Edition, is built on the Carrington framework. Though very shiny, I found it to be too much. It was bigger than necessary, which slowed load times. In addition, it slowed down my site overall. I’m not a programmer and can’t claim to know how, but WordPress Mobile Edition contributed .5-.7 seconds to my site’s load time by itself. Half a second might not seem like much, but it can make a lot of difference in perception of a site’s functionality and reliability.

WPTouch doesn’t negatively impact my site overall, and it’s very quick to load on mobile browsers. It also has a very polished menu system that can be customized through the WordPress Admin Panel. It should be said that the developers are very responsive as well–there was a problem with the menu a month or two ago where it wasn’t loading right, and they had it fixed pretty quickly even though this problem wasn’t happening on all sites. They seem very committed to this product and doing a good job, hence the donation.

Check it out. It’s free and available at BraveNewCode.com.

Speed up WordPress by Disabling Plugins

I’ve known for a long time that WordPress plugins extend load times of both the front-end site and the administrative interface on the back-end. Each one has numerous sets of PHP calls and, since each page is loaded dynamically, every plugin has to be called and checked to see if it is included or not. WordPress leaves nothing out, so the more plugins you have, the slower it becomes as it has to check more and more.

What’s worse, if you have inefficient plugins, they can slow your site down to a crawl. The fault isn’t WordPress’s, your web host, or an overly-large image, but rather is due to poor javascript execution, logic loops, redundant code, or other culprits of Programming Gone Wild™. In these cases, the only options are to rewrite the plugin to make it more efficient or ditch it altogether.

Tired of my administrative interface taking forever to load and switch pages, I decided to test each plugin I use individually to discover the culprit and expunge it from my WordPress installation. Some of the instigators were surprising, but they’re all gone now.

Woopra

I love this little tracking utility because it allows me to see people live when they hit my site. I can see when they came in, what they’re looking at, where they are in the world, and watch the ping away as they leave. It’s just very cool, but it’s also very bloated. It violates the common wisdom of tracking technologies hosted off-server, which is, “Since all the work is being done by our servers, rather than yours, it should have next to no impact on your site performance.” Google Analytics and WordPress Stats also operate in this fashion, where my web server isn’t doing the tracking or analysis so my performance shouldn’t take a hit.

Unfortunately, Woopra (or at least the Woopra plugin for WordPress) often hangs with javascript errors, leading to very long load times on all pages, be they front- or back-end. I had to disable Woopra on our wiki at work because of how much it was slowing things down (which was not using the plugin, by the way, just the stock code), but I hung onto it for my personal site because I like the utility so much. Unfortunately, I just can’t put up with it any more.

WordPress Mobile Edition

I’ve gone back and forth on mobile browsing so many times it’s like a worn out joke that just won’t go away. While I like the idea of providing improved functionality for mobile users, this plugin added at least half a second to all page load times, and often the lag was more than that. Half a second doesn’t sound like much until you’re waiting over and over again for what we have come to expect as instant. That functionality simply isn’t worth the lag to me.

WP-DBManager

This plugin allows you to manage your database through the WordPress administrative interface, and in the meantime automates some nice routine maintenance matters. However, it also slowed down my site, and since I don’t actively use it often, I went ahead and disabled WP-DBManager. I can still re-enable it if I want to do a quick backup or optimization, but most of the time it will sit dormant now.

WP Greet Box

This plugin pops up a box at the top of each post when someone comes from Google, Facebook, et. al. saying, “Welcome! You should consider subscribing!” Though generally annoying, I felt that WP Greet Box did this in a more polished, unobtrusive manner, so I’ve been using it for a while. Unfortunately, it was right behind Woopra in causing my site to slow down, so it had to go.

Total Gains

Though each of these only accounted for 0.4-1 second each of lag, between them they were doubling the load time of everything on my site, from 1-3 seconds to 4-7 seconds (approximately). In addition, now that I don’t have to worry about a mobile edition of my site, I can turn WP Super Cache up to full blast and cache/compress all my pages, decreasing load times further.

Though I’m sorry to see some of these plugins go (I’ve been using Woopra for well over a year now), it’s hard to justify negatively impacting load time across the entire site for both myself and visitors for a few minor conveniences. We must always balance functionality against speed (and security, and a slew of other things for that matter), and in this case speed won out.

For the other 26 plugins I will continue to actively use, they do slow my site down some, but all of them together only impact site times by 1-2 seconds. In those cases, the loss of speed is well worth the gain in functionality.

Which plugins do you keep even though they slow things down a bit? And which is more important to you: Speed, Functionality, or Security?

The Evolutionary Process of Mobile Browsing on WordPress

Two Calls

My first rant, though certainly not my first try

A couple of months ago, I wrote about the trials and tribulations I had encountered and failed to overcome in regards to making WordPress a little more mobile-friendly. I’m not a coder or even a web developer/designer (though I sometimes pretend to be at work), so beyond using the tools and guides provided and tweaking some code, I’m at a loss for how to redo everything and make it work myself. Unfortunately, the tools that existed didn’t play well together and therefore didn’t serve my purposes for providing a fast site that also worked on mobile browsers.

When I wrote about my failed attempts, I learned that the coder, patrias familias, and maintainer of WP Super Cache, Donncha O Caoimhm, modified the plugin to allow mobile developers to add a filter to their code that would tell WP Super Cache to cache and serve data differently depending on certain variables, but no one quite picked up on it or modified their plugin to work in conjunction with WP Super Cache. And since WordPress almost isn’t worth running without WP Super Cache, it was sort of a wash.

A New Hope, Another Failure

As you may recall, I thought I had found a solution in the form of the WordPress Mobile plugin earlier this month, but it too failed. The problem is that you don’t just want a different stylesheet for mobile content; if that was all, there’d be no issue because WP Super Cache doesn’t cache styles, just content. But on mobile devices, you don’t have room or time to load everything, so you really only want to serve the content that is pertinent (blogrolls, for instance, might be nice, but you don’t want to have to scroll past that on a tiny mobile screen). Therefore, plugins that serve content to mobile devices also use a different theme for those devices, and when that theme gets cached, it then ends up being displayed to regular web browsers. WordPress Mobile, like all the other mobile plugins, weren’t using the filter in WP Super Cache to cache and serve their content appropriately.

Eureka! At last!

Donncha has just released version 0.9 of WP Super Cache, however, and this one takes into account user agent strings to identify mobile browsers by using the detection code from Alex King’s WordPress Mobile Edition. I began testing this on SilverPen yesterday using developmental versions of both WP Super Cache and WordPress Mobile Edition, and after identifying and working out a single bug (Donncha worked it out, of course, not me!) it appears to be working great! We ran into a snag where Safari on Mac was being identified as a mobile browser, but Donncha had that fixed before I could even get him the log files.

A new version of WordPress Mobile Edition has not yet been released, and I’m not entirely sure it needs to be. The caching and UA checks are being handled by WP Super Cache now to decide what to cache and serve, so not only should your choice of mobile plugin be irrelevant, it should also Just Work™.

Give it a try and let me know what you think!

Download WP Super Cache

Download WordPress Mobile Edition

Image by: lusi

WordPress not quite ready for mobile browsing

Instead of redacting this entire entry, I’ll let you know that mobile browsing for WordPress does work now. See my updated article on The Evolutionary Process of Mobile Browsing on WordPress for more details.


One of my design goals for revision 3 of SilverPen Publishing was to make the site more accessible. I’m not a web developer by trade and didn’t really know how to do this, but I knew that I didn’t want to exclude people from visiting my corner of the web. To me, this didn’t just mean making SilverPen more friendly to screen readers and other assistive technology devices, but also to make the site work well on mobile devices.

To this end, I found yet another great plugin by Alex King that queries the user agent of the browser trying to access the site. If it’s a mobile web browser, the plugin serves up a custom template that’s very lightweight and fast to load on mobile devices. It worked very well, but unfortunately it only worked in a vaccuum, and even then had some serious repercussions.

WP Super Cache

First off, it simply does not work with WP Super Cache, and in fact, no mobile browsing solution does. For those who haven’t heard of Super Cache, I’ll explain what it does and why it’s necessary very briefly. Every blog post and page that WordPress serves up is dynamically generated on the fly when you access the site. Putting all the pieces together to make a web page puts a lot of load on the server, and it makes the page load a lot slower for you. Caching allows the server to create static pages, rather than dynamic ones, of the same content and therefore serve it up faster. This reduces load on the server and makes the page load a whole lot fast for you.

Because of how WordPress works, this caching is pretty much vital to running a site on WordPress. My traffic’s not that high yet, but it has more than doubled in the last few months, and I expect it to continue increasing at a similar rate. The last thing I need is Bluehost freezing my site temporarily due to a sudden spike of traffic, so like all good WordPress bloggers, I use WP Super Cache.

To make a long story short, WP Super Cache creates a copy of a page the first time someone visits it. Each subsequent visitor is shown that copy, and this is what breaks WordPress Mobile Edition. Since you’re viewing a static copy of the page that has already been generated, you don’t see the mobile theme, rendering the mobile plugin useless.

If it’s a choice between having the page load more quickly for most everyone and reducing the load on my server vs. having the site more accessible on mobile devices, I’m going to have to go with the former. Especially as data plans move towards 3g and faster mobile browsing.

Search Engine de-Optimization

The second reason that mobile browsing fails for WordPress is because it kills SEO, which harms your ranking in search engines. By its very nature of essentially serving a different set of pages to mobile devices, plugins such at WordPress Mobile Edition fool search engine robots into thinking there’s a second website with duplicate content on it. Such duplicate content is ranked down by search engines, which means your pages are less likely to turn up in searches and you’ll get less traffic.

The mobile plugins and solutions for WordPress all admit that it’ll kill your SEO and recommend you “do something” about it, but don’t offer many solutions. I thought I had found an elegant work-around yesterday in the form of themed multiple domains in WordPress, which would allow me to have multiple domains pointing at a single instance of WordPress, wich each domain triggering its own theme. In this instance, you can easily redirect robots that hit those other domains to a separate robots.txt file, which would tell them “don’t index this site.” For example, if I had silverpenpub.net and m.silverpenpub.net (for mobile browsers), I could have the main site indexed and tell the robots not to index the mobile site.

But I don’t want to register a separate domain for mobile browsers, and I couldn’t get it to work with a subdomain for some reason. Maybe I was doing something wrong there and will figure it out eventually, but it’s not going to happen today.

Not worth my time

In the end, trying to twist WordPress into working on mobile devices doesn’t give a  lot of return for the investment, and I’m beginning to think it will be a non-issue before too long. Even I am beginning to dream nightly of acquiring an iPhone, and browsing with a 3g connection means that, even over a cellular data plan, you can load a site quickly. And newer phones have a lot larger screens, which means that my theme displays fine all on its own.

I know that WordPress now has a iPhone-friendly administrative interface, and I hope that they include more features in the future to help their platform run better on mobile devices. Accessibility is still important to me, but I can’t justify 5-10+ hours of work to make the site more accessible to 0.5% of readers by introducing “features” that degrade or break the site for the other 99.5%.