Track full-content local search with a performance budget

[imbajin]

Context

The OINK site intentionally keeps native local search on the summary index while the optional Ask AI integration is added. Native search must remain independent of any external AI provider.

A full-content index can improve recall, but the current planning estimate is roughly 233–243 KiB gzip per language per version. Across five versions and two languages, enabling it mechanically would multiply download, parse, and memory cost for users who only need the current documentation.

Current baseline

• params.offline_search_index: summary
• Search metadata and restrained boosts improve the highest-value entry pages.
• Ask AI is an optional tail action; it does not replace or modify native results.
• Historical versions remain independently addressable and must not silently load every other version's index.

Deferred scope

Do not enable content mode as part of the current OINK site-improvement delivery. This issue tracks a separate, evidence-based decision.

Evaluation requirements

• Measure generated and gzip size for each language and version on an immutable source revision.
• Measure first-open transfer, parse/index time, memory, and repeat-open cache behavior on desktop and representative mobile hardware.
• Compare recall and ranking against the fixed English/Chinese query set used for the summary index.
• Define per-language/per-version budgets and a loading strategy before implementation.
• Preserve explicit load-failure/retry behavior and ensure one failed historical index cannot break latest search.
• Verify keyboard, mobile, and offline behavior in Chromium.

Acceptance boundary

Adopt full-content indexing only if measured recall gains justify the transfer/runtime cost and all agreed budgets pass. Otherwise retain summary and document the result. The 233–243 KiB figure above is a planning estimate, not current-HEAD measurement evidence.