Speed up search by ranking from a title map

[enf0rc3]

Search ranking needed a URL and a title for every result it ordered, and Pagefind keeps both inside the per-page fragment. So ordering thirty results meant downloading thirty files before the panel could draw a single row — which is what a reviewer noticed on the last PR, watching them trickle through six at a time on Slow 4G.

The build now writes a small map of result id to URL and title beside the index. Pagefind's own result stub already carries the id of its fragment, so that map is all ranking needs.

What this gives

• A third of the downloads per search. 10 fragments for a settled query, down from 30 to 35.
• Faster first results. On Slow 4G, 7.2 s against 8.9 s — and that run served the map uncompressed at 122 KB, so behind the CDN, where it is 28.5 KB, the gap is wider.
• Identical relevance. Unchanged on both traffic-weighted query sets.
• A page the query names wins from anywhere. Ranking now sees every result, where it used to see the first thirty. The shallow-page shortlist of 227 that rescued those pages is gone with it, along with the second Pagefind query per search and the filter it needed on every page.
• Graceful failure. A map that goes missing or disagrees with the index falls back to ranking the rows it draws, which is what the engine did before.

How this was measured

Both traffic-weighted query sets replayed through the real overlay against the merged main, same machine, same method:

	before	after
fragments per settled query	30–35	10
real-searches, weighted S@1 / S@5	57% / 84%	57% / 84%
top-pages, weighted S@1 / S@5	90% / 98%	90% / 98%
Slow 4G, typing "kubernetes"	8.9 s	7.2 s

Relevance holding exactly is the point. Widening the ranking window from thirty rows to the whole result set moved nothing, so the shortlist it replaces was doing its job, and this does the same job for a third of the fetches.

219 Playwright tests pass, including the existing ranking, paging and tab-count cases unchanged.

Worth a reviewer's opinion

The map is fetched eagerly alongside the index, so someone who opens the overlay and never types now pays 28.5 KB they did not before. Moving it to the first keystroke would avoid that, at the cost of putting it on the path of the first search.

[team-marketing-branch-protections]

Pull request environment is available at https://stoctodocspr3408.z22.web.core.windows.net.

You can view the ephemeral environment status in Octopus Deploy.

This environment will be automatically deprovisioned when the pull request is closed, or after 7 days of inactivity.