Modul 6 · 6.1

Deutsch

Nederlands English Deutsch Français

Was macht eine Website langsam, und wie misst man das?

Modul 6: Geschwindigkeit · Lesezeit: 9 Minuten

Lernziel: Nach dieser Lektion können Sie messen, wo die Zeit verloren geht, und den Unterschied zwischen Langsamkeit auf dem Server und Langsamkeit im Browser erkennen.

Kernbegriffe: TTFB, Core Web Vitals (LCP, INP, CLS), Labordaten, Felddaten, PageSpeed Insights, Netzwerk-Tab, Komprimierung, externe Skripte, Limits des Hostingpakets, 503

Erst messen, dann erst schrauben

„Die Website ist langsam" kann zehn verschiedene Ursachen haben. Wer ohne zu messen gleichzeitig ein Cache-Plugin, ein Bildoptimierungs-Plugin und ein größeres Paket einsetzt, weiß hinterher nicht, was geholfen hat, und hat jetzt drei Dinge mehr im Blick zu behalten. Beginnen Sie deshalb immer mit drei Fragen (dieselben wie in der Anleitung Ihres Hosters):

Alles langsam, oder nur das Dashboard? Ein langsames Dashboard bei einer schnellen Vorderseite deutet auf Plugins hin, die im Dashboard viel tun, oder auf Bots, die die Login-Seite angreifen.
Immer, oder zu bestimmten Zeiten? Nur zu Stoßzeiten oder wenn eine geplante Aufgabe läuft: dann stößt Ihr Paket an seine Grenzen.
Bei allen, oder nur bei Ihnen? Probieren Sie es auf Ihrem Handy über 4G oder 5G aus, oder bitten Sie jemand anderen. Ist es nur bei Ihnen langsam, liegt es an Ihrer Verbindung oder VPN.

Zwei Hälften: Server und Browser

Die Zeit, die ein Besucher wartet, besteht aus zwei Teilen (Lektion 1.2):

Der Server erstellt das HTML: Webserver, PHP, Plugins, Datenbank. Das sehen Sie als TTFB (Time to First Byte), die Zeit bis zum ersten Byte der Antwort. web.dev nennt als Faustregel, dass die meisten Websites eine TTFB von 0,8 Sekunden oder weniger anstreben sollten.
Der Browser liest dieses HTML und holt danach alles ab, was darin steht: Stylesheets, Skripte, Schriftarten, Bilder, Video, Tracking-Codes, Chat-Widgets. Erst wenn genug davon geladen ist, sieht der Besucher etwas.

Eine hohe TTFB lösen Sie auf der Serverseite: Caching (Lektion 6.2), weniger oder leichtere Plugins, eine neuere PHP-Version, eine aufgeräumte Datenbank (Lektion 6.3) oder mehr Rechenleistung. Eine niedrige TTFB bei trotzdem langsamer Seite deutet auf die Browserseite hin: zu große Bilder, zu viele Skripte, externe Komponenten.

Core Web Vitals

Google misst die Erfahrung der Besucher mit drei Kennzahlen, den Core Web Vitals:

Messung	Was gemessen wird	Gut, wenn
LCP (Largest Contentful Paint)	Wie schnell das größte Inhaltselement (oft das große Foto oder die Überschrift) sichtbar ist	2,5 Sekunden oder weniger
INP (Interaction to Next Paint)	Wie schnell die Seite reagiert, wenn Sie klicken, tippen oder eine Taste drücken	200 Millisekunden oder weniger
CLS (Cumulative Layout Shift)	Wie stark die Seite während des Ladens verspringt	0,1 oder weniger

INP ersetzte im März 2024 die ältere Messung FID. Google nutzt diese Kennzahlen unter anderem bei der Einstufung von Suchergebnissen, aber der wichtigste Grund, sie zu verbessern, ist einfach: Besucher springen bei einer langsamen oder verspringenden Seite ab.

Labordaten und Felddaten

Es gibt zwei Arten von Messungen, und sie liefern unterschiedliche Zahlen:

Labordaten: ein Test zu einem Zeitpunkt, von einem Ort aus, mit einem simulierten Handy und einer simulierten Verbindung. Nützlich zum Vergleichen (vorher und nachher bei einer Änderung), aber es ist kein echter Besucher.
Felddaten: Messungen bei echten Besuchern mit Chrome, über die letzten 28 Tage. Das ist, was Besucher wirklich erleben. Kleine Websites haben oft zu wenige Besucher für Felddaten.

PageSpeed Insights (pagespeed.web.dev) zeigt beides: oben die Felddaten (sofern vorhanden), darunter einen Labortest mit einer Punktzahl und konkreten Hinweisen. Schauen Sie nicht blind auf die Punktzahl von 0 bis 100. Schauen Sie auf die Einzelheiten: Ist LCP schlecht, weil der Server langsam ist (TTFB), oder weil das große Foto 3 MB groß ist?

Testen Sie immer mehrmals (die Zahlen schwanken) und testen Sie auch eine gewöhnliche Seite, nicht nur die Startseite.

Selbst nachschauen mit dem Browser

Die Entwicklertools Ihres Browsers (F12) zeigen, was wirklich passiert:

Netzwerk-Tab: Aktualisieren Sie die Seite bei deaktiviertem Cache (Häkchen „Cache deaktivieren"). Sie sehen jede geladene Datei, ihre Größe und wie lange es dauerte. Sortieren Sie nach Größe: die größten Dateien sind oft Bilder. Sortieren Sie nach Domain: wie viel kommt von anderen Anbietern (Schriftarten, Tracking-Codes, Videos)?
Die erste Anfrage (das HTML selbst): klicken Sie darauf, Tab Timing. „Waiting for server response" ist die TTFB.
Header dieser ersten Anfrage: gibt es Komprimierung (content-encoding: br oder gzip), und kam die Seite aus einem Cache (Lektion 6.2)?

Die üblichen Übeltäter

In der Praxis liegt Langsamkeit bei WordPress meist an einem dieser Punkte:

Kein Seiten-Cache: jede Seite wird bei jedem Besuch neu erstellt (Lektion 6.2).
Zu viele oder zu schwere Plugins, besonders Plugins, die bei jeder Anfrage externe Dienste aufrufen oder aufwendige Datenbankabfragen durchführen (Lektion 5.3).
Große Bilder: ein 5-MB-Foto von einem Handy auf der Startseite (Lektion 4.4 und 6.3).
Ein schweres Theme oder ein Page-Builder, der auf jeder Seite viele Skripte und Stylesheets lädt (Lektion 5.1).
Externe Komponenten: Schriftarten, Videos, Chat-Widgets, Tracking-Codes, Social-Media-Buttons anderer Anbieter. Jedes davon ist eine Verbindung zu einem anderen Server, der langsam sein kann.
Eine alte PHP-Version (Lektion 8.4).
Eine unaufgeräumte Datenbank: tausende Revisionen, Spam, Protokolltabellen von Plugins (Lektion 6.3).
Bots: Crawler, KI-Crawler und Login-Versuche beschäftigen Ihr Paket (Lektion 7.3).
Das Paket stößt an seine Grenzen: zu wenig Rechenleistung (CPU), Prozesse oder Arbeitsspeicher für den Datenverkehr.

Die Grenzen Ihres Pakets

Bei Shared-Hosting erhält jedes Paket einen festen Anteil des Servers: Rechenleistung, Arbeitsspeicher, Festplattengeschwindigkeit und eine Anzahl gleichzeitiger Prozesse. Verbraucht Ihre Website mehr, wird sie gedrosselt, oder Besucher erhalten eine Fehlermeldung 503 (Service Unavailable, bei manchen Hostern „Resource Limit Is Reached"). Bei DirectAdmin mit CloudLinux sehen Sie das unter Resource Usage (mit „faults", wenn Ihre Website gedrosselt wurde) und mit X-Ray sehen Sie pro Seite, welches Plugin oder welche Abfrage die Zeit kostet. Andere Hoster haben vergleichbare Übersichten, manchmal nur auf Anfrage.

Ein größeres Paket hilft, wenn Ihre Website wirklich mehr benötigt (ein stark frequentierter Webshop). Es löst eine schlecht eingerichtete Website nicht: das Problem kommt dann später zurück. Suchen Sie zuerst die Ursache.

Zusammenfassung

Messen Sie zuerst: alles oder nur das Dashboard, immer oder manchmal, alle oder nur Sie.
TTFB ist die Serverseite (streben Sie 0,8 Sekunden oder weniger an); der Rest ist, was der Browser lädt.
Core Web Vitals: LCP (2,5 s), INP (200 ms) und CLS (0,1); INP ersetzte FID im Jahr 2024.
PageSpeed Insights zeigt Felddaten und Labordaten; der Netzwerk-Tab zeigt, was wirklich geladen wird.
Die meiste Langsamkeit entsteht durch keinen Cache, schwere Plugins, große Bilder und externe Komponenten; ein größeres Paket ist erst der letzte Schritt.

Quiz

Aufgabe

Aufgabe A6.1: Messen Sie Ihre TTFB und Komprimierung. Geben Sie die Adresse Ihrer Website ein und, falls gewünscht, eine gewöhnliche Seite (zum Beispiel Ihre Kontaktseite). Das Programm ruft jede Seite dreimal ohne Cookies ab und zeigt die mittlere TTFB, die Größe des HTML und ob der Server das HTML komprimiert sendet (content-encoding gzip oder br). Vergleichen Sie das Ergebnis mit einem Test in PageSpeed Insights und notieren Sie, was Ihnen auffällt.

Weiterführende Informationen

Diese Artikel beschreiben die Schritte in den Panels von WebOké; in anderen Panels funktionieren sie ähnlich.

Cookies bei WebOké

Cookie-Einstellungen

Notwendig

Marketing