Instant Search for Static Sites

The static site search problem

Static site generators produce HTML files that can be served from any CDN. There is no application server, no database, and no runtime. That is the point — static sites are fast, cheap, and secure because there is nothing to run.

But search needs something to run. Users type a query, and something has to score, rank, and return results. Most search solutions require a backend: Elasticsearch, Algolia, Meilisearch, or a custom API. These work, but they introduce the server dependency that static sites are designed to avoid.

Client-side alternatives exist, but they have limitations. Lunr.js is no longer actively maintained and its pure-JavaScript indexing slows down on datasets larger than a few hundred pages. Pagefind compiles indexes at build time, which works well for documentation but cannot index dynamic content like user submissions, new products, or content added after the build.

Sprigr takes a different approach. Your content is compiled into a WebAssembly module and served as a static file alongside your site. The 155 KB WASM engine loads in the browser and executes search queries locally in under 10 ms. No server, no API calls, no ongoing infrastructure.

Build pipeline integration

Push your content to Sprigr as part of your existing build process. Here is an example using curl in a CI/CD step.

#!/bin/bash
# Run after your static site builds

# Extract content from your output directory
# (adapt the jq/script to match your SSG's output format)

curl -X POST "https://api.sprigr.com/1/indexes/your-index-id/records" \
  -H "Content-Type: application/json" \
  -H "X-Sprigr-API-Key: $SPRIGR_API_KEY" \
  -d @records.json

You can also push records programmatically from Node.js, Python, or any language that can make HTTP requests. The API accepts JSON arrays of records with any structure — title, body, URL, tags, categories, or custom fields.

module.exports = function(eleventyConfig) {
  eleventyConfig.on("eleventy.after", function() {
    var fs = require("fs");
    var posts = JSON.parse(fs.readFileSync("_site/search-index.json", "utf8"));

    return fetch("https://api.sprigr.com/1/indexes/your-index-id/records", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-Sprigr-API-Key": process.env.SPRIGR_API_KEY,
      },
      body: JSON.stringify(posts),
    });
  });
};

Why Sprigr over other static search options

There are several approaches to adding search to a static site. Here is how Sprigr compares.

vs Lunr.js

Lunr.js is a pure-JavaScript client-side search library. It was a solid choice when it was actively maintained, but the project has not seen significant updates in years. More importantly, Lunr loads your entire index as a JavaScript object, which causes performance problems on datasets larger than a few hundred pages. Sprigr uses a compiled WebAssembly binary that handles tens of thousands of records with sub-10 ms query times.

vs Pagefind

Pagefind is a build-time indexing tool that generates a static search index. It works well for documentation sites where content only changes at build time. However, Pagefind cannot index dynamic content — if you add a blog post, a product, or user-generated content between builds, it will not appear in search results until the next full build. Sprigr accepts new records via REST API at any time, so your search index stays current without rebuilding your site.

vs Algolia DocSearch

Algolia DocSearch is free for open-source documentation sites, but it requires an application process and is limited to docs. For commercial sites, blogs, e-commerce, or anything that is not open-source documentation, you need a paid Algolia plan with per-query pricing. Sprigr offers a 6-month free trial for everyone, with no per-query charges since all search runs client-side.