I was at WordCamp Vegas this weekend and I noticed, on several occasions, that some of the audience balked at the suggestion of installing plugins. It would seem that somehow the impression is being given that ‘less is more’ in terms of the number of plugins that a WordPress installation should have. I am not exactly sure how this message is being delivered, other than through a network of non-developer-type people who are advising other non-developer-type people on how to build a WordPress site.
I hope this post sheds some light on the ‘Less is More’ phenomenon.
We’ll start this explanation at a n00b non-developer-type level and get a little more technical as I go on.
WordPress is comprised of a series of files that sits on a computer. In the case of your website, the computer has a ‘hole’ open for the “World Wide Web” to access some of its content. This ‘hole’ is called a ‘port’ (think ‘porthole’ from the Titanic). Any computer that has this port open (among other things) can display certain files to the web. These files have to be text-based files–kinda like opening a text editor (not Microsoft Word) and saving a blob of text as blob.txt. Then, the World Wide Web of people can go to the address to your server (your domain name, usually) and access blob.txt and view its contents. You can have several types of text files that get a little more advanced. The next step up from a text file is what’s called an HTML file (that stands for HyperText Markup Language). This is a way to format your text file so that a browser can interpret things like location of the content and the type of content that you are showing.
So, let’s talk about ‘Less is More’ at this level. When a website is accessed, it accesses the HTML page (this is usually ending in .htm or .html with some variations). If that page is filled with JUST the blob from your blob.txt file, it will load faster than a fly avoids a swat. But if you’ve got that file filled with a bunch of links to other files (usually, this is links to images, ‘style sheets’ or ‘javascript’ files, which I won’t get into here), then the load time starts to slow down. If you have ten small images on the page, the slowdown is barely noticeable. If you have ten VERY LARGE images (file size, not necessary width/height) on the page, you can go grab a cup of coffee while you wait for the page to load. Â You can also bet that this is a poorly designed page as each page should have only the most appropriately sized image on the page to do its job. Â The same goes for CSS files and for Javascript files-Anything outside of the existing HTML file could cause a slow-down if it is not developed/designed properly.
So, now we get to WordPress. A step up from HTML is what is called ‘scripting languages’ (something that can be run at the time it is accessed). There are various types of scripting language out there, but WordPress uses  ‘PHP,’ which stands for Hypertext Preprocessor – I know, it’s a little mixed up with the acronym, but just go with it. If you notice, this explanation started with just Text, went on to HyperText markup language and now we’re at HyperText PreProcessor. It’s getting a little more advanced, right?
Right. PHP is a text file that usually ends with .php. This file actually needs a ‘server’ to ‘interpret’ the file and run it at the time it is accessed. So there is this extra layer, if you will, of applications that must be running in order to show a PHP file. These files consist of a mixture between the scripting language and HTML (although, if developed correctly, the files would highly separate out the two). Â You could have a PHP page that is a mile long that could load up in less than a second. The cool thing is that the server only access the parts of the file that is needed to run. It doesn’t need to read the entire script every time the page loads. This makes for a little more flexibility than a straight HTML page does because you can be highly selective in what you access when you load the PHP page. You can add a second mile to your PHP page and it might never change page-load. It might start making the PHP code unreadable, but it doesn’t necessarily change the page load.
So, let’s talk about ‘Plugins’ now. WordPress is uniquely designed to allow for ‘interrupts’ to occur throughout the core of its code. These interrupts are places in which a developer can insert their own code and override what’s happening at the core level. A developer can either do this in the themes functions.php file (highly unadvised) or create a plugin (two big thumbs up). The plugin will generally have 5-7 additional lines of commented code than you would have in the functions.php file, however these are pieces of code that you can now turn on and off at your leisure, as deemed necessary.
Just as with HTML, you can have hundreds of these ‘interrupts’ that WordPress calls ‘Hooks’ or ‘Actions’ and ‘Filters’ either in your functions.php file or as plugins and this would never effect the speed of your site.
The problems begin when the plugins are coded inefficiently. There are a number of different ways to have inefficient code for a WordPress site, but primarily it is either a lot more code that is processed than needed (lots of iterating over data or queries of data) or it is running the plugin with the wrong hook/filter. Another issue can be when a developer doesn’t use unique names of their methods and it ends up overriding or stepping over other plugins or core functionality that wasn’t intended. Once you start having inefficient plugins installed, it can effect the site-speed drastically and immediately.
So, How can we avoid poorly designed plugins slowing our sites down?
1) Vet your plugins: Always read all of the reviews and check which version number of WordPress the plugin works on. Do a google search for anyone complaining about the plugin before installing it.
2) Test your plugin: It’s always best practice to have a copy of your site on another space so that you can test things out before you actually put them on your website. You will be able to catch the small nuances of site-speed before it hits your actual site. Here’s a good tutorial on how to set up a staging site for your WordPress installation.
3) Go premium if you can: Of course, follow my first suggestion for these plugins and vet them well. However, paid plugins generally have much better support when things go wrong and that can be a life-saver (or money saver/money maker).
4) Use a caching plugin. I should have put this first, actually. A caching plugin is magical. It takes the output of the PHP page and turns it into an HTML file to be accessed. This takes away that extra layer of having the applications that interpret PHP have to work to deliver the page. It does mean that you have to delete those html files every now and then but all of the good caching plugins have that option. I recommend WP-Super-Cache or W3-Total-Cache. I usually use WP-Super-Cache for all of my projects that require caching.
WP-Super-Cache Delete Options
Having a ton of well-contained plugins that do very specific things is a much better alternative and does not cause significant site slow-age. On the other hand, having one or two poorly executed plugins can be catastrophic to your bounce rates. As you can see, the quantity is not nearly as important as the quality.
With that… Happy Plugin-ing. 🙂
Alright, so you’ve been hearing about this thing called the “Internet” now for like, 10 years and you’ve even ventured onto Facebook, and although you still don’t quite get it, you have finally come to terms with the fact that… YOU NEED A WEBSITE. Now the question is, “What the heck? How do I do this?”