The Plugin Rule
I got caught up in a discussion on plugins for WordPress today, which got me thinking about some things that I really should share with the Devlounge readership. It might seem a trifle basic to some of you, but you should understand that there are a lot of people who extend and further extend their websites with plugins, widgets, gadgets, gizmos, addons, extensions, or whatever they are called for their publishing platform, and by doing so really just make the visitor’s experience worse.
So what am I talking about, really?
Sometimes you stumble over a cool feature that someone has on his or her website. You want it for your own, or your client wants it for their site. Googling it will find a solution, of course, and it might be a plugin for the CMS you’re using.
Excellent! Install! Blam! It’s up!
Then it happens again. And again. It goes on and on, and suddenly you have 20+ plugins installed, and you’re wondering why the reader stats are going down.
The ease of adding plugins makes us sometime forget 5 things:
- Extending the CMS with plugins might strain it more.
- Additional functionality usually means additional database queries, calls to scripting actions, or whatever.
- Widgets hosted on a different server can hog up a site, just because the server they are on isn’t responding properly.
- Too many things at once might clash, because the developers didn’t take everything into consideration.
- Cramming too many features in one place will most likely make it cluttered and unfocused.
It is very easy to just download a plugin and extend our CMS today. A lot of times that is a good thing, but sometimes it goes too far. There really is no telling how well two different plugins will work together. A lot work perfectly well, but some might clash due to poor programming or coincidence. After all, there is no way that the developer can test his work with everything out there, now is there?
There’s also the matter of load times. First of all, the more you put on a site, the bigger it will get and the slower it will load. This is less of an issue today, with high speed internet access, but it is still an issue. Second, if you use external services, like Share This or Disqus for instance, you will have to wait for them before you can use their functionality. If they are implemented right, the rest of the site will load, but that is not always the case. Third, people are impatient, high speed internet access or not – they want everything to happen the moment they click. So when someone finds a link to your Kick Ass Super Duper Post Of Brilliance, clicks in anticipation of reading something genius, and then it loads slooowly, you might just have lost a faithful reader.
Finally, there is something called two many features as well. Do you really need everything you clutter your site with? Just browsing the blogosphere tells me that the case is usually “probably not”…
The Plugin Rule
So what can you do? I have something I call the Plugin Rule. Basically, it goes something like this:
Never add a plugin for a feature your CMS can do with a little bit of custom coding.
Now, there’s the issue of actually doing that custom coding as well. Let’s say you’re running a WordPress blog and want a submit to Reddit link. You could do that with Share This, with one of the numerous plugins, or you could hack the theme template and add the submit link there. The ideal solution is the last one, since it relies on no plugins nor external services, but not everyone is capable of doing that. They should, of course, choose a plugin that gets the job done. That is, if they really need the feature – otherwise just forget about it.
It all boils down to your level of expertise of course, but try and avoid using plugins for everything. Always search for a less obtrusive solution. And perhaps most important of all: Always question the need of the added functionality. After all, less is sometimes actually more.