Cancel

Jeff Chandler

Benchmarks Indicate Jetpack Doesn’t Negatively Impact Site Loading Times

Jetpack Featured Image
photo credit: the JoshMeister – cc

Jetpack is a WordPress plugin maintained by Automattic and has more than 30 different modules. The modules provide a variety of features including, contact forms, stats, and related posts.

Part of Jetpack’s reputation in the WordPress community is that it’s bloated and slows down websites. Sam Hotchkiss, who is part of the Jetpack team, has published benchmark results showing the performance impact of Jetpack is not as bad as you might think.

Testing Setup

The benchmarks run on two different setups. The first is a website where the user is only running Jetpack with 19 modules activated. (After The Deadline, Contact Form, Custom Content Types, Custom CSS, Gravatar Hovercards, Latex, Notes, Omnisearch, Post By Email, Publicize, Sharedaddy, Shortcodes, Shortlinks, Stats, Subscriptions, Vaultpress, Verification Tools, Widget Visibility, Widgets).

The second environment involves a user running five plugins that replicate similar functionality of popular modules. (Contact Form 7, Google Analytics Dashboard for WP, Simple Custom CSS, Share Buttons by AddToAny, NextScripts: Social Networks Auto-Poster). The plugins were chosen because they have the most downloads in the directory providing similar functionality.

Testing Results

Jetpack, First load, TTFB: 773ms
Jetpack, First load, Complete page load: 1876ms
Jetpack, Repeat view, TTFB: 143ms
Jetpack, Repeat view, Complete page load: 322ms

Other Plugins, First load, TTFB: 797ms
Other Plugins, First load, Complete page load: 2609ms
Other Plugins, Repeat view, TTFB: 460ms
Other Plugins, Repeat view, Complete page load: 529ms

As you can see, the performance impact from using Jetpack is negligible at best. Jetpack also has fewer HTTP requests overall than the custom plugins installed.

Number of HTTP Requests
Number of HTTP Requests

According to Hotchkiss, there’s a series of 35 tests that run against Jetpack every time a change is committed to the master branch. The tests are designed to detect whether or not a change negatively impacts site performance. Hotchkiss says the test results will be released in the near future, “We’ll be releasing all the results of these tests to the public in the near future. Every member of the Jetpack team is committed to making sure that performance is a high priority for the project.”

The results indicate Jetpack doesn’t hinder website performance as much as you might think. It’s only one set of results, but I’m curious to see how it performs in a variety of situations and environments. Do you think the results accurately represent Jetpack and what other benchmark tests would you like to see performed?

Category:
Tags: , ,
33

33 responses to “Benchmarks Indicate Jetpack Doesn’t Negatively Impact Site Loading Times”

  1. I know that you guys use JetPack on the Tavern but thus far I’ve resisted it because of the perceived load-time problem.

    With these results and now that the nRelate related posts plugin has been withdrawn, I may have to take another look.

    • The benchmark results should at least instill more confidence in that the plugin won’t bring your site to crawl. My suggestion is to use it on a test site or a live site and do your own benchmarking as it’s the only sure fire way to know if it has a direct impact on your site’s performance.

    • Very interesting information. I am slowly started to use a few Jetpack features. The testing that you have presented here takes care of one of the big concerns that I had with it. Now I can proceed with a bit more confidence. Thanks!

  2. Since the reduction in number of plugins will in fact result in fewer http calls I accept that part. The rest, though, is smoke. I use JP and I recommend it–with far fewer of the modules activated. But it’s slow. REALLY slow. Just install P3 to prove that to yourself. Or just LOOK.

    • It’s worth noting that some modules will run additional queries on every page load when you’re logged in to your admin account. Your readers, however, won’t trigger these extra queries. So, P3 might show some artificially high results due to that.

      • I think that is something that should be addressed as well. I’ve been spending a lot of time working on improving efficiency of several plugins. A lot of plugins will load all the files for is_admin without checking to see if those files are actually required at the time. Breaking down files so there is a loader that creates the initial menu page and then load files as needed can make big improvements in plugin efficiency.

        I’ve actually been playing with using the autoload method so loading the files can happen automatically when the class is invoked. The overhead is extremely minimal and the page load savings when a given class isn’t being used is pretty impressive across a large system.

        To be honest, this should become standard practice for all plugin authors.

        Also, p3 is a great tool for your average user but for much better benchmarks but there are better tools out there that allow for detailed load measurements. I’ve been using Webgrind to find out which functions, classes, methods, and files are taking longer to load. It’s independent of WP so I can setup scripts to load a given set of pages 50x logged in as admin, logged in as other users, not logged in … Then review the results and draw some conclusions, make changes and run the tests again.

        Granted, webgrind is far from accessible. It took me the better part of a day to figure out how to set it up the first time and I keep finding tricks to automating more of my tests and comparing results. Also, I wouldn’t leave the webgrind and underlying tools active on a production server any more than I’d leave p3 active on a live site.

  3. I haven’t heard of any load time issues with JetPack. The code running it is very efficient from what I’ve seen, so these results aren’t surprising IMO.

  4. I had commented elsewhere regarding this and someone asked my to leave the comment here.

    My issue with the “benchmark” that was run is it will favor Jetpack. Basically they assume that the features in Jetpack are all desirable but that isn’t the case for every site. In the benchmark they replicate 5 features from popular plugins (also note this doesn’t mean those plugins are the best choices. Often popular plugins add a lot of bloat as well. They are popular because they try to be all things).

    Under this scenario the site will definitely load more slowly because all the infrastructure of Jetpack will be loaded once and the infrastructure of the 5 other plugins loads replacing features of Jetpack.

    One of the complaints about “bloat” when discussing Jetpack is all the features that aren’t necessary and the fact that new features can be enabled during update. This typically requires a second plugin to be installed so that new features are off by default.

    A more valid benchmark would be feature to feature. If you use Jetpack for a single feature like the social sharing buttons (which many people do because Jetpack has great social sharing buttons) you could do a benchmark testing that single feature against a stand alone social sharing plugin.

    We did this at copyblogger.com. We had the social sharing buttons from Jetpack enabled on the site and found it was adding a good bit of lag to the site load times. We built our own solution with several key features to make the buttons load more quickly and we stripped out as much code as possible to ensure there was little bloat. Then we benchmarked Jetpack with the social buttons enabled against our plugin and found a huge improvement on page loads, especially in the archives because of some lazy loading features.

    Of course, there is going to be a tipping point that makes the single feature benchmark inaccurate for a given site. If a site is using several of the features in Jetpack it makes sense to use all of the features as required by the site. At this point the benchmarks done by Brute Protect apply because you are using enough features that the number of stand alone plugins can end up resulting in slower load times than Jetpack.

    I no longer do freelance, but when I did I often did site optimizations for customers. There are many instances where enabling Jetpack and disabling half a dozen or more plugins could produce big gains. I also found instances where disabling Jetpack and using one or two plugins produced big gains. Most of the time my first goal in optimizing a site is evaluating each plugin with the plan of disabling it if at all possible.

    It’s important, IMO, to treat each site individually. Sometimes Jetpack is the right tool for the job. Sometimes it isn’t. Using a single benchmark to overturn a “myth” makes for good television but bad science.

    PS don’t let my last comment fool you. I love Mythbusters even if their science is horrible.

    • Interesting. Do you know what is causing that? Is it perhaps needlessly loading some sort of framework under the hood which is bogging things down?

      • Ryan, It isn’t loading any framework that slows things down per se. It loads additional logic that defines what features should be loaded and some pieces have shared framework so it doesn’t have to load the same items multiple times.

        It’s not “bogging things down.” It is very efficient. However, if you are only using a couple of features it will use more resources and take longer than comparably efficient plugins accomplishing the same features.

        I don’t fault Jetpack in any way. It’s a great plugin built and maintained by a great team. I use it on a couple sites I maintain because I’m using several of the features built into the plugin. I opted against it on most of the sites I maintain because I would only use one or two features and it doesn’t make sense to load that logic when I only need a couple features.

  6. Why doesn’t this include a baseline and any actual server info or ram use.

    The whole goal of benchmarking is not to make semi-random comparisons , but rather to show how something reacts under different circumstances (stacks, caching, etc) and find potential areas for improvement.

  7. I don’t really feel like this is a good assessment. In my experience, Jetpack can run okay on some sits and then it brings others to a total crawl. So maybe the server config does come into play some how. But I don’t feel like a single test will really show much.

    I personally don’t really like or need Jetpack, but I know others who consider it a “must have” plugin. To each his own, I guess.

  8. Surely the flaw in this benchmark is that they’re comparing Jetpack with popular plugins that do the same job. What I find is that if I’m using Jetpack, it’s easy to be tempted to use more features: whereas if I don’t, I’m more likely to seek out the lightest plugin (i.e. not necessarily the most popular), or to find a way to avoid using a plugin altogether. The result is a much lighter, faster site (according to P3 and speed tests).

  9. The issue of load time is because Jetpack basically forces you to use the plugins you listed. So, comparing it against a list of plugins with similar functionality isn’t a great comparison since many people only want 2-3 of the things listed. So, you should compare Jetpack against the 2-3 functionality (plugins) they really want to use. Of course, that 2-3 plugins varies by person.

  10. I agree with the fact that we need to know if it’s interesting to install Jetpack for only two or three of its functions. I am very fond of Markdown but does it make sense to install Jetpack ONLY for this function ? That’s the big question.

    • I also love markdown.

      Personally, the tools I use 95% of the time in Jetpack are:
      Markdown
      Stats
      Publicize
      Photon

      It’s super lightweight when you only have a few modules activated. We can’t get into testing every combination, but I would be surprised if running just Markdown caused any sort of significant jump in load times over just plain WP core.

  11. I like Jetpack. It tends to solve simply a number of needs and I have not had any issues with load times. The key for at least me is a judicious use of the modules. Activate what I need and forget the rest.

  12. Jetpack has modules that when turned off are not actually processing on your server. The files are there, but there is no call to them. Furthermore, jetpack as shown in the study uses a lot fewer requests for similar functions.

  13. It’s really just a matter of preference in my opinion. Use them if you want all of the extra functions or don’t if you just need a contact form.

  14. Hey @Jeff,

    While reading this post I look back at the title and believe that the title is misleading.

    The comparisons where JetPack compares with a bundle of 6 other plugins is really a strawman argument. A more appropriate benchmark would compare Jetpack vs. core WordPress with no plugins at all because that is the base-level use-case upon which anyone can build.

    Yes it would be helpful to know Jetpack vs. each of those individual plugins in the case one is comparing the use of one of those plugins vs. Jetpack but just bundling them as he did does not confirm the statement of this post’s title. I doubt you intended that bias, but it is nonetheless a bit regrettable.

    -Mike

    • Hi Mike– we are working on a follow up including core load times for better reference, as well as instructions for people to replicate our data with any set of plugins that they like, so they can see how it compares to their usual tools.

  15. I recently installed JetPack on a new site and in order to get all my sites on one dashboard it installed the json api (I believe). It was the only activie module. I immediately noticed that the site page load slowed. I deactivated the module and the site speed returned.

    • That sounds really odd, definitely get in touch with Jetpack support and we’ll help you look at this.

  17. I’ve never heard that Jetpack was slow. They have a great team of developers that will try to put out the most efficient code possible. I’m not sure why that’s even in question. What I’ve seen from most people talking about Jetpack’s bloat has been in the context of the plugin having too many features, not its speed.

  18. This is good news! Although I really haven’t felt the slowness myself, I’ve heard before that Jetpack somehow makes your site slower. It’s time to put that urban legend to rest.

  21. I use Genesis for all my 9 sites and site speed is what concern me the most, I choose plugins very carefully and even if on my popular site with more than 10k visitors/day I have 30 plugins installed, the page load is under 2 sec. (dedicated server, AdS and Analytics). I have tested Jetpack and I’m not exactly happy to run additional scripts on homepage and archive when I only use the comments module, this is a nonsense even if I really like its functionality.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: