33 Comments

  1. Keith Davis

    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.

    Report

    • Jeff Chandler

      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.

      Report

    • Ray

      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!

      Report

  2. WordPress Helpers (@WPHelpers)

    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.

    Report

    • Ryan Cowles

      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.

      Report

      • Nick the Geek

        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.

        Report

  3. Ryan Hellyer

    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.

    Report

  4. Nick the Geek

    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.

    Report

    • Ryan Hellyer

      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?

      Report

      • Nick the Geek

        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.

        Report

  5. Mahee Ferlini

    I use JetPack and I haven’t experienced any issues

    Report

  6. wycks

    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.

    Report

  7. Ashley

    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.

    Report

  8. Marisa Wright

    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).

    Report

  9. John Lynn

    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.

    Report

  10. Li-An

    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.

    Report

    • Sam Hotchkiss

      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.

      Report

  11. Dave LeBlanc

    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.

    Report

  12. Scott Hartley

    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.

    Report

  13. Scott Winterroth

    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.

    Report

  14. mikeschinkel

    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

    Report

    • Sam Hotchkiss

      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.

      Report

  15. mtibesar

    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.

    Report

  16. Sam Hotchkiss

    Per your requests, we have re-run the tests including WordPress core and Jetpack with no active modules

    https://bruteprotect.com/jetpack-bloat-myth-followup-more-data/

    Report

  17. Justin Tadlock

    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.

    Report

  18. Benjamin Intal

    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.

    Report

  19. Benjamin Intal

    Out of curiosity, they should put in some data for when all the features are turned on.

    Report

  20. hectavex

    Uh, okay. I would like to know what those 35 tests are, because perhaps I’d like to implement those tests in my own environment. But so far, it appears we need a more useful Jetpack benchmark/comparison that is unbiased. Try multiple test runs and tools.

    http://glassocean.net/8-social-login-plugins-for-wordpress-compared/

    https://github.com/perrybutler/rapid-server#benchmarks

    Report

  21. Lore

    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.

    Report

Comments are closed.

%d bloggers like this: