Webentwicklung

Performance ist kein letzter Schliff, sondern eine Entwurfsvorgabe

Eine langsame Anwendung wird nicht schnell: sie wird neu gebaut. Geschwindigkeit entscheidet sich beim Entwurf — was auf dem Server gerendert wird, was in den Browser geht, was gar nie entstehen muss.

Sie ist zudem messbar und öffentlich. Google bewertet jede Website anhand von drei Kennzahlen, im 75. Perzentil echter Besuche über 28 rollende Tage — also an dem, was drei Viertel Ihrer Besucher tatsächlich erleben, nicht an einem Labortest:

• LCP — Darstellung des Hauptinhalts: unter 2,5 s
• INP — Reaktion auf Interaktionen: unter 200 ms
• CLS — visuelle Stabilität: unter 0,1

Diese Schwellen sind unsere Zusage von Beginn weg, kein Ziel, das am Projektende verhandelt wird.

Die richtige Menge JavaScript wählen

Die meisten langsamen Websites sind es aus einem einzigen Grund: sie schicken ein ganzes Programm in den Browser, wo eine Seite genügt hätte. Wir entscheiden Seite für Seite.

• Statische Seite — redaktionelle Inhalte, Präsentationsseiten, Artikel. Beim Build gerendert, unverändert ausgeliefert. Nichts, was der Client ausführen muss.
• Server-Rendering — personalisierte Inhalte oder solche, die sich bei jedem Besuch ändern. Der Browser erhält fertiges HTML und wartet auf nichts.
• Interaktive Inseln — nur Komponenten, die es brauchen, laden JavaScript: ein Formular, ein Filter, eine Karte. Der Rest der Seite lädt keines.

Diese Website ist das Beispiel dafür: sie ist mit Astro gebaut, und die meisten ihrer Seiten laden überhaupt kein Anwendungsskript.

Eine Anwendung wird über fünf Jahre beurteilt, nicht bei der Aufschaltung

Die Kosten einer Anwendung fallen nach der Auslieferung an. Drei Entscheidungen wiegen schwerer als alle anderen:

1. Typen von Ende zu Ende. TypeScript vom Datenmodell bis zur Oberfläche. Eine Schemaänderung, die etwas bricht, meldet sich beim Kompilieren — nicht sechs Wochen später in der Produktion.
2. Tests, die Regeln beschreiben, keine Zustände. Ein Test mit der Aussage «die Startseite zeigt zwölf Artikel» bricht bei jeder Veröffentlichung. Ein Test mit der Aussage «jeder veröffentlichte Artikel erscheint in seinem Index» hält.
3. Abhängigkeiten, die man wieder loswird. Jede Bibliothek ist eine künftige Schuld. Wir nehmen wenige, ausgewählt nach Stabilität und nach der Möglichkeit, sie wieder zu verlassen.

Die Auslieferung messen, nicht die Betriebsamkeit

Wir verfolgen die vier Referenzkennzahlen des DORA-Programms, die Teams, die liefern, von Teams unterscheiden, die beschäftigt wirken: Häufigkeit der Produktivsetzung, Zeit von Commit bis Livegang, Anteil der Auslieferungen mit Störung, Wiederherstellungszeit.

Sie haben eine ungewöhnliche Eigenschaft: sie belohnen Vorsicht nicht. Ein Team, das selten liefert, um «Risiken zu begrenzen», erscheint als genau das — ein Team, für das jede Auslieferung ein riskantes Ereignis ist.

Bestehendes überarbeiten statt alles neu schreiben

Eine vollständige Neuentwicklung ist fast immer die falsche Wahl: sie friert die Weiterentwicklung monatelang ein und wiederholt dieselben Fehler auf neuerer Technologie. Wir isolieren lieber, was Probleme macht, ersetzen es hinter einer stabilen Schnittstelle und lassen den Rest, solange er Dienst tut. Ein funktionierendes System verdient mehr als eine Neuentwicklung aus Prinzip.