Why I Finally Uninstalled Jetpack From WordPress

I’ve been a faithful Jetpack user for years. I’ve watched as Automatic constantly brought in new features and functionalities, making it ever larger. I’ve had my share of problems with deactivating the REST API and the XMLRPC functionality, while trying to keep Jetpack working. Yesterday however, I took the plunge and uninstalled Jetpack from my WordPress installation. In any case, it was hanging on by a thread, as I slowly offloaded its functionality to other plugins. But now I’ve cut the cord, and there’s no going back.

Here are some reasons why, and alternatives to common functions.

Why Remove Jetpack?

The main reason why I’ve been trying to migrate away from Jetpack, is a change in my philosophy of website management. There was a time when I loved the idea of consolidating all the various pieces of my site – security, backup, CDN, etc – in one easily manageable and updated plugin. Less to keep track of, and easier to maintain.

However, over the years I’ve come around to a different point of view. I now try and diversify my functionality into as many specialized pieces as possible. One reason is that I’ve come to believe that specialized little pieces of code do a better job, and are more efficient than large codebases. Second, I believe that developers who focus on targeted problems are more cutting-edge and up-to-date than those who spread their wings too wide.

Google is a great example that has fallen from my graces over the years. The days when I would use Google software all the time are long gone. I would now never install Google Authenticator for example, choosing to use Authy instead. I use LastPass instead of the built-in Google password manager in Chrome.

So philosophically, that’s the main reason why I’m moving away from Jetpack. I prefer to have smaller codebases spread out, rather than putting lots of eggs in one basket.

Access Backdoors that I Want to Close

I want my WordPress installation to be a closed system. I don’t want external services “phoning in”, and getting information from my site programmatically. It’s why I recommend disabling XMLRPC for example. The REST API is another programmatic access point in WordPress that I want to disable. But Jetpack needs at least one of these to function. You have to connect your website to WordPress.com, and that needs one or the other.

I’ve lived with a compromise for a long time. I’ve disabled XMLRPC, while still allowing Jetpack IP addresses to go through. It requires a bit of maintenance, and I could do without it. I like my site to be isolated from the external world and services!

Alternatives to Common Functionality

I’ve moved the most common functionalities of Jetpack to other plugins. Here are some suggestions.

Lazy Loading of Images

If you aren’t already using the amazing “Autoptimize” plugin, you should. It inlines and defers your CSS. It also has a tab where you can enable the lazy loading of images. I’ve tried it, and it works!

Static Content Hosting

I was quite excited when Jetpack announced their CDN for static JS and CSS files. However, after extensive testing, Cloudflare just does a better job. Use that instead!

Backups

For a (quite expensive) fee, Jetpack backs up your website regularly. Just use DropMySite instead. It’s available as an add-on for NameHero at a fraction of the price. Much better!

These are the most common uses of Jetpack and alternatives. There’s so much other functionality, that I won’t go over all of them here, but I’m sure you can easily find lots of resources with a quick Google search that will give you what you want!