Runaway bundle sizes

[rschristian]

Describe the problem

Like many OSS projects, Preact uses Docsearch on our site to support search functionality. Whilst the bundle sizes have historically been a bit larger than we'd like, and there's been some problems with bundling, but generally we've been pretty happy with it.

So when I went to take a look at the new version a few weeks ago I was rather astounded at the bundle size as it's more than quadrupled in just a handful of minors & a major. It went from 26kb in 3.6.0 to 114kb in 4.0.1 which is rather horrific. Some recent PRs have also bumped the bundle size warnings 30%+ at a time which is quite a big jump.

So I'd like to ask ask, is this just the new direction of the lib? Is bundle size not one of the core concerns anymore? We're sorta boxed in from the consumer side as Docsearch was already 50% of the total site JS (at least, outside of our REPL which is much heavier) and we built a custom lazy loading solution to accomodate it. Quadrupling size though, I don't think there's any way we can make that work. We have many users on poor internet connections and older devices and ~100kb of JS just for searching is a big ask.

I'm hoping this is just a temporary thing whilst perhaps you're dealing with bundler woes & complications (I think every front end dev has been there, we get it). From a quick skim it looks like we're always stuck with some AI stuff, which we have no desire to ever use, and it looks like marked is being inlined too? Not totally sure on that. Obviously we're OSS consumers on donated time and resources so it's 100% cool whatever you do, I'd never make demands, but there seems to be a 180 in development priorities which, at least right now, feels like it's leaving smaller/slimmer sites behind.

[dylantientcheu]

Hi @rschristian your concerns are valid and we are working towards reducing the footprint.

We use pretty heavy third-party libraries for the AI needs and we are looking for ways to strip out only the needed parts or lazy loading heavy parts of the library.

We understand AI features are not useful for everyone and should not be included as part of the core bundle.

We are already working on this [1], [2], more will come, please keep the feedback coming, it is useful.

[slorber]

I agree that the integration of new AI features is too heavy, and expressed the same concerns for Docusaurus usage in facebook/docusaurus#11327 (review)

In particular, it doesn't look like our bundler (Rspack) is able to code-split the lib properly, leading to our main bundle embedding a heavy AI SDK, delaying React hydration for all pages of the site, even for sites not using the AskAI feature.

It was probably possible to code-split and lazy-load on intent before, and we had code that did that, but it was not working in practice, and we ended up with all the code in our main bundle. Re-creating a custom DocSearchButton ourselves to lazy-load the rest wasn't particularly convenient.

However, the newly released DocSearch v4.1 exposes multiple entry points, and now lets us the button eagerly, while easily lazy-loading the heavy modal on intent.

Here's a PR: facebook/docusaurus#11421

And the CI reports a very significant impact (not gzipped):

---

Since our former code-splitting system was not even working before, this upgrade also reduces our main bundle size compared to the v3.9 baseline.

See for yourself:

• DocSearch v3.9: https://68cd2c5d1ca4700009008f2e--docusaurus-2.netlify.app/

  • main: 258kb gzipped
  • lazy-loaded: 1kb

• DocSearch v4.0: https://68cd497fac2a780009f76822--docusaurus-2.netlify.app/

  • main: 336kb gzipped
  • lazy-loaded: 0kb

• DocSearch v4.1: https://68d54d82bf81160008c7de97--docusaurus-2.netlify.app/

  • main: 239kb gzipped
  • lazy-loaded: 98kb gzipped

---

Of course, the modal remains too heavy, but at least it is now properly code-split for us and lazy-loaded on intent.

A good start would be to leverage React composition so that DocSearch users not using AskAI could avoid the extra useless dependencies. Then the Ask AI feature could probably be slimmed down.

[NatanTechofNY]

@rschristian Thanks for raising this and for sharing your thoughts so candidly, we truly appreciate the feedback.

DocSearch is an open-source project and we’re grateful for the community that uses and supports it, but we never want that to translate into a drop in quality or care.

This bundle-size regression was an unintended oversight, not a shift in priorities, and we’re sorry it came across as anything less than the level of attention you’ve come to expect from us.

We’ve just released new entry points that help reduce the bundle size right away, and we’re continuing to work on a new composable API that will give developers more flexibility and keep the core package leaner.

Your feedback is incredibly valuable, we definitely do not want DocSearch to add unnecessary weight to anyone’s site.
We’ll keep this thread updated as further improvements land.

[rschristian]

Apologies if this came off as rude to you all as it does to me as I reread my comment, that's a tone I did not intend. Sincerely sorry, that doesn't belong in OSS & I'll make edits to fix that.

Glad to see the bundle size is still a concern!

Just FWIW, this is what we're doing to lazily load on intent to interact, works pretty well I think? Little bit of CSS duplication to make this work but not a biggie. Separating out the button and search modal sounds great though for helping reduce complexity in the future.