How can we consume a more performant modular set of docsearch?

We are infinitely grateful at [webpack](https://github.com/webpack/webpack) that our [docs](https://webpack.js.org) are leveraging the DocSearch functionality with almost little to no needed effort on our side. So first off thank you.

**Do you want to request a *feature* or report a *bug*?**
Kinda both? But not sure.

**What is the current behavior?**
Currently when using docsearch.min.js and doing Code Coverage and Performance Analyses, we are identifying that docsearch.min.js script used to power the search on our webpack docs is shipping about 66% dead code **on the initial download and render of the page**. This means that for the default functionality, we only need about 40% of the actual code for webpack's doc experience to initially load.

For accessibility and web performance reasons, we are looking to only utilize the features we actually need, and even if possible, use `import()` to lazy-load additional pieces of functionality when events occur (such as, a user clicks the search field, then the modal appears, we don't need to modal js code, etc.).

1. Is there a way to consume the docsearch code as raw source and not as a CDN, we very much would like to treeshake this code, but can't since it is not possible (unless I'm wrong) to pull the actual source and load it.

2. Is there a way we can hoist interacting pieces of the docsearch functionality so that their modular pieces can be lazy-loaded on our terms?

An example. in fake React syntax.
```jsx
import DocSearchMenuButton from "./DocSearchMenuButton";
import Loadable from "react-loadable";

const LazyLoadModalComponent = () => import("./DocSearchModal");

return (

)
```

This then allows the LazyLoadModalComponent to be `called()` on a DocSearchMenuButton event!!! Therefore, you never are placing `import()` inside your docsearch code, but for those projects looking to be as performant as possible, we can hoist this API to the top level and be handled the best possible way for first-class code-splitting.

The reason this struck my attention was that I noticed that @ulivz had to lazy load the entire bundle (maybe overkill with the right modular api's) for vuepress.

https://github.com/vuejs/vuepress/blob/f0b33e186a062f03469339a4839a1c8c01afc725/lib/default-theme/AlgoliaSearchBox.vue#L15-L18

**Related**

Thanks for all the support of our project and everything that your team does. If you want to reach out for more questions or a less crapy example, let me know!

~ Sean (webpack team)

Start with the published docsearch.min.js bundle and the linked VuePress AlgoliaSearchBox.vue example to understand the current loading boundary. Evaluate the requested raw-source, tree-shaking, and lazy-loading API against the existing DocSearch consumption model; done means a clearly documented modular path that avoids shipping unused initial code.

Written by the indexing model from the issue text.