Blog

5 Gründe, warum deine Website langsam ist – und was dein Hosting damit zu tun hat

Schlechte Ladezeiten kosten dich Besucher:innen, Rankings und im Zweifel auch Kund:innen. Aber warum ist eine Website eigentlich langsam? Meistens aus mehreren Gründen gleichzeitig, und einer davon hat wenig mit deinen Inhalten oder Plugins zu tun, sondern mit der Infrastruktur darunter. Nach jahrelanger Erfahrung mit der Betreuung von über 100 Websites wissen wir, wo die Probleme am häufigsten stecken.

Letzte Aktualisierung: 13. Mai 2026

Du hast eine schöne Website, gute Inhalte, ein solides Design – und trotzdem verlässt die Hälfte deiner Besucher:innen die Seite, bevor sie überhaupt vollständig geladen hat. Klingt frustrierend? Ist es. Und es ist leider häufiger, als man denkt.

Laut einer Studie von Google verlassen 53 % der mobilen Nutzer:innen eine Seite, die länger als drei Sekunden lädt (Quelle: Think with Google). Und das ist nicht nur ein UX-Problem, es ist auch ein Ranking-Problem. Seit dem Google Page Experience-Update fließt die Ladegeschwindigkeit direkt ins Ranking ein. Wer langsam ist, rutscht nach unten.

Während viele bei Performance zunächst an Bildgrößen oder zu viele Plugins denken, liegt ein wesentlicher Teil des Problems teils viel tiefer: beim Hosting. Bei den Komplizinnen betreuen wir über 100 Websites und wissen daher aus eigener Erfahrung, wie viel die passende Infrastruktur beim Thema Performance ausmacht. Seit Jahren setzen wir deshalb auf hosttech als unseren Hosting-Partner. Aber der Reihe nach.

Wie messe ich, ob meine Website zu langsam ist?

Bevor du optimierst, solltest du erstmal messen. Drei Tools, die wir dafür regelmäßig nutzen:

Google PageSpeed Insights (pagespeed.web.dev) – kostenlos, direkt von Google, zeigt Core Web Vitals und konkrete Verbesserungsvorschläge. Besonders relevant: LCP (Largest Contentful Paint) und FID (First Input Delay).

GTmetrix (gtmetrix.com) – detailliertere Auswertung, Wasserfalldiagramm der einzelnen Ladezeiten, Serverstandort wählbar. Ideal um Hosting-Latenzen sichtbar zu machen.

DebugBear (debugbear.com/test/website-speed) – zeigt TTFB von mehreren Standorten aus

Faustregel: Ein TTFB unter 800 ms ist gut. Über 1800 ms deutet fast immer auf ein Server- oder Hosting-Problem hin. Kein Plugin der Welt kann das kompensieren.

5 Gründe, warum deine Website zu langsam ist

Grund #1: Dein Server ist schlicht zu weit weg

Klingt banal, ist aber physikalisch nicht wegzudiskutieren: Wenn dein Server in den USA oder Asien steht und deine Zielgruppe in Österreich oder Deutschland sitzt, kostet jede Anfrage Zeit. Diese sogenannte Latenz, also die Verzögerung zwischen Anfrage und Antwort, addiert sich bei jeder einzelnen Ressource, die deine Website lädt: CSS, JavaScript, Schriften, Bilder.

Bei einer modernen Website mit 50–80 einzelnen HTTP-Anfragen pro Seitenaufruf kann schon ein Serverstandort in den USA statt in Europa 200–400 ms zusätzliche Ladezeit bedeuten – und das merkt man.

Für uns war ein Serverstandort im DACH-Raum daher ein klares Muss. Das virtual Datacenter von hosttech läuft auf Infrastruktur in Wien: Kurze Wege zu den meisten unserer Kund:innen, schnelle Antwortzeiten, keine geografischen Umwege – passt einfach perfekt für unsere Anforderungen.

Unser Tipp:

Bei vielen Hosting-Anbietern lässt sich der Serverstandort aktiv wählen – oder die Wahl fällt gezielt nach einem Anbieter mit Infrastruktur im DACH-Raum. Das lohnt sich gleich doppelt. Erstens die schon erwähnte niedrigere Latenz für deine Besucher:innen. Zweitens, und das wird oft vergessen, bekommst du damit Support-Zeiten in deiner eigenen Zeitzone. Wer schon mal um 9 Uhr morgens ein dringendes Server-Problem hatte und gemerkt hat, dass der Support erst in ein paar Stunden aufmacht, weil das Team in den USA sitzt, weiß wie viel das wert ist. Mit einem Anbieter, der im DACH-Raum beheimatet ist, hat man Support zu mitteleuropäischen Bürozeiten, ohne lange Wartezeiten.

Grund #2: Shared Hosting – alle teilen sich dieselben Ressourcen

Günstiges Webhosting funktioniert meist so: Hunderte von Websites teilen sich einen Server. CPU, RAM, Datenbankverbindungen, alles wird geteilt. Wenn die Nachbarn gerade einen Traffic-Spike haben oder ein schlecht optimiertes Script läuft, leidet die eigene Seite mit. Das ist wie eine WG mit einer einzigen Internetleitung: Sobald jemand streamt, ruckelt es bei allen anderen.

Das Gemeine daran ist, dass du es nicht sofort mitkriegst. Die Website lädt manchmal schnell, manchmal langsam, abhängig davon, was gerade auf dem Server los ist. Das macht die Fehlersuche besonders frustrierend: Das Problem ist real, aber nicht reproduzierbar. Kein Fehler im Log, kein klarer Auslöser.

Besonders kritisch wird es bei ressourcenintensiven Anwendungen. WooCommerce-Shops mit vielen gleichzeitigen Bestellungen, Membership-Seiten mit Login-Logik oder Websites mit ungecachten Datenbankabfragen brauchen verlässliche Rechenkapazität. Auf einem überbelegten Shared-Server ist das nicht garantiert.

Wer professionell mit WordPress oder anderen CMS arbeitet, stößt beim Shared Hosting öfter an Grenzen, nicht weil die Technologie schlecht ist, sondern weil die Ressourcen schlicht nicht planbar sind.

Wer mehr Kontrolle und verlässliche Performance braucht, kommt früher oder später an einem eigenen Server oder VPS nicht vorbei. Der Unterschied zum Shared Hosting ist grundlegend: Die Ressourcen gehören dir allein, kein anderer Kunde kann die Performance beeinflussen, und die Konfiguration lässt sich exakt auf die eigenen Anforderungen abstimmen, von der PHP-Version über den Caching-Layer bis hin zu Mailserver und Sicherheitseinstellungen.

Der Haken ist die Verantwortung, die damit einhergeht. Serverkonfiguration, Sicherheits-Updates, Monitoring, Backups, das alles liegt nicht mehr beim Anbieter, sondern bei dir selbst. Wer das nicht intern abdecken kann oder will, sollte einen Managed Service in Betracht ziehen. Dabei übernimmt ein Dienstleister die technische Betreuung des Servers, während du selbst die Kontrolle über die darauf laufenden Websites behältst. Du bekommst also das Beste aus beiden Welten: eigene Infrastruktur ohne den operativen Aufwand eines Serveradministrators.

Für viele Unternehmen und Agenturen ist genau das der pragmatischste Weg. Die einmalige Umstellung kostet zwar Zeit und etwas Budget, zahlt sich aber in Form von stabiler Performance, weniger ungeklärten Ladezeit-Problemen und mehr Handlungsspielraum bei der technischen Optimierung langfristig aus.

Unser Tipp:

Wer merkt, dass die Website unter Last schwächelt oder die Performance schlicht nicht planbar ist, sollte das Hosting-Modell hinterfragen. Ein VPS oder Managed Server kostet mehr als ein Shared-Paket, gibt dafür aber verlässliche Ressourcen und echten Handlungsspielraum bei der Optimierung. Die einmalige Umstellung zahlt sich meist schneller aus, als man denkt.

Grund #3: Veraltete PHP-Version und fehlende Server-Optimierung

Die meisten CMS wie WordPress oder Joomla! laufen auf PHP – und die PHP-Version macht beim Thema Performance einen enormen Unterschied. PHP 8.x ist messbar schneller als PHP 7.x – bei dem auf WordPress basierendem Shopsystem WooCommerce etwa rund 23 % mehr Durchsatz (Quelle: Kinsta PHP Benchmarks). Trotzdem laufen viele Websites noch auf veralteten Versionen, weil der Hosting-Provider keine einfache Möglichkeit bietet, das zu ändern oder weil niemand daran gedacht hat.

Dazu kommt die serverseitige Konfiguration. Zwei konkrete Beispiele aus unserer Praxis:

OPcache ist ein PHP-interner Mechanismus, der kompilierten PHP-Code im Arbeitsspeicher vorlädt, statt bei jedem Request alles neu zu verarbeiten. Ist er aktiviert und richtig konfiguriert, merkt man das sofort. Ist er deaktiviert oder läuft mit zu wenig Speicher, verschenkt man Performance, die nichts kosten würde. Dabei kommt es nicht nur darauf an, ob OPcache läuft, sondern auch wie er konfiguriert ist. Die wichtigsten Stellschrauben:

Direktive	Typischer Default	Empfohlener Wert
`opcache.memory_consumption`	128 MB	256 MB
`opcache.max_accelerated_files`	1.000	8.000–10.000
`opcache.revalidate_freq`	2	60
`opcache.interned_strings_buffer`	8 MB	64 MB

Viele Hoster liefern OPcache mit Standardwerten aus, die für kleine Installationen dimensioniert sind, nicht für einen WordPress-Multisite-Betrieb oder einen WooCommerce-Shop mit vielen Plugins.

Ein weiteres Beispiel ist Xdebug, ein Debugging-Tool das Entwickler:innen bei der Fehlersuche hilft, auf einem Produktionsserver aber nichts verloren hat. Ist es aktiv, bremst es PHP spürbar aus. Klingt nach einem Randfall, ist aber in der Praxis öfter anzutreffen als man denkt. Das sind keine Feinheiten, das ist der Unterschied zwischen einer 3-Sekunden-Seite und einer 0,8-Sekunden-Seite. Mit Plesk auf unserem hosttech-Setup können wir PHP-Versionen und serverseitige Einstellungen pro Domain flexibel steuern. Das ist für eine Agentur, die viele unterschiedliche Projekte betreut, Gold wert.

Unser Tipp:

PHP-Version und OPcache-Konfiguration sind zwei der wirkungsvollsten Stellschrauben, die kaum etwas kosten – vorausgesetzt, der Hoster lässt es zu. Wer keine Möglichkeit hat, die PHP-Version pro Domain selbst zu wählen, sollte das als ernstes Signal werten. Ein gutes Hosting gibt dir diese Kontrolle. Und wer Xdebug auf einem Produktionsserver aktiv hat: sofort deaktivieren.

Grund #4: Kein Caching auf Server-Ebene

Caching-Plugins für WordPress wie WP Rocket oder W3 Total Cache sind grandios, aber sie haben ihre Grenzen, wenn der dahinterliegende Server nicht mitspielt. Der Grund: WordPress muss bei jedem Seitenaufruf standardmäßig PHP starten, Datenbankabfragen machen („Welche Menüs gibt es? Welche Widgets? Welche Optionen?“) und die Seite zusammenbauen. Das passiert bei jeder einzelnen Anfrage, außer es gibt einen Cache.

Es gibt dabei zwei Ebenen die sich ergänzen. Die erste ist nginx FastCGI Cache: Dabei speichert der Webserver fertig gerenderte HTML-Seiten direkt zwischen und liefert sie aus, ohne PHP überhaupt zu starten. Für Besucher:innen die keine aktive Session haben – also der Großteil des Traffics – ist das die schnellste mögliche Auslieferung. Die zweite Ebene ist Redis Object Cache: Hier werden Datenbankabfragen im Arbeitsspeicher zwischengespeichert, sodass die Website sie nicht jedes Mal neu ausführen muss.

Wir haben Redis auf unserem hosttech-Server als eigenen Docker-Container aufgesetzt, direkt über die Plesk-Oberfläche ansteuerbar und sauber vom Rest der Infrastruktur getrennt. Kein Shared-Service, keine Abhängigkeiten, volle Kontrolle. Für WordPress braucht es dann nur noch das Plugin „Redis Object Cache“ von Till Krüss: verbinden, aktivieren, fertig.

Bei Managed-Hosting-Lösungen ist das oft gar nicht konfigurierbar. Wer auf eigener Infrastruktur sitzt, kann hier viel mehr herausholen. Wir haben das bei unseren Kund:innen selbst erlebt: Der Wechsel auf serverseitiges Caching hat in einigen Fällen die TTFB (Time to First Byte) halbiert.

Unser Tipp:

Prüf zuerst, ob dein Hoster nginx FastCGI Cache und Redis überhaupt unterstützt – viele Managed-Lösungen tun es nicht. Wenn nicht, ist das ein handfestes Argument für einen Wechsel auf eigene Infrastruktur. Ein Caching-Plugin allein holt längst nicht so viel raus wie die Kombination aus serverseitigem Page Cache und Redis Object Cache. Wer beides zusammen aktiviert hat, merkt den Unterschied sofort im TTFB.

Grund #5: Dein Hosting-Plan ist schlicht zu schwach für deine Website

Das ist der unangenehmste Grund, aber einer der häufigsten: Die Website ist einfach zu groß für das gebuchte Paket. Ein WooCommerce-Shop mit 500 Produkten, Live-Search und Zahlungsabwicklung hat andere Anforderungen als eine einfache Visitenkarten-Website. Wer beides auf denselben 2-Euro-Hosting-Plan setzt, darf sich nicht wundern, wenn die Performance streikt.

Typische Warnsignale: Die Website ist langsam nur unter Last (also wenn mehrere Personen gleichzeitig surfen), das Backend im WordPress-Dashboard reagiert träge, oder Importe und Updates brechen mit Timeout-Fehlern ab. Das sind keine Plugin-Probleme, das ist zu wenig RAM oder zu wenig CPU.

Was wir an unserem Setup mit hosttech besonders schätzen: Wir mussten nicht von Anfang an in eine Überstruktur investieren. Ressourcen lassen sich im virtual Datacenter flexibel erweitern, wenn der Bedarf steigt. Kein großer Sprung, kein Anbieterwechsel, keine aufwändige Migration.

Unser Tipp:

Wenn die Website unter Last langsam wird oder das WordPress-Backend träge reagiert, lohnt sich ein Blick auf die gebuchten Ressourcen, bevor man stundenlang Plugins debuggt. RAM und CPU lassen sich nicht wegcachen. Wichtig bei der Anbieterwahl: Kann man flexibel skalieren, ohne gleich den Server wechseln zu müssen? Das spart im Ernstfall viel Zeit und Nerven.

Was tun, wenn die Website langsam ist? Unser Kurzcheck

Eine langsame Website hat selten nur einen Grund. Meist ist es eine Kombination. Unsere Checkliste:

TTFB messen – über 600 ms? Dann liegt das Problem beim Server.
Serverstandort prüfen – ist er nah an deiner Zielgruppe?
Hosting-Modell hinterfragen – Shared oder dediziert?
PHP-Version checken – läuft deine Website noch auf PHP 7.x?
OPcache-Status prüfen – aktiv und ausreichend Speicher konfiguriert?
Object Cache aktivieren – Redis verfügbar? Dann Plugin installieren und einschalten.
Hosting-Plan mit tatsächlichem Bedarf abgleichen – passt das Paket noch zur Website?

Häufige Fragen zur Website-Performance

Wie viel Einfluss hat das Hosting wirklich auf die Ladezeit?

Sehr viel, besonders beim TTFB. Alles, was vor dem ersten Byte passiert (Datenbankabfragen, PHP-Verarbeitung, Netzwerkweg), liegt direkt beim Hosting. Ein schnelles Caching-Plugin kann einen schlechten Server nicht kompensieren.

Was ist TTFB und warum ist er wichtig?

TTFB steht für „Time to First Byte“, die Zeit zwischen dem Absenden einer Anfrage und dem Empfang des ersten Datenbytes vom Server. Er misst im Wesentlichen die Reaktionsgeschwindigkeit deines Servers. Google empfiehlt einen TTFB unter 200 ms.

Muss ich für gutes Hosting viel Geld ausgeben?

Nicht unbedingt. Aber günstiges Shared Hosting hat eben seinen Preis, der sich in der Performance zeigt. Die ehrliche Antwort: Es kommt darauf an, was die Website braucht. Eine einfache Unternehmenswebsite mit wenig Traffic kommt mit einem günstigen Paket gut aus. Ein WooCommerce-Shop mit hunderten Produkten, Live-Search und gleichzeitigen Besucher:innen braucht mehr – und dort rächt sich das billigste Angebot schnell. Entscheidend ist nicht der Preis, sondern ob das gebuchte Paket zum tatsächlichen Bedarf passt. Und ob man bei wachsendem Bedarf flexibel skalieren kann, ohne den Anbieter wechseln zu müssen.

Bringt ein Caching-Plugin allein etwas?

Ja, aber begrenzt. Ein Plugin wie WP Rocket kann statische Seiten cachen und dadurch PHP-Aufrufe reduzieren, das hilft. Aber es hat keinen Einfluss auf den Serverstandort, das Hosting-Modell oder die PHP-Konfiguration. Die Kombination aus gutem Hosting und Caching-Plugin bringt das beste Ergebnis.

Wie erkenne ich, ob mein Hosting das Problem ist?

Der einfachste Test: den TTFB messen. Liegt der TTFB über 800 ms, ist das ein Warnsignal. Über 1800 ms ist es ein klares Problem. Wichtig: Ein hoher TTFB bedeutet nicht automatisch schlechtes Hosting. Auch langsame Plugins, fehlender Cache oder eine überlastete Datenbank können die Ursache sein. Hilfreich ist deshalb ein Test mit deaktiviertem Cache und deaktivierten Plugins, um die rohe Server-Performance zu isolieren.

Unser Fazit

Schnelle Websites brauchen ein solides Fundament

Ladezeit-Optimierung fängt nicht beim Plugin an, sie fängt bei der Infrastruktur an. Serverstandort, Hosting-Modell, PHP-Version, Caching-Konfiguration: All das liegt unterhalb der WordPress-Oberfläche, ist aber für die Performance mindestens genauso entscheidend wie das beste Caching-Plugin.

Wenn du dir beim Thema Hosting unsicher bist oder deine Website schon länger auf Sparflamme läuft: Wir helfen gerne – meld dich bei uns. Und wenn du selbst nach einer soliden Hosting-Infrastruktur suchst: Schau dir das virtual Datacenter von hosttech an. Klein anfangen, flexibel wachsen. So arbeiten wir, und so empfehlen wir es auch weiter.