We all enjoy reading success stories, right? A website reached a million visitors in just 10 days, a SaaS tool valued at $1 billion in less than a year, an author and her book translated into 100 languages worldwide. But if you think about it, there are hundreds (maybe thousands) of failed projects for every successful one.
Estimated reading time: 13 minutes
Success stories are great, but this time, you’re going to read about a failure. It’s about Speed Booster Pack and the depressing, constant decline of its active installs. What’s the point of that? I hope you’ll learn how things went wrong to learn from my mistakes, as I have.
My story of becoming a WordPress enthusiast… and a web performance junkie
In 2006 I created a WordPress website for the first time. Blogs were “in,” and I wanted to become a writer. So I published my first blog post on WordPress.com in January 2006. Several weeks later, I started from scratch on a free hosting space, then moved that blog to beyn.org in July. It was so fun to write about my own teenage ramblings!
After moving to Beyn, I started obsessing about getting it to load faster so I wrote my own theme, used minimal CSS (compressing it manually), and learned about the differences between image formats. As I got better at WordPress, I started freelancing and made acceptable websites.
In 2012, I saw a writing gig at Tuts+ Code, applied, and was hired. I wrote close to 150 articles & tutorials in four years — two as a writer, and two as “lead WordPress instructor.” After writing everything I knew about WordPress in the first year, I started researching and learning to have more things to write about. Teaching is a strange but great way to learn something. Believe me — writing about things I didn’t know forced me to learn everything about that topic.
Close to the end of my time as a Tuts+ writer, I rediscovered my obsession with speed. Writing about it was easy enough, but I was surprised to see that there were fewer than five companies (in 2015) that offered web performance optimization services. I started a small business called Optimocha in April 2016, and after a very rough year, it got better. I met Frank Goossens, the creator of Autoptimize, and as “partners in performance,” we optimized a ton of websites (in addition to half a ton of websites I optimized on my own) between February 2017 and August 2021.
To keep this part short, I left out a lot of details. If you want to, you can visit HeroPress.com to read more about my story. You’ll learn about the time a blog post got me sued by the Prime Minister of Turkey.
Since I’m obsessed with optimizing websites, and my clients usually share my obsession, the satisfaction rate on my jobs is close to 100%… but Optimocha is not the main focus of this post. So, let’s get to the part when I became the owner of Speed Booster Pack.
Acquiring Speed Booster Pack in 2019
In 2019, Frank told me the folks at Macho Themes were looking for someone to adopt Speed Booster Pack. He introduced me to Cristian Raiber, and after negotiating, we agreed on a deal, and Optimocha became the owner and maintainer of the Speed Booster Pack plugin.
The plugin’s codebase wasn’t in good shape, and it was already in a state of decline. About three months after the acquisition (19 May 2019, to be exact), Speed Booster Pack’s “Active Installations” count in the WordPress.org plugin repository started showing “30,000+” instead of “40,000+.” It was a bummer, but I wasn’t really interested because it simply meant the active install count was around 39,000. Plus, I had bigger things in mind.
A complete rewrite
After a rather unsuccessful attempt to fix Speed Booster Pack’s bugs, I decided to rewrite the whole thing from scratch and turn this plugin from “something with a few checkboxes to apply small optimizations” into “a complete optimization suite.” I wasn’t a good programmer so I searched for one. After meeting with Zahid in October 2019 and talking about my vision of transforming Speed Booster Pack, he agreed to work with me to rewrite the plugin. Unfortunately, I kept focusing on fixing small bugs in the existing code, and the delay saw the further loss of active installs.
As it turns out, things weren’t going to change after the rewrite. We released the complete rewrite (version 4.0) in July 2020, but it only stopped users from leaving — we didn’t get new users.
That’s when I started wondering about the exact number of users Speed Booster Pack had.
Calculating the near-exact user count
It might be silly to wonder how many websites are using your plugin, but for analytics freaks like me, it’s always nice to have more (and better) data in hand. That’s why in 2020, I began searching for a way to see the exact number of Speed Booster Pack users.
It’s against WordPress guidelines (and GDPR, CCPA, etc.) to spy on users, so updating my plugin to include a counter was out of the question — plus, users of older versions wouldn’t have the counter.
I discovered that WordPress.org calculates the number of active installs by counting the websites pinging wordpress.org for plugin, theme, and core updates. Then it rounds down to the nearest “ballpark number,” like 500, 1,000, 10,000, etc. Since WP-Cron (wp-cron.php
) is responsible for periodically pinging the update servers but only fires when a website is actually visited, websites with no visits aren’t counted, but a site with one visit (including search bots and downtime monitors) might be counted as active.
So that active install number is an estimate and probably on the high side as the number grows. Worse, you can’t see what’s happening to it when you’re between the large ballpark figures the plugin repo provides. Are your active installs going up or down? You can look at the Active Install Growth chart for your plugin at WordPress.org for this, but it only shows weekly percentage changes.
Fortunately, Benjamin Wintal found a really smart way to count active plugin installs.
The gist of Benjamin’s method is this:
- Find out the exact date (a Sunday) when the ballpark number changed (e.g. from 1,000+ to 2,000+ or 20,000+ to 30,000+) by waiting or using the Wayback Machine to view older versions.
- Use the Active Installs Growth chart to calculate how many new users installed (or stopped using) your plugin.
(You can also retrospectively calculate active install counts using the date as an anchor.)
After setting up a Google Sheet and adding the necessary data, plus some handy formulas, I was able to calculate the near-exact number of active installs. Here’s Speed Booster Pack’s growth decline graph from 2020:
A big bump, then a huge collapse
Let’s jump to the first half of 2021 when Speed Booster Pack finally began getting new users — as high as 1,000 new users in some weeks!
Zahid and I had released a new version (4.1.0) which had new features like Critical CSS, Sucuri integration, and an experimental feature called “PageSpeed Tricker.” It was part joke, part real: It actually set your PageSpeed test results to 100% on both mobile and desktop, because it added a line to wp-config.php to exit immediately for all browser user agents including the word “Lighthouse.” The joke was to show people how easy it was to manipulate PageSpeed/Lighthouse tests and say “you should optimize your website for real people, not for PageSpeed” to our users.
It was a fun, educational joke that we decided to remove after a few versions, and we showed an immutable notice (when the Tricker was enabled) to prevent people from tricking others into believing their website was really optimized. We thought the increase in active installs was related to that.
Over the course of four months after releasing version 4.1.0, we saw over 5,000 new active installs and we even got past 40K users:
Awesome, right? Well, it turns out the increase in the active install count wasn’t at all related to our work.
In August 2021, we saw this:
That 6.3% drop was then updated to 8.1%, and 12.0% the next week, resulting in this huge collapse:
Just like that, we were in an even worse position than before the increase in active installs. Here’s the graph for the full year:
Initially, I thought this was just a glitch that all plugin owners suffered from, but checking a few other plugins and then the WordPress Slack, I found out that it wasn’t a glitch:
Recently, it was pointed out that the active install counts of several plugins appeared to be inflated artificially. When we looked at the raw data, we found that this was correct for roughly 100+ plugins; fake update data was being sent to us.
This is not unusual, it’s happened before, although people are usually much more blatant about it, which is why it took a long time to notice it. In any case, we adjusted our stats mechanisms to ignore these, and so those 100+ plugins will have seen a drop of around ~8000 installs.
As the data was being faked before, this new count is more accurate. But it doesn’t change the old counts, and we can’t redo those counts as we don’t store that raw data for more than 2 days.
So, consider the percentage drop today as an artifact of this adjustment. It’s not a loss of users, it’s an improvement to the data gathering mechanisms.
Otto #pluginreview (August 26, 2021)
The details of the event weren’t disclosed but here’s what I understood: someone tried to inflate the number of their plugin’s user count and inflated a hundred other plugins too so theirs could stay hidden among the crowd. None of us were accused of anything, but it was shocking (and a bit devastating) to see that immense drop in the graph. Anyone looking at it might assume the affected plugins had become very unpopular.
After some heated discussion on Slack, the final decision was to let the data and charts stand — and basically accept the graph as it was and still is. I still think it was possible to flatten the historical growth graph by changing the weekly growth rates. But all in all, it wasn’t worth fixating on the graph. We simply had to suck it up, for the lack of a better phrase.
I genuinely thought of shutting down for good before realizing that I could turn this into an opportunity to learn more about managing an open-source project with many users.
Now, to the part of the lessons I learned.
Thoughts on the decline
If it’s not worth fixating over graphs and losing active installs, how come I’m writing a 2000-word article about it? Two things:
- I’m not giving up on a good open source project like Speed Booster Pack, and I’m still motivated to improve it even if its decline continues — although I’m confident the user base is going to start growing again at some point.
- I’m now seeing this as a learning experience, both for myself and for developers with open-source software projects.
With my expertise in web performance optimization, I’m earning well from Optimocha. Even though my initial intention was to increase revenue using Speed Booster Pack as a marketing channel, building a solid community around SBP became its own priority over time. This is why I’m still pondering on the decline (without obsessing about it — no, really).
Let me share my ideas on why a WordPress plugin might be losing users.
Basically, it should have more users deactivating the plugin than users activating the plugin. The causes might differ:
- Buggy code: As recently as June 2022, SBP lost 3K users just because I hooked a function to
init
instead oftemplate_redirect
. Yep, something as simple as this could cause users to have problems and deactivate your plugin in response. Even if it doesn’t break their websites, just having PHP notices could push away users. - Bad user experience: Having a complicated interface for settings could cause users to give up trying. This is especially important for technical subjects like speed optimization. You might have to educate users with onboarding, extensive help sections, and even explanatory videos — which I’m currently working on for SBP.
- Failing promises: A plugin doesn’t need to have bugs to fail at fulfilling its promises. If an SEO plugin doesn’t help with SEO, users will switch to another plugin. You have to make sure users see the results they expect as soon as possible.
There might be other things that commonly decrease the number of active installs tracked at WordPress.org:
- Websites with no visitors: As I mentioned before, active installs are counted when websites with your plugin check wp.org servers for plugin, theme, and core updates through WP-Cron. Since WP-Cron fires up when someone or something visits a WordPress site, websites with no traffic or with WP-Cron disabled won’t be counted among your plugin’s active installs. There’s nothing you can do about this. It’s likely a small number of not very active sites, but who knows? It’s a known unknown.
- Not releasing new updates: Currently, WordPress.org warns users against installing old plugins if it’s not tested with the latest three major core releases. (This used to be two years). Similarly, a user might be put off if a plugin they use doesn’t get updates on a somewhat frequent basis. (I mean, would you keep using the same plugin if its competitors were releasing new features, but the one you’re using wasn’t?)
- Compatibility issues: It’s really important to keep yourself up to date with the WordPress ecosystem. When Visual Composer reigned over the theme market, plugins were forced to be compatible with it. When users shifted from Visual Composer to Elementor, plugins incompatible with Elementor lost their user base. Gutenberg is on the rise now, and full site editing might conquer the ecosystem in the not-so-far future. Make sure you test with real-life scenarios using popular (and trending) plugins and themes.
Final thoughts
I’m a proud person. I’m proud of optimizing over 500 websites with a 96% satisfaction rate in Optimocha. Also, I’m proud of writing over 200 articles and tutorials about WordPress across the blogosphere. (Mostly Tuts+ Code and Fuel Themes Blog.) I’m very proud to have great relationships with clients, going so far that several clients have asked to invest in my work. And I’m proud to accept that I’ve made missteps and hurt Speed Booster Pack’s growth in the past.
But I’m not accepting defeat. Learning from my mistakes (which are more than a few) was the best thing that’s happened to me regarding my journey with Speed Booster Pack, which makes the word “defeat” unsuitable to define my story. It’s time for me to grow the business, be a better boss, maybe accept some of those investment queries, release the premium version of Speed Booster Pack, and publish the book about WordPress performance optimization that I’ve been constantly rewriting.
If you want three ideas to take away from this long (maybe too long) article, I’d recommend these:
- Do NOT work on a project with no roadmap. Try to envision your project’s future, and don’t stray away from the path you’ve chosen, even if that path has obstacles.
- Do NOT get down because of drawbacks, obstacles, and other negative stuff. Instead, study everything that went wrong and take steps to ensure you won’t encounter them again.
- Do NOT confuse failure with defeat. Failure stories, hopefully including this one, are almost always great to learn from.
Cheers,
Barış Ünver
Barış Ünver is a co-organizer of the WordPress Ankara Meetup and has contributed to the Polyglots team. He’s the founder of Optimocha, a WordPress speed optimization service, and the owner of the Speed Booster Pack plugin.
I’m never one to believe in absolutes and this is especially true in absolute defeat. I get from Barış’ story that declines and defeats are not simply blocks in on themselves but rather materials which we stumble upon. I believe those who learn from their defeats are the ones life can’t simply knock down. This article is written proof of that.
Absolutely! And we can — as a community and in our own networks — help each other remember this when we face obstacles and setbacks.