Case Study: Improving Performance on an Authority Membership Site
Have you ever had a bad experience with your hosting company?
Brittany Lynch certainly has.
Brittany’s money site was slow, bloated and to top it all off - hacked.
In this short case study you’ll learn how we at SpeedKills.io turned a seemingly hopeless situation around into a big win for Brittany and her audience.
Brittany is the founder of Ideal Me, an online hub where you learn how to create your ideal lifestyle using the many authoritative articles, courses and resources that she makes available.
Brittany is one of Dan Kennedy’s (the “godfather of direct marketing”) most brilliant students, and one heck of a great online marketer.
(To learn about some of the inner workings of Brittany’s business check out this fascinating Customer Spotlight with Brittany.)
Brittany originally hired me to help her set up and maintain her online membership communities and digital products via my unlimited membership site support service, MemberFix.
Everything was going great until we ran into a big problem.
Idealme.com was loading too slowly.
It was so bad, in fact, that customers were complaining and Brittany’s team (myself included) had trouble working on the site because of the lag and constant timeouts.
Here’s how we tackled the problem.
Reduce Plugin Bloat
The first thing we did was deactivate and delete a bunch of unnecessary WordPress plugins.
Excess plugins and scripts bog down site load times so it’s best to remove any plugins that you aren’t actively using.
However, we were still left with quite a few plugins and scripts so this step didn’t have a huge impact.
This is because Brittany needs and actively uses the majority of the plugins she has installed in order to run her powerhouse of a website.
WPEngine Saves the Day?
A few of my clients were happy WPEngine customers, so I suggested that we give their service a whirl.
Brittany agreed to try them out and tasked me with the migration.
The move over to WPEngine was straightforward and our load times instantly improved.
But that’s where the good news ended.
The very next day, support tickets started pouring in from members complaining that they couldn’t access their members only content.
The issue, it turns out, was that WPEngine aggressively caches their customer’s websites.
Caching basically means taking a “snapshot” of your site and then quickly pulling it up for visitors instead of loading all of the website content from scratch each time.
That’s why caching makes your site load faster, especially on subsequent visits.
However, many membership plugins conflict with caching and produce various errors such as:
- Not being able to login to the members area even though you’ve entered the correct credentials
- Getting stuck in a “redirect loop”
- Logging in and not seeing your content
- Problems checking out or purchasing a product
…and other funky issues.
To complicate matters, Brittany runs 2 membership plugins simultaneously (MemberMouse and Zaxaa).
So we had to be mindful to avoid several possible conflicts between:
- The hosting configuration and the membership plugins
- The first membership plugin and the second membership plugin
- Each individual membership plugin and the rest of the plugins
The typical solution in this case is to create a list of pages that you exclude from being cached (so called “caching exclusions”).
Any page that is protected by or involved with your membership site (members area, login, my account, protected content pages, etc.) should be excluded.
So we contacted WPEngine support via their live chat and provided them with a long list of pages and posts that we wanted to be exclude from getting cached.
To our dismay, support said that we can only get 10 exclusions because we share a server with other customers and caching exceptions are resource intensive, which could negatively impact the performance of other sites on the server.
That’s right folks - WPEngine is shared hosting.
Ideal Me has dozens of protected pages across both membership plugins, so 10 exceptions wasn’t going to be nearly enough.
We quickly pointed the DNS back to Bluehost and our members were once again able to access the materials they’d paid for.
But we were now back at square one with a site that moved about as fast as a snail on an all-molasses diet.
WPEngine: Part Deux
A bit later, we actually tried moving to WPEngine again because I thought I could sweet talk support into giving us more exceptions…
But it proved futile and we had to hastily point our DNS back to Bluehost yet a second time.
Needless to say that by this point we were annoyed and anxious to avoid causing any more inconveniences for our team, our customers, and ourselves!
So we upgraded to Bluehost Cloud Hosting which didn’t require us to migrate to another hosting company.
It simply took our existing domain and upgraded the server it was hosted on.
Bluehost’s Cloud turned out to be similar to WPEngine in that they cache the bejesus out of your site to make it load faster.
(In fact, this is the M.O. of the majority of so-called “managed” WordPress hosting providers including Pagely, Flywheel, WPEngine, et al.)
And they give you equally little over your caching settings…that is, none.
Light At The End of the Tunnel
Meanwhile in the background, my business partner Josh and I had been busy building the perfect hosting platform for ourselves.
We were sick of endless hosting issues, sluggish speeds, lack of control over server resources, and subpar support outsourced to the 3rd world.
We knew that great hosting is a competitive advantage and we wanted to harness that advantage for our respective businesses and customers.
When we finally launched SpeedKills.io and tested it with our domains, we were blown away by the results.
Our sites loaded faster than on any other platform we’d used (including WPEngine in several geographies).
We put strong security in place, and we had tons of flexibility over things that hosting companies typically keep under lock and key, such as:
- Server resource settings
- Control over individual caching layers
- Control over PHP version and module (PHP-FPM vs mod_PHP)
- Control over where we deployed our server
Josh and I quickly realized what a tremendous value-add our SpeedKills.io platform would be not just for our current customers but for all of the business communities we were a part of, so we decided to make it commercially available to other small businesses and entrepreneurs as well.
I told Brittany about our new platform and she became our 3rd paying customer (thanks Brittany!) 🙂
We promptly moved 3 of Brittany’s domains to our platform, where they’ve remained to this day.
Before and After Results
In the table and accompanying line graph above you can see that Bluehost Cloud performed worst of all.
WPEngine loaded our site the quickest in Melbourne, Dallas and Stockholm.
And our SpeedKills.io servers loaded Ideal Me the quickest in NYC and San Jose (California being our target geography).
Based on these numbers you might argue that WPEngine is comparable, and in some cases even superior to our own platform, at least speed-wise.
But that’s not quite true because hosting our domain on WPEngine resulted in a non-functioning site.
Ironically, the aggressive caching they used to produce these great load times is the very same caching that caused the membership plugins to not work and rendered the site useless.
So what good is a fast site that doesn’t work?
On the other hand, the load times we achieved for Brittany on SpeedKills.io (and are still improving every single week in keeping with our Kaizen core value) were achieved without breaking the functionality of the site whatsoever.
How did we make the magic happen?
1 - Mindful caching approach
We utilized caching for incredible speeds without causing membership plugin conflicts by carefully selecting what to cache, what not to cache, and which caching layer to turn off altogether.
The main caching layer that causes problems with most WordPress membership plugins is the varnish cache.
While some “managed WordPress hosting” services let you turn off caching, it’s almost always a big “on/off” switch that turns off ALL of the caching.
On the SpeedKills.io platform we have control over each individual caching layer, so we can simply turn varnish off for the entire server instance while retaining the other speed-boosting caching layers that don’t conflict with our membership plugins (Nginx, Apache, Redis, Memcached, etc.)
2 - Focus on target geography
Initially when we moved Idealme.com over to SpeedKills.io we weren’t able to get the same speeds as WPEngine right away.
But because our service is based on the “kaizen” principle of continuous improvement, we continued making optimizations until we eventually beat out both Bluehost Cloud and WPEngine’s load times in our target geography.
The problem with traditional hosting companies is that they don’t do much (or anything) to continue optimizing your site speed, security and user’s experience apart from server updates that every host does as a matter of course.
They depend on blanket optimizations at the server level, which lacks nuance.
One thing we did for Brittany is to analyze her traffic to see where the majority of her visitors are coming from.
This allowed us to make an intelligent decision about the best location to deploy her server.
In our testing we’ve found that the two factors which most influence load times are the quality of the server and its location (relative to where the visitor is browsing from.)
That being the case, it always struck me as odd that a hosting company wouldn’t allow you to deploy a server where it would have the biggest impact for your particular website.
The bulk of Brittany’s traffic hails from California (in fact, that’s usually the case for US-based websites), so we deployed her server in Los Angeles and achieved sub 2 second load times shortly thereafter without compromising on functionality.
Load times for related geographies (Southern USA and East Coast) also generally hover just above 2 seconds.
I estimate that we’ll be able to get it down to under a second in the next month or so.
3. Removed malware and hardened security
Shortly after we moved back to Bluehost for the second time, Idealme.com got hacked bad.
The hacker managed to screw up Idealme.com’s Google results pretty badly and we spent a considerable amount of resources to repair the hack.
It didn’t help that when we asked Bluehost support for assistance that they demanded we pay them a $250 fee just to diagnose the problem.
In the meantime, they shut down not only idealme.com but ALL of the domains in Brittany’s Bluehost account.
Our malware removal specialist, Cristian, cleaned the site and Bluehost restored our account.
However, they then shut it down again because of a suspected malware file.
Cristian once again checked our files and folders and discovered that the file in question was not malware but a licensing script which uses obfuscated code.
A big company like Bluehost uses scripts and algorithms to detect malware and as a result, often produces false positives (flags a file as malware even though it really isn’t).
They again wanted $250 to diagnose/remove the non-existent hack.
Enough was enough and we moved several additional domains of Brittany’s over to SpeedKills.io.
We were then able to implement our in-house security measures to harden the site against future attacks.
Since then, neither Brittany nor any other client has experienced a malware attack on our platform.
Speed vs Flexibility: Why Compromise?
Brittany was flustered with the same question that plagued us before we developed our business concept, which is:
“Why do I have to compromise speed if I want flexibility, and vise versa?”
I rejected the notion that compromise was a necessarily evil from day one, and it has kept our vision strong to continue serving small businesses in a way that lets them operate smoothly, profitably and securely.
Wow that’s an amazing case study, Vic. Thanks for talking us through the details and the whole long journey Brittany faced. Hopefully reading about her travails will save some others treading the same overworn footpath between budget hosts. You really hit the nail on the head about how almost all the managed WordPress hosts rely too heavily on caching and give membership sites no resources:
Any membership site should deal with membership site experts like yourself. We host most of our VIP development clients (almost all of them have a membership component now) for the same reasons.
Thanks for the kind words, Alec. I spent an hour reading *your* case studies on FolioVision.com yesterday. A cosmic, karmic phenomenon, no doubt.
Going a bit further with the break from conventional recommendations above – and I haven’t published about this yet, but will in due time – I’ve been helping Brittany, and several of my other customers, UNBUNDLE their membership sites from their marketing-oriented “main” sites.
I believe this unbundling is a very important trend and is enabled in large part by companies like Zapier and center.io. In this kind of situation, website owners are very much married to their email marketing platform, be it ActiveCampaign, InfusionSoft or, (in our case) Drip.
So how convenient would it be to manage membership access using tags in your respective platform? The ‘new’ generations plugins, which have actually been around for a while, connect the membership component to the email marketing platform in a 2-way sync. e.g. ActiveMember360, iMember360, Memberium (not recommended but for the sake of example), etc.
Further, the ‘marketing’ site that houses the content and landing pages and optin forms that convert visitors into leads into customers should generally have a focus on performance because speed influences SEO and conversion metrics. By placing membership functionality on this public-facing site, you add additional resources for your site to load and you instantly reduce your ability to make use of advanced optimization techniques (e.g. varnish cache) because of how violently they tend to conflict with membership plugins.
Therefore, I think it’s sensible to sequester the “marketing” site from the “membership” site whenever possible, as there’s no longer any compelling reason to combine them, and many reasons to separate them.
The caviar emptor as I like to call it is, that you’d have to be using an email marketing platform for which one of these deeply integrated plugins exists. At present I can only recommend ActiveMember (ActiveCampaign) and iMember360 (InfusionSoft).
I’m hoping somebody develops something akin to Bob Keen’s plugins above for Drip, although it can be done with the Drip.js and Drip pro tools but requires some finagling.
Separation of marketing site and membership site is a long running theme in the marketing world. Dan Kennedy and many of his many disciples often built the membership areas separately (at least on a sub-domain). While I see how it makes the technology easier, I’m not keen on that much separation as it makes for a less organic experience, gradually migrating someone over to paying member. I see a part of the marketing action, bringing people in with free content and showing them small paywalls long the way if the visitor would choose first to register and then to become a member.
My own approach here would be:
1. to use lightweight membership solutions which are native to the primary platform (say RCP for WordPress as a quick example).
2. to build hosting which is not as dependent on cheap tricks like Varnish. A little bit of oomph in your client’s server is pretty cheap on the hardware side once you get away from the expensive, cache-dependent “Managed WordPress” hosts you named.
3. to improve caching for logged-in users (something which we’re working actively on)
It’s true though that the WordPress hosting world treats membership sites very poorly.