Keep Alive
Was ist Keep Alive?
Keep Alive bezeichnet das Offenhalten einer Netzwerkverbindung für mehrere aufeinanderfolgende Anfragen. Bei Webseiten kann der Browser dadurch weitere Dateien über eine bestehende Verbindung laden, statt jedes Mal eine neue TCP- und TLS-Verbindung aufzubauen. Das reduziert Verbindungsaufwand und kann die Ladezeit bei mehreren Ressourcen verkürzen.
Wie Keep Alive funktioniert
Keep Alive (deutsch: Verbindung aufrechterhalten) ermöglicht die Wiederverwendung einer bestehenden Verbindung zwischen Client und Server. Ruft ein Browser beispielsweise eine HTML-Datei, mehrere Stylesheets, Skripte und Bilder von derselben Domain ab, können diese Ressourcen nacheinander oder parallel über bereits geöffnete Verbindungen übertragen werden.
Ohne Wiederverwendung muss der Client für zusätzliche Anfragen neue Verbindungen herstellen. Allein der Aufbau einer TCP-Verbindung benötigt mindestens eine vollständige Hin- und Rückübertragung zwischen Client und Server. Bei HTTPS kommt die Abstimmung der Verschlüsselung hinzu. Je höher die Netzwerklatenz und je größer die Zahl der Ressourcen, desto stärker fällt dieser zusätzliche Aufwand auf.
Keep Alive in den HTTP-Versionen
Die technische Umsetzung hängt von der verwendeten HTTP-Version ab. Bei HTTP/1.0 wurden Verbindungen ursprünglich nach einer Antwort geschlossen. Eine dauerhafte Verbindung musste ausdrücklich vereinbart werden. Seit HTTP/1.1 sind persistente Verbindungen grundsätzlich vorgesehen, sofern Client oder Server die Verbindung nicht mit Connection: close beendet.
| Protokoll | Verbindungsverhalten | Besonderheit |
|---|---|---|
| HTTP/1.0 | Verbindung wird normalerweise geschlossen | Connection: keep-alive fordert die Wiederverwendung an |
| HTTP/1.1 | Verbindung bleibt grundsätzlich offen | Connection: close beendet die Wiederverwendung |
| HTTP/2 | Eine Verbindung überträgt mehrere Anfragen | Multiplexing reduziert parallele Einzelverbindungen |
| HTTP/3 | Mehrere Datenströme laufen über QUIC | QUIC verwendet UDP statt TCP als Transportbasis |
Bei HTTP/2 und HTTP/3 wird Keep Alive nicht mehr über den klassischen Connection-Header gesteuert. HTTP/2 bündelt mehrere Datenströme in einer Verbindung. HTTP/3 nutzt dafür QUIC. Header wie Connection: keep-alive gehören deshalb nicht in HTTP/2- oder HTTP/3-Nachrichten.
Timeout und maximale Anfragen
Eine offene Verbindung bleibt nicht unbegrenzt bestehen. Webserver, Proxyserver, Content Delivery Networks und Load Balancer können eigene Zeitlimits setzen. Ein Keep-Alive-Timeout von fünf Sekunden bedeutet beispielsweise, dass der Server eine ungenutzte Verbindung nach fünf Sekunden schließen darf. Der Server kann eine Verbindung jedoch auch früher beenden, etwa wegen Ressourcenlimits oder eines Neustarts.
Bei HTTP/1.x kann ein Server zusätzlich eine maximale Anzahl von Anfragen pro Verbindung vorsehen. Die historische Angabe Keep-Alive: timeout=5, max=100 beschreibt beispielsweise ein Zeitlimit von fünf Sekunden und höchstens 100 Anfragen. Der Header ist kein verlässlicher Befehl an alle beteiligten Systeme, da zwischengeschaltete Proxys eigene Regeln anwenden können.
Relevanz für SEO und Ladezeit
Keep Alive ist kein eigenständiger Ranking-Faktor. Die Konfiguration kann jedoch die technische Nutzererfahrung beeinflussen, weil weniger Verbindungsaufbauten die Übertragung mehrerer Dateien beschleunigen können. Der Effekt betrifft vor allem Seiten, die viele Ressourcen derselben Domain über HTTP/1.1 laden. Bei HTTP/2 und HTTP/3 übernimmt das Protokoll einen größeren Teil der Verbindungsoptimierung.
Für SEO sollte Keep Alive deshalb gemeinsam mit Dateigrößen, Serverantwortzeit, Caching, Komprimierung und der Zahl blockierender Ressourcen bewertet werden. Eine langsame Seite wird durch eine offene Verbindung allein nicht schnell. Eine technische Analyse zeigt, ob der Verbindungsaufbau tatsächlich Zeit beansprucht oder ob größere Potenziale bei Bildern, JavaScript und Serververarbeitung liegen. Ein strukturierter Einstieg ist eine Analyse mit einem technischen SEO-Crawler.
Messbar ist das zum Beispiel so: Öffne die Netzwerkansicht der Browser-Entwicklertools und untersuche mehrere Dateien derselben Domain. Wiederholen sich bei zahlreichen HTTP/1.1-Ressourcen die Phasen für DNS, TCP und TLS, werden Verbindungen nicht ausreichend wiederverwendet oder früh geschlossen. Ergänzend liefert ein kostenloser Ladezeiten-Check eine übergreifende Bewertung der Website-Geschwindigkeit.
Prüfe die Ladezeit deiner Seite direkt:
Keep Alive richtig konfigurieren
Keep Alive wird auf der Ebene des Webservers oder eines vorgeschalteten Systems konfiguriert. Bei Apache, Nginx, Hosting-Plattformen und Content Delivery Networks unterscheiden sich die konkreten Einstellungen. Vor einer Änderung solltest du deshalb feststellen, welches System die Verbindung tatsächlich beendet. Ein Header-Test allein reicht nicht aus, wenn ein Reverse Proxy oder Load Balancer zwischen Browser und Ursprungsserver steht.
Abgrenzung zu ähnlichen Techniken
Der Unterschied zwischen HTTP Keep Alive und TCP Keepalive liegt im Zweck. HTTP Keep Alive dient der Wiederverwendung einer Verbindung für weitere HTTP-Anfragen. TCP Keepalive sendet dagegen nach längerer Inaktivität Prüfpakete, um zu erkennen, ob die Gegenstelle noch erreichbar ist. Beide Mechanismen arbeiten auf unterschiedlichen Protokollebenen und haben getrennte Zeitlimits.
Der Unterschied zwischen Keep Alive und WebSockets liegt in der Kommunikation. Keep Alive hält eine HTTP-Verbindung für weitere Anfragen verfügbar, während WebSockets nach dem Verbindungsaufbau eine dauerhafte Kommunikation in beide Richtungen ermöglichen. Für Chats oder Live-Daten können WebSockets geeignet sein. Für gewöhnliche HTML-, Bild- und Skriptanfragen genügt die Wiederverwendung der HTTP-Verbindung.
Keep Alive ersetzt außerdem kein Browser-Caching. Eine wiederverwendete Verbindung verkürzt den Transport einer erneut angeforderten Ressource. Caching kann die Anfrage vollständig vermeiden oder mit einer kurzen Gültigkeitsprüfung beantworten. Für eine umfassende technische Optimierung sollten beide Mechanismen im Rahmen der Onpage-Optimierung getrennt geprüft werden.
Häufige Fragen zu Keep Alive
Wie erkenne ich, ob Keep Alive aktiv ist?
Prüfe die Netzwerkansicht der Browser-Entwicklertools und die verwendete HTTP-Version. Bei HTTP/1.1 sollten mehrere Ressourcen dieselbe Verbindung nutzen. Bei HTTP/2 und HTTP/3 ist die Wiederverwendung Bestandteil des Protokolls, weshalb ein klassischer Keep-Alive-Header nicht erforderlich ist.
Muss Keep Alive bei HTTP/2 aktiviert werden?
Nein, HTTP/2 verwaltet mehrere Anfragen über eine gemeinsame Verbindung und verwendet dafür Multiplexing. Der klassische Connection-Header darf in HTTP/2-Nachrichten nicht zur Steuerung von Keep Alive eingesetzt werden.
Welcher Keep-Alive-Timeout ist richtig?
Es gibt keinen universellen Wert für jede Website. Der Timeout muss zur Serverkapazität, zum Traffic, zur HTTP-Version und zu vorgeschalteten Systemen passen. Änderungen sollten mit Last, Antwortzeiten und der Zahl offener Verbindungen getestet werden.
Verbessert Keep Alive automatisch die Core Web Vitals?
Keep Alive kann Verbindungszeiten für zusätzliche Ressourcen reduzieren, verbessert die Core Web Vitals aber nicht automatisch. Große Bilder, blockierendes JavaScript, langsame Serverantworten oder instabile Layouts können weiterhin die maßgeblichen Engpässe sein.
Kann ein Server eine offene Verbindung jederzeit schließen?
Ja, ein Server oder ein zwischengeschaltetes System darf eine Verbindung beenden. Clients müssen deshalb damit umgehen können, eine neue Verbindung aufzubauen und die Anfrage erneut zu senden.
Wenn du technische Engpässe und ihre Auswirkungen auf deine SEO-Sichtbarkeit systematisch prüfen möchtest, bietet ein SEO-Audit eine belastbare Grundlage. Das Erstgespräch ist kostenlos und unverbindlich.
Kostenlosen Potenzialcheck anfragen
Sie haben noch Fragen?
