Kokoro Index

Content sites are usually built twice.

The pattern is familiar. A business starts publishing on a page-based CMS. It works at twenty articles. At two hundred, the demand changes — readers want to filter, sort, compare and browse by attribute — and pages alone cannot do that. So the site gets rebuilt on a heavy framework, becomes slow, and loses the search traffic that made it worth building.

The audience made the constraint concrete. Traffic arrives from social platforms, on phones, on mobile data, with the attention span that implies. A visitor who waits three seconds for a page is a visitor who has already gone back.

So: editorial richness, database-like browsing, and a page weight small enough to survive a poor connection. The three requirements pull in different directions, which is exactly why it was worth building.

Editorial on the surface, structured data underneath.

• Every piece is both. An article is written as long-form editorial and simultaneously carries structured attributes — so the same content powers a considered read and a filterable index without being maintained twice.
• Static pages, small islands. Pages render as plain HTML at build time. Only genuinely interactive fragments — a filter, a save control, a poll — ship JavaScript, and only for themselves.
• Genre-agnostic architecture. The content model was deliberately built wider than the launch topic, so expanding into an adjacent subject is configuration rather than a second codebase.
• Self-hosted variable fonts. Typography controlled and served from the same origin — no third-party font request, no layout shift, no dependency on someone else's CDN.
• Editorial quality treated as a feature. Measure, rhythm, hierarchy and considered typography, because a content site's product is the reading experience.

A framework choice made on a number, not a preference.

Astro for the site, with Preact rather than React for the interactive parts. The reasoning is the kind of decision worth showing, because it's how every technical choice here gets made.

React costs roughly 180 kB to carry a filter and a save button. Preact does the same job in about 37 kB — 14 kB compressed. On a site whose readers arrive on mobile data, that gap matters more than framework familiarity.

• Compatibility without the cost. Preact's compat layer means components still import from React and the code is unchanged. The saving is free — it simply requires someone to check.
• Islands, not hydration everywhere. Most of the page is HTML that never needed JavaScript. Only the parts that are genuinely interactive pay for interactivity.
• Content as files. MDX in version control: reviewable, diffable, restorable, and impossible to lose to a platform decision made by someone else.
• Built for search. Static HTML, real semantics and fast rendering — the technical foundation that content-led search visibility actually depends on.

• Astro 7
• Preact (compat)
• MDX
• Tailwind 4
• Variable fonts
• Static generation

What a client gets from this having been built.

• A content strategy that scales. If your business publishes — guides, listings, products, case studies, a knowledge base — this is the architecture that survives from twenty items to two thousand.
• Speed as a commercial asset. Page weight is measured and argued about here because it decides bounce rate, conversion and search ranking. It's a business metric wearing technical clothing.
• Decisions with reasons attached. Every significant technical choice comes with a number and an explanation you can interrogate. No cargo-culting the popular option.
• No platform lock-in. Content in files, in version control, in your repository. Portable by construction.
• Tested before it reaches you. Studio products exist so client work starts from something proven rather than something plausible.