I am interested in implementing uncss in the cli with npm packages (no gulp/grunt) to strip out reams of unused code from parent themes.

There is a tutorial from 2015 but there is an open issue and no updates so I don't want to waste my time trying a broken approach.

Does anyone currently implement this feature? I currently handle image compression, concatenation, minifying and others with npm packages and would like to add this ability.

The use case is a quick turnaround of premade themes that have a small amount of customisation and are highly optimised for speed.

The idea is to use the task on a parent theme, on any code not written by me. In the child theme dequeue the targeted parent themes stylesheets and enqueue the new lean resources.

I would love to hear your thoughts on this subject, I am keen to explore all opportunities for optimisation but would like something I can run off the command line with my other tasks.


  • For those interested in a manual solution, Chrome inspector now has the 'coverage' feature that records your interactions and determines the unused CSS. If you open a source file and you use persistent authoring you can manually delete the unused css. I'm looking for a more automated solution...
    – JPB
    Jul 10, 2017 at 5:03

1 Answer 1


It is unlikely to ever work in a dynamic enviroment like wordpress, where css rules might be applied based on changes in the content. For example addition of a widget, aligning an image, etc.

(that said, I wish wordpress themes would stop cramming 1M of CSS rules into one file instead of breaking it up and load on a need base)

  • Chrome Inspector's new 'coverage' feature is interesting, as it records your interactions but unfortunately there is no option to strip out the unused css from the source css. I do think it may still be possible to a certain extent, but more with the intention of limiting the amount of customisation that can be applied by the user after delivery. The other part of the implementation would be conditional style sheets for each page (template).
    – JPB
    Jul 10, 2017 at 4:55
  • 1
    if you can limit what is used.... but realistically this is likely to end with unexplained bugs which are harder to figure out (why is X styled bad? is it a bug or do I need to run the tool again with the new content in mind?) frankly I usually say f**k the google insight which might be valuable when you control all parts of development and deployment, but in the context of wordpress are many times just a destruction, especially since most wordpress sites are not even close to have any real life benefit from this kind of optimization. Jul 10, 2017 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.