Du öffnest einen neuen Tab, tippst chatgpt.com ein und stellst sofort eine Frage. Kein Login, kein Ladekreis, kein Warten. Die Seite ist interaktiv, die Antwort beginnt Sekunden später. Dieses Erlebnis haben rund eine Milliarde Menschen – chatgpt.com gehört zu den meistbesuchten Websites der Welt. Die Oberfläche wirkt simpel. Dahinter steckt eine Architektur, die den Autor dieses Artikels über Tage beschäftigt hat: Er durchforstete Quellcode, gebündelte Skripte und Netzwerkanfragen, um zu verstehen, wie OpenAI diesen Dienst aufbaut.
Warum ist das relevant? Die Entscheidungen zeigen, wie man eine Webanwendung für Milliarden Nutzer baut – ohne überflüssigen Schnickschnack, mit einer klaren Priorität: der schnellstmöglichen ersten Interaktion. Der Autor arbeitet nicht bei OpenAI und hat nie den Quellcode gesehen. Seine Analyse beruht auf öffentlich zugänglichen Informationen: Markup, JavaScript, CSS, Netzwerkanfragen, ergänzt durch Vorträge, Tweets und die Karriereseite. Das Ergebnis ist eine Mischung aus Geschichte, Detektivarbeit und technischen Erkenntnissen.
Die Grundlage: Ziele und Einschränkungen
Vor dem Bau einer Webapp stehen zwei Fragen: Was ist das Ziel? Unter welchen Einschränkungen arbeiten wir? Der Autor nennt diese beiden Punkte als entscheidend für jede Architekturentscheidung. Bei ChatGPT ist das Ziel klar: die Website sein, mit der die ganze Welt KI nutzt. Sie muss für jeden zugänglich sein – egal ob jemand auf dem Land mit einer langsamen Verbindung surft oder ein Power-User mit MacBook Pro und Pro-Abonnement.
Diese Vorgabe eliminiert ganze Architekturansätze. Ein klassischer Client-seitig gerenderter SPA (Single-Page Application) wäre ungeeignet, weil der Nutzer zuerst einen leeren Bildschirm sähe, während JavaScript heruntergeladen wird. Apps wie Linear kommen damit klar, weil ihre Nutzer sich einmal anmelden und dann den ganzen Tag in der App arbeiten. Für ChatGPT, das auch Erstbesucher ohne Account ansprechen muss, ist das keine Option. Server-seitiges Rendering (SSR) ist hier der bessere Weg, auch wenn es teurer ist und mehr Komplexität mit sich bringt: Daten abrufen, HTML generieren, versenden – dann auf dem Client hydratisieren. Der Autor weist darauf hin, dass dieser Ansatz mehr Fehlermöglichkeiten birgt, aber für die schnellste Erstladezeit und SEO unverzichtbar ist.
Schauen wir uns an, wie ChatGPT das umsetzt. Der Autor hat den aktuellen Stack rekonstruiert: React Router 7, Vite, Tailwind CSS, TanStack Query, Remix (historisch), und einiges mehr. Auffällig ist, dass OpenAI weitgehend auf Standardbibliotheken setzt, statt eigene Frameworks zu bauen. Ein Blick auf Gemini zeigt das Gegenteil: dort wimmelt es von proprietärem Google-Code. ChatGPT wirkt dagegen schlicht und standardisiert – genau das, was man braucht, wenn man auf Milliarden Nutzer skalieren will.
Die Geschichte: Von Next.js zu React Router
Der Werdegang von ChatGPT ist erstaunlich. Der Dienst startete am 30. November 2022 als Next.js 12 App mit dem Pages Router – damals noch als „Research Preview“ mit geringen Erwartungen. Der Autor fand ein interessantes Artefakt aus dieser Zeit: das Routen-Manifest, das noch im Wayback Machine liegt. Es zeigt, wie einfach die erste Webapp war, und deutet auf interne Werkzeuge hin, die im gleichen Build mitausgeliefert wurden – ein typisches Zeichen für ein hastig zusammengestelltes MVP.
ChatGPT hat den Next.js App Router nie übernommen. Fast 21 Monate lang blieb man beim Pages Router, bevor man im August 2024 zu Remix wechselte. Der Wechsel wurde nicht offiziell angekündigt, sondern von aufmerksamen Beobachtern wie Tibor Blaho entdeckt. Ryan Florence, Mitentwickler von Remix, twitterte damals: „New Remix app just dropped: chatgpt.com.“ Was dann folgte, war aufschlussreich: Die Remix-Version nutzte echte Server-Infrastruktur (einen Express-Server, der Routen-Loader ausführte und JSON in window.__remixContext einbettete), rendete aber fast keine sichtbare UI auf dem Server. Es war eine leere Hülle, plus einige Preload-Links und ein Theme-Skript. Die eigentlichen Interaktionen liefen über die eigene API, nicht über Remix-Actions. Remix diente als Router, als Daten-Pipe und als Hydrations-Shell um eine im Wesentlichen clientseitige App.
Als Remix v2 dann im November 2024 mit React Router v7 verschmolz, zog ChatGPT mit. Heute findet man im Seitenquelltext die Zeile ssr: true. Das ist React Router 7 im Framework-Modus – vollständig Vite-basiert, mit Streaming und Server-Rendering. Und hier liegt der entscheidende Unterschied: Die Remix-Ära lieferte eine leere Hülle, aber die heutige App rendert die gesamte ausgeloggte Erfahrung als echtes HTML. Man ist also noch schwerpunktmäßiger auf SSR gegangen. Ein weiteres Detail: Das Client-Manifest listet 354 Routen, aber nur etwa 13 davon sind die eigentliche Chat-App. Der Rest sind Marketing- und Landingpages – alle in derselben Codebase, demselben Router, demselben Deployment. Die meisten Unternehmen trennen Marketing und App (Linear nutzt für Marketing Next.js), aber OpenAI scheint alles in einem Projekt zu bündeln, sodass der Übergang von einer Kampagnenseite zum Chat ein Client-seitiger Navigationsschritt ist – keine frische Seitenladung.
Schnellster Weg zum ersten Pixel
Die gemessene Startseite für ausgeloggte Nutzer ist nur 84 KB groß (komprimiert) und hat eine Time-to-First-Byte von etwa 50–65 Millisekunden – geliefert über Cloudflare-Edge-Server. In dieser Antwort steckt alles, um eine funktionierende App-Hülle darzustellen: rund 30 KB echtes Markup (Sidebar, Begrüßung, Eingabefeld) plus die dazugehörigen Styles. Nach der Hydrasion kommt die Seite auf gerade einmal 548 DOM-Knoten – sehr leicht.
Das Markup selbst ist wenig spektakulär, aber der <head> verrät die Performance-Arbeit. Vor dem Laden eines Bundles laufen Inline-Skripte: das erste ist das bekannte Theme-Selection-Pattern (wie im Linear-Artikel beschrieben) – das gespeicherte Theme aus localStorage wird vor dem ersten Paint auf das html-Element angewendet, damit es nie zu einem Flash des falschen Themes kommt. Direkt danach wird der Zeitstempel des ersten Ausführungspunkts und des ersten Frames aufgezeichnet – für jede einzelne Anfrage. Performance wird ernst genommen: Man misst den gesamten Ladevorgang vom ersten Byte bis zur Interaktivität.
Die HTML-Antwort wird gestreamt. Das ist React 19 Streaming SSR über React Router: Der Server spült sofort die Hülle, und Suspense-Grenzen füllen sich mit Daten, sobald sie eintreffen – eingeflickt durch winzige Inline-Skripte. Die Loader-Daten kommen parallel über einen eigenen ReadableStream. In diesen Daten steckt eine Reihe von Server-Entscheidungen, was der Client vorwärmen soll: shouldPrefetchModels, shouldPrefetchHistory, shouldPrefetchStarredConversations. Der Server gibt einen individuellen Prefetch-Plan pro Nutzer vor. Der Client ist nur eine dünne Hülle, die vom Server gesteuert wird. Für einen Chat-Dienst ist das ideal: Die Antwort bestimmt durch Tokens, Markdown und Widgets, was gezeigt wird – das HTML-Dokument spiegelt das wider.
Die Authentifizierung folgt einem „Render-first“-Ansatz: Ein ausgeloggter Besucher wird nie durch einen Auth-Check blockiert. Stattdessen betreibt das Backend eine parallele anonyme Oberfläche: /backend-anon/me, /backend-anon/models, /backend-anon/conversation. Anonyme Besucher erhalten eine echte User-ID, sodass Ratenlimits und Experimente ohne Konto funktionieren. Es gibt kein „bist du eingeloggt“-Hin und Her zwischen Nutzer und Eingabefeld. Das ist die direkte Umsetzung der eingangs genannten Einschränkung: so vielen Menschen wie möglich den schnellsten Weg zur KI zu ebnen.
CSS im Milliarden-Maßstab
ChatGPT ist eine der größten Tailwind-Apps der Welt. Adam Wathan nahm sie bereits im März 2023 in die Tailwind-Galerie auf. Als OpenAI 2024 das Framework wechselte, überlebte Tailwind. Wes Bos scherzte gegenüber Tanner Linsley: „Du (TanStack Query) und Tailwind seid die Einzigen, die bei dem Umbau nicht gefeuert wurden.“ Der Vorteil von Tailwind: Es lässt sich deutlich einfacher server-seitig rendern als CSS-in-JS-Lösungen wie styled-components. Man spart den Overhead, indem man CSS in Stylesheets statt in Skripten ausliefert.
Betrachtet man ein beliebiges Element, sieht man die bekannten Utility-Klassen – aber mit einer Besonderheit: Daneben tauchen Klassen wie token- auf. Das ist das Designsystem: eine semantische CSS-Variable-Ebene, die unterhalb der Utility-Klassen liegt. So kann OpenAI das Aussehen der App global steuern, ohne tausende Tailwind-Klassen zu ändern. Ein Kompromiss zwischen Skalierbarkeit und Flexibilität.
Ein weiteres Detail: Um das Bekanntheitsgefühl zu steigern, werden Schriftarten mit font-display: swap geladen – der Text wird sofort mit einer System-Schrift dargestellt und später durch die gewünschte Schriftart ersetzt. Das verhindert unsichtbare Textblöcke.
Nicht das Rad neu erfinden
Der Autor hebt hervor, dass OpenAI fast ausschließlich auf bewährte Open-Source-Bibliotheken setzt: React Router, TanStack Query, Tailwind, Vite, und für das Rendering React 19. Es gibt keine hauseigene State-Management-Lösung, kein proprietäres Routing. Das mag unspektakulär klingen, ist aber ein entscheidender Faktor für die Skalierbarkeit. Wenn tausend Entwickler an einer Codebasis arbeiten und ständig neue Funktionen ausgerollt werden, sind Standardbibliotheken mit klaren APIs und guter Dokumentation Gold wert. Man muss nicht jedes Mal erklären, wie ein eigenes System funktioniert.
Das zeigt sich auch in der Art, wie Komponenten gebaut sind. Die UI besteht aus vielen kleinen, wiederverwendbaren Teilen – aber nicht aus tausenden Mikrokomponenten. Der Autor findet, dass die Komplexität vor allem im Datenfluss und im Rendering liegt, nicht in der Darstellung. Denn letztendlich ist jede Antwort ein Render-Problem: Der Server generiert Markup, der Client fügt es ein. Ob das nun ein einfacher Textblock ist oder ein interaktives Diagramm – die Grundstruktur bleibt gleich.
Kannst du schon tippen?
Der vielleicht wichtigste Indikator für eine gute UX ist die Tastatur-Eingabe. Der Autor misst die Zeit, bis das Eingabefeld fokussiert werden kann. Dank des SSR-Ansatzes ist der Fokus sofort nach dem ersten Paint möglich – noch bevor die JavaScript-Bundles vollständig geladen sind. Das ist ein konsequenter Schritt: Der Nutzer soll nichts anderes tun können, als seine Frage einzutippen. Kein Warten auf Logik, keine Verzögerung. Alles andere ist sekundär.
Um das zu erreichen, verwendet ChatGPT einen Mechanismus, der den Tastatur-Event schon auf dem unhydrierten DOM erlaubt. Sobald der Nutzer tippt, wird die Eingabe in einem temporären Buffer gespeichert und nach der Hydrasion in den React-State übernommen. Das ist eine kleine Optimierung.
Feature-Flagging und das Einlassen von Milliarden Fremder
OpenAI schaltet neue Features nicht für alle gleichzeitig frei. Stattdessen nutzen sie ein System aus Feature-Flags, gesteuert durch den Server. Der Kunde erfährt erst zur Laufzeit, welche Funktionen aktiv sind. Das erlaubt Experimente mit einem kleinen Prozentsatz der Nutzer, ohne die Stabilität zu gefährden. Gleichzeitig ist das die Basis, um den Dienst für eine Milliarde Nutzer zu öffnen: Man kann die Infrastruktur langsam aufbauen, Engpässe erkennen und beheben.
Der anonyme Zugang ohne Account ist das Paradebeispiel dafür. Der Autor vermutet, dass diese Entscheidung eine der größten Hürden für die Verbreitung von KI-Diensten beseitigt: die Registrierung. Indem OpenAI den Login-Schritt überspringt, sinkt die Abbruchrate drastisch. Jeder, der chatgpt.com aufruft, kann sofort loslegen. Das ist die logische Konsequenz aus dem Ziel, die Website der Welt für KI zu sein.
Der Unterschied zu Claude und anderen
Abschließend vergleicht der Autor ChatGPT mit Claude von Anthropic. Claude setzt auf eine ähnliche Architektur, aber mit feinen Unterschieden. Während ChatGPT auf Tailwind und React Router setzt, verwendet Claude eine eigene Komponentenbibliothek. Beide verfolgen das SSR-Prinzip, aber ChatGPT ist aggressiver beim Server-Rendering der Ausgeloggten-Seite. Auch die Entscheidung, Marketing und App in einem Projekt zu bündeln, ist einzigartig. Das Ergebnis: ChatGPT lädt schneller und ist zugänglicher, aber Claude bietet vielleicht eine konsistentere visuelle Identität. Letztlich zeigt der Vergleich, dass es nicht die eine richtige Lösung gibt – sondern die, die am besten zu den eigenen Zielen passt.
Was bedeutet das für uns?
Die Analyse von ChatGPT Web zeigt, wie eine Organisation mit klaren Zielen und klugen Kompromissen ein Produkt für Milliarden baut. Der Weg von Next.js über Remix zu React Router spiegelte eine Evolution der Prioritäten wider: von einem schnellen MVP zu einer stabilen, skalierbaren Plattform. Die Konzentration auf Standardbibliotheken, die extreme Performance-Optimierung und die radikale Zugänglichkeit ohne Account sind Prinzipien, die jedes Team – ob Startup oder Großkonzern – auf seine eigene Situation übertragen kann.
Wenn du chatgpt.com öffnest und sofort eine Frage triffst, steckt hinter dieser Eingabezeile Jahre an Architekturarbeit, unzählige Abwägungen und der Mut, auch mal Altes über Bord zu werfen. So baut man Software für eine Milliarde Menschen.
Quelle: performance.dev
