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 introduces a new Docusaurus Faster option: siteConfig.future.experimental_faster.ssgWorkerThreads.
It permits you to optimize the static site generation phase of your site, by executing SSG tasks in a worker thread pool.
This enables you to distribute load across your computer CPUs more evenly, and can greatly decrease SSG time for larger sites. It is particularly impactful on large sites, and sites using features that produce many pages (tags, blog pagination, blog authors pages).
Note: we recommend you try to turn all v4 future flags on globally: future.v4: true. This opt-in for upcoming v4 breaking changes and prepare your site for it.
Using a thread pool to distribute the SSG load over multiple workers can significantly improve the SSG execution time. According to my local tests (Mac M3 Pro), SSG can be divided by ~2 and probably more if there are many pathnames to render.
On our site, SSG goes from 12 seconds to 6 seconds (executing yarn build:website --locale en), which reduces the total build time by ~6 seconds using the default thread pool settings:
hyperfine --runs 3 \
'DOCUSAURUS_SSG_WORKER_THREAD_COUNT=1 yarn build:website --locale en' \
'yarn build:website --locale en'
Benchmark 1: DOCUSAURUS_SSG_WORKER_THREAD_COUNT=1 yarn build:website --locale en
Time (mean ± σ): 44.025 s ± 0.111 s [User: 101.346 s, System: 19.927 s]
Range (min … max): 43.919 s … 44.141 s 3 runs
Benchmark 2: yarn build:website --locale en
Time (mean ± σ): 38.447 s ± 1.321 s [User: 124.407 s, System: 23.509 s]
Range (min … max): 37.042 s … 39.665 s 3 runs
Summary
yarn build:website --locale en ran
1.15 ± 0.04 times faster than DOCUSAURUS_SSG_WORKER_THREAD_COUNT=1 yarn build:website --locale en
This build benchmark only reports a 15% improvement because SSG is only a part of the full Docusaurus build. The SSG time went from 12s to 6s locally so it remains significant for that particular phase (50% improvement). For sites with thousands of pages, the impact can be even more significant. Once we activate Rspack persistent caching (faster rebuilds), saving 50% of SSG time will be much more important to have super fast site rebuilds.
Fine-tuning
Providing sensible defaults for the worker thread pool config is difficult. We'll improve the current defaults according to early adopter's feedback.
There are env variables that you can use to adjust settings:
DOCUSAURUS_SSG_WORKER_THREAD_COUNT: number of threads (default to CPU count)
DOCUSAURUS_SSG_WORKER_THREAD_TASK_SIZE: number of pathnames to render per worker task submission (default=10)
Note: these variables are implementation details. We may refactor/rename them in minor versions. Eventually, we'll expose a public API for fine-tuning thread pool configuration.
Using DOCUSAURUS_SSG_WORKER_THREAD_COUNT=1 permits to not use worker threads: SSG will be executed in the current main thread (historical SSG behavior of Docusaurus).
We recommend you benchmark with various settings, find out what works best for you, and report your results to the community here. Note that settings that work better for you locally might not be the best when running on your CI / CDN build.
Example benchmark you can try locally using hyperfine:
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.pr: performanceThis PR does not add a new behavior, but existing behaviors will be more memory- / time-efficient.
4 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.
Motivation
This PR introduces a new Docusaurus Faster option:
siteConfig.future.experimental_faster.ssgWorkerThreads
.It permits you to optimize the static site generation phase of your site, by executing SSG tasks in a worker thread pool.
This enables you to distribute load across your computer CPUs more evenly, and can greatly decrease SSG time for larger sites. It is particularly impactful on large sites, and sites using features that produce many pages (tags, blog pagination, blog authors pages).
To use this option, the v4 future flag
siteConfig.future.v4.removeLegacyPostBuildHeadAttribute
must be turned on.Note: we recommend you try to turn all v4 future flags on globally:
future.v4: true
. This opt-in for upcoming v4 breaking changes and prepare your site for it.If possible, use the following config:
Benchmark
Using a thread pool to distribute the SSG load over multiple workers can significantly improve the SSG execution time. According to my local tests (Mac M3 Pro), SSG can be divided by ~2 and probably more if there are many pathnames to render.
On our site, SSG goes from 12 seconds to 6 seconds (executing
yarn build:website --locale en
), which reduces the total build time by ~6 seconds using the default thread pool settings:This build benchmark only reports a 15% improvement because SSG is only a part of the full Docusaurus build. The SSG time went from 12s to 6s locally so it remains significant for that particular phase (50% improvement). For sites with thousands of pages, the impact can be even more significant. Once we activate Rspack persistent caching (faster rebuilds), saving 50% of SSG time will be much more important to have super fast site rebuilds.
Fine-tuning
Providing sensible defaults for the worker thread pool config is difficult. We'll improve the current defaults according to early adopter's feedback.
There are env variables that you can use to adjust settings:
Note: these variables are implementation details. We may refactor/rename them in minor versions. Eventually, we'll expose a public API for fine-tuning thread pool configuration.
Using
DOCUSAURUS_SSG_WORKER_THREAD_COUNT=1
permits to not use worker threads: SSG will be executed in the current main thread (historical SSG behavior of Docusaurus).We recommend you benchmark with various settings, find out what works best for you, and report your results to the community here. Note that settings that work better for you locally might not be the best when running on your CI / CDN build.
Example benchmark you can try locally using hyperfine:
Test Plan
CI + dogfood + Argos
Test links
https://deploy-preview-10826--docusaurus-2.netlify.app/
Related issues/PRs
Follow up of:
postBuild({routesBuildMetadata})
API, deprecatehead
attribute + v4 future flag #10850Also the expected next step for Docusaurus Faster: #10556