Langsame Website: Ursachen systematisch finden

Eine langsame Website kann viele Ursachen haben. Große Bilder, aufwendiges JavaScript, langsame Datenbankabfragen, externe Dienste, fehlendes Caching oder eine verzögerte serverseitige Verarbeitung können sich ähnlich bemerkbar machen.

Deshalb ist es selten sinnvoll, ohne Diagnose wahllos Einstellungen zu verändern oder verschiedene Optimierungs-Plugins zu installieren.

Der bessere Weg ist eine systematische Fehlersuche: Zuerst wird festgestellt, wo die Verzögerung entsteht. Anschließend wird die technische Ursache eingegrenzt und erst dann eine gezielte Änderung vorgenommen.

In dieser Anleitung zeigen wir dir, wie du bei einer langsamen Website Schritt für Schritt vorgehst und typische Ursachen voneinander unterscheidest.

Kurz erklärt: „Die Website ist langsam“ ist zunächst nur ein Symptom. Für eine sinnvolle Optimierung musst du herausfinden, ob die Verzögerung beim Server, im Browser, bei einzelnen Ressourcen, in der Anwendung oder bei einem externen Dienst entsteht.

Was bedeutet eigentlich „langsame Website“? #

Besucher können Geschwindigkeit auf unterschiedliche Weise wahrnehmen.

Eine Seite kann beispielsweise lange weiß bleiben, bevor überhaupt etwas erscheint. Bei einer anderen Website wird der Inhalt schnell sichtbar, aber ein großes Bild erscheint erst deutlich später. Wieder eine andere Seite lädt optisch schnell, reagiert jedoch verzögert auf Klicks.

Diese Situationen können völlig unterschiedliche technische Ursachen besitzen.

Fall A
→ Server antwortet spät

Fall B
→ Hauptinhalt erscheint spät

Fall C
→ große Ressourcen laden langsam

Fall D
→ Seite reagiert langsam auf Interaktionen

Fall E
→ externe Funktion verzögert sich

Fall F
→ Problem tritt nur gelegentlich auf

Bevor du optimierst, solltest du deshalb möglichst genau beschreiben können, was tatsächlich langsam ist.

Zuerst messen, dann optimieren #

Der erste Schritt ist eine reproduzierbare Ausgangsmessung.

Wenn du nur nach Gefühl arbeitest, kannst du später kaum beurteilen, ob eine Änderung tatsächlich geholfen hat.

Teste deshalb eine konkrete URL mehrfach und dokumentiere die wichtigsten Ergebnisse.

Wie du solche Messungen sinnvoll durchführst, erklären wir unter Website-Ladezeit messen und richtig beurteilen.

Praxis-Tipp: Notiere vor einer Änderung mindestens die getestete URL, Gerätetyp, verwendetes Messwerkzeug und die auffälligen Messwerte. Danach kannst du denselben Test wiederholen.

Nicht nur die Startseite testen #

Eine schnelle Startseite bedeutet nicht automatisch, dass die gesamte Website schnell ist.

Teste deshalb die Seite, auf der das Problem tatsächlich auftritt.

Bei einem Online-Shop können beispielsweise Produktseite, Warenkorb und Checkout technisch sehr unterschiedlich arbeiten.

Startseite schnell
Produktseite langsam

→ Problem wahrscheinlich nicht pauschal
  auf der gesamten Website

Das ist bereits ein wertvoller Hinweis für die weitere Diagnose.

Ist die gesamte Website oder nur eine Seite langsam? #

Öffne mehrere unterschiedliche Seiten derselben Website.

Sind alle Seiten ähnlich langsam, kommen eher übergreifende Ursachen infrage. Ist dagegen nur eine bestimmte URL oder ein bestimmter Seitentyp betroffen, solltest du zunächst dessen Besonderheiten untersuchen.

Beispiele:

alle Seiten langsam
→ serverseitige Verarbeitung?
→ globale Scripts?
→ Theme?
→ externe Dienste?
→ allgemeine Konfiguration?

nur Produktseiten langsam
→ Shop-Funktionen?
→ Produktbilder?
→ Varianten?
→ Datenbankabfragen?
→ zusätzliche Scripts?

nur eine einzelne Seite langsam
→ spezifischer Inhalt?
→ eingebettetes Video?
→ Slider?
→ externe API?
→ ungewöhnlich große Ressourcen?

Ist die Website immer oder nur manchmal langsam? #

Auch der zeitliche Verlauf ist wichtig.

Eine dauerhaft langsame Website hat möglicherweise eine andere Ursache als eine Seite, die normalerweise schnell ist und nur gelegentlich sehr lange reagiert.

Bei sporadischen Problemen können beispielsweise externe Dienste, Hintergrundprozesse, Lastspitzen oder zeitweise Netzwerkprobleme eine Rolle spielen.

Führe deshalb mehrere Messungen zu unterschiedlichen Zeitpunkten durch, wenn das Problem nicht konstant auftritt.

Frontend und Backend unterscheiden #

Für die Fehlersuche ist eine grobe Trennung zwischen serverseitiger Verarbeitung und browserseitiger Verarbeitung hilfreich.

BACKEND / SERVER

Anfrage
   ↓
Webserver
   ↓
PHP / Anwendung
   ↓
Datenbank
   ↓
HTML-Antwort


FRONTEND / BROWSER

HTML
   ↓
CSS
   ↓
JavaScript
   ↓
Fonts
   ↓
Bilder
   ↓
Darstellung und Interaktion

Eine Website kann auf der Serverseite schnell erzeugt werden und anschließend im Browser trotzdem langsam wirken.

Umgekehrt kann ein sehr schlankes Frontend auf eine serverseitige Antwort warten, die lange benötigt.

TTFB als erster Hinweis #

Die Time to First Byte, kurz TTFB, kann einen ersten Hinweis darauf geben, wie lange es bis zum Eintreffen des ersten Bytes der Antwort dauert.

Ein auffälliger TTFB bedeutet allerdings nicht automatisch, dass ausschließlich der Webserver langsam ist.

Der Wert kann unter anderem durch Netzwerk, Verbindungsaufbau, serverseitige Verarbeitung und weitere Faktoren beeinflusst werden.

Die Bedeutung solcher Messwerte behandeln wir ausführlicher unter Website-Ladezeit messen und richtig beurteilen.

Wenn bereits die HTML-Antwort lange dauert #

Wenn der Browser lange auf die eigentliche Dokumentantwort wartet, solltest du zunächst den serverseitigen beziehungsweise anwendungsseitigen Bereich untersuchen.

Mögliche Ursachen können sein:

• aufwendige PHP-Verarbeitung,
• langsame Datenbankabfragen,
• externe API-Abfragen,
• fehlendes oder nicht greifendes Caching,
• fehlerhafte Erweiterungen,
• ressourcenintensive Hintergrundprozesse.

Erst wenn klar ist, welcher Bereich tatsächlich Zeit benötigt, lässt sich sinnvoll weiterarbeiten.

Eine hohe TTFB bedeutet nicht automatisch schlechtes Hosting #

Die Ursache einer langsamen serverseitigen Antwort kann innerhalb der Website-Anwendung liegen.

Ein WordPress-Plugin kann beispielsweise bei jedem Seitenaufruf aufwendige Datenbankoperationen ausführen oder auf einen externen Dienst warten.

Mehr Serverleistung kann ein ineffizientes Verhalten unter Umständen abmildern, beseitigt aber nicht automatisch dessen Ursache.

Wichtig: Beurteile Hosting-Performance nicht anhand eines einzelnen TTFB-Werts. Zuerst muss geklärt werden, welcher Teil der Anfrage die Verzögerung verursacht.

PHP und die Anwendung untersuchen #

Dynamische Websites erzeugen Inhalte häufig mit PHP oder einer vergleichbaren serverseitigen Anwendung.

Bei WordPress werden dabei beispielsweise WordPress selbst, Theme, Plugins und Datenbank beteiligt.

Eine langsame PHP-Verarbeitung kann unterschiedliche Ursachen besitzen:

aufwendiger Plugin-Code
zu viele oder ineffiziente Datenbankabfragen
externe HTTP-Anfragen
große Datenmengen
fehlerhafte Prozesse
ungeeignete Konfiguration
veraltete Software
ressourcenintensive Funktionen

Die reine Anzahl installierter Plugins ist dabei kein zuverlässiges Qualitätsmaß.

Viele Plugins bedeuten nicht automatisch eine langsame Website #

Die Aussage „zu viele Plugins machen WordPress langsam“ ist zu pauschal.

Ein einzelnes schlecht programmiertes oder für die jeweilige Aufgabe sehr aufwendiges Plugin kann mehr Performance-Probleme verursachen als mehrere schlanke Erweiterungen.

Entscheidend ist deshalb nicht nur:

Wie viele Plugins sind installiert?

Sondern:

Was tun diese Plugins bei einem Seitenaufruf?

Plugins nicht wahllos auf der Live-Website deaktivieren #

Wenn ein Plugin als Ursache vermutet wird, sollte die Prüfung kontrolliert erfolgen.

Das wahllose Deaktivieren von Erweiterungen auf einer produktiven Website kann Funktionen beeinträchtigen oder einen Online-Shop unbenutzbar machen.

Bei umfangreicheren Tests ist eine Staging- oder Testumgebung deshalb häufig die bessere Wahl.

Achtung: Erstelle vor größeren Änderungen ein aktuelles Backup. Bei Shops, Mitgliederseiten oder anderen dynamischen Websites muss zusätzlich berücksichtigt werden, dass zwischen Backup und Wiederherstellung neue Daten entstehen können.

Datenbank als mögliche Ursache #

Viele dynamische Websites greifen bei jedem Seitenaufruf auf eine Datenbank zu.

Problematisch können beispielsweise sehr aufwendige Abfragen, große Datenmengen oder ungünstige Erweiterungen sein.

Bei WordPress können unter anderem Plugins, Themes oder individuelle Funktionen Datenbankabfragen auslösen.

Ein Datenbankproblem sollte jedoch diagnostiziert und nicht allein aufgrund der Größe der Datenbank vermutet werden.

Eine große Datenbank ist nicht automatisch langsam #

Die Dateigröße beziehungsweise Datenmenge einer Datenbank sagt allein wenig über die tatsächliche Abfrageperformance aus.

Entscheidend ist unter anderem, welche Daten abgefragt werden und wie effizient dies geschieht.

Deshalb ist:

Datenbank groß → Datenbank langsam

keine zuverlässige Schlussfolgerung.

Externe API-Abfragen auf dem Server #

Eine Website kann während der serverseitigen Verarbeitung andere Systeme kontaktieren.

Beispiele sind:

Zahlungsdienste
externe APIs
Lizenzserver
CRM-Systeme
Versanddienste
externe Datenquellen

Wenn eine solche Anfrage synchron abgewartet werden muss und der externe Dienst langsam reagiert, kann sich dadurch auch die Antwort deiner Website verzögern.

Das Problem muss dann nicht auf dem eigenen Webserver liegen.

Caching prüfen #

Caching kann die serverseitige Arbeit erheblich reduzieren, wenn bereits erzeugte Inhalte oder Ergebnisse wiederverwendet werden können.

Welche Cache-Arten sinnvoll sind, hängt von der jeweiligen Website und Anwendung ab.

Vereinfacht können unterschiedliche Ebenen beteiligt sein:

Browser-Cache
Page Cache
Object Cache
Opcode Cache
CDN / Edge Cache

Diese Systeme erfüllen unterschiedliche Aufgaben und sollten nicht einfach als ein einziger „Cache“ betrachtet werden.

Cache ist nicht für jeden Inhalt gleich geeignet #

Eine öffentliche statische Inhaltsseite lässt sich anders behandeln als ein personalisierter Kundenbereich oder ein Warenkorb.

Bei dynamischen Bereichen muss deshalb genau festgelegt sein, welche Inhalte zwischengespeichert werden dürfen.

Ein aggressiver Cache kann zwar Performance verbessern, bei falscher Konfiguration aber auch veraltete oder für den falschen Benutzer bestimmte Inhalte ausliefern.

Cache leeren ist keine dauerhafte Optimierung #

„Cache leeren“ wird häufig als universelle Problemlösung empfohlen.

Das Leeren eines Caches kann bei veralteten oder fehlerhaften Cache-Inhalten sinnvoll sein. Es beseitigt aber nicht automatisch die Ursache einer langsamen Website.

Nach dem Leeren müssen bestimmte Cache-Inhalte außerdem zunächst neu aufgebaut werden.

Wenn der Server schnell antwortet, aber die Seite trotzdem langsam wirkt #

Dann solltest du den browserseitigen Teil genauer untersuchen.

Typische Kandidaten sind:

große Bilder
zu viele übertragene Daten
JavaScript
CSS
Webfonts
Videos
externe Dienste
Drittanbieter-Widgets
ungünstige Ladeprioritäten

Google PageSpeed Insights kann bei der Identifikation solcher Probleme helfen. Die Bedienung und Interpretation erklären wir unter Google PageSpeed Insights richtig verwenden.

Bilder als Performance-Ursache #

Bilder gehören bei vielen Websites zu den größten übertragenen Ressourcen.

Ein typischer Fehler ist beispielsweise, ein Foto mit mehreren tausend Pixeln Breite hochzuladen, obwohl es auf der Website wesentlich kleiner dargestellt wird.

Auch ungeeignete Kompression oder ein unpassendes Dateiformat können unnötig große Dateien verursachen.

Wie du Bilder sinnvoll vorbereitest, erklären wir unter Bilder für das Web optimieren: Dateigröße, Format und SEO.

Pixelabmessungen und Dateigröße unterscheiden #

Ein Bild besitzt sowohl Abmessungen als auch eine Dateigröße.

Beispiel:

Abmessungen:
4000 × 2667 Pixel

Dateigröße:
5,8 MB

Beide Eigenschaften können für die Performance relevant sein.

Nur ein modernes Dateiformat zu verwenden, ohne unnötig große Abmessungen zu reduzieren, ist deshalb nicht immer ausreichend.

Das richtige Bildformat verwenden #

WebP und AVIF können bei geeigneten Bildern eine deutlich effizientere Kompression ermöglichen als ältere Formate.

PNG bleibt dagegen beispielsweise sinnvoll, wenn bestimmte Eigenschaften wie verlustfreie Grafikdarstellung oder Transparenz benötigt werden.

Welches Format für welchen Einsatzzweck sinnvoll ist, erklären wir unter WebP, AVIF, JPG und PNG: Welches Bildformat verwenden?.

Lazy Loading richtig einsetzen #

Lazy Loading kann verhindern, dass Bilder weit außerhalb des sichtbaren Bereichs sofort geladen werden.

Das reduziert beim ersten Seitenaufruf unter Umständen unnötige Datenübertragung.

Bei einem wichtigen Bild im unmittelbar sichtbaren Bereich kann ungeeignetes Lazy Loading dagegen den Zeitpunkt verzögern, an dem dieses Bild dargestellt wird.

Insbesondere bei einem LCP-Bild sollte deshalb geprüft werden, ob dessen Ladeverhalten sinnvoll konfiguriert ist.

Mehr dazu findest du unter Core Web Vitals erklärt: LCP, INP und CLS.

JavaScript als mögliche Ursache #

JavaScript ermöglicht interaktive und dynamische Funktionen, muss aber vom Browser geladen, verarbeitet und ausgeführt werden.

Problematisch kann beispielsweise sehr umfangreicher Code oder lange Arbeit auf dem Hauptthread sein.

Mögliche Quellen sind:

Theme
Plugins
Page Builder
Tracking
Animationen
Slider
Chat
externe Widgets
Marketing-Scripts

Die richtige Lösung ist nicht automatisch, JavaScript vollständig zu entfernen. Zuerst muss geklärt werden, welcher Code tatsächlich relevant ist.

Ungenutztes JavaScript richtig interpretieren #

Performance-Werkzeuge können melden, dass Teile einer JavaScript-Datei beim untersuchten Seitenaufruf nicht verwendet wurden.

Das bedeutet nicht automatisch, dass die komplette Datei gelöscht werden darf.

Ein Script kann beispielsweise erst nach einer Benutzerinteraktion oder auf einer anderen Unterseite benötigt werden.

Solche Hinweise sind Ausgangspunkte für eine Analyse, keine automatischen Löschanweisungen.

JavaScript verzögern: Vorsicht bei automatischen Optimierungen #

Bestimmte Performance-Lösungen können JavaScript verzögert laden oder ausführen.

Das kann in geeigneten Fällen helfen, kann aber auch wichtige Funktionen beeinträchtigen.

Nach solchen Änderungen solltest du deshalb insbesondere testen:

Navigation
Formulare
Cookie-Banner
Slider
Suche
Login
Warenkorb
Checkout
Zahlungsfunktionen
mobile Menüs

CSS kann die Darstellung verzögern #

CSS bestimmt die visuelle Darstellung einer Website.

Bestimmte Stylesheets können für das Rendering benötigt werden, bevor der Browser die Seite korrekt darstellen kann.

Performance-Werkzeuge können deshalb auf render-blockierende CSS-Ressourcen hinweisen.

Auch hier gilt: Eine angezeigte Datei darf nicht einfach entfernt werden. Ohne benötigtes CSS kann die Website falsch oder zunächst unformatiert dargestellt werden.

Ungenutztes CSS bedeutet nicht automatisch unnötige Datei #

Ein globales Stylesheet kann Regeln für zahlreiche Seitentypen enthalten.

Auf einer einzelnen getesteten URL werden möglicherweise nur einige davon benötigt.

Das Analysewerkzeug kann deshalb ungenutztes CSS melden, obwohl die entsprechenden Regeln auf anderen Seiten gebraucht werden.

Eine Optimierung sollte daher immer im Kontext der gesamten Website erfolgen.

Webfonts untersuchen #

Webfonts können zusätzliche Netzwerk-Anfragen und Rendering-Effekte verursachen.

Eine Website benötigt häufig nicht jede denkbare Schriftstärke und jeden Schriftschnitt.

Wenn beispielsweise zahlreiche Font-Dateien geladen werden, obwohl tatsächlich nur wenige Varianten verwendet werden, entsteht unnötiger Aufwand.

Prüfe deshalb, welche Schriftarten und Schriftschnitte wirklich benötigt werden.

Externe Schriftarten #

Werden Fonts von einem externen Anbieter geladen, kommt eine zusätzliche externe Verbindung hinzu.

Lokal bereitgestellte Schriftarten können in bestimmten Konfigurationen Vorteile bieten, müssen aber ebenfalls korrekt eingebunden und optimiert werden.

Die Entscheidung sollte nicht ausschließlich anhand der Anzahl der Requests getroffen werden.

Videos können erhebliche Datenmengen verursachen #

Direkt eingebundene oder automatisch startende Videos können große Datenmengen verursachen.

Auch eingebettete Videoplattformen können zusätzliche Scripts, Frames und externe Verbindungen laden.

Wenn Videos eine Seite ausbremsen, sollte geprüft werden, ob sie bereits beim ersten Seitenaufruf vollständig benötigt werden oder ob eine leichtere Vorschaulösung möglich ist.

Drittanbieter-Dienste untersuchen #

Viele moderne Websites laden Ressourcen von anderen Anbietern.

Dazu gehören beispielsweise:

Analytics
Tag-Manager
Social-Media-Feeds
Maps
Videos
Chat-Systeme
Bewertungsdienste
Werbesysteme
Marketing-Tools

Diese Ressourcen liegen teilweise außerhalb deiner direkten Kontrolle.

Wenn ein Drittanbieter langsam reagiert oder umfangreichen Code ausführt, kann sich das auf die Website-Performance auswirken.

Den geschäftlichen Nutzen externer Dienste berücksichtigen #

Die technische Optimierung darf nicht isoliert von der Funktion der Website betrachtet werden.

Ein notwendiger Zahlungsdienst kann beispielsweise nicht entfernt werden, nur weil er zusätzliche Ressourcen benötigt.

Bei einem kaum genutzten Social-Media-Widget kann die Abwägung dagegen anders aussehen.

Eine sinnvolle Frage lautet:

Ist der Nutzen dieser Funktion groß genug für die zusätzlichen technischen Kosten?

Browser-Entwicklerwerkzeuge verwenden #

Die Entwicklerwerkzeuge moderner Browser können zeigen, welche Ressourcen eine Website lädt und wie lange einzelne Anfragen benötigen.

Besonders hilfreich ist die Netzwerkansicht.

Dort kannst du beispielsweise erkennen:

HTML-Dokument
CSS-Dateien
JavaScript
Bilder
Fonts
API-Anfragen
externe Ressourcen
HTTP-Statuscodes
übertragene Datenmengen
Ladezeiten einzelner Requests

Eine Waterfall-Ansicht lesen #

Eine Wasserfallansicht zeigt die zeitliche Abfolge der geladenen Ressourcen.

Vereinfacht:

HTML        ███████
CSS            █████
JavaScript      █████████
Font              ██████
Hero-Bild            ███████████
API                       █████████

Damit kannst du erkennen, ob beispielsweise eine wichtige Ressource erst spät entdeckt wird oder eine externe Anfrage ungewöhnlich lange benötigt.

Nicht nur auf die Anzahl der Requests schauen #

Eine Seite mit 100 HTTP-Anfragen ist nicht automatisch langsamer als eine Seite mit 50.

Entscheidend sind unter anderem:

Größe der Ressourcen
Caching
Ladepriorität
Abhängigkeiten
Übertragungsprotokoll
Verarbeitung im Browser
Antwortzeit der Quellen

Die Anzahl der Requests ist deshalb nur ein Teil der Analyse.

Gesamtgröße der Seite prüfen #

Die übertragene Datenmenge kann insbesondere bei mobilen Verbindungen relevant sein.

Wenn eine einfache Inhaltsseite beispielsweise viele Megabyte überträgt, lohnt sich eine Untersuchung der größten Ressourcen.

Häufig sind Bilder, Videos, Fonts oder umfangreiche JavaScript-Dateien beteiligt.

Die Gesamtgröße sollte jedoch im Kontext des Seitentyps beurteilt werden. Eine Bildergalerie benötigt naturgemäß mehr Daten als eine reine Textseite.

Core Web Vitals als Diagnosehinweis verwenden #

Die Core Web Vitals können helfen, die Art eines Performance-Problems einzugrenzen.

Auffälliger Wert	Erste Fragestellung
LCP	Warum erscheint der wichtige Hauptinhalt so spät?
INP	Warum reagiert die Seite langsam auf Interaktionen?
CLS	Warum verschieben sich Seitenelemente unerwartet?

Die genaue Bedeutung und Diagnose dieser Werte behandeln wir unter Core Web Vitals erklärt: LCP, INP und CLS.

Desktop schnell, Mobil langsam #

Wenn eine Website auf dem Desktop gut funktioniert, auf mobilen Geräten aber deutlich schlechter abschneidet, solltest du nicht automatisch von einem Messfehler ausgehen.

Mobile Geräte können weniger Rechenleistung besitzen und über langsamere oder instabilere Netzwerkverbindungen zugreifen.

Besonders umfangreiches JavaScript und große Datenmengen können sich unter solchen Bedingungen stärker bemerkbar machen.

Die Website auf einem echten Smartphone testen #

Neben synthetischen Messungen lohnt sich deshalb immer ein praktischer Test.

Öffne wichtige Seiten auf einem Smartphone und benutze sie tatsächlich.

Achte beispielsweise auf:

Erscheint der Hauptinhalt schnell?

Funktioniert das Menü unmittelbar?

Reagieren Buttons?

Springt das Layout?

Laden Bilder auffällig spät?

Reagieren Formulare schnell?

Funktioniert der Checkout?

Ein technischer Score ersetzt nicht die tatsächliche Benutzung der Website.

Eingeloggte und ausgeloggte Besucher unterscheiden #

Bei Content-Management-Systemen kann sich die Website für einen angemeldeten Administrator anders verhalten als für normale Besucher.

Bestimmte Cache-Mechanismen werden beispielsweise für eingeloggte Benutzer nicht verwendet.

Teste die öffentliche Website deshalb zusätzlich in einem privaten Browserfenster, in dem du nicht angemeldet bist.

Ist nur der WordPress-Adminbereich langsam? #

Wenn die öffentliche Website schnell ist, aber der Administrationsbereich langsam reagiert, handelt es sich um ein anderes Fehlerbild.

Dann solltest du nicht primär Bilder oder Frontend-Caching untersuchen.

Mögliche Ursachen können beispielsweise Plugins, externe API-Aufrufe, Datenbankoperationen oder Hintergrundprozesse innerhalb der Anwendung sein.

Die Diagnose sollte sich in diesem Fall auf den Administrationsbereich konzentrieren.

WooCommerce und dynamische Seiten #

Online-Shops besitzen Bereiche, die sich nicht wie gewöhnliche öffentliche Inhaltsseiten behandeln lassen.

Warenkorb, Kundenkonto und Checkout enthalten dynamische beziehungsweise benutzerspezifische Informationen.

Eine Cache-Konfiguration, die für einen Blogartikel funktioniert, kann für solche Seiten ungeeignet sein.

Achtung: Ändere Cache- und JavaScript-Einstellungen bei einem produktiven Online-Shop nur kontrolliert. Teste anschließend Warenkorb, Login, Checkout und Zahlungsablauf vollständig.

Hintergrundprozesse berücksichtigen #

Backups, Imports, Exporte, Cronjobs, Bildverarbeitung oder andere Hintergrundaufgaben können Ressourcen beanspruchen.

Wenn Performance-Probleme immer zu bestimmten Zeiten auftreten, sollte deshalb geprüft werden, ob parallel wiederkehrende Prozesse laufen.

Ein einzelner Test während eines umfangreichen Imports ist möglicherweise nicht repräsentativ für den normalen Betrieb.

Fehlerprotokolle prüfen #

Bei ungewöhnlichem Verhalten können Fehlerprotokolle wichtige Hinweise liefern.

Wiederkehrende PHP-Fehler, Timeouts oder andere Meldungen können auf ein konkretes Problem hinweisen.

Ein Log sollte jedoch nicht allein nach der Anzahl der Einträge beurteilt werden. Entscheidend sind Zeitpunkt, Art und Zusammenhang mit dem beobachteten Performance-Problem.

HTTP-Fehler sind nicht dasselbe wie langsame Performance #

Wenn eine Ressource mit einem Fehlerstatus antwortet, handelt es sich nicht mehr ausschließlich um eine Performance-Frage.

Beispiele:

403 → Zugriff verweigert
404 → Ressource nicht gefunden
500 → interner Serverfehler

Die wichtigsten Statuscodes erklären wir unter HTTP-Statuscodes erklärt: 200, 301, 404, 403 und 500.

DNS-Probleme von Performance-Problemen unterscheiden #

Wenn eine Domain überhaupt nicht korrekt aufgelöst wird, handelt es sich zunächst um ein DNS- beziehungsweise Erreichbarkeitsproblem und nicht um eine gewöhnliche langsame Website.

Auch solche Fehler können für Besucher subjektiv wie „die Website lädt nicht“ wirken.

Deshalb ist eine genaue Fehlerbeschreibung wichtig.

HTTPS-Probleme können ebenfalls anders aussehen #

Fehlerhafte Zertifikate, Mixed Content oder andere HTTPS-Probleme sind ebenfalls von einer reinen Performance-Störung zu unterscheiden.

Die entsprechende Diagnose behandeln wir später unter SSL-Zertifikat und HTTPS prüfen: Häufige Fehler erkennen.

Serverressourcen und Limits #

Webanwendungen benötigen Rechenzeit, Arbeitsspeicher und weitere Ressourcen.

Werden verfügbare Ressourcen oder definierte Limits erreicht, kann sich dies auf die Verarbeitung auswirken.

Allerdings sollte auch hier die Ursache untersucht werden.

Wenn beispielsweise ein fehlerhaftes Plugin extrem viele Ressourcen benötigt, ist eine Erhöhung des Limits möglicherweise nur eine kurzfristige Symptombehandlung.

Mehr Leistung ist nicht immer die Lösung #

Ein leistungsfähigerer Tarif oder Server kann bei einem tatsächlichen Ressourcenengpass sinnvoll sein.

Er sollte aber nicht als erste Standardantwort auf jedes Performance-Problem verwendet werden.

Website langsam
      ↓
Ursache feststellen
      ↓
tatsächlicher Ressourcenengpass?
      ↓
JA → Ressourcenbedarf bewerten

NEIN → technische Ursache beheben

CDN: sinnvoll, aber kein Allheilmittel #

Ein Content Delivery Network kann bestimmte statische Ressourcen über geografisch verteilte Systeme bereitstellen und dadurch insbesondere für räumlich weit verteilte Zielgruppen Vorteile bieten.

Ein CDN repariert jedoch keinen ineffizienten PHP-Code und keine langsame Datenbankabfrage.

Auch hier muss die Maßnahme zum tatsächlichen Engpass passen.

Standort der Besucher berücksichtigen #

Netzwerklatenz hängt unter anderem davon ab, über welche Strecke und Route Daten übertragen werden.

Wenn die Zielgruppe einer Website überwiegend in der Schweiz und Mitteleuropa liegt, sollte die Performance nicht ausschließlich anhand eines Teststandorts auf einem anderen Kontinent beurteilt werden.

Für reproduzierbare Vergleiche sollten möglichst ähnliche Testbedingungen verwendet werden.

Ist die Website wirklich langsam oder nur dein Anschluss? #

Auch die lokale Internetverbindung, ein VPN, WLAN-Probleme, Browser-Erweiterungen oder ein einzelnes Gerät können das Ergebnis beeinflussen.

Wenn nur du ein Problem bemerkst, solltest du deshalb gegenprüfen.

Beispielsweise:

anderer Browser
privates Browserfenster
anderes Gerät
Mobilfunk statt WLAN
VPN testweise deaktivieren
anderer Internetanschluss

Ändert sich das Verhalten deutlich, liegt möglicherweise kein allgemeines Website-Problem vor.

Performance und Verfügbarkeit unterscheiden #

Eine Website, die zeitweise überhaupt nicht erreichbar ist, besitzt nicht einfach nur ein Ladezeitproblem.

Wenn ein Fehler sporadisch auftritt, kann kontinuierliches Monitoring helfen festzustellen, wann und wie häufig die Website tatsächlich nicht erreichbar war.

Das behandeln wir unter Website-Monitoring: Erreichbarkeit und Ausfälle überwachen.

Nicht fünf Optimierungs-Plugins gleichzeitig einsetzen #

Mehrere Performance-Plugins mit überlappenden Funktionen können zu schwer nachvollziehbaren Wechselwirkungen führen.

Wenn beispielsweise mehrere Systeme gleichzeitig Caching, Minifizierung, Lazy Loading und JavaScript-Optimierung übernehmen, wird die Fehlersuche unnötig kompliziert.

Eine klar dokumentierte Konfiguration ist besser als möglichst viele gleichzeitig aktive Optimierungen.

Nicht gleichzeitig zehn Dinge ändern #

Für eine systematische Diagnose solltest du Änderungen nachvollziehbar durchführen.

Wenn du gleichzeitig Plugins deaktivierst, Bilder ersetzt, Caching umstellst, PHP änderst und JavaScript verzögerst, weißt du anschließend nicht, welche Maßnahme welchen Effekt hatte.

Besser:

messen
  ↓
Hypothese bilden
  ↓
eine gezielte Änderung
  ↓
testen
  ↓
erneut messen
  ↓
Ergebnis dokumentieren

Nach Performance-Änderungen Funktionen testen #

Eine Website ist nicht optimiert, wenn sie zwar schneller lädt, aber wichtige Funktionen nicht mehr korrekt arbeiten.

Nach technischen Änderungen solltest du deshalb neben den Messwerten auch die tatsächliche Funktion prüfen.

Bei einer normalen Unternehmenswebsite beispielsweise:

Navigation
Kontaktformular
Suche
mobile Ansicht
Cookie-Banner
interaktive Elemente

Bei einem Shop zusätzlich:

Produktvarianten
Warenkorb
Gutscheine
Kundenkonto
Checkout
Zahlung

Wann solltest du professionelle Hilfe einbeziehen? #

Wenn sich die Ursache mit normalen Messwerkzeugen nicht eindeutig eingrenzen lässt, kann eine tiefergehende technische Analyse notwendig sein.

Das gilt besonders bei:

sporadisch extrem langen Antwortzeiten
wiederkehrenden Timeouts
>500-Fehlern
hoher Datenbanklast
komplexen Shop-Problemen
externen API-Abhängigkeiten
Problemen nur unter höherer Last
schwer reproduzierbaren Fehlern

In solchen Fällen können Server- und Anwendungslogs, Profiling oder weitere Diagnosewerkzeuge erforderlich sein.

Ein sinnvoller Diagnoseweg #

Website wirkt langsam
        ↓
Problem reproduzieren
        ↓
betroffene URL bestimmen
        ↓
nur eine oder alle Seiten?
        ↓
dauerhaft oder sporadisch?
        ↓
mehrfach messen
        ↓
serverseitige Antwort auffällig?
        ↓
JA
→ PHP / Anwendung / Datenbank
→ externe APIs
→ Cache
→ Hintergrundprozesse
→ Ressourcen prüfen

NEIN
→ Browser / Frontend untersuchen
→ Bilder
→ CSS
→ JavaScript
→ Fonts
→ externe Ressourcen
        ↓
Core Web Vitals prüfen
        ↓
konkreten Engpass identifizieren
        ↓
eine gezielte Änderung durchführen
        ↓
Funktion der Website testen
        ↓
unter vergleichbaren Bedingungen erneut messen

Diagnose nach Symptom #

Symptom	Erster Prüfbereich
Seite bleibt zunächst lange leer	HTML-Antwort, TTFB, serverseitige Verarbeitung
Hauptinhalt erscheint sehr spät	LCP-Element, Bilder, Fonts, blockierende Ressourcen
Klicks reagieren verzögert	INP, JavaScript, Main Thread
Elemente springen beim Laden	CLS, Bilder, Fonts, dynamische Inhalte
Nur eine Seite ist langsam	seitenspezifische Ressourcen und Funktionen
Nur Shop-Seiten sind langsam	dynamische Shop-Prozesse, Datenbank, Plugins
Nur gelegentlich langsam	Monitoring, externe Dienste, Hintergrundprozesse, Last
Nur für dich langsam	Gerät, Browser, Netzwerk, VPN

Häufige Fehler bei der Performance-Fehlersuche #

sofort das Hosting verantwortlich machen

nur einen einzigen Test durchführen

nur die Startseite testen

Performance-Score mit Ladezeit gleichsetzen

alle Plugins gleichzeitig deaktivieren

mehrere Cache-Systeme übereinander installieren

Cache leeren als dauerhafte Lösung betrachten

jede PageSpeed-Empfehlung blind umsetzen

JavaScript ungeprüft verzögern

alle Bilder pauschal lazy laden

Datenbankgröße mit Datenbankgeschwindigkeit gleichsetzen

nur Desktop testen

externe Dienste ignorieren

mehrere Änderungen gleichzeitig durchführen

nach Änderungen nur den Score prüfen
und nicht die Website selbst

Checkliste: Langsame Website systematisch untersuchen #

Welche URL ist langsam?
        ↓
Sind weitere Seiten betroffen?
        ↓
Problem dauerhaft oder sporadisch?
        ↓
Mobil und Desktop getestet?
        ↓
mehrere Messungen durchgeführt?
        ↓
HTML-Antwort / TTFB auffällig?
        ↓
PHP / Anwendung prüfen
        ↓
Datenbank prüfen
        ↓
externe APIs prüfen
        ↓
Caching prüfen
        ↓
Bilder und Datenmenge prüfen
        ↓
JavaScript prüfen
        ↓
CSS prüfen
        ↓
Fonts prüfen
        ↓
Drittanbieter-Ressourcen prüfen
        ↓
Core Web Vitals betrachten
        ↓
konkrete Ursache eingrenzen
        ↓
eine Änderung durchführen
        ↓
Website vollständig testen
        ↓
erneut messen
        ↓
Ergebnis dokumentieren

Zusammenfassung #

Eine langsame Website kann viele unterschiedliche Ursachen haben. Deshalb ist „Website schneller machen“ keine einzelne technische Maßnahme, sondern zunächst eine Diagnoseaufgabe.

Stelle zuerst fest, ob das Problem die gesamte Website oder nur bestimmte Seiten betrifft und ob es dauerhaft oder nur sporadisch auftritt. Anschließend solltest du zwischen serverseitiger Verarbeitung und browserseitiger Performance unterscheiden.

Bei einer langsamen serverseitigen Antwort kommen unter anderem PHP, Anwendung, Datenbank, externe APIs, Caching und Hintergrundprozesse infrage. Antwortet der Server schnell, solltest du verstärkt Bilder, JavaScript, CSS, Fonts und externe Ressourcen untersuchen.

Messwerkzeuge wie PageSpeed Insights, die Browser-Entwicklerwerkzeuge und die Core Web Vitals helfen dabei, einen Engpass einzugrenzen. Ihre Hinweise sollten jedoch nicht ungeprüft als automatische Optimierungsanweisungen verstanden werden.

Führe Änderungen kontrolliert durch, teste anschließend die tatsächliche Funktion der Website und miss unter vergleichbaren Bedingungen erneut.

Die wichtigste Regel bei einer langsamen Website lautet deshalb nicht „mehr optimieren“, sondern: Erst das Problem reproduzieren, dann den Engpass identifizieren und anschließend genau die Ursache beheben, die tatsächlich für die Verzögerung verantwortlich ist.