This is a problem I thought would be solved by 2017
UnCSS: Remove unused styles from CSS
41–50 of 50 posts
Re: UnCSS: Remove unused styles from CSS
#42Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly. It's such a hard problem to solve and the Stylesheet Snowball is one of the most frustrating pieces of technical debt a large site can pick up. It makes me wonder if scoped CSS modules, despite fundamentally breaking CSS with their hyper specific hyb…
> Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly.
The only way I can think to handle this is if you've got a really thorough test suite in Selenium or similar. Do a before and after, capture screengrabs of everything and flag up where the 'new' CSS has caused visual differences.
It's a horrible solution but then it's a horrible problem.
Re: UnCSS: Remove unused styles from CSS
#43I made a similar tool, although it doesn't load the page in a browser to remove unused styles.
Re: UnCSS: Remove unused styles from CSS
#44Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly. It's such a hard problem to solve and the Stylesheet Snowball is one of the most frustrating pieces of technical debt a large site can pick up. It makes me wonder if scoped CSS modules, despite fundamentally breaking CSS with their hyper specific hyb…
> Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly. The only way I can think to handle this is if you've got a really thorough test suite in Selenium or similar. Do a before and after, capture screengrabs of everything and flag up where the 'new' CSS has caused visual differences. It's a horrible so…
Alternatively, you could dump the DOM of each rendered test case and use that to construct a single document that has all the classes and ids that are in use in it and run UnCSS on that. Maybe. Not saying it will be easy (in particular rules which are about certain hierarchies might get hairy) but I think it's worth a shot.
Re: UnCSS: Remove unused styles from CSS
#45Earlier quoted context omitted.
> Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly. The only way I can think to handle this is if you've got a really thorough test suite in Selenium or similar. Do a before and after, capture screengrabs of everything and flag up where the 'new' CSS has caused visual differences. It's a horrible so…
Alternatively, you could dump the DOM of each rendered test case and use that to construct a single document that has all the classes and ids that are in use in it and run UnCSS on that. Maybe. Not saying it will be easy (in particular rules which are about certain hierarchies might get hairy) but I think it's worth a shot.
Huh, pulling it out the unit tests is a pretty good idea actually - if the test coverage is good enough it might be worth a bit of investigation.
Especially since it'd be an optional build step you'd only want to run infrequently.
Re: UnCSS: Remove unused styles from CSS
#46I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a smaller but different CSS file for each page you visit. My impression is that number of requests is a more critical optimization than file size (at least when serving CSS sized files)
Really depends. How big is the once CSS file you're loading and how much of the CSS is common from page to page? If 20kb is for a specific component on one or two, less-visited pages, then it probably doesn't make sense to lump everything together.
A fairly safe default starting point would be:
1. Tiny subset of inlined critical CSS (See https://www.smashingmagazine.com/2015/08/understanding-criti...) 2. Asynchronous + rel=preload loading of the main CSS of your site 3. Then, if there are hefty chunks of CSS for specific pages only, bring those in on those pages.
This changes a bit if you're using HTTP/2. Then the multiplexing makes it beneficial to break the CSS into a few smaller files instead of one big one.
In the end, you probably just have to experiment and test. :) No guaranteed "this is best" approach here.
Re: UnCSS: Remove unused styles from CSS
#47I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a smaller but different CSS file for each page you visit. My impression is that number of requests is a more critical optimization than file size (at least when serving CSS sized files)
caching is out of style nowadays, you lose precious user tracking, not to mention dynamic web. Its as bad as DNS TTL (some keep it at couple of minutes or lower).
Re: UnCSS: Remove unused styles from CSS
#48Have used tools like this before, and invariably end up accidentally stripping styles from an component with a dynamically assigned className or something equally silly. It's such a hard problem to solve and the Stylesheet Snowball is one of the most frustrating pieces of technical debt a large site can pick up. It makes me wonder if scoped CSS modules, despite fundamentally breaking CSS with their hyper specific hyb…
I agree, it's a hard problem. Perhaps run a test-suite with UnCSS? If you still accidentally strip styles then the test-suite is not complete.
Not a bad idea.
Re: UnCSS: Remove unused styles from CSS
#49I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a smaller but different CSS file for each page you visit. My impression is that number of requests is a more critical optimization than file size (at least when serving CSS sized files)
From what I've heard, the answer depends greatly on whether we're talking http 1 or 2
HTTP/2 is pretty much everywhere now, including virtually all mobile devices. So targeting HTTP2 is pretty sensible IMO.
Re: UnCSS: Remove unused styles from CSS
#50I've been hoping someone would write a similar tool, but using a browser, so that I could run a webapp, click around (using a checklist, to cover all of the views) and get a resulting list of used CSS rules from the browser. That would have the advantage of supporting complex webapps written in any language/environment.
There's a "Coverage Support" experiment in Chrome DevTools which does css + js coverage in a way you describe it. The CSS part was shown on Chrome DevSummit 2016 [1] [1] https://www.youtube.com/watch?v=HF1luRD4Qmk
Starts around the 18min mark in the video.