Estimated reading time at 200 wpm: 8 minutes
CaptainsWatch is now lightning fast, after I took action. The few who visit will find that pages and other content load almost instantly. The site had developed what I can only describe as a chronic illness. Pages loaded like they were wading through treacle. The Gutenberg editor — WordPress’s block-based writing tool — was throwing a cryptic error at random moments: Updating failed. The response is not a valid JSON response.
Whether or not you agree our Fat Disclaimer applies
So – you’re no tech-bro. And you might be wondering why this story or what’s it about. The core of it is not really about AI. It’s about how ‘advice’ and ‘expertise’ and take one down into rabbit holes. It’s about the victory of human common sense, over blind technology.
If you still think this is about ‘IT’ kindly move on now
The problem was intermittent, just often enough to be maddening. The site wasn’t dead. It was just… very unwell, slow, unreliable, and deeply uncooperative. Yuh know – like like a colleague who repeatedly turns up to work hung over and achieves very little.
So I did what any reasonable person does in 2026. I called in the AIs. And doing that proved again my contradictory saying “Use AIs – don’t trust AIs!”
When Things Got Seriously Bad
Before the investigation could conclude, the site got dramatically worse.
On 5–6 August 2026, multiple WordPress sites on my hosting account did a blink on and off. Something was dying! I opened a ticket with my hosting provider. They reported that the account had hit its CPU usage limit. The debug log was throwing thousands of MySQL connection errors. The culprit eventually identified itself: Broken Link Checker, a plugin that had attempted a database schema update, failed silently, and then retried that failed update thousands of times on every WordPress page load. Every. Single. Load.
It was essentially staging a one-plugin riot inside my database. Broken Link Checker was deactivated immediately and has not been invited back.
Enter the Investigation — With ChatGPT
Working with ChatGPT over many sessions, a methodical investigation began.
Suspects were lined up and systematically eliminated. Cloudflare — cleared. The All-In-One Security plugin’s REST API restrictions — investigated, partially resolved, cleared. SEOPress AI making mysterious external calls — source code read in detail, cleared. GenerateBlocks rebuilding CSS on every save — cleared. WP-Optimize running complex cache-purge routines on every post update — cleared.
The site remained slow. Gutenberg saves were taking 2,350–2,800 milliseconds on the server, roughly 6 times over normal. 🙄
At this point you might be thinking that the AI was helping. Yes – it was ruling out some stuff but not really making progress. Look, it’s like going to the doctor with a very bad tummy ache and they’re checking your every orifice, taking blood tests, putting you on a scale, measuring your head circumference – for over more than an hour! You get the picture – AI models do not have a date with the grave – like all humans – so they an take as long as they like!
The investigation had become, in its own words, vulnerable to “framing effects.” It needed fresh eyes.
So in getting ready for the next stage GPT directed by me, created a full log of all activity. Wait for it – that resulted in a dossier totalling 30,154 words from about 10,00 lines.
Bringing in a Second Opinion
Claude was handed the dossier and asked for an independent appraisal. 30-odd thousand words is nothing for an AI model. That volume was digested in about 2 minutes.
Claude’s opinion in tight summary was another 1200 words. It was blunt: the investigation had become code-reading heavy and measurement light. Two hundred and fifty kilobytes of analysis, and the 2.8-second save from tests on the site, was described as a black box. I didn’t like what has happening. I agreed. My suggestion was to tell everybody to take a rest from reading source code and start running controlled experiments.
Specifically: build a clean test site and measure things empirically.
The Control Experiment
A fresh WordPress installation was created at test site under captainswatch.org. Same Krystal hosting account. Same Cloudflare setup. Same GeneratePress theme family. One post. No history. No accumulated years of plugin debris.
Gutenberg save time on the clean test site was 718 milliseconds.
One the live site: 2,800 milliseconds.
The host was not the problem. The theme was not the problem. Something specific to the live site — its history, its configuration, its accumulated state — was costing roughly 2,000 milliseconds on every single save of an edited post.
The Moment of Absurd Clarity
The question I posed: what has been present on the live site throughout this entire investigation, but is absent from the clean test site?
The answer arrived with the slow, dawning horror of a joke whose punchline I should have seen coming.
WP_DEBUG.
That’s WordPress’s debug logging – a diagnostic tool. It was discovered from the logs to have been switched on from 2024. Yes two years ago. Don’t ask me how that happened. That meant that every single PHP request — every page load, every Gutenberg save, every admin action — was writing synchronously to a log file on a disk in ‘the cloud’. And it did a massive job: 55MB of logs is crazy for this kind of thing.
The diagnostic tool was the pathology. One line changed in wp-config.php was required to stop it:
define('WP_DEBUG', false);Immediate result: 691 milliseconds.
Weeks of investigation in the background – a dossier of 30,000 words – dozens of plugins read at source-code level – AIs going down rabbit holes. The answer was switching off the thing. It sent the AIs on a fishing expedition.
Yes – I had a good laugh in the end.
Going Further
With the site now breathing normally, three further improvements followed in quick succession.
I upgraded PHP from 8.2 to 8.3 then to 8.5, resulting in faster execution across the board. OPcache was enabled on my suggestion. It’s a thing that stores compiled PHP scripts in memory so they don’t need to be parsed fresh on every request – which matters considerably when you have 34 active plugins. Then Redis Object Cache was connected via a Unix socket provided by my cPanel in the background. That stores repeated database query results in memory rather than hitting the database each time. Do I know what PHP, Opcache and Redis are? Do I understand these things? Do I have to understand what a spanner is – or even bog roll – before I use it? I do not!
The AIs were about to give up. Oh yes – just like people when I get tough or the going gets tough. They were directed to find another fix for the config file.
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/kredis/ebcedebd/redis.sock');Entered and saved that code – an Bob’s your uncle! Well, no – I don’t know Bob and I don’t even know if you have an uncle. Chrysst!
Each intervention was measurable. Each produced further improvements.
Where the Site Stands Now
Let’s look at the journey in one place:
- Start of the day: 1,200–1,567 ms (time to serve a page). Time to save pages: ~2800 ms
- WP_DEBUG off: 691 ms.
- PHP 8.5 + OPcache: 570 ms.
- Redis Object Cache: 456 ms.
But wait – at 2026-08-16 Litespeed cache plugin was installed, activated and configured – leading to further reductions to around 63 ms.
Now, pages load almost instantly. The Gutenberg editor saves without faffing about. The site that was wading through treacle is now, frankly, rather sprightly. It’s been given a dose of youth! Thanks to me I dare say – and I do say.
What This Taught Me
Several things, some technical and some not.
Two AIs are better than one – and two of them can be worse than one! Because of their brute compute strength they can head down rabbit holes like nobody’s business. Long investigations develop their own momentum and assumptions.
Empirical testing beats code archaeology. Reading plugin source code is valuable for a limited period. Running a controlled timing experiment takes twenty minutes and answers questions that days of code-analysis cannot.
Diagnostic tools have costs. WP_DEBUG exists for good reason. It should have been switched off. But it is not something I knew about, to switch on.
And finally – a single human can be better than two or three AI models doing a tag team! The most sophisticated explanation can be wrong, and the answer unearthed by human intellect came down to three lines of code.
But it’s not that simple really. The wrong turns and failed attempts of the AIs were valuable. All that enabled me to step back and look at the deeper and bigger picture. I had to go in – and then come out to gain a fundamental perspective.
The is genuinely sweet now. Blazing fast. And I’m still laughing. 🤣
