The docs build is constraint to master only so we'd have to merge this to see. Tried it locally, the first build is actually slower than before, the following one is about 3 times faster.

but it requires that you setup caching of node_modules/.cache across your CI builds

node_modules are cached based on the lock file, pretty much exactly as the GH docs suggests. But only in the tests workflow, not in the docs, so will replicate it there. I guess that regular node_modules caching should be fine? Or there is some special .cache folder I'd have to handle manually?

I guess I should rather wait for the actual release, as this would immediately generate renovate downgrade PR I think.

I'll update the PR after the release and we'll see 🤷🏻‍♂️

FYI the first build is actually slower.

Did you try to run "docusaurus clear" before? Webpack 4 used cache-loader which is somehow also some kind of caching, so you must compare comparable clean states :)
But it's true that the first build might be slower anyway, as Docusaurus has to write more content to the cache. It could become faster if we allow disabling that cache, but I don't think it will be significantly better.

Nope, just ran yarn build (so docusaurus build, or in fact node --max_old_space_size=16000 node_modules/@docusaurus/core/bin/docusaurus build which might no longer be needed if the major leak/perf issue is gone).

Will the perf benefit still be there if I change something in the source files (e.g. adjust some heading on one page)? If so, the first run perf is not really important.

Anyway, great that this is being addressed, at least partially (it still feels out of space to wait for minutes, even tho there are lots of pages).

I don't know about the memory leak but let me know if I should investigate this.

Will the perf benefit still be there if I change something in the source files (e.g. adjust some heading on one page)? If so, the first run perf is not really important.

Yes that's the point, minor doc changes should be significantly faster.
It's not very well documented but afaik it's also caching asset handling like ideal image resizes etc.

Anyway, great that this is being addressed, at least partially (it still feels out of space to wait for minutes, even tho there are lots of pages).

It has not been the main focus as we were not feature complete but I'll try to do my best to improve build times.

But I still strongly recommend moving older versions to standalone Jamstack deployments to avoid slowing down builds forever. See for example what I did on the Jest website for v < 25.x: https://jestjs.io/

I plan to write some kind of scalability doc soon.

ready, let me know if there are problems