💥 Proposal

Note to myself: before implementing that, let's add an artificially large sidebar to Docusaurus so that our build-size bot can measure the HTML page size and track regressions!

We have some sites that have extremely large sidebars (sometimes related to generated doc pages from code).

Rendering the same large sidebar, again and again, can lead to perf problems:

• increased server-side rendering build times
• increased static HTML pages

For example, Demisto reported the issue: demisto/content-docs#616 (comment)

They were able to remove 12min of build time, by simply not rendering the sidebar on the server at all, and only rendering it after React hydration:

import React from 'react';
import BrowserOnly from '@docusaurus/BrowserOnly';
import DocSidebar from '@theme-original/DocSidebar';

function DocSidebarBrowser(props) {
  return (
    <BrowserOnly fallback={<div>Sidebar...</div>}>
      {() => <DocSidebar {...props} />}
    </BrowserOnly>
  );
}

export default DocSidebarBrowser;

In my opinion, it is not a good solution:

• it produces layout shifts, as the sidebar magically appears in the browser after some delay (that can be significant on slow connections). Can be seen in https://xsoar.pan.dev/docs/reference/index
• it may affect SEO (even if Google can crawl JS), as crawlers need to run the JS code before being able to crawl related pages

Navigating from the homepage to a doc with a huge sidebar is also a slow experience, as the whole sidebar is currently rendered (even if it is fully collapsed), slowing down the navigation.

A possible solution is to have an option to optimize the sidebar by making it lazier:

• Collapsed category childrens do not need to be rendered on the server, as they are not visible
• We don't need to render them on the client immediately before the user click on the category to expand it