Results of the Measure Jetpack Project Likely to Be Published After WordCamp Stockholm in November

Nearly a year ago, we published information about a new project by Arūnas Liuiza, a WordPress plugin developer, called Measure Jetpack that would benchmark Jetpack’s performance on websites. Outside of a post published in January, there’s been little information on its progress.

I reached out to Liuiza and discovered that he’s going to give a lightning talk about the project at WordCamp Stockholm in November. “I’ll have to rerun all the tests with the latest versions of everything in October for the presentation,” he told the Tavern. “I’ll probably publish the results soon after the WordCamp speech.”

I asked Liuiza what is the most challenging part of the project, “The biggest challenge is to find the time,” he responded. “I’ve become way more busy than I was when I started this, that’s why it is taking so long.” He goes on to say that the results he’s accumulated so far do not show major performance hits unless all modules are activated.

Jetpack 4.2 was released last month with major performance improvements. Liuiza has partial test results for Jetpack prior to version 4.2 but is unsure if he’ll publish those in a separate report.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.


  1. “He goes on to say that the results he’s accumulated so far do not show major performance hits unless all modules are activated.”

    I suppose “major” is relative, but any usage of Jetpack modules at all not only greatly hurt speed for most users, but also SEO. It is a typical example of the lack of transparency behind a lot of the WordPress related applications and services out there. Not only does Jetpack (Photon) upload your images to Automattic-owned servers, but they don’t even explain that is happening during activation, not to mention that it also kills your on-site SEO; it remains a “hacky” app for clueless users.

    Besides the lack of transparency on features, there is also no disclosure of the server “map” that Jetpack is powered by. While a website and user base near Dallas (e.g.) might not see a speed decrease, 90% of internet users around the world probably will.

    The fact that Jetpack, and other Automattic-owned plugins, continue to be “featured” and “recommended” with hype marketing across the WordPress universe just makes other developers more jaded and less interested to contribute to the community. It is definitely a cash cow for Automattic, but it is also their worst enemy as well.


    1. Are you sure it’s not clear what Photon is doing? I’ve never used it for the reasons you mentioned, but I don’t recall it ever being vaguely described. I thought it was quite clear how it worked.


      1. We do try to be as clear as possible with what our services do — although there’s always room for improvement.

        We do state very clearly that Photon is a content delivery network (free!) for images that we use to serve your images in an optimised form instead of using the host’s bandwidth and resources. For many users this is a big plus not only because of speed but also because you won’t eat up your bandwidth allocation if traffic spikes since images can be quite large.

        We take it as implied that if you opt in to use a CDN then we need to upload your images to our servers. That’s the only way it can work :-)


    2. Jesse, thanks for your feedback. You are right that “major” is relative and whether Jetpack is right for your site or not depends a lot on a number of factors, including your personal preferences. We are very conscious of performance issues which is why we’re constantly monitoring how Jetpack performs and shipping improvements (see our two recent releases).

      We are actually looking forward Liuiza’s results as an independent study like this will help us find even more ways of improving our product.

      Your assertion that “any usage of Jetpack modules at all not only greatly hurt speed for most users, but also SEO” and that “[Photon] kills your on-site SEO” is sad to hear. This is most definitely not the case for the majority of our users (including users which uses the same technology) and if you’ve experienced this personally I would love to get more detail on specifically what sort of hit your performance and search engine rankings have taken when using our services. Our CDN, sitemaps, verification, and related posts features are actually designed to help your SEO and traffic (such as in this case study) and our indexing service is one of the few such plugins that many hosts allow because we take all the server processing load onto our infrastructure. Based on Google’s recommendations, and like most CDNs, Photon images have canonical links so it shouldn’t effect search engine rankings.

      Around the lack of transparency, I understand your natural curiosity around how we manage our infrastructure but I’m sure you understand it wouldn’t be in either our, or our users’ interests, to disclose potentially compromising information of how we manage our data centers, locations, and other details. However we we have data centers around the world and you can ping a Photon domain from your machine to see where you land. Additionally, we do publicly show real-time activity on our data centres (each colour is a different data center and dark areas are mostly due to it being nighttime in that part of the world.)

      As you know, Automattic (and Jetpack) are hugely committed to, and invested in, open source and transparency: we open source all the code we can (including Jetpack itself! and our new UI), we provide as much API access as we can (including for Photon), and as a company we publish bi-annual transparency reports.

      If you have any additional or further questions I would be very happy to try and address them, either here or email me personally at


    3. Photon does not “kill” your on site SEO, there’s a common misconception about how it works.

      Images hosted on servers use canonical urls which point back to the original images on a users own domain.


      1. how dare you to kill an urban myth?

        anyway image seo is probably the least important seo factor for most sites


    4. Besides the lack of transparency on features, there is also no disclosure of the server “map” that Jetpack is powered by. While a website and user base near Dallas (e.g.) might not see a speed decrease, 90% of internet users around the world probably will.

      Sorry about that. All of the information is public, just maybe not easy enough to find.

      Here are some links that hopefully help:

      1) Complete documentation of the Photon API.
      2) Photon source code.
      3) Photon and other Automattic services are served from 21 different data centers on 6 continents and we continue to add more. The locations are all listed here along with a map. If you are interested in our level of network interconnection and more specific information about the data centers, you can find that information in PeeringDB.

      While it’s true that Photon does make your site faster by globally distributing your images and serving them from our servers, IMHO that actually isn’t the primary benefit. The best part is that since Photon dynamically resizes the images on our servers, your images will always be served at the correct size, regardless of whether those sizes are stored in your wp-content/uploads folder. This can drastically reduce the number of bytes sent to clients – making things much faster, especially for clients on slower internet connections. It also ensures that if you switch to a theme that displays content at a different size, you don’t need to “regenerate thumbmails” which can be slow or expensive (or both). Photon also supports some other nice features like transparently serving webp images to browsers that support it. There are other optimizations and features on the roadmap as well. We hope to share them soon.


  2. I dislike Jetpack with a passion, but one thing I can not see any issue with, is it’s performance. There is bound to be some inefficiencies here and there, just like with other plugins, but I’m yet to see any noticeable lag or fundamental problems which would make it’s performance notably bad in comparison to other plugins. If anything I suspect it’s performance would be significantly better than the average plugin.


    1. Hi Ryan! Thanks for the performance-related vote of confidence ;-)

      I’d be very curious to know why you dislike Jetpack so passionately :-)

      Feel free to email me personally at if you prefer to carry on the conversation off the comment boards.


      1. I’ve offered my opinion on this to many people in the Jetpack project including Matt himself, going all the way back to when it first launched. So I can’t tell you anything which the project hasn’t been made repeatedly aware of previously.

        My primary reason for disliking it, is that it took a bunch of extremely good WordPress plugins which I loved and recommended to everyone and replaced them with one giant bloated tool which includes everything plus the kitchen sink.

        IMO, the best plugins are simple plugins which solve one purpose. Jetpack tries to solve everything. Many of the individual components are great, but as a cohesive unit I consider it nothing more than a piece of marketing.

        I think the individual components should be maintained separately from the core plugin, so that users can install them individually if they like, then have them bundled together into Jetpack so you can keep the marketing and branding which seems to work so well. The Jetpack team seems totally disinterested in this approach though.


      2. I agree with that. I use only a Jetpack function – Markdown – and it was a standalone plugin before merging into Jetpack. I don’t need Jetpack for ONE function. There are some alternatives for the moment but it’s boring to think I will have to install one day Jetpack just for that.
        In my opinion, there should be separate extensions for each module so users could choose what they need. And if they want to, they can grab Jetpack.


Comments are closed.