DEV Community: Marinnov Nikola

Fixing the WordPress "Persistent Object Cache" Warning Without Accidentally Freezing Your Dashboard

Marinnov Nikola — Tue, 30 Jun 2026 12:59:08 +0000

Today I opened my WordPress dashboard, ran a Site Health check, and saw a warning that said: "You should use a persistent object cache."

To be completely honest, I had no clue what a persistent object cache actually was. As you probably know from my previous post, I’m still a wanna-be developer learning the ropes. But after reading up on it, it became clear that saving database queries in the server's memory would make my site much faster. It sounded like a mandatory tweak, so I decided to turn it on.

Since I already had the LiteSpeed Cache plugin running on my site, I figured I’d handle it directly through there. I went to LiteSpeed Cache > Cache > Object tab, toggled the Object Cache option to ON, and selected Redis as the method. At this point, I totally didn't realize I had to change the host and port settings as well, so I just clicked save.

That’s when everything went south.

Instantly, my WordPress admin panel froze. Every time I clicked a menu, the page loaded indefinitely until it finally timed out and hit me with the dreaded "critical error on this website" screen. I couldn't even load the settings page to toggle it back off. I was completely locked out of my backend.

I even tried deleting the plugin files through my hosting file manager and reinstalling it from scratch, but it had absolutely no effect. The moment I activated it again, the error returned because the broken settings were permanently stuck inside the WordPress database. Out of options and completely stuck, I asked AI for help, and it gave me the advice to bypass the broken WordPress UI entirely using code.

Here is what actually happened under the hood. By default, LiteSpeed Cache assumes your server runs Redis over a standard network port on localhost. But my hosting provider (JetHost) isolates environments and uses a UNIX socket path instead of a network port. Because WordPress kept trying to talk to a network port that wasn’t listening, it got stuck in an endless connection timeout loop on every single page load.

Following the AI's advice, I logged into my hosting client area, opened the File Manager, and edited my main wp-config.php file. Right before the line that says /* That's all, stop editing! Happy publishing. */, I added these two lines to force the object cache off at the root level:

define('LITESPEED_CONF', true);
define('LITESPEED_CONF__OBJECT', false);

The moment I saved the file, my WordPress dashboard instantly unlocked and loaded normally again.

Next, I went back to my hosting control panel and opened their native "Redis Manager" tool. I turned the Redis status to Active and copied the unique connection socket path they provided. It looked like this:

/home/example/.jethost-redis/redis.sock

With the dashboard now accessible, I went back to the LiteSpeed Object Cache settings page. It was loading perfectly fine because my wp-config.php code was keeping the broken cache script asleep.

I filled out the configuration fields using the exact data from my host:

In the Host field, I deleted localhost and pasted the UNIX socket path.

In the Port field, I changed it to 0. This is crucial because UNIX sockets don't use network ports, so the value must be zero.

I clicked Save Changes.

Finally, I went back to my wp-config.php file and deleted the two temporary lines I added earlier so the plugin could actually do its job.

I refreshed the WordPress settings page, flipped Object Cache to ON, and hit save one last time. The connection test immediately changed to a green "Passed". No more dashboard freezes, the Site Health warning is gone, and the site is running exactly how it should.

After that, I fixed the exact same issue in the blog section of the Romanian version of the Eduboom website. This time, I edited the host and port fields right from the beginning, which saved me an extra hour of fixing self-created problems.

An AI Built My WordPress Theme. Then I Found the Performance Bugs It Left Behind.

Marinnov Nikola — Tue, 23 Jun 2026 05:27:13 +0000

I’m what you’d call a “wannabe developer.” My main focus is SEO, but I like trying new things and getting my hands dirty when something breaks.

The project was simple enough: a WordPress site dedicated to the 90s classic PC games I keep recommending to people. Instead of hand-coding the theme, I described the layout I wanted, gave an AI the homepage content, and asked it to build a custom theme from scratch.

To be fair, it did a decent job. The site launched with a perfect 100/100 on Lighthouse for both mobile and desktop. Clean HTML, fast load, no obvious mess.

Then I made a few small content edits to the homepage, re-ran the test, and the mobile score dropped to 89. Desktop stayed at a clean 100.

This is not a deep performance war story. The fix was a single image attribute. But the reason that attribute ended up in the wrong place says a lot about why AI-generated code still needs a human code review.

The Symptom: Visual Priority vs. DOM Order

A flawless desktop score next to an 89 on mobile is classic throttling behavior. Fast desktop connections easily mask critical path bottlenecks that PageSpeed’s simulated 4G and mid-range mobile hardware immediately expose. The drop indicated an asset was needlessly competing for early bandwidth.

The mobile report pointed straight to an image in the Largest Contentful Paint (LCP) path: a screenshot from Disney’s Aladdin.

That was odd, because the image is not visible on the initial screen. The homepage opens with a massive data table of games spanning roughly 25 rows, you can see the live layout at bestclassicpcgames.com. On a mobile viewport, that table completely takes over the screen and pushes the actual game sections deep below the fold. The Aladdin screenshot is the first image in the source code, but visually, it is nowhere near the initial viewport.

The Bug: A Naive Heuristic

Checking the theme template revealed the issue:

<img src="..." alt="Aladdin video game" width="800" height="450" fetchpriority="high">

The code is valid, but the assumption is wrong. The AI relied on a naive heuristic: it assumed the first image tag in the HTML source code was the hero image.

In a standard blog layout, that logic usually holds up. But lacking spatial awareness of the massive HTML table altering the viewport hierarchy, the AI forced mobile browsers to waste limited early bandwidth downloading a hidden asset.

The fix was immediate:

<img src="..." alt="Aladdin video game" width="800" height="450" loading="lazy">

Chasing the Cache Ghost

The code update was correct, but the first retest still returned an 89 and showed fetchpriority="high" in the rendered source.

I spent twenty minutes looking for a phantom optimization layer, a WordPress filter, or a plugin conflict before realizing I was just being gaslit by a server-side cache. The template was already fixed, but the caching layer was cheerfully serving the pre-edit HTML.

Once I purged the cache properly, the issue disappeared. Mobile snapped back to a stable 100 with a 1.0s LCP. It was a useful reminder: before chasing a performance regression, make sure the testing tool is actually seeing the code you changed.

The Takeaway for Auditing AI Themes

The AI didn't "fail" here; it made a reasonable guess based purely on source order. But because AI lacks visual and contextual awareness of the rendered page, it can write technically flawless code that completely reverses your asset delivery strategy.

If you are using LLMs to scaffold themes or components, add a quick global grep to your review pipeline:

Audit fetchpriority and loading="lazy": Verify them against the actual viewport hierarchy rather than DOM order. Look out for images buried under heavy layout elements, data tables, or hero sliders.
Isolate the Testing Environment: Save yourself the debugging panic, always purge your server caching layers and test cleanly to avoid auditing stale code.

AI-generated code is clean enough to ship, but it still requires a human to verify whether its structural assumptions match reality.