[WIP]: Use Rspack instead of Webpack #10402
Draft
+433
−175
Conversation
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
⚡️ Lighthouse report for the deploy preview of this PR
|
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Size Change: -133 kB (-1.15%) Total Size: 11.4 MB
ℹ️ View Unchanged
|
slorber
added
the
Argos
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
hardfist
reviewed
Aug 16, 2024
This was referenced Aug 19, 2024
|
Are you considering runtime sizes as well before proceeding with this migration ? It seems that the bundler community is solely focused on who's faster (farmfe/rspack/turbopack etc), while almost no attention is being paid to the actual runtime javascript sizes whatsoever. Even rspack's documentation is very vague on what it does exactly to reduce the code size compared to webpack 5. I'm posting the measured network size (Chrome devtools Network tab) for the preview link vs the main branch. I do realize that this PR is behind the main branch, so the numbers might vary when the PR is updated. But here is what I see: Rspack PoC (netlify URL)JS: 9 requests, 1.0 MB compressed, 2.7 MB uncompressed Webpack 5 (docusarus.io)JS: 10 requests, 981 KB compressed, 2.0 MB uncompressed If we assume that the "base" is the same, there is a ~716 KB (minified) diff between webpack and rspack. Feel free to adjust the numbers after a rebase, but this is definitely concerning. I appreciate the build time perf boost. It is quite important. But we must not forget that there is a lot more to performance than pure blind speed. I cannot see any concrete numbers or benchmarks around "runtime" sizes either. Most comparisons are based on webpack-bundle-analyzer, which is incorrect since the |
|
@tmpaul yes we obviously consider this, we even have a bot to warn us: And bundler authors as well This is why this PR is a draft POC, it's not ready to merge. We are already aware of that code splitting problem. Most likely we'll provide an experimental feature flag to turn Rspack on. |
Closed
3 tasks
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Disclaimer
For now, this is only a POC to see how complicated it would be to switch bundlers or provide an alternative bundler as an experimental flag. We also hope to measure possible performance improvements.
We don't have a real plan yet.
Motivation
Rspack is mostly retro-compatible with Webpack and the most suitable choice for Docusaurus in the short term (see also #4765 (comment))
This should improve bundling performance, the main bottleneck for many sites.
State
The current state of this PR:
yarn startworks for the Docusaurus website 🎉yarn buildworks for the Docusaurus website 🎉But we are not done, there are many details to handle before it becomes usable. For example, restoring the ChunkAssetPlugin)
Note: the Rspack team is willing to help us and most of the initial POC code is inspired by @hardfist patch on our init template here: hardfist/docusaurus-rspack#1
Performance
Approximate build time measurements taken on a local MacBook pro M3 on 14 August :
For
yarn build:website:fast:For
yarn build:website --locale en:Note: these measures involve running
yarn clear:websitefirst. Rspack does not support (yet) persistent caching like Webpack.Note: these results are not final, and ballpark estimates. They may change in the future.
Surprisingly, it seems to improve the SSG performance too. We'll have to figure out why, maybe the server output is more optimized.
Test Plan
CI
Test links
https://deploy-preview-10402--docusaurus-2.netlify.app/
Related issues/PRs
#4765