Michael D. WandzilakIf your WordPress site blinks white for a split second before the real page appears, you’re seeing a Flash of Unstyled Content — FOUC. It looks broken, it feels cheap, and it’s one of the most-asked-about annoyances in WordPress. Here’s why it happens and the dead-simple fix we’ve relied on for years.
This post is a revived classic from our old developer’s notes. It collected a long thread of grateful comments back in the day, so we’ve brought it back — lightly updated for 2026.
What’s actually happening
A browser builds your page in stages. It receives the raw HTML first, then fetches the stylesheets that tell it what everything should look like. In the brief window before the CSS arrives and applies, the browser paints whatever default it has — usually a blank white background. On a fast local install you’ll never notice it. Over a real connection, with latency in the mix, that gap becomes a visible white flash.
WordPress makes it more likely than a hand-built site because of how much it loads. A common culprit is jQuery being pulled in by multiple plugins, often in different versions, along with a stack of stylesheets and scripts that all have to be requested before the page settles. The more render-blocking requests sit ahead of your CSS, the longer that white moment lasts.
The fixes people try first (and why they fall short)
When we first chased this down, the internet was full of workarounds. The popular ones:
- Dropping an empty
<script></script>tag just before the stylesheet call. - Loading a blank print stylesheet (
media="print") to nudge the render order. - Downgrading jQuery to an old version to dodge a particular conflict.
Each of these helps in some specific setup and does nothing in others. None of them addressed the real problem for us, which is simply: the browser is painting a background before our CSS loads. So we stopped fighting the load order and changed what gets painted in that first moment.
The workaround that actually works
Style the html element itself with your background. The html element is the very first thing the browser knows about, so a background set directly on it is painted immediately — long before the rest of your stylesheet finishes. Instead of white, the visitor sees the correct color (or image) from the first frame.
html {
background-color: #ddd;
background-image: url(images/bg.jpg);
}That’s the whole trick. Put your real background color — and a background image if you use one — on html, in CSS that loads as early as possible. Hit refresh, and the flash is gone. It even behaves in Chrome, and it’s rock-solid in Firefox.
Doing it the modern way
The principle hasn’t changed, but in 2026 we have sharper tools to apply it:
- Inline your critical CSS. Put the handful of style rules needed for the first paint — including that
htmlbackground — directly in the<head>so there’s no separate request to wait on at all. - Tame your scripts. Defer or async non-essential JavaScript so it stops blocking the render, and clean out plugins that each drag in their own copy of jQuery.
- Cache and serve from the edge. A caching layer and a CDN like Cloudflare get your CSS to the browser faster everywhere, which shrinks the FOUC window for every visitor.
Set the background on html, inline what’s needed for the first paint, and stop letting plugins pile render-blocking junk ahead of your styles. Do that and the white flash simply stops happening.