Warum ist meine Website langsam? 10 Server Ursachen und Lösungen

Warum ist meine Website langsam?

Eine Website ist langsam, weil der Server die erste Antwort zu spät erzeugt oder weil diese Antwort zu spät beim Browser ankommt. Die häufigsten Ursachen sind knappe Hosting Ressourcen, eine veraltete PHP Version, langsame Datenbankabfragen, fehlendes Caching, DNS und TLS Verzögerungen, Bot Traffic und überladene Plugins. Erst messen, dann beheben.

Langsame Seiten haben zwei getrennte Quellen. Die erste liegt beim Server: Der Browser sendet eine Anfrage, und die Antwort kommt spät. Die zweite liegt im Browser: Die Antwort kommt schnell, aber Bilder, Skripte und Schriften halten die Darstellung auf. Daher behandelt dieser Beitrag nur die erste Quelle.

Details zu Bildern, JavaScript und Core Web Vitals wiederholen wir hier deshalb nicht. Dazu lesen Sie unsere Beiträge zur Wirkung der Ladezeit auf SEO, zur Bildoptimierung und zur JavaScript Performance.

Wenn Sie Ihren eigenen VPS oder cPanel Account verwalten, können Sie die Befehle Schritt für Schritt nachvollziehen. Wenn Ihr Hoster alles betreibt, erfahren Sie, welche Befunde Sie weitergeben und wie Sie diese formulieren. Wir sind ein Team für digitales Marketing und Web, kein Hosting Anbieter. Deshalb stützen sich die Erklärungen auf offizielle Dokumentation und Standards.

Warum ist meine Website langsam: Liegt es am Server oder am Browser?

Trennen Sie zunächst die beiden Seiten. Öffnen Sie die Entwicklertools Ihres Browsers und schauen Sie im Netzwerk Panel auf die erste Dokumentanfrage. Konkret zeigt die Zeitleiste die Wartezeit auf die Serverantwort als eigenen Punkt. Ist diese Wartezeit lang, liegt das Problem sehr wahrscheinlich beim Server.

Angenommen, die Wartezeit ist kurz, die Seite wirkt aber trotzdem träge. Dann liegt das Problem im Browser. Zum Beispiel können schwere Bilder oder blockierende Skripte die Ursache sein. In diesem Fall helfen Ihnen unsere Beiträge zu Bildern und JavaScript weiter.

Viele Websites leiden allerdings unter beidem. Der Server antwortet langsam, und die Seite ist zudem schwer. Gehen Sie dann der Reihe nach vor: Beheben Sie zuerst den Server, denn alle weiteren Ladeschritte warten auf das erste Byte.

Entscheiden Sie nie nach einer einzigen Messung. Testen Sie deshalb dieselbe Seite zu verschiedenen Zeiten und aus verschiedenen Netzen. Eine Seite, die nachts schnell und nachmittags langsam ist, deutet meist auf ein Ressourcenlimit oder ein Trafficproblem hin. Eine dauerhaft langsame Seite hat dagegen häufiger ein Problem mit Cache, Datenbank oder Konfiguration.

Beachten Sie auch, wie sich die Langsamkeit für Besucher anfühlt. Denn Besucher sehen einen leeren Bildschirm, Sie selbst sehen eine Zahl. Also besteht Ihre erste Aufgabe darin, dieses Gefühl in einen messbaren Wert zu übersetzen. Ohne diesen Wert erkennen Sie also nicht, ob eine Korrektur gewirkt hat.

Was ist TTFB und ab wann gilt sie als langsam?

TTFB, die Zeit bis zum ersten Byte, ist die Zeitspanne zwischen dem Start der Navigation zu einer Seite und dem Moment, in dem das erste Byte der Antwort eintrifft. Laut web.dev gehören Weiterleitungen, die DNS Abfrage, der Verbindungsaufbau samt TLS und die Anfragephase bis zum ersten Byte dazu.

Dieselbe Quelle nennt Schwellenwerte: Gute TTFB Werte liegen bei 0,8 Sekunden oder darunter, schlechte Werte über 1,8 Sekunden. Allerdings sind das nur allgemeine Richtwerte. Eine serverseitig gerenderte Seite und eine komplett im Browser aufgebaute Seite beurteilen Sie nicht mit demselben Maßstab.

Zunächst: TTFB ist keine Core Web Vitals Metrik. Allerdings warten Metriken wie LCP auf das erste Byte. Eine schlechte TTFB verzögert also jeden weiteren Schritt. Deshalb beginnen wir die Diagnose hier.

TTFB ist zwar eine einzige Zahl, sie verbirgt aber mehrere getrennte Verzögerungen. Die folgenden Abschnitte trennen diese Teile nacheinander:

• Die Weiterleitungskette und der Sprung von HTTP auf HTTPS.
• Dann die Dauer der DNS Auflösung.
• Danach der TCP Verbindungsaufbau und der TLS Handshake.
• Schließlich die Zeit, die der Server für den Seitenaufbau braucht: PHP, Datenbank, Cache.

Warum ist meine Website langsam: In welcher Reihenfolge diagnostizieren Sie?

Einstellungen zufällig zu ändern ist der teuerste Weg, denn Sie wissen nie, welche Änderung geholfen hat. Die folgende Reihenfolge geht von günstigen, sicheren Prüfungen zu aufwendigen, riskanten Eingriffen:

1. Messen Sie die Zeit bis zum ersten Byte der Startseite mehrmals und notieren Sie die Werte.
2. Trennen Sie danach DNS, Verbindung, TLS und Serverzeit voneinander.
3. Zählen Sie dann die Weiterleitungen in der Kette.
4. Prüfen Sie außerdem Cache Header und Seitencache.
5. Dann kontrollieren Sie die PHP Version und die Speichergrenzen.
6. Protokollieren Sie anschließend die langsamen Datenbankabfragen.
7. Schließlich suchen Sie in den Zugriffsprotokollen nach Bot und Angriffstraffic.

Ein einziger Befehl deckt die ersten beiden Schritte ab. Dabei nutzt das Beispiel die Zeitvariablen des Werkzeugs curl. Ersetzen Sie example.com durch Ihre eigene Adresse:

curl -o /dev/null -s -w "dns: %{time_namelookup}\nverbindung: %{time_connect}\ntls: %{time_appconnect}\nerstes_byte: %{time_starttransfer}\ngesamt: %{time_total}\n" https://example.com/

Die Werte in der Ausgabe sind kumulativ. Wenn Sie also den TLS Wert vom Wert für das erste Byte abziehen, erhalten Sie grob die Bearbeitungszeit des Servers. Zum Beispiel als Beispielrechnung: Zeigt TLS 0,25 und das erste Byte 1,45, hat der Server etwa 1,2 Sekunden gebraucht. Diese Zahlen dienen nur als Beispiel.

Führen Sie den Befehl mindestens fünfmal aus. Denn der erste Lauf trifft oft auf einen kalten Cache, spätere Läufe sind schneller. Allein dieser Unterschied ist schon ein Hinweis.

Wie sehen Sie, wohin die Zeit im Server fließt?

Eine Messung von außen zeigt, dass die Verzögerung im Server liegt, aber nicht wo. Dafür können Sie der Serverantwort einen Server-Timing Header hinzufügen. Laut MDN übermittelt dieser Header Leistungsmetriken zum Anfrage und Antwortzyklus an den Browser. Zum Beispiel zeigt er die Lesezeit der Datenbank oder die CPU Zeit.

Server-Timing: db;dur=53, app;dur=47.2

Im Beispiel zeigt db die Datenbankzeit in Millisekunden. Der Eintrag app steht für die Zeit des Anwendungscodes. Diese Werte sehen Sie im Netzwerk Panel im Bereich Timings. Auch web.dev empfiehlt den Header, um Datenbankabfragen, die Seitenerzeugung und Cache Treffer zu messen.

Den Header zu erzeugen erfordert allerdings Code. Daher ist dieser Schritt Aufgabe Ihrer Entwicklerin oder Ihres Plugin Autors. Sie müssen nur wissen, was Sie verlangen: eine Zeitmessung, die den Seitenaufbau in mindestens drei Teile zerlegt. Dann wandert die Diskussion von Vermutungen zu Zahlen.

Seien Sie vorsichtig, wenn Sie ihn live aktivieren. Denn Metriknamen können Systemdetails verraten. Aktivieren Sie die Details deshalb nur in einer Testumgebung oder mit eingeschränktem Zugriff.

1. Wie bremst ein Ressourcenlimit im Hosting Ihre Website?

Shared Hosting teilt CPU, Arbeitsspeicher und Festplatte einer Maschine unter vielen Websites auf. Außerdem setzen Anbieter Limits pro Konto. Eine Website, die das Limit überschreitet, wird gedrosselt, also warten Anfragen in einer Schlange, und die Zeit bis zum ersten Byte steigt.

Das typische Symptom ist eine zeitabhängige Langsamkeit. Zum Beispiel ist die Seite morgens schnell, wird aber während einer Kampagne oder eines Backups langsam. Viele Panels enthalten eine Anzeige der Ressourcennutzung. Name und Detailgrad unterscheiden sich je nach Anbieter, suchen Sie also den passenden Bereich in Ihrem Panel.

Auch web.dev geht darauf ein. Dort steht, dass eine Anwendung mit zu wenig Arbeitsspeicher Mühe hat, Seiten schnell auszuliefern. Das heißt, das Problem kann in der Obergrenze Ihres Tarifs liegen und nicht in Ihrem Code.

Die Reihenfolge der Lösung ist dabei einfach. Reduzieren Sie zuerst unnötige Prozesse, dann ergänzen Sie Caching. Stoßen Sie danach immer noch an die Grenze, denken Sie über einen Tarifwechsel nach. Worauf Sie bei der Auswahl achten, erklären wir in unserem Leitfaden zur Wahl des Webhostings.

Seien wir ehrlich: Das Ressourcenlimit können Sie nicht selbst ändern. Diese Entscheidung liegt beim Anbieter, daher können Sie nur Belege sammeln. Messungen mit Uhrzeit und Screenshots der Nutzungsanzeige stärken Ihr Support Ticket deutlich.

2. Bremst eine veraltete PHP Version Ihre Website und gefährdet sie?

Konkret gibt das PHP Projekt jedem Release Zweig zwei Arten von Support. Laut php.net gibt es in den ersten zwei Jahren Fehlerkorrekturen und Sicherheitskorrekturen. In den folgenden zwei Jahren gibt es nur noch Sicherheitskorrekturen. Nach vier Jahren erreicht der Zweig das Lebensende, und es folgen keine Patches mehr.

Eine alte Version ist also nicht nur langsam, sondern auch angreifbar. Einen genauen Geschwindigkeitsgewinn versprechen wir nicht, denn der Gewinn hängt von der Anwendung ab. In den Release Notes aktueller Versionen lesen Sie aber die Hinweise zur Performance.

Um Ihre Version zu erfahren, genügt ein Befehl auf dem Server:

php -v

Nutzen Sie cPanel, finden Sie die Versionswahl meist im Bildschirm MultiPHP Manager. Im WordPress Dashboard kann außerdem die Seite Website Zustand unter Werkzeuge vor der PHP Version warnen.

Ändern Sie die Version daher nicht direkt auf einer Live Seite. Probieren Sie sie zuerst auf einer Testkopie aus, denn alte Plugins und Themes können mit einer neuen Version Fehler zeigen. Welche Version aktuell stabil ist, sehen Sie auf der Seite php.net.

3. Wie verzögern langsame Datenbankabfragen eine Seite?

Zum Beispiel kann PHP beim Aufbau einer dynamischen Seite dutzende Abfragen an die Datenbank senden. Eine einzelne Abfrage ohne Index kann mit wachsender Tabelle auf Sekunden anwachsen. Eine solche Abfrage hält die ganze Seite auf, also leidet die Zeit bis zum ersten Byte direkt.

Laut MySQL Dokumentation ist das Slow Query Log standardmäßig ausgeschaltet. Der Standardwert von long_query_time beträgt 10 Sekunden. Schalten Sie das Log deshalb nicht nur ein, sondern senken Sie auch den Schwellenwert. Die folgenden Einstellungen sind ein Beispiel:

[mysqld]
slow_query_log = 1
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log

Der Dateipfad hängt von der Distribution ab. Ist das Log gefüllt, fasst das Werkzeug mysqldumpslow den Inhalt zusammen. Eine verdächtige Abfrage prüfen Sie mit EXPLAIN:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

Zeigt die Ausgabe einen vollständigen Tabellenscan, fehlt womöglich ein passender Index. Machen Sie allerdings vor dem Anlegen eines Index ein Backup. Wie das geht, steht in unserer Anleitung zur Backup Strategie für Websites. Wenn Sie Ihre Abfragelogik auffrischen möchten, hilft auch der Beitrag zu SQL Abfrageszenarien.

Im Shared Hosting haben Sie auf diese Einstellungen meist keinen Zugriff. Bitten Sie dann Ihren Anbieter um eine Zusammenfassung der langsamen Abfragen.

4. Baut der Server ohne Cache jede Seite für jeden Besucher neu auf?

Ja. Ohne Cache wiederholt also jeder Besuch dieselbe Arbeit. PHP läuft, die Datenbank antwortet, und das HTML entsteht neu. Dabei kann ein Blogbeitrag oder eine Kategorieseite tagelang gleich bleiben. Diese Arbeit jedes Mal zu wiederholen, verschwendet Ressourcen.

Unterscheiden Sie drei Ebenen:

• Ein Seitencache liefert fertiges HTML direkt aus.
• Ein Objektcache hält häufige Datenbankergebnisse im Arbeitsspeicher.
• Die eingebaute PHP Erweiterung OPcache speichert kompilierten Code.

Auch im Browser sind Header wie Cache-Control wichtig. web.dev empfiehlt passende Header für statische und halbstatische Inhalte sowie eine Strategie für die Cache Invalidierung. Den Objektcache im Detail erklärt unser Beitrag zu Redis und Memcached.

Achten Sie darauf, denn Warenkorb, Kasse und Kundenkonto müssen außerhalb des Seitencaches bleiben. Sonst könnte ein Kunde den Warenkorb eines anderen sehen. In Shops prüfen Sie daher immer die Ausnahmeliste des Plugins, das diese Einstellung anwendet.

5. Kann eine DNS Verzögerung die Zeit bis zum ersten Byte verlängern?

Ja, bei den meisten Websites ist der Anteil aber klein. Bevor sich der Browser mit Ihrem Server verbindet, muss er den Domainnamen in eine IP Adresse übersetzen. Ist diese Auflösung langsam, verspätet sich die gesamte Anfrage. Den Unterschied spüren Sie, wenn die DNS Server Ihres Anbieters langsam sind oder die Kette der Einträge lang ist.

Zunächst nutzen Sie zur Prüfung den Befehl dig. Die Zeile Query time am Ende der Ausgabe zeigt die Auflösungszeit in Millisekunden:

dig example.com

Im Browser listet unsere DNS Abfrage die Einträge A, CNAME und NS auf. Wo die Domain liegt, zeigen Ihnen außerdem die WHOIS Abfrage und die IP Abfrage.

Suchen Sie nach überflüssigen CNAME Ketten, alten Subdomains ohne Nutzung und widersprüchlichen NS Einträgen. Bieten Sie IPv6 an, bestätigen Sie mit dem IPv6 Test, dass beide Protokolle funktionieren.

Gehen Sie deshalb bei Änderungen an DNS Einträgen vorsichtig vor. Ein falscher Eintrag kann E-Mail und Website gleichzeitig lahmlegen. Sind Sie unsicher, überlassen Sie die Änderung Ihrem Domain oder Hosting Anbieter.

6. Wie verzögern TLS und Weiterleitungsketten das erste Byte?

In der Praxis kostet jede Weiterleitung eine weitere Runde. Ein Besucher tippt eine http Adresse, der Server leitet auf https um, und danach folgt eine weitere Weiterleitung auf die Adresse mit www. Eine Kette aus drei Schritten erzeugt also drei getrennte Wartezeiten vor dem ersten Byte. web.dev weist ebenfalls darauf hin, dass sich Weiterleitungen aufsummieren.

Diesen Befehl führen Sie aus, um die Kette zu sehen:

curl -sIL -o /dev/null -w "weiterleitungen: %{num_redirects}\nend_url: %{url_effective}\n" http://example.com/

Liegt die Zahl über eins, kürzen Sie die Kette. Das Ziel: Jede alte Adresse führt direkt zur Endadresse. Im Browser erledigt das unser Redirect Checker.

web.dev empfiehlt außerdem den HSTS Header. Er hilft dem Browser, bei späteren Besuchen die Weiterleitung von HTTP auf HTTPS zu überspringen. Gültigkeit und Kette Ihres Zertifikats prüfen Sie mit dem SSL Check. Was ein Zertifikat leistet, lesen Sie in unserem Beitrag zum SSL Zertifikat.

Allerdings sollten Sie HSTS nicht leichtfertig einschalten. Einmal verbreitet, lässt es sich schwer zurücknehmen, denn Browser merken sich die Regel. Stellen Sie deshalb zuerst sicher, dass alle Subdomains für HTTPS bereit sind.

7. Wie bremsen Bot und DDoS Traffic eine Website?

Jede Anfrage erzeugt Arbeit auf dem Server, egal ob sie von einem Menschen oder einem Bot stammt. Fressen gefälschte Bots, übereifrige Crawler oder Angriffstraffic die Ressourcen, spüren echte Besucher die Langsamkeit. Daher ist das Symptom meist ein plötzlicher, unerklärlicher Lastanstieg.

Zunächst beginnen Sie mit den Zugriffsprotokollen. Der folgende Befehl sortiert die Adressen mit den meisten Anfragen. Der Pfad der Logdatei hängt von Ihrem Setup ab, und das erste Feld ist als IP angenommen:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

Logdateien im Browser prüfen Sie mit unserer Logfile Analyse. Blockieren Sie aber nicht jede starke Quelle. Zwar empfiehlt Google bei Überlast die Antwortcodes 500, 503 oder 429. Trotzdem warnt die Dokumentation zur Crawling Rate davor, dass lang anhaltende Fehlerantworten die Darstellung Ihrer Website bei Google beeinträchtigen können.

Den echten Googlebot erkennen Sie mit unserem Beitrag zur Googlebot Verifizierung. Fragen Sie sich, warum das Crawling nachlässt, hilft der Beitrag zum Rückgang der Crawl Rate.

Einen Angriff mit hohem Volumen stoppen Sie nicht selbst. Dafür brauchen Sie Schutz auf Netzwerkebene. Wenden Sie sich deshalb sofort an Ihren Hosting Anbieter oder einen Schutzdienst am Netzwerkrand.

8. Wie bremsen überladene Plugins eine WordPress Website?

Außerdem fügt jedes Plugin dem Seitenaufbau Code und oft zusätzliche Abfragen hinzu. Das Problem ist nicht die Anzahl, sondern der Aufwand jedes einzelnen. Zehn saubere Plugins können weniger kosten als ein nachlässiges. Zählen Sie daher nicht, sondern messen Sie die Kosten.

Das Plugin Query Monitor auf WordPress.org zeigt die Abfragen pro Seite und welches Plugin oder Theme sie sendet. Installieren Sie es daher zuerst auf einer Testkopie. Prüfen Sie dann langsame Abfragen und wiederholte Anfragen nach Komponenten.

Hinzu kommt der Ballast in der Datenbank. Manche Einträge der WordPress Optionstabelle laden bei jedem Seitenaufruf automatisch. Zum Beispiel können Reste entfernter Plugins diesen Bereich vergrößern. Folglich trägt jede Seite unnötige Daten mit sich.

Zudem sind geplante Aufgaben eine weitere Ressource. Der WordPress Planer startet mit Besuchen. Fallen schwere Aufgaben in Stoßzeiten, können sie die Zeit bis zum ersten Byte verlängern.

Die Regel ist einfach: Entfernen Sie Plugins, die Sie nicht nutzen, und behalten Sie von zwei gleichartigen Plugins nur eines. Müssen Sie über die Grundstruktur entscheiden, lesen Sie unseren Vergleich WordPress oder individuelle Website. Machen Sie auf einer Live Seite immer ein Backup, bevor Sie ein Plugin löschen.

9. Wie stark beeinflussen CDN und Serverdistanz das erste Byte?

Die räumliche Distanz zwischen Server und Besucher erhöht die Latenz. Steht Ihr Server in Europa und der Besucher auf einem anderen Kontinent, dauert jede Verbindungsrunde länger. Weil ein TLS Handshake mehrere Runden braucht, vervielfacht sich der Unterschied.

web.dev empfiehlt als Lösung ein CDN. Ein CDN liefert Ressourcen von Servern aus, die näher am Besucher stehen. Zudem bieten CDN Anbieter meist schnelles DNS, HTTP/2, HTTP/3 und modernes TLS.

Ein CDN löst allerdings nicht alles. Dynamische Seiten, die sich nicht zwischenspeichern lassen, gehen weiter zum Ursprungsserver. Auch einmalige Abfrageparameter können den CDN Cache blockieren. Zum Beispiel sinkt die Trefferquote, wenn jede Anfrage einen anderen Tracking Parameter trägt.

Um das bei sich zu prüfen, schauen Sie, wo die meisten Besucher sitzen. Liegt Ihre Zielgruppe in einem Land, ist ein Server in der Nähe dieses Landes oft so wirksam wie ein CDN. Für diese Entscheidung werfen Sie einen Blick auf die Rechenzentren Ihres Hosting Anbieters.

10. Warum gehen auf einem VPS Arbeitsspeicher und CPU aus?

Auf Ihrem eigenen VPS legen Sie die Ressourcengrenzen fest, aber die Verantwortung wandert auch zu Ihnen. Ist der Arbeitsspeicher voll, lagert das System auf die Festplatte aus, und alles wird langsam. web.dev beschreibt genau das: Bei zu wenig Arbeitsspeicher hat die Anwendung Mühe.

Drei Befehle liefern eine schnelle Momentaufnahme:

free -h
uptime
ps aux --sort=-%mem | head -5

Der erste zeigt Speicher und Auslagerung, der zweite die durchschnittliche Last, der dritte die Prozesse mit dem größten Speicherbedarf. Sie können außerdem in den Kernel Protokollen suchen, ob das System einen Prozess wegen Speichermangels beendet hat.

Nutzen Sie PHP-FPM, zählt die Zahl der gleichzeitigen Worker. Ist sie zu niedrig, warten Anfragen dagegen in einer Schlange. Ist sie zu hoch, geht der Speicher aus. Der richtige Wert hängt vom Serverspeicher und von der Größe Ihrer Anfragen ab. Tippen Sie also keine Zufallszahl ein, sondern lesen Sie die Konfigurationsdokumentation.

Seien Sie in dieser Phase besonders vorsichtig, denn eine falsche Worker Zahl kann die Website komplett lahmlegen. Haben Sie kein sicheres Backup und keinen Plan für den Rückweg, überlassen Sie die Änderung einer Fachperson.

Welches Werkzeug misst was?

Zusammengefasst zeigt die Tabelle die Werkzeuge dieses Beitrags auf einen Blick. Die letzte Spalte zeigt, wann Sie welches wählen.

Verlassen Sie sich daher nicht auf ein einziges Werkzeug. Kombinieren Sie Messung von außen mit Messung von innen, dann geht die Diagnose schneller. So haben Sie im Gespräch mit Ihrem Anbieter konkrete Daten in der Hand.

Wie fassen Sie die 10 Ursachen in einer Tabelle zusammen?

Die Tabelle stellt typisches Symptom und erste Prüfung jeder Ursache nebeneinander. So können Sie bei der Diagnose schnell nachschlagen. Die Antwort auf die Frage, warum ist meine Website langsam, besteht selten aus einer einzigen Zeile. Meist überlagern sich zwei oder drei Ursachen, lesen Sie die Tabelle also vollständig.

Wann sollten Sie es nicht selbst tun und Ihrem Hosting Anbieter überlassen?

Alles selbst lösen zu wollen, geht nämlich oft nach hinten los. In den folgenden Fällen überlassen Sie die Arbeit Ihrem Anbieter oder einer erfahrenen Systemadministratorin:

• Sie haben im Shared Hosting keinen Zugriff auf Servereinstellungen.
• Der Angriffstraffic trifft auf Netzwerkebene ein.
• Sie müssten die Datenbankstruktur ohne Backup ändern.
• Sie wollen PHP auf einem Live Shop ohne Test aktualisieren.
• Die Ursache ist ein Ressourcenlimit, und ein Tarifwechsel ist nötig.
• Sie sind nicht sicher, was ein Befehl tut.

Diese Liste ist keine Zaghaftigkeit, sondern Risikomanagement. Denn ein falscher Befehl kann Website, E-Mail und Daten gleichzeitig treffen. Fügen Sie beim Support Ticket Ihre Messwerte und die Uhrzeit der Verlangsamung hinzu. So findet der Anbieter die Ursache schneller.

Gehen Sie bei der Sicherheit mit derselben Ehrlichkeit vor. Ein langsamer Server ist allerdings manchmal ein Zeichen für einen Einbruch. Haben Sie diesen Verdacht, lesen Sie unseren Beitrag zu den OWASP Top 10 und holen Sie Fachhilfe.

Wie schaden langsame Seiten SEO und Umsatz?

Ein langsamer Server schadet auf zwei Wegen. Erstens verlassen Besucher die Seite, bevor sie sich öffnet. Zweitens crawlen Suchmaschinen weniger, wenn der Server Fehler liefert. Laut Googles Dokumentation senken häufige Antworten mit 500, 503 oder 429 die Crawling Rate, und dieser Rückgang betrifft den gesamten Hostnamen.

Im E-Commerce schlägt sich die Wirkung direkt im Umsatz nieder. Folglich ist jede Verzögerung auf dem Weg zum Warenkorb eine verlorene Chance. Die Details finden Sie in unserem Beitrag zur Ladezeit im Onlineshop.

Bei der Messung helfen Ihnen unser Lighthouse Test und der Beitrag zu Core Web Vitals, Verzögerungen im Browser zu verstehen. Verbessert sich der Server, verbessern sich diese Messwerte oft mit. Trotzdem versprechen wir nicht, wie stark eine Metrik steigt.

Wie bestätigen Sie die Verbesserung nach einer Korrektur?

Nehmen Sie vor und nach jeder Änderung dieselbe Messung unter denselben Bedingungen. Verwenden Sie also dieselbe Seite, dasselbe Zeitfenster und denselben Befehl. Ändern Sie deshalb immer nur eine Sache. Ändern Sie drei Einstellungen zugleich, wissen Sie nicht, welche gewirkt hat.

Suchen Sie nicht nach einer einzigen Endantwort auf die Frage, warum ist meine Website langsam. Denn jede Korrektur verkleinert den Rest und hinterlässt eine neue größte Ursache. Der Prozess ist also eine Schleife: messen, eine Sache beheben, erneut messen.

Eine einzelne Messung genügt allerdings nicht. Führen Sie den Befehl mindestens fünfmal aus und achten Sie auf den Gesamttrend. Notieren Sie außerdem den Stand mit warmem und mit kaltem Cache getrennt.

Echte Besucherdaten sammeln sich langsamer. web.dev nennt für Felddaten den Chrome User Experience Report und die Bibliothek web-vitals. Diese Daten bewegen sich deshalb eventuell nicht innerhalb weniger Tage. Beginnen Sie daher mit Labormessungen und beobachten Sie die Felddaten später.

Führen Sie zudem ein Messprotokoll. Datum, Änderung sowie Werte davor und danach stehen nebeneinander. Kehrt das Problem nach sechs Monaten zurück, spart Ihnen dieses Protokoll Zeit.

Warum ist meine Website langsam, obwohl ich aufgerüstet habe, und wie hilft unser Team?

Wir sind kein Hosting Anbieter und betreiben keine Server als Dienstleistung. Als Team für digitales Marketing und Web helfen wir Ihnen, die Wirkung der Langsamkeit auf Geschäftsergebnisse zu messen. Außerdem helfen wir Ihnen zu trennen, was zum Server und was zur Website gehört.

Planen Sie eine neue Website, bauen wir eine Struktur, die Performance von Anfang an einrechnet. Dazu schauen Sie sich also unsere Leistung Webdesign an. Bei der Auffindbarkeit verbindet unsere SEO Beratung technische Befunde mit einem Inhaltsplan. Betreiben Sie einen Shop, sehen Sie sich die E-Commerce Beratung an.

Eine kleine Anmerkung: Kein Befehl in diesem Beitrag ist Zauberei. Denn jeder beantwortet nur eine Frage. Die Antwort zu deuten, also zu wissen, welcher Wert für Ihre Website normal ist, braucht Zeit und Vergleich. Nehmen Sie daher Ihre ersten Messwerte heute auf, denn morgen haben Sie eine Referenz zum Vergleichen.

Wir empfehlen, Befunde, die Eingriffe am Server erfordern, gemeinsam mit Ihrem Anbieter zu lösen. Wir formulieren den Befund klar und helfen Ihnen zu entscheiden, was Sie verlangen. So wird Ihr Support Ticket keine vage Beschwerde mehr.