Why we keep Ornova Labs on static HTML — and how it stays fast

When we rebuilt this website, the obvious move was to reach for a framework — React, or one of the meta-frameworks everyone defaults to. We didn't. Ornovalabs.com is hand-written, framework-free static HTML and CSS with a small amount of vanilla JavaScript, and it loads about as fast as a page can. This article explains that decision and, more usefully, the specific techniques that keep a static site quick — most of which apply no matter what you build with.

None of this is anti-framework. Frameworks earn their weight on genuinely interactive applications. The point is narrower: for a content and marketing site, the default reach for a framework often adds cost you never recover.

Why a framework became the default

Frameworks solve real problems: managing complex state, reusing components, coordinating large teams. Somewhere along the way, though, "use a framework" stopped being a decision and became a reflex — applied to brochure sites and blogs that have no state to manage and no application logic to speak of.

The cost is easy to overlook because it's invisible on a developer's fast laptop. A typical framework setup ships a runtime, a hydration step, and a bundle of JavaScript the browser must download, parse and execute before the page is fully interactive. On a mid-range phone over a patchy connection — which is exactly the device a site engineer is holding — that overhead is the difference between instant and sluggish.

What we mean by static HTML

Static here means the server sends finished HTML. There's no client-side rendering step, no virtual DOM to reconcile, no waiting for JavaScript before content appears. The browser receives markup it can paint immediately, styles it with a single stylesheet, and runs a few kilobytes of optional JavaScript for niceties like the theme toggle and the mobile menu.

Crucially, "static" does not mean "hand-maintained and repetitive". This site is generated from small templates and a single product catalogue, so adding a product or article is a data change, not a copy-paste. You get the output characteristics of static HTML without the maintenance pain people associate with it.

The fastest JavaScript is the JavaScript you never send. Static HTML starts from zero and adds only what a page genuinely needs.

What actually affects Core Web Vitals

Google's Core Web Vitals reward exactly the things static HTML is naturally good at. It's worth knowing which lever does what:

Notice that two of the three are largely about not doing things — not shipping heavy JavaScript, not injecting content late. A static page passes them almost by default, because there's no hydration to delay interaction and no client render to shift the layout.

The techniques we use to stay fast

Being static gets you a fast start; a handful of deliberate techniques keep it that way. None are exotic:

• One stylesheet, loaded once. A single cached CSS file styles every page. Shared design tokens keep it small and consistent rather than letting per-page styles pile up.
• Defer the JavaScript. The small script that powers the menu and theme toggle is loaded with defer so it never blocks the first paint.
• Preconnect and preload fonts. A preconnect to the font host and a preload on the stylesheet shave the round-trips that otherwise delay text rendering.
• Size your images. Every image has explicit width and height so the browser reserves space and the layout doesn't jump — the cheapest CLS fix there is.
• Lazy-load below the fold. Images that aren't visible on load don't compete for bandwidth with the ones that are.
• Respect reduced motion. Animations are gated behind a media query, so they cost nothing for users who don't want them.

The theme of all six is the same: do the necessary work early, defer or skip everything else, and never make the browser guess about layout.

When static HTML is the wrong choice

Static is not a universal answer, and treating it as dogma is just the mirror image of the framework reflex. If your site is fundamentally an application — a dashboard, an editor, anything with rich, stateful interaction across many views — a framework is the right tool and you should use one. The same goes for highly personalised pages that differ for every logged-in user.

The honest dividing line is whether the page is primarily content or primarily behaviour. Marketing pages, blogs, documentation and product pages are content; they render once and mostly sit still. That's the sweet spot for static HTML. Our actual applications — the ones behind the Launch buttons — are separate apps built with the frameworks that suit them. The marketing site doesn't need to carry that weight, so it doesn't.

Why this helps SEO and AdSense

Speed isn't only a courtesy to users; it's something search engines measure and reward, and it's something ad programs care about indirectly. Because static HTML arrives fully formed, crawlers see the complete content immediately with no dependence on executing JavaScript — which removes a whole class of indexing problems that client-rendered sites run into.

Fast, content-first pages also tend to satisfy the practical bar for ad eligibility: real content present on load, a responsive layout, quick interaction, and no broken or empty shells waiting on a bundle. You don't get those properties by adding a performance plugin at the end; you get them by not creating the problem in the first place.

Key takeaways

• For content sites, a framework is a choice to justify, not a default to assume.
• Static HTML passes most Core Web Vitals by avoiding hydration and late layout changes.
• The big wins are mundane: one cached stylesheet, deferred JavaScript, sized images, preconnected fonts.
• Generate static pages from templates so "static" doesn't mean "tedious to maintain".
• Use frameworks where there's genuine application state — and keep them off pages that don't need them.

We kept Ornova Labs on static HTML because the site is content, and content wants to be fast. The tools above are the entire trick. There's no secret — just a refusal to send work to the browser that the browser never needed to do.

Frequently asked questions