Disable SSR Config Option

[trevor-moore-dev]

Is there any objection to providing a cli/config option for disabling SSR? I think it could come in handy for certain use-cases, namely, for internal documentation apps (where SSR isn't a necessity), since rendering all the pages consumes a significant amount of time (and memory).

Rspress provides such an option: https://rspress.dev/guide/basic/ssg#disabling-ssg

Obviously doing SSR is advantageous, but if someone isn't really concerned with web core vitals and other SEO benefits, all it adds is additional build time, and I figure there'd be no harm in making this configurable?

[slorber]

@trevor-moore-dev we have implemented something similar called Hash Router to build your docs for offline distribution, that you can browse simply by clicking a file:///my-website/index.html file on your FS.

It doesn't do SSG, and only renders on the client, so will build faster. However, the SSG phase of your site is likely not the most expensive part of your build: it's usually the bundling phase, that still needs to happen.

Related: I'm in the process of optimizing the SSG phase (#10826), I would be curious to know how long SSG takes for your site, and if possible benchmark against it to see the impact.

(you can see perf log times for each major step with DOCUSAURUS_PERF_LOGGER=true yarn build)

[trevor-moore-dev]

Thanks for the info, I tried out Hash Router but quickly realized that SSR is necessary for @easyops-cn/docusaurus-search-local. So regardless of using hash or browser router, that wouldn't be an option for us, as I'm assuming most search crawlers (probably Algolia too?) would require HTML to be populated for indexing.

I'll try out setting DOCUSAURUS_PERF_LOGGER=true and get back to you, after [email protected] already we've seen a definite improvement, though I haven't benchmarked anything yet. And speaking of performance optimizations, do you know when persistent caching will be available to re-enable on CI servers? Asking since I saw that Rspack v1.2 was released a couple days ago and got excited!

Lastly, I wanted to thank you for how responsive and helpful you've been, it's definitely very appreciated! Very thankful for all the work you do. Maybe someday I'll get around to contributing over the weekends or something instead of just asking for things 😁

[slorber]

Afaik Algolia has support for client-side rendering crawling: https://docsearch.algolia.com/docs/legacy/config-file/#javascript-rendering

Docusaurus local search plugins are likely to crawl the SSG HTML files written to disk, so if you don't write those, they won't work.

You can still build your own search plugin that spawns in plugin.postBuild() a temporary HTTP server and a local crawler that executes JS, but that might be slower than SSG, and it's your responsibility to make it work 😅. Looks complicated.

Re-enabling Rspack persistent caching should be in v3.8 if it works well. Last time I tried it didn't, will try again soon. (#10823)

No problem and thank you 🤗

[trevor-moore-dev]

@slorber here's the output when running DOCUSAURUS_PERF_LOGGER=true npm run build on my work machine which has a 12-core CPU and 36 GB RAM:

[PERF] Build - 197.61 seconds! - (53mb -> 1488mb)
[INFO] Use `npm run serve` command to test your build locally.

We're currently using [email protected] and we've enabled experimental_faster: true. Our GitHub Actions Runner isn't as robust as my machine (4-core CPU and 16 GB RAM), and build times take around twice as much or more (would have to set DOCUSAURUS_PERF_LOGGER=true to see specifically how much longer it takes).