facebook / facebook/docusaurus
Docusaurus bundle size heavily impacted by number of routes & source path length
- Dominant language
- TypeScript
- Stars
- 66.2k
- Forks
- 10k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 52
Description
### Have you read the Contributing Guidelines on issues?
- [X] I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#reporting-new-issues).
### Prerequisites
- [X] I'm using the latest version of Docusaurus.
- [ ] I have tried the `npm run clear` or `yarn clear` command.
- [ ] I have tried `rm -rf node_modules yarn.lock package-lock.json` and re-installing packages.
- [ ] I have tried creating a repro with https://new.docusaurus.io.
- [ ] I have read the console error message carefully (if applicable).
### Description
**[Discussion from the Docusaurus Discord server](https://discord.com/channels/398180168688074762/867060369087922187/969108175548723230)**
tl;dr The number of routes/pages is directly impacting the bundle size of a Docusaurus build and it seems there are opportunities to further optimize this.
I unfortunately can't share my project/output here, but I am running into an issue where my site with ~4k pages is very slow on initial site load. After initial investigation, I found that the bundled main.xxxx.js file was (~10mb) and was littered with strings of the file paths for all the pages in our project (e.g. `/docs/path/to/file.md`). One optimization we made was to dump all markdown files into `/docs` and rely on slugs in order to shorten the length of the path string (e.g. `/docs/path/to/file.md` to `/docs/file.md`). This reduced it down to ~4mb but this is still too large. Ideally the number of routes/paths wouldn't be a bottleneck to the framework.
@Josh-Cena mentioned a possible optimization to split up registry.js/routesChunkNames.json into multiple JSON files and lazy load each only when on the path
### Reproducible demo
_No response_
### Steps to reproduce
1. Create a project with a large amount of routes/pages in the order of thousands.
2. Do a production build.
3. Look at the built main.xxxx.js under `build/assets/js` directory
4. Note the binary size (for me was a couple mb's) and that the file is littered with the file paths of the markdown files
5. Serve the build and note that it takes a long time to load the page initially due to this large main.xxxx.js
### Expected behavior
Expect the site to load quickly regardless of the number of pages
### Actual behavior
The initial load of the site is hindered by this large main.xxxx.js
### Your environment
_No response_
### Self-service
- [ ] I'd be willing to fix this bug myself.
Contributor guide
Assessment
This issue has not been assessed yet.