(If you go down this route you might prefer ag/the silver surfer/similar, as being faster than grep.)

I've actually reported a couple of security bugs in servers in the past, which were caused by people running grep for searches.

Imagine you have a tree of web-content at /var/www, when a user searches for "foo" you run "grep -r -h foo /var/www", then you parse out the resulting filenames.

Now imagine what happens if your user searches for "foo /tmp; rm -rf /". Whenever you pass user-input to a command-line application you need to be damn sure you know what you're doing - if the shell is involved in parsing your command you'll have problems.

If you're running grep it isn't a static site anymore.

The big difference here is that the bloom filter implementation runs entirely client-side. It saves a roudtrip per search.

The indexing task can be done during static site generation and results shipped as resources, but the query part (search string parsing, ranking, snippet generation, etc) needs some code running locally (browser, js). We've used Minimal Perfect Hash Function with bloom filter to reduce the mem of a service from ~27G to ~8G, as the data was static. Probably something like that can be used here too, to make indices small.