Unduck and the Quest for the Zero-Latency Redirect
How a minimalist middleware engine uses data-as-code to outrun the giants of search.
- Unduck eliminates search redirect latency by moving the entire routing logic from remote servers to the local browser.
- The engine bundles thousands of search shortcuts into a single 2.6MB TypeScript file to treat data as cacheable code.
- Service Workers intercept search queries locally to bypass the DNS and TLS overhead of traditional search engines.
- This architecture reduces the redirect phase from over 150 milliseconds to approximately 5 milliseconds.
The 100ms Tax
For power users, search engine "bangs" are muscle memory. Typing !w for Wikipedia or !gh for GitHub into DuckDuckGo saves seconds of clicking. But that convenience comes with an invisible performance tax. Every bang requires a full round-trip to a remote server, only for that server to issue an HTTP redirect back to the client.
In an era of highly optimized frontends, this DNS and time-to-first-byte latency feels sluggish. Unduck proposes a radical alternative. The fastest way to handle a request is to never send it to a server at all.
Data as Code: The 2.6MB Dictionary
To eliminate the server, Unduck must know where to send every possible query. The solution is an exercise in brute force. The repository contains a massive TypeScript file, src/bang.ts, weighing in at over 2.6 megabytes. This file hardcodes thousands of DuckDuckGo bangs directly into the application bundle.
Shipping a multi-megabyte JavaScript payload to save 100 milliseconds might sound counterintuitive. However, this is where modern web architecture flips the script. By treating data as code, Unduck leverages the browser's aggressive caching mechanisms.
const url = new URL(window.location.href);
const query = url.searchParams.get("q")?.trim() ?? "";
const match = query.match(/!(\S+)/i);
const bangCandidate = match ? match[1].toLowerCase() : null;The Zero-Server Stack
Unduck is built with Vite and relies heavily on Progressive Web App (PWA) standards. Once a user visits the site, a Service Worker installs the logic locally. Subsequent searches do not even hit the network for the redirect phase.
With service workers we can intercept the `fetch` request, before the index.html gets rendered/loaded. One should (in theory) be redirected some micro-seconds faster than doing the redirect in the index.html js
This architecture transforms a web page into a piece of local infrastructure. It acts as middleware sitting directly in the browser's omnibox, intercepting queries before they ever leave the machine.
Local vs. The World
The performance benefits become obvious when comparing network waterfalls. The traditional approach pays the TLS and DNS tax twice: once for the search engine, and once for the final destination.
| Phase | Server-Side (DuckDuckGo) | Client-Side (Unduck) |
|---|---|---|
| DNS Resolution | Required (~20-50ms) | Skipped (Local Cache) |
| TLS Handshake | Required (~50-100ms) | Skipped |
| Routing Logic | Remote Server | Local JS Runtime |
| Total Latency to Redirect | ~150ms+ | ~5ms |
By embracing static deployment and aggressive local caching, Unduck proves that sometimes the best backend is no backend at all. It is a highly specialized tool that perfectly executes a single, vital function.