The goal is not to hide latency with animation. The goal is to remove every piece of avoidable work before the browser paints. A mobile WebView opened from a Telegram Mini App, a messenger link, or an in-app browser should receive a complete readable document in the first response.
What the server does
At startup, the application builds a fixed instant.Store with explicit page and byte budgets. The article body is copied once, assigned an ETag, and kept immutable for the lifetime of the process. Requests only select the prebuilt page, set a small set of HTTP headers, and write bytes.
- No localization negotiation.
- No theme switching.
- No asset pipeline.
- No static directory.
- No runtime markdown, templ, CSS, image, script, or font loading.
Why this is useful
Most product pages eventually need richer interaction. But many entry points do not. A campaign article, announcement, menu excerpt, onboarding note, policy page, or emergency status page can be rendered as a single stable document. That makes it cheap to cache, easy to benchmark, and predictable under load.
The memory budget is intentionally explicit in the application: one page, a small byte cap, and startup failure if content grows beyond the configured limits.
How to read the benchmark
The benchmark measures the handler path after startup work is complete. It does not include network, TLS, kernel scheduling, CDN behavior, or a browser. That keeps the signal focused on the framework-side cost of serving an instant page.
If the page changes, restart the process. There is no background refresh and no hidden cache invalidation loop. Simplicity is the feature.