Blog
The page you're reading was rendered on our server in single-digit milliseconds — we can say that plainly because we read it off this site's own request logs, not a lab benchmark. That number isn't the result of an optimization sprint. Nobody profiled this page. It's fast because of decisions made before the first line of it was written, and that distinction is the whole point of this post.
The common way: build on whatever the platform gives you, watch the scores come in orange, then spend launch month 'optimizing' — compressing, deferring, lazy-loading, caching, and generally negotiating with an architecture that wants to be slow. The results are real but fragile. Every redesign, every new plugin, every marketing tag starts the negotiation over.
The other way: pick an architecture whose default output is fast, so speed doesn't need defending. That's the way we build, and it rests on three decisions.
Every page on this site is assembled on the server and arrives as complete HTML. The browser's job is to paint it. There is no client-side framework booting up, no hydration pass re-deriving what the server already knew, no skeleton screens apologizing for work that hasn't happened yet. Server rendering isn't a performance technique here — it's the default, and deviating from it is what would need justifying.
Most of what a marketing site does — headlines, sections, galleries, footers — is not interactive, and shipping JavaScript for it is pure tax. Vanolee Arc treats interactivity as *islands*: small, deliberate components added only where a page genuinely reacts to the user. A form that validates as you type earns its JavaScript. A paragraph does not. This entire site carries one small vanilla script for scroll choreography — and with JavaScript disabled, every page still works.
This is the one most stacks can't choose. Between a request and our HTML there is exactly one codebase — our framework, in native Rust. No CMS round-trips to a separate backend, no plugin chain, no platform middleware we've never read. When the whole path is yours:
Fast sites aren't a vanity metric. Visitors bounce from slow pages before they read a word; search engines fold speed into ranking; and every apology-spinner is a moment your brand spends looking broken. But the deeper cost of the optimize-later path is organizational: speed becomes a project that competes for budget, loses, and quietly regresses. When the architecture is fast by default, nobody has to champion it.
Fast isn't something we tune for at the end. It's something we refuse to build away from at the start.
Every claim in this post is checkable from where you're sitting: open devtools, reload, and look at the timing. That's the standard we'd want you to hold any studio to — including us.