The common tagline about WordPress plugins goes like this – they are an essential part of the WordPress ecosystem because they offer the power to extend the functionality of WordPress with a nearly endless list of click-to-download integrations. And WordPress plugins are super popular – the number of plugins and installations absolutely backs up this claim. Yet there are drawbacks that rarely make it into those ubiquitous Best WordPress Plugins blog posts. And those drawbacks – security and performance – are getting more problematic. So it’s worth asking – are WordPress plugins even needed, and if so, which ones?
Trends in Google searches for the past five years. What is that little blip of interest in website hack back in the summer of 2015? You guessed it – Ashley Madison®
Among WordPress developers and power users, WordPress plugins are used with a sense of turf protection – peeps have their favorite go-to plugins they have been using since back in the day and don’t want change. Among casual users, WordPress plugins are a quick solution that goes from Google search to final installation in 20 seconds – peeps are in a hurry.
The power users don’t want to change and the casual users don’t care. So that doesn’t leave much space for examining the benefits of WordPress plugins versus their costs in order to discover more secure and performant ways of accomplishing the same objectives. But let’s go for it anyways. And yeah, I just used the word performant. Ridiculous word.
There are 54,852 plugins listed on the WordPress Plugin Directory and the top 10 most popular boast 35+ million downloads. That’s a lot. Nowhere near as many as the 3,127,123,396 YouTube views of the K-pop phenomenon Gangnam Style (remember that?) or even the 1,269,045,064 views of the extraordinarily strange I’m a Gummy Bear (The Gummy Bear Song). But still. People love them some WordPress Plugins (and gummy bears).
WordPress Plugin Security Issues
So while listening to either Gangnam Style or I’m a Gummy Bear and thinking about how popular and awesome WordPress Plugins are, check out these recent headlines from our favorite WordPress Security website WordFence:
Backdoor in Captcha Plugin Affects 300K WordPress Sites
The WordPress repository recently removed the plugin Captcha … At the time of its removal, Captcha had over 300,000 active installs, so its removal significantly impacts many users … Based on the public data we’ve gathered, this developer … is very likely a criminal actor attempting yet another supply chain attack.
Cryptomining Supply Chain Attack Hits Government Websites
Three Plugins Backdoored in Supply Chain Attack
In the last two weeks, the WordPress.org repository has closed three plugins … Duplicate Page and Post, No Follow All External Links and WP No External Links … because they contained content-injection backdoors. “Closing” a plugin means that it is no longer available for download from the repository, and will not show up in WordPress.org search results. Each of them had been purchased in the previous six months as part of the same supply chain attack, with the goal of injecting SEO spam into the sites running the plugins.
An accessibility plugin, a Captcha security plugin, and some pretty ordinary and useful plugins to make managing WordPress easier. It’s not stupid or naive to assume those would work as intended. Those are the exact things that the traditional WordPress Plugin sales pitch promotes – easily extend basic functionality with a library of free add-ons.
Yet those free add ons got sold or hacked and ended up installing admin level backdoors or placing cryptomining scripts onto viewer’s computers. Those headlines are just from the past few months. And that’s not all of them. Not good.
How would you explain that to your client or user? Blame it on the plugin! But why was that plugin even there in the first place. Someone had to install it.
No one can know for sure what the future potential of a plugin getting sold or hacked is. So, to prevent this kind of thing, it may be better to ask – could the intended functionality have been achieved in a way that doesn’t open up the whole website and its viewers to security compromises?
WordPress Plugin Performance Issues
There are two primary types of WordPress plugins – front end and back end. Front end plugins offer presentation extensions visible to viewers – sliders, banners, callouts and chat apps are common examples. Back end plugins offer functional extensions generally not visible to viewers but rather helpful to developers – backup tools, custom post type and custom field management applications and Search Engine Optimization plugins are common examples. Many span both front and back end – form entry and caching plugins are examples.
All plugins will affect your website’s performance as they add scripts, stylesheets, php loops and / or database queries. But any functionality of any kind technically does this. So the better question is – does a plugin do a worse job at adding unnecessary scripts, stylesheets, php loops and / or database queries than could be achieved by another means?
Front End Plugins
In general, front end plugins are going to decrease performance more than back end plugins are, for a couple of reasons:
- Front end plugins – like WordPress themes and Page Builders – are designed to offer a wide range of functions to wide a range of needs. They therefore have more bloat. That slider plugin has all kinds of styles for many kinds of sliders, but you may only need one. The viewer still has to load up all the styles for all the sliders. If a developer custom coded just the desired functionality, there would be more efficiency and less wasted code.
- Front end plugins do their thing when viewers are looking at the site – the hits from added stylesheets, scripts, php loops and database queries are taken in alignment with page views. Back end plugins do not necessarily run in alignment with page loads. Many back end plugins only run selectively to help set up loops and functions or add content. A page duplication plugin is an example.
Based on the above, and based on our custom design workflow, we don’t use any front end plugins except for hybrid front end and back end plugins like Yoast and Gravity Forms. It’s just not worth the performance hit and security risks.
What kind of performance hit are we talking about? Here’s a table comparing some popular slider plugins.
Slider Plugin Page Load time Requests Page size Soliloquy 1.34 secs 26 945 KB Nivo Slider 2.12 secs 29 1 MB Meteor 2.32 secs 27 1.2 MB Revolution Slider 2.25 secs 29 1 MB LayerSlider 2.12 secs 30 975 KB
God your mom intended and get on with it.
The argument for using a plugin instead of custom design and development is always cost – the great arbiter of decisions since Adam Smith. The plugin is in fact cheaper in the short run. But in the long run:
- How much does it cost to explain to your clients, customers or viewers about that cryptomining malware? But that could never happen to you, of course.
- Over time, plugin need to be maintained, updated and checked against updates to WordPress itself and the website’s theme. That takes time. Which leads many to not do it out of fear of breaking something. So no one updates anything, including WordPress itself. Not good. And expensive to untangle.
Maybe it’s not the client’s fault, though. Maybe the client never made the decision, but has to deal with the effects. WordPress designers and developers often take on budget jobs, install a bunch of plugins to accomplish the client’s goals cheaply then hand it off to the client to manage. Please … just don’t do this. If the client doesn’t have the budget to do something safely, the developer should inform the client of the risks and let the client make the call.
Back End Plugins
Back end WordPress plugins usually offer much more of a functional benefit compared with their performance hits as compared with the performance hit of manually developing that feature for a couple of reasons:
- Back end plugins generally don’t add code that initiates more HTTP requests for the viewer. Managing custom post types, search engine titles and compressing images doesn’t really slow down the website for visitors. The time it takes for a back end plugin to do its thing is experienced by the developer, not the viewer
- Back end plugins run either one time or on a schedule that is not related directly to page load
Sure, poorly coded backend plugins can have a negative or even detrimental effect on the front end performance of the website. But don’t use crap – problem solved.
Beyond WordPress itself, a WordPress website only requires 2 files to work – an index.php file and a style.css file. Zero plugins are needed. Before you install a plugin, ask whether the security risks and performance hits are worth the functions gained. After all, any additional functionality can technically be custom coded.
Plugins We Use
Here’s the Plugins we find to be worth the performance and security risk trade offs. Some way more than others. These plugins are on the base WordPress install we build each new project from.
WP Migrate DB
It’s hard to think about life without the Pro version of WP Migrate DB. The plugin makes exporting and migrating WordPress databases a breeze. If you’ve worked on a WordPress site on a local machine and had to export the database to a live site, you know that it can be a bit of a headache to deal with find / replace re-writing the fully formed URLs, exporting the database then importing it. Add a staging environment, then add frequent database merges and then add a team of multiple developers all working across local, staging and production environments. WP Migrate DB takes care of all this and adds on the ability to push and pull media files as well. The team behind the plugin – Delicious Brains – are WordPress developer darlings and also make substantial income off their suite of plugins, so the security risk seems pretty minimal. There’s no front end exposure for site performance. Could all this be accomplished without a plugin? Absolutely. Do we want to do that? No. Easy decision.
Rather than just talk about the awesomeness of Yoast – which is pretty clearly established – it’s more relevant here to talk about the tradeoff of how you’d accomplish Yoast’s work without a plugin. You’d need to dig into the
wp_title hook to set the SEO title tag and the
wp_head action hook to add other meta tags with different attributes for description, open graph images, etc. Those could all be driven by stock custom fields in each page or post. But what a pain. From a performance point of view, Yoast touches the front end in that it applies changes to page markup. Those changes would have to me made even if you custom coded the solution. There’s no indication that Yoast adds any bloat to the process of SEO management. Yoast is making good cheddar on their Pro services, so the security risk is pretty low – they have all the incentive in the world to keep their operation secure.
Advanced Custom Fields
Many of the core functions of Advanced Custom Fields can be accomplished without too much fuss not using a plugin. You can add custom fields and key / value pairs right in the post edit screen. Advanced Custom Fields makes it super easy to create templates of custom fields that you can apply to groups of pages or posts. And the Pro version goes bananas allowing you to built out repeaters – sortable repeating sub-fields – and even an entire custom page builder tuned specifically to your needs. ACF operates entirely on the back end – no http requests are added for visitors. And they make money on their Pro version, so security doesn’t seem a reasonable threat compared to the benefits.
Custom Post Type UI
Even more of the features of Custom Post Type UI can be accomplished manually without a plugin using vanilla post type functions like
add_post_type_support() but it’s a pain. Additionally, Custom Post Type UI makes setting up custom taxonomies a lot easier. The plugin has no effect on the front end and has been around for ages so the security risk seems minimal. Totally possible to live without, but the risk / benefit analysis makes it a clear win.
WordPress Plugins We Avoid
As with the list above, these aren’t used because the cost / benefit tradeoff isn’t worth it – the performance decreases and security risks aren’t worth the advantages. There are other, more optimal ways to achieve the same goals.
WordPress Redirect Plugin like Redirection
Plugin based redirects are slow – the request has to go through DNS, then the server routing, then past the
.htaccess file, then WordPress resolves the request then performs the redirect. Takes, like, forever. A more optimal solution is to use the
.htaccess file for redirects, as that which kicks in before WordPress even sees and resolves the request. Better yet if you’re with a badass host like WP Engine, use regex redirects on the Nginx level which kicks in even before the
.htaccess file sees the request. If you wanna be a real redirect ninja, you can redirect requests on the DNS level with Cloudflare. But just don’t use a plugin.
WordPress Backup Plugins
Regular backups are critical, and can be a pain the ass – but by no means impossible – to do without a plugin. You’d need to export all your content via SFTP and connect to your database via Sequel Pro or phpMyAdmin to make regular database backups. And all that content piles up – you’d ideally only want to back up what’s changed, a version control of sorts. Thankfully, good WordPress hosts take care of this. We love us some WP Engine, and they offer nightly backups plus one click backups at any time. You can restore a backup – including the database – at anytime also with one click. They only keep a couple weeks of backups, though. If you wanna get more long term, you can download the entire install with the database and put it in cold storage in Dropbox or something. No backup plugin needed.
WordPress Slider Plugins
In terms of front end functionality plugins, we’ve not found a use case where the benefits outweigh the performance cost of code bloat. We use Bootstrap as our frontend framework, so there’s huge amounts of built-in extensibility there. For front end functionality not provided natively by Bootstrap – fancybox media being a fun example – it’s not difficult to either enqueue the stylesheets and scripts manually where needed or better yet compile and include them in the main theme css and js files.
WordPress Google Analytics Plugin
If the advantage here is to be able to view your Google Analytics data inside your WordPress admin interface, that seems not much of an advantage. Just use Google Analytics – problem solved with no risk and the same benefits. Maybe your clients want to see their stats when signed in to the website?
WordPress SSL Plugin like Really Simple SSL, WP Force SSL or WordPress HTTPS (SSL)
We’re big time believers in all sites using SSL for everything. But why use a plugin to accomplish this? It should happen at the server level. ‘Nuff said.
Cache Plugins like WP Super Cache, W3 Total Cache or WP Rocket
As with SSL, everything should get cached. But not with a plugin. Do it at the server level, or using Cloudflare. Caching plugins get pretty nasty on the back end and can cause a lot of headaches in our experience.
With WordPress hacks tied to nefarious plugins on the rise, and with website performance affecting SEO rankings and visitor retention rates more now than before, it’s pretty clear that the use of a plugin needs to be judged against those costs. Before installing a plugin, ask if the same goals can be accomplished in a different way. Which plugins make your list?