Architektonisches F&E-Exemplar 01 — Referenz: diese Seite
Zero-Trust-Briefing-Pipeline, an ein gemessenes Performance-Budget gebunden
Architektonisches F&E-Exemplar: Forschung und Entwicklung des Studios, in diesem Repository gebaut und gemessen. Es ist keine Kundenarbeit und beschreibt keinen Kunden. Jede Zahl auf dieser Seite ist gemessen oder berechnet, ihre Methode ist angegeben.
Entwurfsfrage
Kann eine öffentliche Website, die Anfragen von Entscheidern entgegennimmt, alles ablehnen, was sie nicht prüfen kann, keine Cookies setzen und keine Analyse betreiben und dennoch mit einem Lighthouse-Performance-Wert von 100 gemessen werden, auf dem Desktop und auf einem gedrosselten Telefon? Diese Seite ist das Exemplar: die eigene Eingangstür des Studios, gebaut nach den Toleranzen, die es verkauft.
Nachweisstufe A: in diesem Repository umgesetzt und durch seine Tests geprüft. Die Messungen sind Labordaten einer Maschinenklasse; ihre Grenzen stehen unter „Zielkonflikte und Grenzen“.
I
Randbedingung und Toleranz
Drei Randbedingungen standen vor jedem Code fest, und jede wird bei jedem Release geprüft.
Vertrauensgrenze: Nichts aus dem Browser wird vertraut. Herkunft, Körpergröße, Schema, Honigtopf und Ausfüllzeit, eine Bot-Prüfung und ein Bereiniger laufen in dieser Reihenfolge auf dem Server. Eine Anfrage, die an einer davon scheitert, wird abgelehnt, nie repariert.
Datensparsamkeit: keine Cookies, keine Analyse, nichts im Browser gespeichert. Der einzige Dritte ist eine Bot-Prüfung, geladen im letzten Schritt des Formulars und nur dort, wo die Zustellung angebunden ist.
Bildtakt: Der eigene Rhythmus des Bildschirms bleibt beim Scrollen erhalten. Im aufgezeichneten Scroll beträgt das Bildintervall auf einem 60-Hz-Display im Median 16,7 ms und im 99. Perzentil 16,9 ms, ein Bild je Aktualisierung.
II
Architektur
Eine Route, eine Pipeline und ein Renderpfad, der das Framework vom kritischen Pfad fernhält.
Zustell-Pipeline: Browser, Herkunftsprüfung und Ratenbegrenzung, Schemavalidierung, Bot-Prüfung, Bereiniger und Prioritätsklasse, dann Zustellung per signiertem Webhook (HMAC-SHA256, idempotent) oder per SMTP über TLS an das Postfach des Studios. Jeder Schritt kann ablehnen; eine Ablehnung beendet die Anfrage und bietet dem Besucher einen E-Mail-Entwurf an. Das System schließt im Fehlerfall.
Rendering: serverseitig gerenderte Seiten unter einer durchgesetzten Content-Security-Policy mit einem Nonce je Anfrage. Das Framework startet nach dem ersten inhaltlichen Rendering hinter einem einzigen Loader-Skript, sodass das erste Rendering nicht darauf wartet. Abschnitte unterhalb des sichtbaren Bereichs werden bei Bedarf gegen eine gemessene Platzhalterhöhe gezeichnet.
Kryptografie im Offenen: Ein Sicherheitssimulator auf der Seite signiert und versiegelt eine Nachricht im Browser des Besuchers mit Web Crypto (HMAC-SHA256, AES-256-GCM), mit denselben Funktionen und denselben Tests wie die Referenzarchitektur.
III
Verifikation
Behauptungen werden an ausführbare Prüfungen gebunden, nicht an Screenshots.
Vor jedem Release laufen ein Design-Audit mit mehr als zweihundert Prüfungen und ein HTTP-Smoke-Test mit mehr als hundertachtzig gegen einen Produktions-Build, danach ein Flow in einem echten Browser in zwei Viewports; nach dem Release läuft eine Live-Prüfung.
Barrierefreiheit wird mit axe über Seiten, Sprachen und Viewports geprüft (keine Verstöße). Die Content-Security-Policy wird in einem echten Browser gegen die Live-Seite geprüft (keine Verstöße, keine Konsolenfehler). Die Share-Karte wird in jeder Sprache gerendert und verglichen, in der die Seite veröffentlicht ist.
Layoutbewegung wird so getestet, wie sie geschieht: Platzhalterhöhen innerhalb von 15 % der gezeichneten Höhe, und die Wahl einer Budgetstufe bewegt nichts. Die Layoutverschiebungs-Metrik des Browsers ignoriert Verschiebungen innerhalb von 500 ms nach einem Klick; deshalb vergleicht der Test Positionen und Höhen.
Die Zustellung wird Ende zu Ende gegen einen lokalen SMTP-Empfänger mit einem echten Bot-Prüfungs-Token verifiziert. Über die Annahme durch einen bestimmten Mail-Anbieter wird nichts behauptet.
IV
Gemessenes Ergebnis und Grenzen
Was gemessen wird und auf welchem Profil.
Gemessen
Dies sind die veröffentlichten, datierten Messungen der Live-Seite. Die Bildwerte sind die Intervalle zwischen den Bildern eines aufgezeichneten Scrolls über die ganze Seite.
- Lighthouse-Performance
- 100 · 100
- Desktop · mobil
- Largest Contentful Paint
- 425 ms
- Desktop
- Layoutverschiebung (CLS)
- 0,00
- Desktop
- Bildintervall (Median · 99. Perzentil)
- 16,7 · 16,9
- ms · 60-Hz-Display, ein Bild je Aktualisierung
Lighthouse, desktop preset, live production (syncflow.agency), median of 5 runs, 17. Okt. 2026. Bild-Sampler: 1280×800, Headless-Chrome, 60 Hz, 8. Okt. 2026.
Zielkonflikte und Grenzen
Was dieser Entwurf kostet und was die Zahlen nicht beweisen.
Labordaten, keine Felddaten
Lighthouse-Läufe sind Labormessungen auf einer Maschinenklasse. Der Mobilwert ist, wie das Profil oben angibt, der Median von Läufen auf einer ruhigen Maschine; auf einem ausgelasteten Rechner erreicht derselbe Build weniger, weil die Hydration im Fenster der Gesamtblockierzeit liegt. Ein Lauf unter Last wird nie als 100 veröffentlicht.
Bildtakt, nicht Bildarbeit
Die Bildwerte sind Intervalle zwischen Bildern bei 60 Hz, wobei 16,7 ms ein Bild sind. Sie zeigen, dass im aufgezeichneten Scroll kein Bild ausgelassen wurde; sie sagen nicht, wie lange die eigene Arbeit eines Bildes dauert.
Strenge hat ihren Preis
Eine durchgesetzte Richtlinie und eine Route, die im Fehlerfall ablehnt, bedeuten: Eine fehlende Einstellung erzeugt einen Fehler statt eines stillen Erfolgs. Das Formular sagt das vor der Nutzung und bietet einen E-Mail-Entwurf an.
Gemessen auf
- Lighthouse 13.5 · live production
- 412×823 · slow 4G · 4× CPU
- 1280×800 · 60 Hz · frame sampler