[tootie]

It's mentioned in this post but lunr.js is a clever option if you don't have much content. The idea is that your search page has to create a json object with all your content and lunr will build an index out of it client-side. This sounds like terrible architecture but you could stuff about 100 blog posts into an object the size of one big jpeg. For a few dozen articles it's pretty snappy.

[simonw]

Yeah that's a pretty useful trick.

Sphinx, the Python documentation engine, does something like that - e.g. https://datasette.readthedocs.io/en/stable/search.html?q=fts... which runs off this generated JavaScript index file: https://datasette.readthedocs.io/en/stable/searchindex.js

[techntoke]

A few dozen articles? I've seen examples with Fuse.js and Hugo searching over 10,000 articles and it is fast. No server-side components required.

[contravariant]

I think most people (me included) underestimate how ridiculously tiny raw text is compared to other common file types.

[chopraaa]

Great way to botch user experience since the user has to download the index.

[techntoke]

There are ways to optimize this per section, alphabetically, etc. Otherwise Xapian is very easy to setup and would be my goto over Elasticsearch.

[evandrofisico]

You can also do the lunr index creation server side, with lib in php or python, generating a quite smaller file and also reducing processing time on the client side.

I've been developing a podcast hosting solution that parses the xml feed, generate static pages and prebuilds a lunr index, and for ~100 posts, it takes around 30 seconds to build server side and less than a second to download and and load on the client.

[tootie]

What's the file size of the index? Is it just encoded in JSON?

[kevinastone]

Yes, it's encoded json for lunr.js. Here's the index for my static-site blog: https://blog.kevinastone.com/search_index.json. It's 305kb un-compressed at the moment (38kb gzipped).