Plugin Audit & Performance: Lessons from Head for Change
Recently, we had the opportunity to work with Head for Change, a UK charity doing incredible work around brain health in sport. Their mission is to provide care for former athletes living with neurodegenerative diseases, raise awareness about head injuries, and support research that makes football and rugby safer.
The site setup included:
- A static/marketing site built with Divi → headforchange.org.uk
- An LMS subdomain running LearnDash → learnheadforchange.org.uk
- Hosting was on Kinsta for both sites.
The client asked us for a plugin audit, an overall performance review, and to check login issues (since the courses are used by schools/universities, multiple users needed to log in from the same IP without being locked out).
First Roadblock: Staging on Kinsta
We always run audits on a staging environment that mirrors the live site 100%. Normally, on Kinsta, that means spinning up a staging site. The issue? Their account didn’t have staging included, and upgrading required buying an additional package. It was Friday, and waiting for approval would take at least 3 days. The client needed this urgently before their launch.
Workaround: we used WP Staging Pro to create a clone of the site on the same server. That way, we didn’t need to purchase anything extra.
But that’s where we hit the second wall. The staging process failed due to Kinsta’s server configuration.
Server Findings
Here’s what we found when digging into Kinsta’s setup:
Server Resources
- Total Memory: 1.5 GB
- PHP Threads: 6
- Memory per Thread: 256 MB
WP Staging failed because of the 256 MB per-thread limit. Temporarily switching to 3 threads × 512 MB allowed the process to finish. After that, we reverted to the default 6 × 256 MB setup.
Risk: Any heavy background process (large imports, staging, or LearnDash tasks) could fail under the 256 MB/thread limit.
Performance & Stability
- With no external load, the site performed fine.
- Baseline stability was good.
Caching
- Kinsta excludes WooCommerce pages like
/cart/,/checkout/,/my-account/. - But there’s no official confirmation that LearnDash pages are excluded. That’s risky for LMS sites where user progress and course data are dynamic.
- We configured the Kinsta MU plugin to purge LearnDash content, but the best practice is always: no full-page caching for logged-in users.
Risk: Outdated content, quiz/session conflicts, or broken progress tracking for learners.
Community Reports
Other LearnDash users in the Facebook group had also flagged issues with Kinsta hosting. So this wasn’t an isolated case.
Plugin Audit
The LMS subdomain originally had 27 plugins installed. After the audit:
- Reduced to 18 plugins (a 37% reduction).
- Suggested disabling “Disable Emails” before launch.
- Removed unused or outdated plugins.
- Replaced plugins not compatible with the current WP version.
Result: same functionality, cleaner setup, faster performance.
Other Fixes & Cleanups
During the audit, we spotted several issues both front-end and back-end.
Front-End Issues
- Donate button and Follow button weren’t working → linked them back to the main site.
- Cookie policy page existed but wasn’t added to any menu, and there was no cookie popup → fixed.
- Courses were set to Free Form navigation, even though the FAQ said topics should be done in order → updated settings.
- The site wasn’t fully mobile responsive. Lessons and quizzes in Focus Mode had horizontal scrolling issues due to Divi. Fixed this with a few lines of CSS.
- Removed unnecessary JS: and also removed
comment-replysince comments were disabled.
Back-End Issues
- Groups Dashboard pages had WISDM shortcodes, but the plugin wasn’t even installed.
- Many CPT and custom fields were unused → removed.
- Extra WooCommerce tables were left in the DB from older installs → cleaned up.
- Unnecessary functions sitting in
functions.php→ removed.
Login Testing
This was a critical request: multiple users logging in from the same IP.
- We tested this thoroughly → no issues.
- Turns out the client’s team (Risto) had already fixed the original lockout problem caused by Wordfence. The solution was applied via Patchstack.
But we did uncover another login-related issue → Kinsta’s resource limits.
Load testing showed that if 3 users hit wp-login.php at the same time, the 4th request failed due to no available resources.
Imagine this happening with only 17 plugins installed, while most of our clients run with 70+ plugins. Not sustainable.
Hosting Bottleneck
All of this pointed back to hosting. The caching setup + limited resources were the real bottlenecks.
As part of the audit, Risto offered the client a free test migration to MemberHost. The difference was night and day.
The client immediately noticed the speed boost and agreed to move away from Kinsta.
Summary
In just 13 developer hours, here’s what we achieved:
- Reduced plugin count by 37% (27 → 18).
- Fixed responsiveness and layout issues in LearnDash Focus Mode.
- Cleaned up database, post types, unused scripts, and custom code.
- Fixed front-end issues (buttons, cookie policy, FAQ consistency).
- Verified login works for multiple users from the same IP.
- Discovered server bottlenecks on Kinsta and migrated to MemberHost for better performance.
Overall, the site is now lighter, faster, mobile-friendly, and running on more reliable hosting — ready for launch.
