is there an issue to follow any work on this?
We've recently moved the Snap theme to sub-theme Boost, and this delay is somewhat annoying for developers.
Workarounds we've employed or things we've noticed:
* we have a grunt task that hits this url: joule2.dev/theme/styles.php/snap/-1/all, this starts the CSS regeneration process as soon as we hit save in our code editors so hopefully it is nearly done by the time we switch to the browser and refresh or load a new page
* we also spotted the tree post process call was taking up a lot of time. We were wanting to skip this in our child theme, but it seems if you set it to null in the child theme, it just uses the value from the parent theme (Boost). Even if you replace the call with a new function that does nothing, it still parses the full tree which is where the time is mostly spent. Hacking the Boost theme
* The time taken seemed to be proportional to the length of the total CSS. Our dev VMs have a whole lot of plugins installed and took an extra 10 seconds compared with a default Moodle install. We also found a few bits of the SCSS code that were using @extend and generating silly amounts of CSS code. We fixed the ones in Snap and also filed a bug upstream about uses of @extend in Boost: MDL-58930
* There are existing PHP extension Sass libraries on github that call the C lib to go faster, though it sounded like they only supported Apache