About

A test site that admits it is a test site

Usharea has no customers, no roadmap and nothing to sell. It is a fixed target: a handful of real pages that can be deployed, moved, cached, broken and re-deployed while somebody watches what the infrastructure does.

Where the name comes from

Usha is the Sanskrit word for dawn - the first light before anything else is visible. It seemed like a reasonable name for the thing you put up before the real site exists, and it gave the palette on this page somewhere to start: night indigo, then violet, then the coral and amber that arrive just before sunrise.

What it is used for

The site is a fixture for four kinds of check that are awkward to run against an application you are still building:

• Deployment verification. Does a push produce a new deployment, does the new deployment actually serve, and does the previous one stop serving? The deployment identifier on the diagnostics page answers all three without leaving the browser.
• Region and routing. Which region handled the request, and does that change when the host is reconfigured? Region codes are reported straight from the response.
• Caching and headers. Static assets, HTML documents and function responses each want different cache rules. Getting them wrong on a site with five pages is cheap; getting them wrong on a real one is not.
• Crawl and index. Titles, descriptions, canonical URLs, structured data, a sitemap, a robots file and a feed - all present, all deliberately boring, so that anything a search console reports is a fact about the host rather than about the markup.

What it deliberately leaves out

The absences matter more than the features. There is no analytics script, no tag manager, no consent banner, no web font fetched from another origin, no CSS framework and no npm dependency tree. htmx is committed to the repository rather than pulled from a CDN at runtime, which means the site has no third-party requests at all and a strict content security policy is actually achievable.

The practical effect: when a page here is slow, the network path is slow. There is nothing else it could be.

A test site is only useful while it stays boring. The moment it acquires features, it stops measuring the host and starts measuring itself.

How the pages are put together

Each page is a complete HTML document written by hand. Navigation is upgraded by hx-boost, so clicking a link fetches the next document and swaps its body in place rather than reloading the whole browsing context - but the URL still changes, the title still changes, and pressing back still works. With JavaScript disabled the same links are ordinary links.

Smaller pieces - the tab panels on the home page, the header table on the diagnostics page, the response to the contact form - are fetched as HTML fragments and swapped into place. That is the entire architecture. There is no client-side router, no hydration step and no state to reconcile.

Frequently asked

Is any of the content real?

The technical descriptions are accurate - they describe this site. Everything else is placeholder material written to give crawlers something structurally realistic to read. No organisation, product or person described here exists.

Can I reuse it?

Yes. Replace the canonical domain in each page head, in sitemap.xml, in robots.txt and in feed.xml, then deploy. The README lists every place the domain appears.

Why not a static site generator?

Because a generator would put a build step between the repository and the served bytes, and the build step is exactly the variable this site is trying to eliminate. Five hand-written pages are easier to reason about than a template that produces five pages.