Nice, thanks! A while ago I was looking for a a search lib precisely like this for my blog. I really like the idea of a client-side search - it feels extremely responsive to use compared to server side. The bandwidth-saving chunking tech is a nice bonus that I didn't expect - the websites I've used seem to naively load the entire index.
So.... A complete index of my site is too large...
So I could chunk the index up... For example, one index for words beginning with each letter of the alphabet. I could host the index for words beginning with 'a' at mysite.com/search/a
But I could do yet smaller indexes! I could make one index for each word. Ie. use the URL mysite.com/search/abacus
We could call these mini-indexes search result pages...
That is, in essence, what Pagefind is doing under the hood — but Pagefind also addresses the other reply in that it can combine these results when you search multiple words (among many other search benefits)
It's not quite that simple because the user can search for more than one word. Generating all searches for one or two words is probably feasible but not much more than that. After that you probably do want to just generate one index per word and merge them together at search time to dynamically generate the search result page.
This looks fantastic! I've used Lunr [0] (a client-side search engine), but as noted in the article, the index is huge and search is quite slow for a site with a lot of content. Splitting the index up is a great idea. Thank you!
Five years ago when I switched from WO to Hugo I wrote my own solution based on SQLite’s fts5 full-text search and using Hugo itself so the results match the theme of your site:
I wonder how this compares to algolia? I recently added that to an open source project I released recently and the search results aren’t just not relevant they aren’t even close to correct. It works by first indexing your site by scraping it.
