Most WordPress sites still run on hacks written ten years ago, because nobody wants to touch the stylesheet and set off a cascade collapse. Those skeletons cost you performance. A ReliCSS CSS audit is the reality check that tells you which ones can go.
I have been doing this since the WordPress 4.x days and I have seen some horror stories: 4,000-line style.css files stuffed with !important flags and IE6 float fixes. Messy and fragile at the same time. Stu Robson’s ReliCSS works like a front-end archaeologist, digging through your files for the parts that belong in a museum.
What a ReliCSS CSS audit finds: fossils and artifacts
ReliCSS sorts what it finds into three severity levels, based on whether native CSS can now do the same job. The output tells you how much debt is sitting in the file and lets you prioritize the refactor instead of guessing.
- High severity is the fossil layer: hacks for dead browsers like IE6 and IE7. Any
*htmlselector or_propertyhack is dead weight, so those go first. - Medium severity covers the IE8 to IE10 workarounds. They may still work, but they break easily, and a modern theme should be using flexbox or grid there instead.
- Low severity is mostly stale vendor prefixes such as
-webkit-and-moz-. Harmless enough, though Autoprefixer should be adding those at build time rather than you keeping them in source.
For how that weight shows up in load times, I went into it in Modern CSS: Beyond the JavaScript Bloat in 2025.
Example: replacing the checkbox hack
For years we used the checkbox hack for mobile menus and toggles. Clever, and still a hack. A ReliCSS CSS audit flags it now that the :has() selector exists. The difference in complexity is easy to see.
/* The Naive Fossil Approach */
.nav-toggle:checked ~ .menu {
display: block;
}
/* The Modern Solution using :has() */
body:has(.nav-toggle:checked) .menu {
display: block;
}The second version is shorter and says what it means. The MDN Web Docs for :has() cover how the selector behaves, and the ReliCSS tool is where you run your own dig.
If a ReliCSS CSS audit on your site is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days and I know which parts of a stylesheet to pull out first.
Audit before you refactor
A few extra kilobytes of CSS look harmless, but the browser still parses and computes the whole tree. Cleaning the stylesheet is real WordPress performance work. Run the audit, then decide what to delete.
