Seite langsam: die Ursache finden, bevor du den Tarif wechselst

„Die Seite ist langsam” führt oft direkt zur Frage nach einem grösseren Tarif. In vielen Fällen ist das die falsche Antwort auf eine ungestellte Frage.

Schritt 1: wo geht die Zeit hin?

Drei Phasen, die man getrennt messen muss:

curl -so /dev/null -w '
  DNS:        %{time_namelookup}s
  Verbindung: %{time_connect}s
  TLS:        %{time_appconnect}s
  Erstes Byte:%{time_starttransfer}s
  Gesamt:     %{time_total}s
' https://example.com/

• Erstes Byte hoch, Gesamt kaum höher: Der Server braucht lange zum Nachdenken. Ursache liegt in Anwendung, Datenbank oder Prozesslimit.
• Erstes Byte niedrig, Gesamt hoch: Die Antwort ist gross. Ursache sind unkomprimierte oder zu grosse Inhalte.
• Verbindung und TLS hoch: Netzweg oder Serverstandort.

Schritt 2: statisch gegen dynamisch

# statische Datei
curl -so /dev/null -w 'statisch:  %{time_starttransfer}s\n' https://example.com/favicon.ico

# dynamische Seite
curl -so /dev/null -w 'dynamisch: %{time_starttransfer}s\n' https://example.com/

Ist die statische Datei schnell und die dynamische Seite langsam, ist das Hosting nicht der Engpass. Dann hilft ein grösserer Tarif nicht – es sei denn, das Prozesslimit ist erreicht.

Schritt 3: schwankt es mit der Tageszeit?

# alle 5 Minuten messen, über einen Tag
while true; do
  printf '%s ' "$(date +%H:%M)"
  curl -so /dev/null -w '%{time_starttransfer}\n' https://example.com/
  sleep 300
done | tee messung.txt

Ein Muster, das zur Hauptlastzeit ansteigt und nachts verschwindet, spricht für ein erreichtes Prozesslimit auf Shared Hosting. Dann ist ein grösserer Tarif tatsächlich die richtige Antwort – oder Caching, das die Zahl der PHP-Aufrufe senkt.

Eine gleichmässig hohe Zeit rund um die Uhr spricht dagegen: Da ist etwas in der Anwendung langsam, und zwar immer.

Schritt 4: in der Anwendung nachsehen

Die häufigsten Fundstellen, nach Wirkung sortiert:

Zu viele Datenbankabfragen pro Seite. Das klassische N+1-Problem: Eine Abfrage holt 50 Datensätze, und für jeden folgt eine weitere Abfrage. 51 statt 2.

-- langsame Abfragen protokollieren
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;

Fehlende Indizes.

EXPLAIN SELECT * FROM bestellungen WHERE kunde_id = 42;
-- type: ALL bedeutet: volle Tabelle gelesen

Externe Aufrufe im Seitenaufbau. Ein Wetterdienst, ein Bewertungswidget, eine Preisabfrage – synchron eingebunden, hält jede davon die Seite an, bis sie antwortet. Solche Aufrufe gehören in einen Cache oder in einen Hintergrundprozess.

Kein Caching. Bei Seiten, die sich selten ändern, ist ein Seiten-Cache die wirksamste Einzelmassnahme überhaupt: Statt PHP und Datenbank läuft nur noch die Auslieferung einer Datei.

Schritt 5: das Naheliegende

Bevor irgendetwas an Hosting oder Architektur geändert wird, lohnen sich drei Dinge, die fast immer etwas bringen:

• Bilder in passender Grösse und in WebP oder AVIF. Ein 4.000 Pixel breites Foto, das auf 800 Pixel angezeigt wird, verschwendet ein Vielfaches der nötigen Datenmenge.
• Kompression aktiv. Prüfen mit curl -sI -H 'Accept-Encoding: gzip, br' https://example.com/ | grep -i content-encoding.
• Cache-Header für statische Dateien mit versionierten Dateinamen.

Und wann ist es doch das Hosting?

• Die statische Datei ist bereits langsam.
• Die Antwortzeit schwankt stark mit der Tageslast.
• Es gibt 503- oder 508-Fehler unter Last.
• Der Anbieter bricht Prozesse ab.
• Die Anwendung braucht einen Dienst, den es auf Shared Hosting nicht gibt.

Trifft eines davon zu, führt der Weg zu einem grösseren Tarif oder einem eigenen Server. Die Entscheidungskriterien dafür stehen im Vergleich zwischen vServer und Shared Hosting.