Eigene Website
So haben wir posch.cloud gebaut.
Diese Seite dokumentiert posch.cloud selbst: technische Entscheidungen, gemessene Werte und ihre Grenzen.
Einordnung
Eigene Website, eigene Messwerte.
Es ist kein Kundenprojekt. Alle Zahlen stammen aus Lighthouse-Labormessungen von posch.cloud, nicht aus CrUX-Felddaten.
Lighthouse-Ergebnisse
Die Zahlen hinter der Website.
Gezeigt sind die Mediane aus jeweils 5 Desktop- und 5 Mobile-Läufen mit Lighthouse 12.8.2 vom 12. August 2026. Alle Desktop-Performance-Läufe erreichten 100 Punkte.
Desktop (Median)
Alle 5 Desktop-Performance-Läufe: 100
Lighthouse-Scores
- Performance
- 100
- Barrierefreiheit
- 100
- Best Practices
- 100
- SEO
- 100
Lab-Kennzahlen und Ladezeiten
- LCP
- 0.47s
- CLS
- 0
- TBT
- 0ms
- FCP
- 0.30s
- Speed Index
- 0.30s
- TTI (Legacy)
- 0.47s
Mobile (Median)
Mobile Performance: 98 bis 99 Punkte
Lighthouse-Scores
- Performance
- 99
- Barrierefreiheit
- 100
- Best Practices
- 100
- SEO
- 100
Lab-Kennzahlen und Ladezeiten
- LCP
- 2.12s
- CLS
- 0
- TBT
- 0ms
- FCP
- 1.07s
- Speed Index
- 1.07s
- TTI (Legacy)
- 2.12s
Was wir gebaut haben
Technische Entscheidungen.
Wir setzen JavaScript sparsam ein, hosten Schriften selbst und definieren Sicherheits-Header bewusst. So bleibt die Auslieferung schnell und kontrollierbar.
Astro 7.0.9, standardmäßig statisch
Statisches HTML ist der Standard. React-Inseln kommen nur dort zum Einsatz, wo die Oberfläche Interaktion braucht.
Auslieferung über Cloudflare
Die Website wird über Cloudflare ausgeliefert; statische Assets kommen vom Edge. Cloudflare Web Analytics misst die Nutzung ohne Marketing-Cookies.
Schriften selbst gehostet
Geist, Geist Mono und Instrument Serif werden lokal ausgeliefert - ohne Anfragen an externe Schriftanbieter.
Sicherheits-Header und Sprachversionen
Sicherheits-Header werden bei der Auslieferung gesetzt. Die Standardsprache ist de-AT; Englisch liegt unter /en/, beide Versionen sind mit hreflang verknüpft.
Barrierefreiheit
Barrierefreiheit von Anfang an.
Die Website wurde WCAG-orientiert geplant und umgesetzt. Der Lighthouse-Labortest ersetzt keine Prüfung auf WCAG-Konformität.
Semantik, Tastaturbedienung, sichtbare Fokuszustände, Kontrast und verständliche Fehlermeldungen sind von Anfang an Teil der Umsetzung.
- Sinnvolle Überschriftenhierarchie und semantische Seitenbereiche
- Skip-Link, per Tastatur bedienbare Navigation und sichtbare Fokuszustände
- Formulare mit Beschriftungen, Statusmeldungen und verständlichen Fehlern
- Lighthouse-Score für Barrierefreiheit: 100 im Labor - als Signal, nicht als Zertifikat
Unser Prozess
Vier Schritte am eigenen Projekt.
Von der Positionierung bis zum Launch.
01
Verstehen
Wir haben die Positionierung geschärft, DACH als Primärmarkt festgelegt und Deutsch (Österreich) als Standardsprache gewählt.
02
Gestalten
Warm Ink verbindet Instrument Serif für Überschriften, Geist für die Oberfläche und Honey als einzigen Farbakzent. Der Aufbau folgt einem redaktionellen Layout.
03
Entwickeln
React-Inseln wurden sparsam eingesetzt, wichtige Schriften vorgeladen und Sicherheits-Header definiert. Performance wurde von Anfang an geprüft.
04
Live gehen
Auslieferung über Cloudflare, Webanalyse mit Cloudflare Web Analytics ohne Marketing-Cookies, Monitoring und dokumentierte Labormessungen.
Messhinweis
Messmethode und Grenzen.
Testaufbau:
- Tool: Lighthouse 12.8.2 in Headless Chrome
- Je 5 Läufe auf Desktop und Mobile; ausgewiesen sind die Mediane
- Messstandort: Cloudflare PDX; Laborkontext, kein globales Nutzungsprofil
- LCP-Element in allen Läufen: die Wortmarke "posch.cloud" im Header (span.text-lg)
- TTI stammt aus dem ungewichteten Legacy-Audit interactive im Lighthouse-Rohbericht
- Keine CrUX-Felddaten; die Ergebnisse können je nach Gerät und Verbindung abweichen
Messwerte ersetzen kein gutes Handwerk.
Sie machen einen Teil davon sichtbar. Wenn Performance und Barrierefreiheit für deine nächste Website wichtig sind, erzähl uns von deinem Projekt.
Projekt starten