RangeError: Invalid string length when building with a very large number of blogs about docusaurus

[slorber]

A 30k blog post? 🤯 why do you have so many?

Yes, it seems like we should not use JSON.stringify but instead use a serialization lib supporting streaming.

For example https://github.com/dominictarr/JSONStream#jsonstreamstringifyopen-sep-close

---

Note to myself: I'll probably take this opportunity to encapsulate this streaming, and expose simpler, more testable interfaces to create route data bundles because I'm not a fan of our historic plugin actions API for that:

// Create a blog archive route
const archiveProp = await createData(
  `${docuHash(archiveUrl)}.json`,
  JSON.stringify({blogPosts: listedBlogPosts}, null, 2),
);
addRoute({
  path: archiveUrl,
  component: blogArchiveComponent,
  exact: true,
  modules: {
  archive: aliasedSource(archiveProp),
  },
});

That would be more convenient to have everything handled for you, and just write:

addRoute({
  path: archiveUrl,
  component: blogArchiveComponent,
  exact: true,
  props: {
    archive: {blogPosts: listedBlogPosts},
  },
});

Note we'd still need to keep a way to create data bundles independent from routes (+ streaming support), because those data bundles can be shared between routes, reducing the amount of data to load when navigating from one route to another. (although this data could probably be added as a routeContext)

[slorber]

https://mesghalapp.com/en/news/archive/

To be honest I don't think Docusaurus is designed to support that kind of scale. It seems you have 2k entries just for 2024, and if it keeps growing at the same pace the build time will quickly become unsustainable.

You'd rather use a docs framework that supports server-side-rendering.

Note that the blog archive page can be disabled with option archiveBasePath: null, so it might unlock you temporary:
https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog#archiveBasePath

But even with that solution, I doubt Docusaurus will be the best choice for your need.

[slorber]

I'm interested in improving the build performance

You are lucky because I'm actively working on Docusaurus performance issues right now.

The upcoming v3.2 release will be faster and have some basic perf logging that you can turn on with DOCUSAURUS_PERF_LOGGER=true (internal usage, not publicly documented for now). You can try using the latest canary to benefit from these improvements. Afaik canary doesn't have yet any breaking change from v3 so it should be fine.

However, it does not fix all the problems yet, and the main unfixed bottleneck remains bundling your app with Webpack for both client consumption and SSR. Also, the bundle we assemble for server/node usage is historically a huge single JS file, that causes memory issues during the SSG phase.

Yes the build process can be improved, but this is likely quite technical and I'd prefer it to handle it myself. Most likely we will try to swap Webpack by Rspack soon and provide a flag to enable Rspack to provider an incremental migration path. But Rspack is not yet 100% retrocompatible with Webpack so it might not even work right now.

[ardavank]

@slorber thanks for looking into this issue, I'm replacing Wordpress with Docusaurus and I'm migrating an existing news website. The reason for this is the simplicity, speed and the low maintenance cost of Docusaurus!

You can see it in action: https://mesghalapp.com/en/news

Currently I have two blockers:
1- Is the issue with the JSON.stringify
2- The 26mb file limit of Cloudflare

The screenshot above is for including only ~2K blogs
The JSON.stringify({blogPosts: listedBlogPosts} creates a massive file especially when the blogs are written in other languages that need to be encoded as well.

is possible to split this file into smaller files as well?

[ardavank]

@slorber thanks for info, currently I'm only keeping the news for 3 months by deleting the older ones to manage this limitation.
I feel like the build process can be improved, can you please guide me on how to debug the build and get more performance log for each step of the progress?
I'm interested in improving the build performance

[ardavank]

@slorber
I tried version 0.0.0-5861, and here are the results:

> [email protected] build
> docusaurus build --locale en --out-dir build/en

[PERF] Get locales to build: 0.197ms
[INFO] [en] Creating an optimized production build...
[PERF] Load - loadContext: 149.412ms
[PERF] Plugins - initPlugins: 123.724ms
[PERF] Plugin - loadContent - docusaurus-plugin-sitemap@default: 0.609ms
[PERF] Plugin - loadContent - docusaurus-plugin-google-gtag@default: 0.646ms
[PERF] Plugin - loadContent - docusaurus-bootstrap-plugin@default: 0.703ms
[PERF] Plugin - loadContent - docusaurus-mdx-fallback-plugin@default: 0.865ms
[PERF] Plugin - loadContent - docusaurus-theme-classic@default: 22.973ms
[PERF] Plugin - loadContent - docusaurus-plugin-content-pages@default: 110.539ms
[PERF] Plugin - loadContent - docusaurus-plugin-content-blog@default: 1.233s
[PERF] Plugins - loadContent: 1.234s
[PERF] Plugins - contentLoaded - docusaurus-plugin-sitemap@default: 0.081ms
[PERF] Plugins - contentLoaded - docusaurus-theme-classic@default: 0.13ms
[PERF] Plugins - contentLoaded - docusaurus-bootstrap-plugin@default: 0.207ms
[PERF] Plugins - contentLoaded - docusaurus-mdx-fallback-plugin@default: 0.254ms
[PERF] Plugins - contentLoaded - docusaurus-plugin-google-gtag@default: 1.55ms
[PERF] Plugins - contentLoaded - docusaurus-plugin-content-pages@default: 3.212ms
[PERF] Plugins - contentLoaded - docusaurus-plugin-content-blog@default: 803.121ms
[PERF] Plugins - contentLoaded: 814.188ms
[PERF] Plugins - allContentLoaded - docusaurus-plugin-content-blog@default: 0.085ms
[PERF] Plugins - allContentLoaded - docusaurus-plugin-content-pages@default: 0.089ms
[PERF] Plugins - allContentLoaded - docusaurus-plugin-sitemap@default: 0.115ms
[PERF] Plugins - allContentLoaded - docusaurus-theme-classic@default: 0.134ms
[PERF] Plugins - allContentLoaded - docusaurus-plugin-google-gtag@default: 0.152ms
[PERF] Plugins - allContentLoaded - docusaurus-bootstrap-plugin@default: 0.168ms
[PERF] Plugins - allContentLoaded - docusaurus-mdx-fallback-plugin@default: 0.185ms
[PERF] Plugins - allContentLoaded: 1.043ms
[PERF] Plugins - loadPlugins: 2.176s
[PERF] Load - loadPlugins: 2.176s
[PERF] Load - loadSiteMetadata: 0.478ms
[PERF] Load - loadCodeTranslations: 1.057ms
[PERF] Load - createSiteFiles: 195.6ms
[PERF] Loading site: 2.529s
[PERF] Creating webpack configs: 334.828ms
[PERF] Deleting previous client manifest: 0.569ms

✔ Client
  Compiled successfully in 5.21m

✔ Server
  


● Client █████████████████████████ cache (99%) shutdown IdleFileCachePlugin
 stored

✔ Server
  

[PERF] Bundling: 5:21.375 (m:ss.mmm)
[PERF] Reading client manifest: 17.088ms
[PERF] Compiling SSR template: 1.507ms
SSG - Load server bundle
[PERF] SSG - Load server bundle: 44.964ms
[PERF] SSG - Server bundle size = 29.351 MB
[PERF] SSG - Evaluate server bundle: 842.003ms
[PERF] Loading App renderer: 887.578ms
[PERF] Generate static files: 1:55.173 (m:ss.mmm)
[PERF] Executing static site generation: 1:56.080 (m:ss.mmm)
[PERF] Deleting server bundle: 2.146ms
[PERF] Executing postBuild(): 215.985ms
[PERF] Executing broken links checker: 809.84ms
[SUCCESS] Generated static files in "build/en".
[INFO] Use `npm run serve` command to test your build locally.

it looks like that Generate static files and Executing static site generation steps are taking ~4 minutes.
Is this expected?

[slorber]

It's more 2min than 4min, because the log is unclear but one ask is composed of another.

And yes that seems expected that rendering, minifying and wriing thousands of static files takes time.

For a blog, the number of pages to generate can grow quickly depending on your usage of tags and your pagination setting.

What takes the most time remains the bundling phase, which has not been optimized yet.