Today I discovered a bug in a WordPress plugin update that had a tremendous negative performance impact:
Luckily the solution was an easy one to fix, but I’ve gotten some question about how I found out where the issue was, so I thought I take you along on some performance debugging steps I always take.
Staging & Local Development
First off, I work with both local development sites as well as staging sites. For my local development environments I use LocalWP.
This means I work with two other version of the site besides the production site itself. This is how I discovered the issue before the update was deployed to the live site.
Performance Debug Tools
I’m using the same tools for all three environments.:
Two WP CLI extensions
WP Profile and WP Doctor. Both have different ways to inspect whatever needs inspecting. Learn about them, play with them and add them to your deployment flow. They’re indispensible in my dev environment just as much as my text editing tool.
WP Debug
Using WP Debug goes without saying, right? If you’ve never seen it, do check out the related developer docs.
Query Monitor
The WordPress plugin Query Monitor, together with Laps, are the two plugins I install on every single non-production site. They help to debug where issues lie, and where the fix most likely is to be found.
Slow Queries
Turn on (or have your hoster do it for you) your MySQL Slow Query log and see what’s causing your WordPress site to slow down. And where. This is one you may want to have turned on production for short times as well.
Debug Plugins and Themes
Disable plugins one by one to identify the source of any performance issues. There are ways to automate this with WP CLI. I’ll cover this in my WP CLI course.
And lastly:
Chrome DevTools
Use the Network tab first, then look at Performance insights, Performance and Lighthouse. There is more to use, but this is my base performance debugging stack.
Leave a Reply