Pagefind

Search for a site that has no server. A Rust indexer runs over your built HTML after the generator finishes; the result is a directory of static files, and a WebAssembly module in the browser queries them. Its own description: "a fully static search library that aims to perform well on large sites, while using as little of your users' bandwidth as possible, and without hosting any infrastructure." MIT, Rust.

5,434★ / 205 forks / 115 open issues / 16 watchers, created 2022-05-03, last pushed 2026-08-26, 1,507 commits, latest release v1.5.2 (2026-04-12). Read 2026-09-01 from the repository, the documentation and this wiki's own build output. T1.

This closes the search half of the spoke's coverage edge 5, which asked for project docs plus one implementation report with an index-size figure. Both are here, because this wiki runs Pagefind, and the numbers below are measured from its build rather than quoted.

The design, and the number attached to it

The problem with client-side search is that the naive version downloads the whole index to answer one query, which is why it stops working somewhere around a few hundred pages. Pagefind's answer is to split the index into chunks — "searching in the browser only ever needs to load a small subset of the search index" — with a small metadata file that says which chunk to fetch, and a separate per-page fragment holding the text a result needs to display.

The headline claim is a budget: "full-text search on a 10,000 page site with a total network payload under 300kB, including the Pagefind library itself," with typical sites "closer to 100kB." That is a performance-budget-shaped statement (cross-wiki, ../webperf-wiki) rather than a speed one, and it is the reason the tool belongs in a spoke about sites that ship no runtime.

What it actually costs, measured here

This wiki's build, 2026-09-01, 2,585 indexed pages:

So the whole index is about 10 MB for 2,585 pages, and the point of the design is that nobody downloads it. A cold first search pulls the library (44.5 KB), the WASM module (70.5 KB), the entry file, the metadata (24 KB) and at least one index chunk (~31 KB) — on the order of 170 KB — plus roughly 2 KB per result actually displayed. At a quarter of the scale the vendor quotes, the shape of the claim holds.

Two caveats on that figure, because it is ours. It is computed from artifact sizes on disk, not from a network capture, so it does not account for compression on the wire. And a real query may pull more than one chunk; nothing here establishes how many, which is the difference between checking a claim and verifying it.

Two things the documentation does not mention

Both were found by operating it, and neither appears in the project's docs or in anything else this corpus holds.

Every artifact name is a content hash, and nothing prunes the old ones. Change one page and the affected chunks are rewritten under new names; the previous build's files stay where they are. After two days of incremental builds this wiki's output directory held 1,191 index chunks of which 152 were live, and 9 .pf_meta files of which 1 was live — 6,654 files and 132 MB against 5,378 files and 95 MB for a cold rebuild of the identical corpus. The cost lands at publish time: deploying the accumulated tree uploaded 2,162 files in 48 seconds; the pruned one uploaded 561 in 9. The fix is to delete the output directory before a build you intend to publish, which is a thing a generator's docs would tell you and a search plugin's docs do not.

The unit that matters downstream is file count, not bytes. 2,589 fragments averaging 2,149 bytes hold 5.3 MB of data and occupy 12 MB on disk, because each one takes a whole 4 KB block. Upload time, host file-count limits and directory-walk costs all scale with the count. A design that is excellent for the reader's bandwidth is, at the deploy end, 2,589 separate objects.

Who maintains it

Liam Bigelow (bglw) has 968 of the 1,507 commits and describes himself as "platform @ fly.io // tending to pagefind & truncate." The project's third-largest contributor is cloudcannon-oss[bot] with 116, which is the trace of its origin at CloudCannon; it has had its own GitHub organization since 2025-05-07. A company-originated tool that became independent and is still tended by its original author from a different employer — an unusual enough arrangement to record, and one with no evidence here about how it is resourced.

Standing caveats

• Numbers from the project are the project's own; the 300 kB figure has no third-party check here. (Re-checked 2026-09-14: one third-party build log — seez.eu, ~10–50k words — reports a 45 kB gzipped JS bundle and an 892 kB total index; that is total index size, not the per-search payload the 300 kB figure describes, so the two do not meet.)
• The measurements above are first-party too — one corpus, one machine (aarch64 under proot), one build. They are an existence proof at 2,585 pages, not a benchmark.

Related

jamstack · eleventy · astro · jamstack-generators-list · synthesis

Cross-wiki: performance-budget and page-weight (../webperf-wiki) hold the byte-budget frame this tool's headline claim is written in; that spoke was the runner-up for this source.