✔️ [V2]

🔨 Explore the source changes: d94cea5

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/60eeedef61ab790008082531

😎 Browse the preview: https://deploy-preview-5136--docusaurus-2.netlify.app

⚡️ Lighthouse report for the changes in this PR:

Lighthouse ran on https://deploy-preview-5136--docusaurus-2.netlify.app/

Size Change: -123 kB (-13%) 👏

Total Size: 850 kB

_{compressed-size-action}

This can have huge impact on sites with very large sidebars, and a good impact on smaller sites too!

Note some very large sites already use a trick to avoid rendering the sidebar on SSR and can save up to 12min build time!: demisto/content-docs#616 (comment)

function DocSidebarBrowser(props) {
  return (
    <BrowserOnly
      fallback={<div>Sidebar...</div>}>
      {() => {
        // Something that should be excluded during build process prerendering.
        return <DocSidebar {...props} />
      }}
    </BrowserOnly>
  );
}

I think current PR is a good compromise to avoid delaying the visibility of the sidebar and keep acceptable perfs. Obviously it will remain faster to simply not render the sidebar on the server.

@jdevalk may I ask you what you think about the potential SEO impacts of server-rendering only a subset of the full sidebar?

The risk is that search engines won't follow the links in the parts of the sidebar that aren't rendered immediately. So pages deeper are more clicks away from the main page. Whether that's a problem depends on how many links point to that documentation, but I've seen some docusaurus sites that have such hideously long menu's that that's not ideal either. So in all, especially as it'll make pages faster, I think this is a smart change to make.

👍 this seems to work fine!