Jetpack: When to Use It

If you’ve been around WordPress sites for more than a day, you’ve seen, or heard of, Jetpack. Jetpack is essentially a super-plugin that consists of over 30 features (I’ll call them modules). Those modules are powered by the WordPress.com eco-system. You add this plugin to your self-hosted WordPress site, log in with (or sign up for) your WordPress credentials, as activate whichever of the 30 module that you will. Many of these features are common functionality that many users want in a site, and having them all in one place is very attractive. Jetpack has Automattic’s reputation behind it, which means that it’s going to work. So, with all of those features wrapped up in one package, it’s sort of a no-brainer that it should be installed in every WordPress site, right?

Well…not so fast.

Jetpack’s Weight

When I’m hired to re-build a website, one of the first things that I do is take stock of the plugins that are used. There’s a critical mass of plugins that a site can reach (this isn’t really a number…it varies from site to site) before the user begins to experience performance issues. It’s very easy to experiment with a plugin to see if it suits your purposes, or find that you don’t need a specific plugin any longer, deactivate it, and forget that it’s there. I frequently see sites with 8-10 plugins (sometimes more) that are inactive and just sitting there, taking up space. The problem is that even inactive plugins can weigh a site down, and can still be security issues if they are not kept up to date. In any case, the best rule of thumb is to keep your site “lean and mean.” If you’re not using it, take it out.

Fire and Forget

With so many features included in Jetpack, it’s very easy to flip switches and forget about them. All of those modules that are active require resources and http requests (remember that it’s driven by a connection to WordPress.com), and those requests are expensive when it comes to page load time and overall site performance. When using Jetpack, it’s absolutely critical to keep only modules that are being used active. The rest should always remain de-activated.

And, About Those Features

There’s no denying that Jetpack is loaded with excellent features, the reliability of which are proven. That said, I almost never install Jetpack on a site. The reason is that I typically only need three or four of Jetpack’s modules on any given project, and I have other “go-to” plugins in my toolkit to take care of the functionality that I need. Let’s look at a few of those modules:

Enhanced Distribution and Publicize: Where distribution is concerned, I like to offload that responsibility to another service to reduce payload on my server and site (I use dlvr.it, and can recommend them highly). Every WordPress site that I build has WordPress SEO by Yoast installed, which will ping search engines with new content. Thus, most of the functionality involved in these components of Jetpack are either offloaded, or taken care of by another plugin when I build a site.
Sharing: Jetpack’s sharing features are good for basic sites. I typically need to include more advanced sharing features for my clients, and my go-to is the ShareThis plugin, which makes it very easy to place the links that you want on the posts and/or pages that you want. I also like ShareThis analytics, and, in my experience, so do marketers and my clients.
Stats: The advantage to using Jetpack’s stats is having it neatly integrated into your dashboard. However, Google Analytics beats WordPress stats in every way, hands down. No serious marketer or SEO expert that I know would prefer WordPress stats over Google Analytics. I pipe my Google Analytics data into my WordPress dashboard with Analyticator, so this is another case where the feature is handled by a different, dedicated plugin.
Contact Forms: The contact forms offered by Jetpack are very, very basic, and don’t offer much in the realm of interactive functionality. If the project requires forms (and what project doesn’t?), I recommend Gravity Forms, every time.
Carousel and Tiled Galleries: I can’t imagine using either of these in a custom theme. I either build out this functionality with a jQuery plugin that I adapt into the theme, or use other dedicated plugins that are very effective.
Infinite Scroll and Mobile Theme: Infinite scroll is too easy to code by hand to bother with a plugin, and a mobile theme is far, far too complex a thing for a plugin to handle for you. A great deal of planning goes into mobile design…it’s not something that just happens after flipping a switch.
Shortcode embeds: Benny supports media embeds right in the editor. Why is this relevant, again?
Extra Sidebar Widgets: What I hear most people talk about with this feature is embedding a Twitter stream. There are other, excellent plugins with less overhead that will handle this for you, and, for that matter, Twitter’s API makes this very easy to just roll this by hand.
Custom CSS: Adding a stylesheet through the WYSIWYG editor to over-ride your theme just isn’t best practice, and I’m sort of surprised that Automattic included this. I’m not saying I’ve never done this: if a site is broken and needs a quick CSS hotfix to get it operational again while I formulate a permanent solution to the issue, then this comes in handy. That’s a tiny percentage of cases, though, and the correct way to alter your theme’s styles is to create a child theme.
JSON API: When I need to package a site’s contents in JSON to make them accessible for a web service elsewhere, I turn to this plugin instead. It handles the heavy-lifting of creating the jSON feed, so all that I need to worry about is parsing it on the other end. Also, there is a rumor that JSON endpoints will be native in version 4.1, which will be an outstanding addition.

What I Like in Jetpack

Of course, those are only a few of the modules offered by Jetpack. Many of the others don’t grab my attention, but may be deal-breakers for other developers. The most appealing features to me in Jetpack are the comments, social login, and subscriptions features. If I needed all of these in a project, as well as perhaps another module or two offered by Jetpack, then I would consider the plugin. I’ve found these cases to be rare, though, and needing one or two of these would lead me to pursue other options, such as Disqus, for the client.

So, My Advice

When using Jetpack, keep it tuned. Part of the reason that I find Jetpack unappetizing is because 98% of my work is in custom themes that I’ve built from scratch. Jetpack adds a lot of functionality with very little coding to themes that are purchased, or child themes, and, as such, finds a wide audience among WordPress users. Because I’m building custom themes for my clients, I’m building a lot of this functionality from scratch, and/or using other plugins because I’ve used them extensively and know that they fit my workflow. For very basic sites, Jetpack would be an effective tool to have in your arsenal. Certainly, if I’m hired to do work on a site and the client has already become very familiar with using Jetpack, then removing it is generally counter-productive. My advice regarding Jetpack is use it carefully and sparingly. It’s a heavy plugin, and most users only take advantage of a small percentage of it’s features. When I’m building a project, Jetpack generally doesn’t make an appearance, but, as with every other well-developed tool, there are use cases in which it fits.

Image attribution: JD Hancock under Creative Commons.