A Primer on WordPress Plug-Ins
- WordPress is a monolithic platform, which means your entire site is stored on the same server
- This means any plug-in you install will impact your entire site, whether you want it to or not
- Common problems include slow site speed, security issues, and a broken website
- If you need a specific feature, we recommend building it with the help of a trusted developer
WordPress is the most popular choice for building a website, with 38.2% of all sites built on this platform. And a major part of its popularity stems from the use of plug-ins.
Plug-ins are a core feature of the platform, offering an easy way to customize your website without the help of a developer. The thought behind plug-ins is that you don’t need to understand how they work. It’s an appealing proposition for many businesses who want to build (or maintain) a website on their own.
But as we started to touch on in our piece on WordPress myths, plug-ins actually create more problems than they solve. While that piece gave the tl;dr version, we’re here to give you the full explanation.
Read on to learn about how plug-ins work, the issues they create — and the exceptions for when you might want to use one.
Necessary Context: How WordPress Works
To give you the full context on plug-ins, you should have an idea of how WordPress works, and where plug-ins fit into the picture. Here’s a crash course.
WordPress is, by nature, a monolithic platform — all the site action happens in one place. Your content is hosted on the same server that’s used to display your site to visitors.
Every element of your website from the code that controls the functionality, including the database (more often than not), and every piece of content is stored on the same server people around the entire world are hitting when they type that URL into their browser.
This setup sounds logical on its face until you compare it to a website built with a headless CMS (content management system).
With a headless CMS, all of the code and functionality of the site are isolated to its own server. When a visitor wants to visit the website, they are pinging a different server. For the end-user, this means their computer doesn’t have to parse through a bunch of code to see the website.
All the visitor needs to see are the visual elements and compiled data (aka content). Not having to render all of this code, thanks to the setup of the headless CMS, means the website will load faster. The problem with the monolithic platform is that the codebase needed to manage the back-end of the site is loaded as well — meaning your visitor has to wait for the entire website to render before they can look at it, even the parts that are irrelevant to them.
Tying this concept back to plug-ins, the separation between the server(s) that hosts your website and the server that delivers the website to visitors matters quite a bit.
To put it simply, the separation between servers creates a buffer zone.
When a device doesn’t have to render every bit of code on a site to display it, there are fewer opportunities for plug-ins to cause issues with load order and load time — both of which culminate in a slower website and frustrating experience for your user.
Knowing Your Front End From Your Back End
Get your mind out of the gutter — we’re not talking dirty here. The distinction is simple but matters quite a bit for plug-ins.
The front end is what your readers see, and the back end is where you manage the website.
Because WordPress is a monolithic site, the front end and back end of the site are in the same place. With a headless CMS, each end is in a separate place.
Plug-ins, too, have front end and back end versions. Front end plug-ins are the ones that affect website speed, visual elements, and things like that. Back end plug-ins are more process-oriented and don’t usually affect the site speed — unless you’re on WordPress.
If you load a back-end plug-in with WordPress, it’s still going to impact the font end. Regardless of what type of element you’re adding to your WordPress website, it requires more resources on the server, which means it will impact site speed. Even if it’s a back-end plug-in.
When you have the separation, like sites that run over Shopify’s API or Strapi (both examples of a headless CMS), that back-end plug-in is running on a different server.
The Problem With WordPress Plug-Ins
Because the front end, the back end, and everything in between runs from the same server with WordPress, introducing new plug-ins will affect the entirety of a site — no matter where you put them.
Here’s what makes it a problem: Plug-ins are built in a vacuum. At its core, a plug-in is a piece of code that is added to your site to perform a desired function. Each plug-in is a one-size-fits-all bit of code that’s copy/pasted into your website, without regard for anything else that’s already there.
Because all plug-ins are built individually, they’re not built to work well with others — and they don’t want to. When your website is loading, each plug-in is a selfish asshole that needs to be the first to arrive — and they’ll fight each other for it.
The more plug-ins you throw in the mix, the more competition each element has for that coveted first spot in the load order. The more plug-ins jockeying for the position means the more potential for fights to break out. When fights break out, your site grinds to a halt or succumbs to a total collapse.
Each plug-in also brings its own scripts and elements that make the website heavier. When one plug-in doesn’t like the cut of another plug-in’s jib, or another decides to reinvent itself to keep up with the times and takes the rest of the site down with it.
The more plug-ins you add, the more avenues exist for a problem.
For example, we once worked on a website that had something like 30 plug-ins, which is an insane amount. The website was constantly breaking because one plug-in wasn’t compatible with another. To remedy the problem, the company would make a change — which created a chain reaction ending in a broken piece of custom software that tore down a mission-critical piece of the business.
Our first step in helping this client was to audit their plug-ins and apps with them. From here, we created a list of must-have functionalities. Then, we took the list and built in as much functionality as we could into a more modern theme.
Plug-Ins Break Programming Rules
In web development, there’s a programming methodology known as DRY, which means Don’t Repeat Yourself.
If you’re writing code to build a button on a site, the code that renders the button is only written in one spot and is referenced everywhere it’s needed. Even if the button looks a bit different on another page, it’s still referencing the same central code, which means you get several uses out of one snippet of code.
Plug-ins completely shatter this methodology. If you use a plug-in to add buttons to your site, every button you add creates another repeated snippet of code. And that mentality goes against the entire methodology that kind of modern programming is built on, which is to not repeat code.
Plugging In Security Risks
Slow website speed, cage matches, and duplicate code are all small potatoes when it comes to another issue of plug-ins: Security risks.
A lot of plug-ins will add stuff to your site that’s shady af — especially if it’s free. The companies and programmers who created the plug-ins aren’t giving it away out of the goodness of their hearts. They’re getting something in return — like personal and proprietary information.
The right to this information is probably buried somewhere deep on page 23,957 of the terms of service that you quickly accepted as you installed the plug-in.
When you’re installing plug-ins, you’re installing snippets of foreign code onto your website.
This code gives people with the right knowledge the ability to access your server. Since the entirety of a WordPress site is hosted on a single server, this allows the person to do a number of shady things, like deface your site or redirect your URL to their site.
And you may never realize your site has been hacked. A lot of times people have this assumption that if you’re hacked, it’ll set off some kind of cyber burglar alarm and you’ll know right away. But that’s wrong.
If someone shady hacks your site through a plug-in and launches a bunch of Viagra ads from your server, you could never know. But you’ll pay the price from either customers burned from seeing these malicious ads, and Google’s going to find the malware and hit you with a penalty.
You’re responsible for your own website, and if a hacker abuses your poor cybersecurity, you’re considered at fault — which means a severe penalty that’s tough to recover from.
Installing a plug-in is an exercise in balancing risk vs. reward. Is the banner you want to add to your front page worth the potential abuse of personal data? Each time you install a plug-in, you’re skyrocketing the risk that something is going to go wrong, either because it breaks something on your site or doesn’t work well. You’re exposing yourself and your clientele to untold danger with every snippet of code.
That risk makes the decision to install or not to install a much bigger question than whether you need a banner on your front page.
The Case for Plug-Ins: Proceed With Caution
Now that we’ve (hopefully) scared you straight, there are limited circumstances in which we’d recommend plug-ins.
When creating or upgrading websites, we might install trusted plug-ins that act more as a utility than a feature. By that, we mean something that’s going to save more time to use the plug-in than it will take to fix the eventual issues it causes.
As an example, we might install a plug-in like Advanced Custom Fields for WordPress. That utility plug-in lets us add different content to our themes, and creates a greater ability to edit different pieces of content.
This particular plug-in also doesn’t drag the site speed down by adding scripts and CSS to the front end. It’s simply adding some database entries and a way to edit those entries — without impacting the user.
Avoid plug-ins that do things like adding Google Analytics to your site. It’s simple to add the code for Google Analytics directly to your site through your WordPress theme. Adding a plug-in is not only redundant, but it also increases the amount of time your site takes to load.
We also recommend avoiding plug-ins that add modals, pop-ups, and similar elements. While helpful for lead generation, these types of plug-ins tend to add a bunch of JavaScript to your website that doesn’t get used. All of this extra JavaScript increases the load on the front end of our site — again ratcheting up that load time.
How Can I Customize My Site?
If plug-ins aren’t the right choice for customizing your site (in most cases), what’s a business owner supposed to do?
For features you’re going to use consistently, we recommend building it on your own.
If there’s a particular feature that you’re relying on a plug-in to implement, like pop-up forms, have a developer build it for you. A skilled developer will not only make sure the feature works well with everything else on the site, but also provide support for updates along the way.
We especially recommend going the custom route if the operations of your business depend on a specific plug-in. If a feature suddenly broke or disappeared, and you’d be completely screwed, that feature should not be a plug-in.
It might be more expensive up-front to pay a developer to build something, in contrast with using a free plug-in. But putting the heartbeat of your business in the hands of a WordPress plug-in is a riskier gamble.
When you install a plug-in you found somewhere online, the person who built that plug-in has no vested interest in you at all. If they get hit by a bus tomorrow, if they decide that they’re done supporting the plug-in, or if they decide to change it in a way that breaks your site, your business is now in peril.
You’ll have to scramble for another plug-in or alternate solution after you’re already plunged into chaos. By contrast, if there’s an issue with a custom feature built by a trusted developer, you can simply give them a call and get the problem sorted.
Another cautionary tale based on experience: We’ve seen clients who build their entire website (and business) around two or three mission-critical plug-ins. This approach is not only a gamble for all the reasons you’ve already heard, but it also creates a ton of technical debt and forces that company to build their entire business around those plug-ins.
Not only are these clients relinquishing control of their site in the near-term, but they’re also limiting the possibilities for growth in the long-term.
As they grow and expand, they may need to add in new software, website features, or even operations functions to more efficiently manage the increasing revenue. But if their entire operations are built around plug-ins, and they don’t play well with the improvements, the business will be in quite a bind.
The Takeaway
If there’s a function you need on your website, it’s best to reach out to a trusted developer before you install a plug-in.
A developer has the knowledge and insight to help you determine whether you need a plug-in to do that thing (like installing Google Analytics), or if they can build you something better.
Though hiring a dev might cost more up-front, you’ll get what you pay for:
- You can trust the feature will work well with the rest of your website
- Your website won’t break when you need an update
- You’re not accruing additional technical debt
- The code they create will be efficient, meaning your site speed won’t be affected
- Your developer will provide the needed support to help your business grow with your technology stack
If you have any questions about plug-ins, need advice about technology, or want to knock some website features off your wishlist, get in touch. Building websites are one of our many passions, and we’re happy to help however we can.