Removing extra CSS on a WordPress site

[maryam2022]

I want to remove the extra CSS that is not used <snip> to increase the speed of the site
Is it possible to do this automatically?

<snip>

[edited by: not2easy at 12:30 pm (utc) on Jul 19, 2022]
[edit reason] Please see TOS [webmasterworld.com] [/edit]

[not2easy]

Hi maryam2022 and welcome to WebmasterWorld [webmasterworld.com]

The CSS in a WP site is created with the theme to cover every feature of the CSS that might ever be used. So you would need to first ensure that you will never use the features that you remove and nothing can do that automatically.

You can optimize the CSS by using compression but the speed gain is not significant unless it was poorly created. You would do better to work on caching, image optimization and avoiding unnecessary plugins.

[akeniali]

This tecnique is called "Unused CSS", more info: [web.dev...]

There are WordPress plugins able to do it "automagically", for example Perfmatters and WP Rocket. Only used CSS are initially loaded (inline or in a separate CSS file). Unused CSS can be simply unloaded or delayed until user interaction.

[not2easy]

The Lighthouse tools are good, but you would need to check on every variation of the WP pages and posts because the CSS for /archive/ or /tag/ or /category/ files is not usually the same as for your home page. Those variations usually have elements that would be listed as "unused" but if those were removed, it could leave pages using whatever default is inherited. To save 6kb it is not worth it for most designs.

[akeniali]

Good points, not2easy. I agree, every CSS variation has to be manually tested. Those WP plugins I mentioned creates a unique used-css-profile for each type of page: home, post, archive, tag. Every single "page page” has its own used-css-profile, and it makes sense considering that pages tends to be more unique. Those WP plugins allow to manually adding stylesheets and selectors to the generated used CSS, in case the automation doesn't include something needed.

Also consider that the “unused” can be just delayed instead of removed. It should be a parachute for the risks you refer to. Delay until user interaction (or timeout) it's enough to have assets lazy loading, so a faster page.

You're right, 6kb is not worth. Anyway if you take a look at the amount of unoptimized CSS loaded by modern super-template with Elementor inside, you often see we're more on the 600kb side :)

[TorontoBoy]

The last time I looked, Gutenberg adds in a whole crapload of unnecessary CSS. Try turning off the Gutenberg editor and use the Classic Editor, if possible. Then take a look at the results.

Of course this will not work if you use the Gutenberg editor.

[tangor]

Today's net speeds make simple css (bloated) fly like an eagle. Unless you know what you are doing, and WHY this particular piece of that CSS can be removed, turn your efforts to the real speed optimizations of images, third party, and plugins.

Also bear in mind, any upgrade to WP will likely restore all that you removed and you just have to do it all over again.

Secondary note: ALWAYS update WP for security reasons!

[lucy24]

In the specific case of WordPress, the problem is not with individual lines of CSS not being needed. It’s the sheer, over-the-top number of separate style sheets, all of which have to be requested one by one. And we're not talking two or three or four; there can be dozens. (I gave up counting the day I found 31.) The number of requests can be far more time-consuming than the size of each individual one.

This is, analogously, why sprites are recommended for some types of image. The total amount of information is the same; the number of server requests goes way down.

[akeniali]

lucy24 all true, but bloat mainly depends on the theme more than WordPress itself.

[lucy24]

Well, it's the same thing. Each theme means at least one more stylesheet. And once you're getting the stylesheet, it doesn't much matter how big it is.

[ronin]

Today's net speeds make simple css (bloated) fly like an eagle

I think in some contexts, this sentiment is absolutely right - don't worry about things that won't make a difference anyway.

But I also think the web isn't so fast universally, that there aren't significant - and sometimes substantial - gains to be made by chopping off as much of the dead wood as possible, so @maryam2022 is pursuing (I think) an entirely reasonable approach here.

Two points:

1) It's worth remembering that it's the World Wide Web, not the Western Wealthy Web (or whatever the term is). Bearing this in mind has local as well as remote benefits - if we aim to write websites that work speedily on laptop connections in the developing world, that also means, they will work speedily on a mobile handset when there's a fraction of a 3G signal halfway up a mountain two hours from a town that's accustomed to 5G connectivity.

2) I try to get my pages downloading to the point of DOMContentLoaded (on my usual laptop setup) in less than 0.3s. If the page download time is consistently above that, I'll go through various audits to see what I can speed up / chop out etc.

One of the techniques I came across last year, which worked very effectively, was to split my main CSS file into two files and async the secondary CSS so that it still downloads (usually within 0.8s to 1.1s), but it doesn't render-block the DOM while it's downloading.

The benefit of this approach is that I still get to keep all of my CSS, but the initial CSS render-block is reduced to as brief a hiccup as possible.

[not2easy]

As someone who feels good to see 3Mb in download speed I agree and have split my css between layout and top of the screen in one file and the rest in a second file for several years now - it helps.

[akeniali]

Two points:

1) It's worth remembering that it's the World Wide Web, not the Western Wealthy Web (or whatever the term is). Bearing this in mind has local as well as remote benefits - if we aim to write websites that work speedily on laptop connections in the developing world, that also means, they will work speedily on a mobile handset when there's a fraction of a 3G signal halfway up a mountain two hours from a town that's accustomed to 5G connectivity.

2) I try to get my pages downloading to the point of DOMContentLoaded (on my usual laptop setup) in less than 0.3s. If the page download time is consistently above that, I'll go through various audits to see what I can speed up / chop out etc.

Those are great points.

There is a good reason why PageSpeed Insight [pagespeed.web.dev ] mobile is considered the benchmark in the speed specialists' community, as it simulate loading using a smartphone and slow connection. It is under these conditions that many people around the world use the Internet. “This site loads fast on my computer, so it's fast” is a naive statement, to say the least.

[lucy24]

<topic drift>
It also helps to hang on to elderly devices, like a first-generation iPad *, or the smartphone that your carrier will no longer support. Check periodically to ensure that your site will display and function adequately on something other than your brand-new desktop.

Seriously, though, I wouldn't look to the size (as opposed to number) of stylesheets as a significant problem. Look instead to things like images: not simply their displayed size, but the downloaded filesize. If something isn't meant to display at all on smaller viewports, make sure it isn't downloaded in the first place.


* Mine grew increasingly prone to crash when doing anything that involves going online. But it continues to have no trouble with my own sites.
</td>