We asked whether sitewide search would break our perfect score. It already had, and it was still running.

Published August 5, 2026 · ZenMasterWorks

The question that started this

Simple enough on its face: would adding search back disrupt the site's PageSpeed standard? The honest answer required going back to the original incident rather than guessing. The public incident log had the real numbers — a verified re-test showing 99 Performance with the old search box live, back to 100 once it was removed, with the root cause named directly: the search box "added its own main-thread JS work (index fetch, scoring, DOM rendering on every keystroke)."

Checking the old removal turned up something worse

The incident log described the original removal as clean — markup, CSS, and JavaScript all confirmed removed together from the homepage. That part held up. What it didn't cover was work-pricing.html, a separate page carrying its own independent copy of the same feature. That copy's HTML had been removed at some point. Its script and stylesheet rules hadn't.

The script called initSearchInstance('heroSearchInput', ...), looked for an element with that ID, found nothing, and quietly returned — but the fetch('/search-index.json') a few lines above it had already gone out by then. Every load. For a feature that hadn't existed on that page in days. It cost real bytes and a real network round-trip, for zero user benefit, and it would never have shown up as a visible bug — the page looked and worked completely normally.

The index was stale too

Once we knew the old search-index.json existed, checking it directly was the obvious next step rather than trusting it was current. It wasn't: 209 entries, none of them from the past two days of work. Rebuilt it from scratch, sourced directly from each live page's own title, canonical URL, and meta description — 181 real, current entries after excluding noindexed pages, permanently-excluded audits, external client sites, and fictional-demo pages.

What the new version does differently

Not a restoration of the old feature — a different design, built specifically around the failure that broke the last one:

• No network request until someone actually opens the search panel — zero cost for the visitors who never use it, not even a deferred one
• Opens as a fixed overlay, not inline content, so it can't shift anything on the page when it appears
• Input is debounced at 200ms instead of searching on every keystroke
• Keyboard navigation and ARIA state built in from the start, not retrofitted after launch

How it was actually verified

Reading the code and reasoning it should be safe isn't the same as checking. Six specific behaviors were tested against a real HTTP server in an actual browser: no fetch fires on page load, the page's scroll height is identical before and after opening the panel, the fetch does fire once the panel opens, results appear only after the debounce window and not before, arrow-key navigation correctly highlights results, and Escape closes the panel. All six passed.