You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is part of the Docusaurus Faster project aiming at reducing production build times
Motivation
LightningCSS is built in Rust and a much faster alternative to many tools we use today: PostCSS, cssnano...
I don't expect CSS minification to be a major bottleneck in terms of build time, but as part of adding Rspack support it will become even faster by using Rust tooling for the whole CSS chain, using a built-in lightningCSS integration.
Also, I'm adding this option so that users can turn LightningCSS on independently from Rspack. It's possible that depending on feedback we'll activate Lightning CSS as a default minimizer on the next major version, and yet keep Rspack experimental, so it's worth having the option to collect feedback because this change can have subtle CSS side effects.
I also think our legacy Css Nano preset is way too complex and we should move back to a simpler targets / browserslist-based setup.
Replacing NanoCSS + CleanCSS with LightningCSS had the following impact:
No visual change detected by Argos
CSS bundle increase from 103Kb to 119Kb (+6Kb)
From manual analysis of the before/after CSS bundle, this increase is notably due to our former setup that "re-organize" the CSS file and try to factorize common repeated rules under shared selectors.
Although it decreases a bit the file size, it also changes the order of the CSS and is less predictable and could cause side effects (in our case apparently it hasn't been a problem though).
We may restore these CleanCSS optimizations later but for now I'd like to use LightningCSS directly so that we can later only use Rust tooling and remove all the slower JS tools from our pipeline.
+6Kb seems acceptable, and devs that really want to keep it can use the clean-css-cli on top of the already-built website.
For reference here are the options we currently use:
ArgosAdd this label to run UI visual regression tests. See argos.yml GH action.CLA SignedSigned Facebook CLApr: new featureThis PR adds a new API or behavior.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docusaurus Faster
This PR is part of the Docusaurus Faster project aiming at reducing production build times
Motivation
LightningCSS is built in Rust and a much faster alternative to many tools we use today: PostCSS, cssnano...
I don't expect CSS minification to be a major bottleneck in terms of build time, but as part of adding Rspack support it will become even faster by using Rust tooling for the whole CSS chain, using a built-in lightningCSS integration.
Also, I'm adding this option so that users can turn LightningCSS on independently from Rspack. It's possible that depending on feedback we'll activate Lightning CSS as a default minimizer on the next major version, and yet keep Rspack experimental, so it's worth having the option to collect feedback because this change can have subtle CSS side effects.
I also think our legacy Css Nano preset is way too complex and we should move back to a simpler targets / browserslist-based setup.
Test Plan
CI + Argos
Test links
https://deploy-preview-10522--docusaurus-2.netlify.app/
CSS impact analysis
Replacing NanoCSS + CleanCSS with LightningCSS had the following impact:
From manual analysis of the before/after CSS bundle, this increase is notably due to our former setup that "re-organize" the CSS file and try to factorize common repeated rules under shared selectors.
See the before/after files here: https://gist.github.com/slorber/2cea4d3fc8d6e0b50dcebdc58596d514
CleanCSS has level 2 optimizations that can "restructure" the CSS so that it takes less space
For example it will extract duplicate rules and create a shared declaration at the top:
Although it decreases a bit the file size, it also changes the order of the CSS and is less predictable and could cause side effects (in our case apparently it hasn't been a problem though).
We may restore these CleanCSS optimizations later but for now I'd like to use LightningCSS directly so that we can later only use Rust tooling and remove all the slower JS tools from our pipeline.
+6Kb seems acceptable, and devs that really want to keep it can use the clean-css-cli on top of the already-built website.
For reference here are the options we currently use: