Social Warfare Today — Better, Faster, Stronger

Last week, Jason wrote about an “Aha” moment – his article was a feel-good sort of thing that got us all teary-eyed and had the Social Warfare team patting each other on the back, saying things like, “Yeah, I love you too, man.”

I do love Jason – he’s one special guy, and without his business oversight the Social Warfare plugin would likely still be just a great idea instead of an active, kick-butt reality.

It’s my turn at the wheel, though, and I’m more stoked about the tech end of the business than the gushy stuff.

So – for the nerds in the audience, let’s look at Social Warfare with the hood up.

Optimizing for Performance: Making Social Warfare Better, Faster, Stronger

Since day one, the speed and performance of this plugin has been my main concern. I’ve sought to make Social Warfare the most robust, full-featured social sharing WordPress plugin anywhere (and testing says we’ve hit that target).

But as I continue moving forward in my own journey as a developer, I’m constantly learning: I’m reading, studying, and discovering daily better ways to write the code that makes the magic happen. I’m finding new ways to make the functions faster than what I already thought was lightning fast.

Every developer reading this is nodding now – right? The online world is in constant flux.

Over the past week, I’ve been deep-diving into even the most miniscule optimizations – trying to squeeze out every last drop of performance I can. I’ve been scouring WordPress development forums, database optimization articles, and anything else I could set my eyes on that would help me improve Social Warfare’s already blazing speed. Sometimes I feel like the engine boss on an Indy racer’s crew. Every little bit counts.

Let me share with you some of the things I’ve been learning, some performance issues I’ve identified, and the solutions I’ve come up with to make Social Warfare better, faster, and stronger than it’s ever been before.

The cornerstone of our performance is the Social Warfare caching system

In order to display the share counts of the various social network buttons, we have to send out API (application program interface) requests to each network asking them for those numbers. These API requests take time to process. That time slows down page loads, and that’s why we created a caching system.

Once we receive the information from the API calls, we cache the information and the bitlinks that we fetch from their respective API’s. This cached data is then loaded with WordPress’s own initialization process adding virtually no time at all to page load times.

However, the actual API calls take a lot of time. On slower servers, they can add up to a full second to the page load time. This is why we cache the data and don’t retrieve it on every page load, but rather only once per hour (new posts), 3 hours (posts over 21 days old), or 6 hours (posts over 60 days old).

Investigating, Identifying, and Improving

So caching that data is a pretty good solution, but there are some shortcomings I’ve discovered and improved upon in our most recent update. Now, I know this is going to be a bit techie for some of you. For others, you know the value of this insight. I’m giving away knowledge that has taken me a ton of time to learn.

Let’s dig in.

Challenge: Rebuilding multiple caches at once

What if the cache is expired — so we need to run the API calls for several posts and we’re viewing a blog roll page that has, let’s say, 10 posts… and 5 of those posts need new data? That could add up to 5 seconds of API calls to update the cache. Of course, this could only happen once in a great while (because of the caching schedule mentioned above), but it could still happen.

Solution: Now the cache will only update when the actual blog post is loaded — so that if the cache needs rebuilt, it will never add more than 1 second to the page load time.

Challenge: Getting every bit of data into the cache

I discovered that certain pieces of information we need for processing were adding around 6 additional database queries to the gathering process. Now, bear in mind that database calls don’t add a lot of time to the page load process (but they do add some), so I still wanted to find a way to eliminate these calls entirely.

Solution: I’ve now bundled the data that we need into the cache system so that when the cache is fresh, it requires zero additional database requests.

Challenge: Search engine considerations

What if a search engine crawls the page when the cache needs rebuilt? The page might take up to 1 second longer than usual.

Solution: We’re now only serving cached count numbers to search engines, meaning there will be no additional page load time when the site is crawled.

Challenge: Finding the ultimate caching solution

What if we could make the cache rebuild process not take any additional page load time at all? What if we could run those API requests in a way that adds no extra page load when it’s cached and no extra page load when it’s generated for search engines — but also no extra page load when the cache is being rebuilt and the API calls are being run?

That would mean that even if the cache is out of date and the API calls need to be run again, it wouldn’t impact load time at all!

Solution: I’ve just made it so that if the cache is expired and new numbers need fetched, the user will still be served cached data. Then after the page is finished loading, the API calls and cache rebuild process will be triggered and will be run in the background — with zero noticeable impact on anyone viewing the site.

Challenge: Loading external resources

What about requesting resources like CSS, JavaScript, and images? Those slow down the page load and need to be reduced as much as humanly possible.

Solution: I’ve removed the click-to-tweet CSS and bundled it with the main CSS. I’ve also replaced the Twitter image icon and replaced it with the icon font version that we use on the buttons. This reduces (from 5 to 3) the number of HTTP resource requests that our plugin makes.

Testing Social Warfare performance

Social Warfare, version 1.3.10, is the most lightweight version in the plugin’s history, and is very likely the most lightweight social sharing plugin on the market today. I invite you to consider the results of my own test and to run tests of your own.

Before publishing the most recent update, I wanted to know exactly how it would impact the load time of a WordPress post.

Here are the conditions of that test:

1. The theme is set to the WordPress default Twenty Fifteen theme.
2. All plugins are deactivated. except Query Monitor. It is used to display page generation time and the number of database queries used to generate the page.
3. A blog post is selected that contains Social Warfare on the top, bottom, and in the floating sidebar. It also contains two click-to-tweet shortcodes that will need to be processed.
4. The page is loaded 10 times with Social Warfare deactivated, and 10 times with it activated.

These results show that our plugin now adds just 0.031 seconds of time to the PHP! Additionally, it processes its functions with zero extra database calls, and only three external http resource requests (CSS, JS, and a font for the icons).

I’d love for you to replicate this test on your own site and let me know the results.

And, as always, if you discover any hiccups whatsoever, let us know so we can fix it right away and continue to make this plugin the best it can possibly be.

Social Warfare today — the bottom line

Jason’s teamwork insight was right on the money: The most difficult and heated part of the work can be the most valuable.

His business savvy, Dustin’s social media acumen, and my hard-headed, nose-to-the-grindstone refusal to settle for mediocrity, gave us the ability to build a tool we’re proud of — a tool we know can benefit you and your online work.

If you’ve not yet tried it for yourself, here’s how to get going: Try Social Warfare

That’s enough from me. It’s your turn.

If you have your own test results and observations to share, I’d love to hear them.