Skip to content
posch.cloud
Menu
DEEN

Our own website

How we built posch.cloud.

This page documents posch.cloud itself: technical decisions, measured results, and the limits of those measurements.

About this page

Our site, our measurements.

This is not a client project. Every figure comes from Lighthouse lab tests of posch.cloud, not CrUX field data.

Lighthouse results

The numbers behind the site.

These are the medians from 5 desktop and 5 mobile runs with Lighthouse 12.8.2 on 12 August 2026. Every desktop Performance run scored 100.

Desktop (median)

All 5 desktop Performance runs: 100

Lighthouse scores

Performance
100
Accessibility
100
Best Practices
100
SEO
100

Lab performance metrics

LCP
0.47s
CLS
0
TBT
0ms
FCP
0.30s
Speed Index
0.30s
TTI (legacy)
0.47s

Mobile (median)

Mobile Performance: 98 to 99

Lighthouse scores

Performance
99
Accessibility
100
Best Practices
100
SEO
100

Lab performance metrics

LCP
2.12s
CLS
0
TBT
0ms
FCP
1.07s
Speed Index
1.07s
TTI (legacy)
2.12s

What we built

Technical decisions.

We keep JavaScript small, self-host the fonts, and define security headers deliberately. That keeps delivery fast and predictable.

  • Astro 7.0.9, static by default

    Static HTML is the default. React islands are used only where the interface needs interaction.

  • Cloudflare delivery

    The site is delivered through Cloudflare, with static assets served at the edge. Cloudflare Web Analytics measures usage without marketing cookies.

  • Self-hosted typography

    Geist, Geist Mono, and Instrument Serif are served locally, with no requests to third-party font providers.

  • Security and language routing

    Strict security headers, de-AT at the root, English under /en/, and matching hreflang alternates.

Accessibility

Accessibility from the start.

The site was planned and built with WCAG principles in mind. A Lighthouse lab test does not establish WCAG conformance.

Semantics, keyboard access, visible focus states, contrast, and clear errors were part of the build from the start.

  • Sensible heading hierarchy and semantic page regions
  • Skip link, keyboard-accessible navigation, and visible focus states
  • Forms with labels, status messages, and understandable errors
  • Lighthouse Accessibility 100 in the lab - a signal, not a certificate

How we worked

The process, applied to our own site.

Four stages from positioning to launch.

  1. 01

    Discover

    We sharpened the positioning, set DACH as the primary market, and made German (Austria) the default language.

  2. 02

    Design

    Warm Ink: Instrument Serif for display, Geist for UI, Honey as the only accent. Editorial, not a dashboard.

  3. 03

    Build

    We used React islands sparingly, preloaded key fonts, and defined security headers. Performance was tested from the start.

  4. 04

    Launch

    Cloudflare delivery, Cloudflare Web Analytics without marketing cookies, monitoring, and documented lab results.

Measurement note

How we measured it.

Test setup:

  • Tool: Lighthouse 12.8.2 in Headless Chrome
  • 5 runs each for desktop and mobile; figures shown are medians
  • Test location: Cloudflare PDX; lab context, not a global usage profile
  • LCP element in every run: the "posch.cloud" wordmark in the header (span.text-lg)
  • TTI is the unweighted legacy interactive audit from the raw Lighthouse report
  • No CrUX field data; results can vary by device and connection

Metrics do not replace good work.

They make part of it visible. If performance and accessibility matter to your next website, tell us what you are building.

Start a project