Page Shows Without Styles Briefly - Cache Purge Hook Was the Cause

👁 115 reads

On several pages, you could briefly see raw HTML without formatting - headings stacked one after another, links in blue, zero column layout. The effect appeared only sometimes and only for some visitors, so it was hard to catch for a long time. The cause turned out to be a cache plugin hook that cleared everything including CSS and JS files on every publish.

What the Symptom Looked Like

A page without styles is classic FOUC, or flash of unstyled content. It’s usually explained by asynchronous font loading or critical CSS injected with delay. Here the mechanism was different and simpler: the stylesheet wasn’t loading with delay, it simply wasn’t there.

The HTML document served from cache contained a reference to a specific minified file with a hash in the name. That hash is generated when the file is created and hardcoded into the HTML. If the file is deleted but the HTML remains, the reference hangs in the air. The server responds with a 404, the browser shrugs and draws the content without any formatting.

The window was narrow - measured in seconds, sometimes tens of seconds, depending on when someone visited and how quickly minification rebuilt. That’s why the problem almost never appeared in manual testing. You’d refresh the page, everything worked, the issue was closed as unreproducible.

Where the Dozen Daily Purges Came From

The plugin called a full purge including CSS and JS files on every publish. With a dozen posts per day, the directory was cleared a dozen times per day. Each such purge is one potential window where HTML points to a non-existent stylesheet.

It’s worth noting the scale: this isn’t a failure that happens once a month during a theme update. It’s a repeatable event built into the normal editorial workflow. The more you publish, the more often you open the window. A site that publishes two posts a week will practically never notice this. A news site with a dozen posts per day will have a dozen windows per day and regular complaints from readers that WordPress is slow or looks broken.

Full Purge vs Targeted Invalidation

The table below shows what actually changed in system behavior after changing the strategy. It contains only data that could be unambiguously read from configuration and logs - no estimates and no averages I can’t back up.

The key observation is logical, not measurement-based: a new article doesn’t change the CSS file content. Style rules are the same before and after publishing text. So there’s no technical justification for content publication to trigger asset regeneration.

What Should Trigger Full Purge

This is my opinion based on this one implementation, not a hard rule. I’d leave full purge including CSS and JS for three situations: changes to theme files, updates or configuration changes to plugins affecting the front end, and manual click by an administrator who knows what they’re doing. Everything else - new post, editing an old one, category change, new comment - should invalidate only the URLs whose content actually changes.

In practice, the list of URLs to invalidate on publish is short and predictable. The post itself, because it just appeared. The homepage, because it displays a list of latest posts. Category listings the post belongs to. The RSS feed, because readers and aggregators pull it independently. Beyond that, nothing else changes content.

LiteSpeed Cache Configuration - What to Look For

The plugin name is secondary here, because the pattern repeats in many cache solutions for WordPress. Look in settings for two things that often sit in separate tabs and aren’t visually connected.

First is automatic purge rules on publish - usually a list of checkboxes with scopes like homepage, archives, author, tags, everything. Second is minification and combining options for CSS and JS, with a separate toggle responsible for deleting generated files when purging cache. The problem only arises when both sets of settings are enabled simultaneously and linked by the same event.

If the plugin lets you separate these two layers - page cache and asset cache - separate them. If it doesn’t, you’re left with modifying behavior at code level: hooking into the publish event, replacing the full purge call with a series of targeted invalidations. A settings-level solution is better because it doesn’t disappear on plugin update.

How to Check This on Your Site

1. Open the homepage in incognito mode and view source. Copy the full address of the CSS file from the head section - the minified one with a hash in the name.
2. Paste that address into a second tab and make sure the file opens and returns content, not an error.
3. In the admin panel, publish a test post. Don’t edit the theme, don’t change any settings - just publish content.
4. Immediately after publishing, refresh the tab with the CSS file address. If you get a 404, you have confirmation: content publication deletes assets.
5. At the same moment, open the homepage in a third tab. If you see raw HTML without formatting, you’re seeing exactly what readers see.
6. Check whether the CSS file address in the source of the newly generated page is already different from the one copied in step one. A hash change confirms regeneration.
7. Go into plugin settings and find the purge rule on publish. Limit it to post, homepage, categories, and RSS feed.
8. Separately find the option responsible for deleting minified CSS and JS when purging cache and unlink it from the publish event.
9. Repeat steps one through five. The CSS file should survive publication with the same hash in the name.
10. Observe for a few days of normal editorial work. With a dozen posts per day, the effect will either return quickly or not return at all - there’s no third option.

// read moreClaude Fable 5.2 Pricing & API: Costs, Cache, Batch, Model IDGuidesPhone Storage Full? Clear Cache and WhatsApp, Not PhotosGuidesAnthropic Paper Shows AI System Outperforms Humans at AlignmentNews

Kinetyra