Echtzeit in Web-Apps

„Echtzeit" steht in vielen Lastenheften — gemeint ist meistens etwas anderes als technische Echtzeit. Es geht darum, dass Nutzer Änderungen sehen, ohne die Seite manuell neu zu laden: ein neuer Auftrag erscheint im Dashboard, der Status eines Vorgangs ändert sich live, ein zweiter Mitarbeiter sieht in derselben Maske, was gerade bearbeitet wird.

Für diese Anforderung gibt es drei etablierte Techniken: WebSockets, Server-Sent Events (SSE) und Polling. Sie unterscheiden sich in Komplexität, Ressourcenbedarf und Einsatzbereich erheblich. Dieser Artikel ordnet sie ein — mit dem Ziel, die richtige Wahl zu treffen, statt reflexhaft zur „mächtigsten" Lösung zu greifen.

WebSockets passen, wenn...

• Daten in beide Richtungen fließen (Chat, kollaboratives Bearbeiten, Live-Konfiguration).
• niedrige Latenz zentral ist (Spiele, Trading, Echtzeit-Steuerung von Geräten).
• viele Nachrichten pro Sekunde übertragen werden — der Overhead pro Nachricht ist minimal.

SSE passt, wenn...

• Updates nur vom Server zum Browser fließen müssen (Dashboards, Statusmeldungen, Live-Listen, Notifications).
• die Infrastruktur HTTP-nah bleiben soll — SSE läuft durch jedes Reverse-Proxy- und CDN-Setup, das normales HTTP versteht.
• Sie eine einfache Lösung suchen, die ohne zusätzliche Bibliotheken stabil funktioniert.

Polling passt, wenn...

• Updates selten sind und Verzögerungen von einigen Sekunden oder Minuten akzeptabel.
• die Server-Infrastruktur keine dauerhaften Verbindungen zulässt (z. B. striktes Hosting-Setup, klassische PHP-Umgebungen).
• die Implementierung so einfach wie möglich bleiben soll — Polling braucht weder spezielle Server-Komponenten noch eigene Protokolle.

In der Praxis ist Polling oft die richtige erste Lösung, auch wenn sie sich nach „Notlösung" anhört: Wenn ein Statusfeld einmal pro Minute aktualisiert wird, ist eine permanent offene Verbindung schlicht überdimensioniert.

Drei Punkte, an denen Echtzeit-Projekte regelmäßig stolpern:

• Reverse Proxies und Load Balancer. Manche Standardkonfigurationen unterbrechen lange offene Verbindungen nach kurzer Zeit. WebSockets und SSE brauchen passende Timeouts — das wird gerne erst beim Go-Live entdeckt.
• Skalierung über mehrere Server. Sobald Ihre Web-App auf mehreren Instanzen läuft, müssen Echtzeit-Nachrichten zwischen diesen Instanzen ausgetauscht werden. Das erfordert eine zusätzliche Komponente (z. B. Redis Pub/Sub) — und genau dieser Schritt wird in Prototypen oft vergessen.
• Authentifizierung. WebSocket- und SSE-Verbindungen müssen gegen denselben Sicherheitsstandard geprüft werden wie reguläre HTTP-Endpunkte. Token, Session-Bindung, Rollen — alles muss auch hier greifen.
• Mobiles Verhalten. Smartphones beenden offene Verbindungen aggressiv, sobald die App in den Hintergrund wechselt. Eine saubere Reconnect-Strategie ist Pflicht, sonst sieht der Nutzer beim Zurückkehren veraltete Daten.

Pragmatisches Vorgehen statt Reflex: selten direkt mit WebSockets beginnen, weil sie häufig mehr Komplexität einführen, als das Projekt benötigt. Für die meisten Anwendungen reicht SSE für Server-zu-Browser-Updates oder Polling für seltene Aktualisierungen — beide sind robust, einfach zu betreiben und laufen durch jede Standard-Infrastruktur.

Erst wenn der Anwendungsfall echte bidirektionale Kommunikation verlangt — etwa kollaboratives Bearbeiten oder eine Live-Steuerung — sind WebSockets die richtige Wahl. Dann aber von Anfang an mit Plan: passende Reconnect-Logik, Heartbeats, klare Trennung zwischen Echtzeit-Layer und Geschäftslogik.

Wenn Sie sich unsicher sind, welche Technik zu Ihrem Anwendungsfall passt: Eine kurze Beschreibung, was live aktualisiert werden soll und wer wem etwas schickt, reicht meistens, um die Auswahl in fünfzehn Minuten zu klären.