One of the issues with thoroughly cataloguing all of the css selectors in a page is the fact that they may not be immediately obvious from the page source alone, since javascript can execute and change the selectors in the DOM. Currently, to address this, we query the DOM's selectors with Javascript well after the dom has loaded and save them to be used later. However, this only somewhat addresses the issue.
Page selectors can be altered not only during the initial rendering of the page, but upon a user interaction as well. At this point, it doesn't seem like it's a good idea to purge everything while trying to take into account the multitude of ways JS can add, remove or alter selectors that may be in our CSS.
We can potentially keep going down this rabbit hole of ever more complex JS execution and page rendering, and simply add listeners for DOM changes and save whenever we need to, but maybe there is a simpler way that still meets our goal.
What if we didn't bother considering javascript, and only dealt with the page source? Obviously, the downside to this is that we're opening the door to over-purging our CSS from dynamically appearing selectors. However we may be able to get around that. Ultimately, the goal is faster page rendering, by splitting the most critical CSS in priority chunks while not removing any CSS that will be used at any point. So let's do just that. Instead of removing CSS that we did not find a use for, let's load it last. I imagine that the amount of selectors not caught in the initial page source wouldn't be too significant for most web pages and so loading the remaining CSS even after the DOM has fully rendered, via JS, may not cause much of an issue with most web pages.
One of the issues with thoroughly cataloguing all of the css selectors in a page is the fact that they may not be immediately obvious from the page source alone, since javascript can execute and change the selectors in the DOM. Currently, to address this, we query the DOM's selectors with Javascript well after the dom has loaded and save them to be used later. However, this only somewhat addresses the issue.
Page selectors can be altered not only during the initial rendering of the page, but upon a user interaction as well. At this point, it doesn't seem like it's a good idea to purge everything while trying to take into account the multitude of ways JS can add, remove or alter selectors that may be in our CSS.
We can potentially keep going down this rabbit hole of ever more complex JS execution and page rendering, and simply add listeners for DOM changes and save whenever we need to, but maybe there is a simpler way that still meets our goal.
What if we didn't bother considering javascript, and only dealt with the page source? Obviously, the downside to this is that we're opening the door to over-purging our CSS from dynamically appearing selectors. However we may be able to get around that. Ultimately, the goal is faster page rendering, by splitting the most critical CSS in priority chunks while not removing any CSS that will be used at any point. So let's do just that. Instead of removing CSS that we did not find a use for, let's load it last. I imagine that the amount of selectors not caught in the initial page source wouldn't be too significant for most web pages and so loading the remaining CSS even after the DOM has fully rendered, via JS, may not cause much of an issue with most web pages.