facebook / facebook/docusaurus

Docusaurus bundle size heavily impacted by number of routes & source path length

Open
#7,256 15 comments 9 reactions 0 assignees View on GitHub
better engineering domain: performance
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.