Wie man eine Unternehmenswebsite aufbaut: Notizen zu unserer eigenen Website

Die Website eines Softwareunternehmens ist die erste Software, die das Unternehmen schreibt. Wer sie öffnet, sieht den Code nicht, aber das Ergebnis. Lädt die Seite langsam, steht in einer Sprache noch ein türkischer Satz oder funktioniert das Kontaktformular stillschweigend nicht, schließt der Besucher daraus auf die Arbeit des Unternehmens.

Deshalb haben wir die Website nicht wie eine Broschüre gebaut, sondern wie ein kleines Produkt. Im Folgenden schreibe ich, welche Entscheidung wir warum getroffen haben und wo wir uns geirrt haben.

Statische Generierung

Die Website ist mit Next.js geschrieben. In der ersten Version wurden die Seiten bei jeder Anfrage auf dem Server neu erzeugt. Der Grund war eine harmlose Zeile: Das Root-Layout las den Request-Header, um die Sprache zu ermitteln. Next stuft jede Seite, bei der es das sieht, als dynamisch ein.

Die Folge: Cloudflare konnte keine einzige Seite cachen. Jeder Besuch ging bis zum Server bei Hetzner. Lokal gemessen lag die Time to First Byte bei wenigen Millisekunden. Der Code war also nicht langsam. Das Problem hätte sich erst bei größerer Last gezeigt.

Die Lösung bestand darin, die Sprache nicht aus der Anfrage, sondern aus der Adresse abzuleiten. Jede Sprache hat ihr eigenes Root-Layout. Die Sprache ergibt sich aus dem Ordner, in dem die Seite liegt. Heute werden alle rund dreihundert Seiten einmal während des Builds erzeugt.

Sieben Sprachen und Konsistenz

Die Website ist auf Türkisch, Englisch, Französisch, Portugiesisch, Deutsch, Spanisch und Arabisch online. Die Übersetzung selbst ist der leichte Teil der Arbeit. Schwierig ist, dass sich ein Text bei einer Änderung an sieben Stellen gleichzeitig ändern muss.

Die meisten Fehler, die wir bei den ersten Prüfungen fanden, folgten demselben Muster. Eine lange Kette von Bedingungen, die den Text je nach Sprache auswählte, fiel stillschweigend in den letzten Zweig, wenn eine Sprache vergessen wurde. Und der letzte Zweig war meist Türkisch. So landete ein türkischer Satz mitten auf einer französischen Seite.

Das haben wir mit einer Hilfsfunktion behoben. Jede Stelle, die einen Text auswählt, muss alle sieben Sprachen auf einmal liefern. Fehlt eine Sprache, lässt sich der Code nicht kompilieren. Der Fehler wird erkannt, bevor er online geht.

Akademische Titel waren ein ähnliches Problem. In einer Übersetzung war aus dem Titel „Doç. Dr.“ ein Professor geworden. Titel werden jetzt in keiner Sprache mehr übersetzt. Sie stammen aus dem türkischen Datensatz, und ein Test prüft das bei jedem Push.

Tests

Ein schweres Test-Framework haben wir nicht aufgesetzt. Mit dem eingebauten Testmodul von Node haben wir neun Tests geschrieben. Jeder davon fängt einen Fehler ab, der uns zuvor tatsächlich passiert ist.

Dazu gehören: Der Titel bleibt in jeder Sprache gleich. In keinem Text steht ein Geviertstrich. Der Markenname wird nicht übersetzt. Jeder türkische Beitrag hat eine Entsprechung in sechs Sprachen. Rechtstexte werden in der Übersetzung nicht zusammengefasst. Der letzte Test ist grob, aber er funktioniert: Ist eine Rechtsseite in einer Sprache kürzer als sechzig Prozent der türkischen Fassung, wurde sie sehr wahrscheinlich zusammengefasst.

Bei jedem Push auf GitHub laufen Typprüfung, Lint, diese Tests und der Produktions-Build. Schlägt einer davon fehl, geht die Version nicht online.

Sicherheit

Die Content Security Policy ist streng. Skripte, Schriften und Bilder dürfen nicht von fremden Domains geladen werden. Die Schriften kommen von unserem eigenen Server. Deshalb sendet der Browser des Besuchers beim Öffnen der Seite keine Anfrage an Dritte. Google Analytics wird nur geladen, wenn der Besucher zustimmt.

Die Ansicht des Arbeitsprotokolls auf der Startseite sendet den Text, den der Besucher eingibt, an ein Sprachmodell. Das ist die Stelle der Website, die sich am leichtesten missbrauchen lässt. Wer ein kostenpflichtiges Modell gratis nutzen will, kann den Endpunkt direkt aufrufen. Das verhindern wir mit mehreren Schichten: einer Prüfung, ob die Anfrage von unserer Seite kommt, einem kurzlebigen, einmal verwendbaren signierten Ticket, einem stündlichen und täglichen Limit pro Adresse, einer täglichen Obergrenze für die gesamte Website und einem Limit für die Zahl der Anfragen, die gleichzeitig an das Modell gehen dürfen.

Deployment

Der Code liegt auf GitHub. Auf dem Server bei Hetzner läuft Coolify. Bei jedem Push auf den Hauptzweig baut es die Website als Docker-Image neu und bringt sie online. Ein Deployment dauert etwa zweieinhalb Minuten.

Davor sitzt Cloudflare. Mit dem Wechsel zur statischen Generierung lässt sich auch das HTML cachen. Die Seiten bleiben dort bis zu einer Stunde.

Wo wir uns geirrt haben

Der Cache war nicht nur die Quelle der Geschwindigkeit, sondern auch die Quelle eines Irrtums. Wir haben eine neue Version veröffentlicht. Coolify meldete Erfolg, aber die Startseite erschien in ihrer alten Fassung. Der Grund war einfach. Cloudflare forderte keine neue Kopie an, solange die vorhandene nicht abgelaufen war.

Die richtige Lösung ist, den Cache am Ende jedes Deployments automatisch zu leeren. Eine Veröffentlichung gilt erst dann als abgeschlossen, wenn sie nicht nur auf dem Server, sondern dort abgeschlossen ist, wo der Besucher sie sieht.

Dann ist da noch die Barrierefreiheit. Der automatische Scan fand auf den Seiten keine Fehler. Aber die kleinen Beschriftungen auf der Startseite lagen über einem halbtransparenten Foto, und das Scan-Werkzeug kann den Kontrast über einem Foto nicht messen. Wir haben die Pixel hinter den Beschriftungen gesondert gemessen. Das Verhältnis lag bei etwa 3:1. Nachdem wir das Foto etwas aufgehellt und die Beschriftungen einen Ton dunkler gemacht hatten, lag es über 5:1. Auch wenn das Werkzeug „keine Fehler“ meldet, muss man hinsehen.

Warum wir das erzählen

Einem Kunden zu sagen „Wir liefern funktionierende Software“ ist leicht. Wenn wir offen beschreiben, was wir bei dieser Website getan haben, lässt sich auch leichter erkennen, worauf dieser Satz beruht.