Wir haben die Server von 20 Webhostern gemessen, die in Deutschland verkaufen. Nicht aus Werbebroschüren abgeschrieben, sondern am 18.10.2026 mit unserem eigenen Werkzeug, jeden Anbieter fünfmal. Uns interessierte eine einzige Frage: Wie schnell schickt der Server seine erste Antwort?
Die Unterschiede sind enorm. Die schnellsten Server erzeugen die Seite in wenigen Millisekunden, der langsamste braucht 482 ms. Marktführer IONOS hat einen schnellen Server, verliert aber beim Verbindungsaufbau mehr als eine halbe Sekunde. Alles steht unten, mit einem Bildschirmfoto jeder Messung.
Kurz gesagt: die schnellsten Webhoster in Deutschland
Unter den Servern, die in Deutschland stehen und kein CDN vorgeschaltet haben, erzeugen diese fünf die Seite am schnellsten:
- Uberspace: etwa 1 ms Verarbeitung am Server, 282 ms TTFB
- STRATO: etwa 4 ms Verarbeitung am Server, 217 ms TTFB
- webgo: etwa 5 ms Verarbeitung am Server, 285 ms TTFB
- manitu: etwa 11 ms Verarbeitung am Server, 230 ms TTFB
- goneo: etwa 15 ms Verarbeitung am Server, 204 ms TTFB
So kurze Verarbeitungszeiten bedeuten meist, dass die Startseite aus einer fertigen Kopie kommt, also aus einem Seiten-Cache. Soll Ihre eigene Website ähnlich schnell antworten, achten Sie darauf, dass Ihr Tarif einen Seiten-Cache bietet.
Was ist TTFB, und warum vier Teile?
TTFB (Time to First Byte) ist die Zeit von der Anfrage des Browsers bis zum ersten Byte vom Server. Nach dem Google-Leitfaden web.dev gelten bis 800 ms als gut, über 1,8 Sekunden als schlecht. Alles andere auf der Seite beginnt erst nach diesem ersten Byte; eine lange TTFB lässt sich durch keine Optimierung im Frontend ausgleichen. Mehr dazu in unserem Ratgeber zur TTFB.
Die TTFB wirkt wie eine einzige Zahl, besteht aber aus vier Teilen, und jeder verrät etwas anderes:
- DNS: die Übersetzung der Domain in eine IP-Adresse. Zeigt, wie schnell Ihr DNS-Anbieter ist.
- TCP-Verbindung: der erste Handshake mit dem Server. Spiegelt grob die Entfernung zum Server.
- TLS-Handshake: der Aufbau der verschlüsselten Verbindung. Zeigt, wie der Server eingestellt ist; TLS 1.3 verkürzt ihn.
- Wartezeit am Server: der Server erzeugt die Seite und schickt das erste Byte. Das ist der eigentliche Maßstab für die Qualität des Hostings.
In der Wartezeit steckt außerdem ein Netzwerk-Roundtrip. Zieht man ihn (die TCP-Zeit) ab, bleibt die reine Verarbeitungszeit am Server. Das ist eine Schätzung, aber weil sie nicht von der Entfernung abhängt, ist sie der fairste Vergleich zwischen Anbietern.
So haben wir gemessen
Gemessen haben wir die eigene Website jedes Anbieters, kein Kundenpaket. Wir behaupten also nicht: „Bei Hetzner lädt Ihre Seite in 289 ms.“ Ihr Paket, Ihr Theme und Ihre Datenbank gehören Ihnen. Aber ein Hoster, dessen eigene Website langsam antwortet, der 2026 noch ein altes Protokoll nutzt oder keinen einzigen Sicherheits-Header setzt, sagt Ihnen etwas über sein Handwerk.
Gemessen haben wir aus der Türkei. Der Weg nach Deutschland und zurück kostet von dort etwa 150 ms (TCP und TLS zusammen), und zwar für jeden Server in Deutschland ungefähr gleich viel. Aus Deutschland gemessen wären alle Werte kürzer, an der Reihenfolge würde sich nichts ändern. Deshalb sortieren wir nach der Verarbeitungszeit am Server.
Zwei Korrekturen. In der ersten Fassung dieses Artikels vom 31.07.2026 war der Wert, den wir „TTFB“ nannten, in Wahrheit die Ladezeit der ganzen Startseite; ein Anbieter mit schwerer Seite fiel zurück, selbst wenn sein Server schnell war. Außerdem hatten wir geschrieben, fünf Anbieter stünden nicht in Deutschland. Bei domainFACTORY, Contabo und RAIDBOXES war der angezeigte Standort der Adresseintrag des vorgeschalteten CDN; die Verbindungszeiten zeigen, dass die Anfragen in Europa beantwortet werden. Wirklich im Ausland steht: Cloud86. netcup, damals in Amsterdam verortet, antwortet jetzt aus Frankfurt.
Gemessen am 18.10.2026 mit unserem eigenen Site Speed Metrix. Das Bild unter jedem Anbieter zeigt unsere TTFB-Messung für ihn. HTTP-Version, Sicherheits-Header und Serverstandort stammen aus demselben Scan, aus unserem SEO-Check. Marktanteile: hosttest.de (Daten von hostadvice und builtwith), April 2026.
Webhoster-Vergleich: die Ergebnistabelle
| Anbieter | Serverzeit | TTFB | HTTP | Standort |
|---|---|---|---|---|
| Cloud86Istanbul, TR | ~0 ms | 85 ms | h3 | Istanbul, TR |
| UberspaceMainz, DE | ~1 ms | 282 ms | h2 | Mainz, DE |
| STRATOBerlin, DE | ~4 ms | 217 ms | 1.1 | Berlin, DE |
| webgoHamburg, DE | ~5 ms | 285 ms | h2 | Hamburg, DE |
| manituSankt Wendel, DE | ~11 ms | 230 ms | h2 | Sankt Wendel, DE |
| domainFACTORYCDN (Sucuri) | ~13 ms | 549 ms | h3 | CDN (Sucuri) |
| goneoWiesbaden, DE | ~15 ms | 204 ms | h2 | Wiesbaden, DE |
| ContaboCDN (Cloudflare) | ~40 ms | 290 ms | h3 | CDN (Cloudflare) |
| netcupFrankfurt am Main, DE | ~50 ms | 224 ms | h3 | Frankfurt am Main, DE |
| MittwaldFrankfurt am Main, DE | ~52 ms | 279 ms | h2 | Frankfurt am Main, DE |
| IONOSKarlsruhe, DE | ~57 ms | 784 ms | h2 | Karlsruhe, DE |
| HetznerNürnberg, DE | ~69 ms | 289 ms | h3 | Nürnberg, DE |
| hosting.deAachen, DE | ~74 ms | 381 ms | h2 | Aachen, DE |
| lima-cityBremen, DE | ~87 ms | 303 ms | h2 | Bremen, DE |
| dogadoDortmund, DE | ~88 ms | 367 ms | h2 | Dortmund, DE |
| Host EuropeCDN (Akamai) | ~104 ms | 167 ms | h2 | CDN (Akamai) |
| RAIDBOXESCDN (Cloudflare) | ~106 ms | 345 ms | h3 | CDN (Cloudflare) |
| All-InklNeusalza-Spremberg, DE | ~148 ms | 397 ms | h2 | Neusalza-Spremberg, DE |
| InterNetXKarlsruhe, DE | ~166 ms | 382 ms | 1.1 | Karlsruhe, DE |
| AlfahostingHalle, DE | ~482 ms | 801 ms | 1.1 | Halle, DE |
Was uns aufgefallen ist
Die Server liegen weit auseinander. Uberspace, STRATO und webgo erzeugen die Seite in wenigen Millisekunden, Alfahosting braucht etwa 482 ms. Genau auf diese Zahl kommt es bei der Wahl des Hosters an.
IONOS verschenkt einen schnellen Server an eine langsame Verbindung. Der Server erzeugt die Seite in etwa 57 ms, aber die TCP-Verbindung dauert 176 ms und der TLS-Handshake 364 ms. Mit 784 ms TTFB landet IONOS weit hinten. Die eigene Website nutzt noch TLS 1.2.
4 Anbieter haben ihrer Website ein CDN vorgeschaltet: domainFACTORY (Sucuri), Contabo (Cloudflare), Host Europe (Akamai), RAIDBOXES (Cloudflare). Ein CDN verteilt Kopien einer Website über Server in der Nähe der Besucher (Was ist ein CDN?). Bei diesen Websites ist der echte Serverstandort nicht zu sehen, und die gemessene TTFB beschreibt das CDN, nicht den Hosting-Server.
domainFACTORY und RAIDBOXES schwanken stark. domainFACTORY lag in fünf Messungen zwischen 195 und 1041 ms; RAIDBOXES lag in fünf Messungen zwischen 314 und 574 ms. Antwortet dieselbe Seite so unterschiedlich, kommt der Server oder die Schicht davor unter Last ins Straucheln.
3 Anbieter nutzen 2026 noch HTTP/1.1: STRATO, InterNetX und Alfahosting. Auffällig ist STRATO: Der zweitgrößte Hoster Deutschlands liefert einen der schnellsten Server der Liste über ein altes Protokoll aus. HTTP/3 ist nur bei 6 Anbietern an: Cloud86, domainFACTORY, Contabo, netcup, Hetzner und RAIDBOXES.
5 Anbieter setzen überhaupt keine Sicherheits-Header: Cloud86, webgo, Contabo, hosting.de und Host Europe. Kein CSP, kein X-Frame-Options. Wer das auf der eigenen Website vergisst, lässt ahnen, wie sorgfältig er mit Ihrer umgeht.
Manche Anbieter laufen im Netz eines anderen. InterNetX im Netz von IONOS (AS8560), Alfahosting im Netz von dogado (AS45012). Auf keiner Preisseite steht das, in den Messdaten schon.
Die 20 Webhoster im Einzelnen
Die Reihenfolge folgt der Verarbeitungszeit am Server. In jeder Überschrift stehen zwei Zahlen: wie lange der Server für die Seite braucht und die gesamte TTFB. Unter jedem Anbieter sehen Sie die Messung aus Site Speed Metrix.
Cloud86: Server ~0 ms, TTFB 85 ms
Die Website von Cloud86 steht gar nicht in Deutschland, sondern in Istanbul, im Netz eines türkischen Anbieters. Der Verbindungsaufbau von nur 23 ms bestätigt das. Deshalb hat Cloud86 in unserer Messung die niedrigste TTFB. Für Besucher in Deutschland gilt das Gegenteil: Jede Anfrage muss erst nach Istanbul und zurück.
Die TTFB im Detail: DNS 5 ms, TCP 23 ms, TLS 34 ms, Wartezeit 23 ms. Server in Istanbul, TR. HTTP/3 an, 83 % Komprimierung, kein HSTS, keine Sicherheits-Header.
Uberspace: Server ~1 ms, TTFB 282 ms
Der Server von Uberspace schickt die Seite praktisch ohne Wartezeit, die Verarbeitung dauert etwa 1 ms. Die Zeit geht woanders verloren: Der TLS-Handshake braucht 149 ms, rund doppelt so lange wie bei den meisten anderen. Beim Verbindungsaufbau ist also noch etwas zu holen.
Die TTFB im Detail: DNS 2 ms, TCP 65 ms, TLS 149 ms, Wartezeit 66 ms. Server in Mainz. HTTP/2 (kein HTTP/3), 66 % Komprimierung, kein HSTS, Sicherheits-Header Note D.
STRATO: Server ~4 ms, TTFB 217 ms
STRATO hat einen der schnellsten Server im Test, die Seite steht nach etwa 4 ms. Trotzdem liefert der zweitgrößte Hoster Deutschlands seine eigene Website 2026 noch über HTTP/1.1 aus. Ein schneller Motor mit altem Getriebe.
Die TTFB im Detail: DNS 3 ms, TCP 66 ms, TLS 78 ms, Wartezeit 70 ms. Server in Berlin. HTTP/1.1, 80 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D. Marktanteil 16 %.
webgo: Server ~5 ms, TTFB 285 ms
Auch webgo lässt niemanden warten, die Verarbeitung dauert etwa 5 ms. Wie bei Uberspace geht die Zeit beim TLS-Handshake verloren: 151 ms. Bei der Sicherheit schwächelt webgo, es gibt weder Sicherheits-Header noch HSTS.
Die TTFB im Detail: DNS 1 ms, TCP 64 ms, TLS 151 ms, Wartezeit 69 ms. Server in Hamburg. HTTP/2 (kein HTTP/3), 85 % Komprimierung, kein HSTS, keine Sicherheits-Header.
manitu: Server ~11 ms, TTFB 230 ms
manitu liefert ein ausgewogenes Bild. Der Server erzeugt die Seite in etwa 11 ms, beim Verbindungsaufbau geht nichts verloren. Die fünf Messungen lagen zwischen 222 und 244 ms, also stabil.
Die TTFB im Detail: DNS 9 ms, TCP 65 ms, TLS 80 ms, Wartezeit 76 ms. Server in Sankt Wendel. HTTP/2 (kein HTTP/3), 79 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note C.
domainFACTORY: Server ~13 ms, TTFB 549 ms
Vor domainFACTORY sitzt Sucuri, eine Firewall mit CDN. Wo der eigentliche Server steht, ist deshalb von außen nicht zu sehen; das „USA“ aus der ersten Fassung war Sucuris Adresseintrag. Das eigentliche Problem ist die Schwankung: Die schnellste von fünf Messungen lag bei 195 ms, die langsamste bei 1041 ms.
Die TTFB im Detail: DNS 11 ms, TCP 173 ms, TLS 179 ms, Wartezeit 186 ms. Hinter Sucuri. HTTP/3 an, 76 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note C.
goneo: Server ~15 ms, TTFB 204 ms
Unter den Servern in Deutschland hat goneo die kürzeste TTFB: 204 ms. Der Verbindungsaufbau gehört mit 57 ms zu den schnellsten, und der Server erzeugt die Seite in etwa 15 ms. Bei den Sicherheits-Headern reicht es nur für ein D.
Die TTFB im Detail: DNS 8 ms, TCP 57 ms, TLS 67 ms, Wartezeit 72 ms. Server in Wiesbaden. HTTP/2 (kein HTTP/3), 80 % Komprimierung, kein HSTS, Sicherheits-Header Note D.
Contabo: Server ~40 ms, TTFB 290 ms
Die Website von Contabo läuft hinter Cloudflare. Das „Toronto“ aus der ersten Fassung war Cloudflares Adresseintrag; 78 ms für den Verbindungsaufbau zeigen, dass die Anfrage in Europa beantwortet wird. Auf der Serverseite vergehen etwa 40 ms.
Die TTFB im Detail: DNS 7 ms, TCP 78 ms, TLS 87 ms, Wartezeit 118 ms. Hinter Cloudflare. HTTP/3 an, 91 % Komprimierung, HSTS gesetzt, keine Sicherheits-Header.
netcup: Server ~50 ms, TTFB 224 ms
netcup gehört zu den ausgewogensten Anbietern im Test. Die TTFB liegt bei 224 ms, HTTP/3 ist an, und bei den Sicherheits-Headern bekommt netcup die beste Note der Liste. Die Website, die in der ersten Fassung in Amsterdam auftauchte, antwortet jetzt aus Frankfurt.
Die TTFB im Detail: DNS 12 ms, TCP 52 ms, TLS 58 ms, Wartezeit 102 ms. Server in Frankfurt am Main. HTTP/3 an, 92 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note B.
Mittwald: Server ~52 ms, TTFB 279 ms
Der Server von Mittwald erzeugt die Seite in etwa 52 ms, und die fünf Messungen liegen eng beieinander (278 bis 291 ms). Ein Server ohne Überraschungen.
Die TTFB im Detail: DNS 5 ms, TCP 72 ms, TLS 78 ms, Wartezeit 124 ms. Server in Frankfurt am Main. HTTP/2 (kein HTTP/3), 82 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note C.
IONOS: Server ~57 ms, TTFB 784 ms
Marktführer IONOS ist das spannendste Ergebnis dieser Messung. Der Server selbst ist schnell, die Seite steht nach etwa 57 ms. Der Weg dorthin dauert aber: 176 ms für die Verbindung und 364 ms für den TLS-Handshake. Die eigene Website verbindet noch über TLS 1.2; mit TLS 1.3 wäre der Handshake halb so lang.
Die TTFB im Detail: DNS 11 ms, TCP 176 ms, TLS 364 ms, Wartezeit 233 ms. Server in Karlsruhe. HTTP/2 (kein HTTP/3), 89 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note C. Marktanteil 28 %.
Hetzner: Server ~69 ms, TTFB 289 ms
Bei Hetzner stimmt das Bild: Der Server erzeugt die Seite in etwa 69 ms, HTTP/3 ist an, und die fünf Messungen weichen kaum voneinander ab. Nur bei den Sicherheits-Headern fällt Hetzner mit einem D zurück.
Die TTFB im Detail: DNS 4 ms, TCP 70 ms, TLS 76 ms, Wartezeit 139 ms. Server in Nürnberg. HTTP/3 an, 86 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D. Marktanteil 13 %.
hosting.de: Server ~74 ms, TTFB 381 ms
Der Server von hosting.de ist mit etwa 74 ms Verarbeitung Mittelmaß, der TLS-Handshake dauert mit 160 ms lange. Sicherheits-Header gibt es keine, HSTS ebenfalls nicht.
Die TTFB im Detail: DNS 7 ms, TCP 70 ms, TLS 160 ms, Wartezeit 144 ms. Server in Aachen. HTTP/2 (kein HTTP/3), 78 % Komprimierung, kein HSTS, keine Sicherheits-Header.
lima-city: Server ~87 ms, TTFB 303 ms
In der ersten Fassung stand lima-city ganz vorn; diese Reihenfolge beruhte auf der Ladezeit der ganzen Seite. Nach echter Serverzeit liegt lima-city in der unteren Hälfte, der Server erzeugt die Seite in etwa 87 ms.
Die TTFB im Detail: DNS 3 ms, TCP 68 ms, TLS 77 ms, Wartezeit 155 ms. Server in Bremen. HTTP/2 (kein HTTP/3), 60 % Komprimierung, kein HSTS, Sicherheits-Header Note C.
dogado: Server ~88 ms, TTFB 367 ms
Der Server von dogado erzeugt die Seite in etwa 88 ms. Der Verbindungsaufbau ist mit 89 ms für einen Server in Deutschland etwas lang; dafür sind die fünf Messungen fast identisch (363 bis 374 ms).
Die TTFB im Detail: DNS 4 ms, TCP 89 ms, TLS 97 ms, Wartezeit 177 ms. Server in Dortmund. HTTP/2 (kein HTTP/3), 86 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D.
Host Europe: Server ~104 ms, TTFB 167 ms
Die Website von Host Europe läuft hinter dem CDN von Akamai. 14 ms für den Verbindungsaufbau heißen: Die Antwort kam von einem CDN-Server ganz in der Nähe unseres Messpunkts, daher die niedrige TTFB. In den rund 104 ms, die von der Wartezeit übrig bleiben, steckt auch der Weg vom CDN zum eigentlichen Server.
Die TTFB im Detail: DNS 4 ms, TCP 14 ms, TLS 31 ms, Wartezeit 118 ms. Hinter Akamai. HTTP/2 (kein HTTP/3), 81 % Komprimierung, kein HSTS, keine Sicherheits-Header. Marktanteil 7 %.
RAIDBOXES: Server ~106 ms, TTFB 345 ms
Auch RAIDBOXES läuft hinter Cloudflare; das „Toronto“ aus der ersten Fassung war Cloudflares Eintrag. Die fünf Messungen schwankten zwischen 314 und 574 ms. Auf der Serverseite vergehen etwa 106 ms.
Die TTFB im Detail: DNS 8 ms, TCP 72 ms, TLS 87 ms, Wartezeit 178 ms. Hinter Cloudflare. HTTP/3 an, 81 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D.
All-Inkl: Server ~148 ms, TTFB 397 ms
Bei All-Inkl klappt der Verbindungsaufbau reibungslos, aber der Server braucht etwa 148 ms für die Seite. Damit gehört er zu den drei langsamsten Servern der Liste.
Die TTFB im Detail: DNS 1 ms, TCP 80 ms, TLS 88 ms, Wartezeit 228 ms. Server in Neusalza-Spremberg. HTTP/2 (kein HTTP/3), 80 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note C. Marktanteil 3 %.
InterNetX: Server ~166 ms, TTFB 382 ms
InterNetX betreibt kein eigenes Netz, sondern läuft im Netz von IONOS (AS8560). Der Server erzeugt die Seite in etwa 166 ms, ausgeliefert wird noch über HTTP/1.1.
Die TTFB im Detail: DNS 1 ms, TCP 69 ms, TLS 77 ms, Wartezeit 235 ms. Server in Karlsruhe. HTTP/1.1, 81 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D. Marktanteil 5 %.
Alfahosting: Server ~482 ms, TTFB 801 ms
Der langsamste Server der Liste: Alfahosting braucht für die Seite etwa 482 ms, die schnellsten schaffen das in wenigen Millisekunden. Ausgeliefert wird über HTTP/1.1, das Netz gehört dogado (AS45012).
Die TTFB im Detail: DNS 17 ms, TCP 73 ms, TLS 156 ms, Wartezeit 555 ms. Server in Halle. HTTP/1.1, 81 % Komprimierung, HSTS gesetzt, Sicherheits-Header Note D.
Diese Fragen sollten Sie Ihrem Hoster stellen
Nehmen Sie die Tabelle nicht als Rangliste, sondern als Fragenkatalog. Fragen Sie beim nächsten Gespräch mit einem Anbieter:
- In welcher Stadt steht mein Server, und in wessen Netz läuft er?
- Gibt es in meinem Tarif einen Seiten-Cache? Wie viele Millisekunden braucht der Server für eine Seite?
- Sind TLS 1.3 und HTTP/3 eingeschaltet?
- Sind HSTS und Sicherheits-Header in meinem Tarif schon eingerichtet?
Ein guter Anbieter beantwortet jede Frage in einem Satz. Die TTFB Ihrer eigenen Website messen Sie auf dieselbe Weise kostenlos mit Site Speed Metrix. Wie die Lage in der Türkei aussieht, zeigt unser Test türkischer Hosting-Anbieter.
Diese Zahlen stammen vom 18.10.2026, die erste Messung war am 31.07.2026. Ein Hoster kann morgen TLS 1.3 einschalten oder seinen Server beschleunigen. Sobald wir neu messen, steht das Datum hier.
