perf: load default preset in startup #1691
Conversation
The default preset is a widely relied on, especially by frameworks (e.g. nuxt). Currently, this means the hot path will have to `require` the preset and _block until resolution finishes_. If we load the default preset up front, it means the call to cssnano will actually run much faster. This does mean initial load is likely technically slower, but the gain of the call performance seems to outweigh this.
|
I am not sure I understand. Did you notice that requiring the default preset noticeably affect the Nuxt compilation process. How many time is cssnano called during compilation? Intuitively it feels to me the difference would be negligible. |
|
The difference is that the module resolution will happen during startup when we initially import cssnano etc That means it can be happening long before we actually call cssnano. Whereas currently, we require the module once we call it, which means we will block until the module has been resolved etc It seems to be quicker this way even though we are still loading the module (but much earlier and not blocking the function call) |
Did you measure that it is quicker? |
|
the reason i discovered it was because i was digging through cpu profiles of a nuxt build. so yes, in the run i was profiling, it was faster mostly seemed to be because the module resolution happened at the start, rather than blocking the cssnano call later on this would be a small bump in perf though so if you don't feel it makes sense, let me know and we can close this |
As long as you've verified that it works, I think we can merge it as it is unlikely to break something. |
The default preset is a widely relied on, especially by frameworks (e.g. nuxt).
Currently, this means the hot path will have to
requirethe preset and block until resolution finishes.If we load the default preset up front, it means the call to cssnano doesn't need to do this and will actually run faster.
This does mean initial load is likely technically slower, but the gain of the call performance seems to outweigh this.
of course this is a balance. if you don't want the cost of resolving one more module (for all users), feel free to close this. though i suspect most consumers are loading the default already