Support building search indexes at compile time, instead of runtime.

[xuanswe]

Feature Description

Support building search indexes at compile time, instead of runtime.

Problem/Solution

Currently, the search engine will index on client browser. For a medium or large site, users might have a bad experience because of the indexing performance.

In https://github.com/imfing/hextra/discussions/112, a proposal is to support configuring another search engine, such as https://pagefind.app, which allows to build search indexes at compile time.

On small sites, I think there are no disadvantages. Users should not detect the slowness at compile time.

For medium or large site, a small disadvantage is that the building time will be slower, but the users will be happier. However, this problem could be minimized easily with a parallel CI/CD as follow:

• First, we deploy only hugo site without building search indexes.
• Then we have another job to build search indexes in parallel and push the result later to the hugo site.

This allows building the site fast, while the search feature will be available later.

Alternatives Considered

It would be nice if the community could suggest different search engines that support compile time indexing. So that we can choose the best option. It also helps to see if we can have a general implementation that supports even multiple search engines.

[Vonng]

the Docsy theme use lunr, and it works perfectly as expected.

[imfing]

the Docsy theme use lunr, and it works perfectly as expected.

@Vonng Lunr.js is no longer actively maintained.

the Docsy documentation site itself uses Google Custom Search instead: https://www.docsy.dev/search/?q=search

Speaking of pagefind, it's definitely possible to support it. It just takes some time and effort to integrate

[w3c-cool]

@imfing 期待pagefind或algolia的加入,感谢大神的作品,非常好的主题. 我最近正在将知识库迁移到hextra,文档非常多,遇到了和这位哥们一样的问题https://github.com/imfing/hextra/discussions/112#discussion-5690069