Leitfaden: Website-Ladezeiten messen und optimieren

Wie schnell ist Ihre Website wirklich? Die Frage klingt einfach, aber die Antwort ist es selten. Die Ladezeit einer Website hängt von vielen Faktoren ab. Vom Server und seiner Konfiguration über die Größe und das Format der eingebundenen Medien bis hin zum JavaScript, das im Hintergrund ausgeführt wird. Hinzu kommt, dass Ihre Besucher die Website unter ganz unterschiedlichen Bedingungen aufrufen: auf schnellen Desktop-Rechnern mit Glasfaseranbindung ebenso wie auf älteren Smartphones mit einer schwankenden Mobilfunkverbindung.

Die gute Nachricht: Sie müssen kein Performance-Experte sein, um die Ladezeit Ihrer Website zu messen und zu verbessern. Die Werkzeuge dafür sind kostenlos, direkt im Browser verfügbar und liefern konkrete Hinweise darauf, wo Optimierungspotenzial besteht. Und selbst kleine Verbesserungen können einen spürbaren Unterschied machen. Für die Zufriedenheit Ihrer Besucher, für Ihre Platzierung in den Suchergebnissen und letztlich für Ihren Geschäftserfolg.

Dieser Leitfaden begleitet Sie durch den gesamten Prozess: von den Grundlagen der Performance-Metriken über die praktische Messung mit Browser-Tools und Online-Diensten bis hin zu konkreten Optimierungsmaßnahmen, die Sie direkt umsetzen können. Am Ende finden Sie eine kleine Checkliste, sie Sie als wiederkehrendes Prüfwerkzeug bei Relaunches, Updates oder der regelmäßigen Qualitätssicherung einsetzen können.

Wer im Internet unterwegs ist, erwartet, dass eine Website sofort reagiert. Bereits nach drei Sekunden Wartezeit verlassen über 50 Prozent der mobilen Nutzer eine Seite wieder und jede weitere Sekunde senkt die Wahrscheinlichkeit, dass ein Besucher bleibt, ein Produkt kauft oder ein Kontaktformular ausfüllt. Die Ladezeit einer Website ist damit kein rein technisches Detail, sondern hat unmittelbaren Einfluss auf den Geschäftserfolg.

Auch für die Sichtbarkeit in Suchmaschinen spielt Geschwindigkeit eine zentrale Rolle. Google nutzt die sogenannten Core Web Vitals, ein Set aus drei Performance-Metriken, als offizielles Ranking-Signal. Websites, die diesen Schwellenwert erfüllen, werden in den Suchergebnissen gegenüber langsameren Konkurrenten bevorzugt. Wer die Ladezeit seiner Website vernachlässigt, verschenkt also nicht nur Nutzerzufriedenheit, sondern auch organischen Traffic.

Nicht zuletzt ist eine schnelle Website auch ein Beitrag zur Barrierefreiheit. Nicht jeder Nutzer verfügt über eine schnelle Internetverbindung oder ein aktuelles Gerät. In vielen Regionen der Welt, aber auch in ländlichen Gebieten Deutschlands, sind die Verbindungen langsamer, als man es aus der Großstadt gewohnt ist. Eine schlanke, schnell ladende Website stellt sicher, dass möglichst viele Menschen problemlos auf Ihre Inhalte zugreifen können.

Um die Ladezeit einer Website zu bewerten, reicht ein einzelner Wert nicht aus. Verschiedene Metriken beleuchten unterschiedliche Aspekte der Nutzererfahrung: Wie schnell erscheint der erste Inhalt? Wie lange dauert es, bis die Seite auf einen Klick reagiert? Verschiebt sich das Layout während des Ladens? Erst die Kombination mehrerer Metriken ergibt ein vollständiges Bild.

2.1 Core Web Vitals - Die Google-Metriken

Google hat drei Kernmetriken definiert, die Zusammen die wesentlichen Qualitätsaspekte einer Website abdecken: Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität. Um die Core-Web-Vitals-Bewertung zu bestehe, müssen mindesten 75 Prozent aller Seitenbesuche den jeweiligen "Gut"-Schwellenwert erreichen.

Largest Contentful Paint (LCP)

Der Largest Contentful Paint misst den Zeitpunkt, an dem das größte sichtbare Element im sichtbaren Bereich der Seite vollständig geladen ist, typischerweise ein Hero-Bild, eine große Überschrift oder ein eingebettetes Video. Damit beantwortet LCP aus Nutzersicht die Frage: "Wann kann ich den Hauptinhalt der Seite sehen?" Ein guter LCP-Wert liegt bei maximal 2,5 Sekunden. Werte zwischen 2,5 und 4 Sekunden gelten als verbesserungswürdig, alles darüber als schlecht.

Interaction to Next Paint (INP)

Die Metrik Interaction to Next Paint hat im März 2024 die ältere Metrik First Input Delay (FID) abgelöst und ist seitdem die offizielle Kennzahl für die Reaktionsfähigkeit einer Website. Während FID lediglich die Verzögerung bei der allerersten Nutzerinteraktion gemessen hat, bewertet INP sämtliche Interaktionen während des gesamten Seitenbesuchs. Jeden Klick, jeden Tap, jede Tastatureingabe.

Hinter einer einzelnen Interaktion stecken dabei drei Phasen: Zunächst wartet der Browser, bis er die Interaktion überhaupt verarbeiten kann (Input Delay), dann führt er den zugehörigen Event-Handler aus (Processing Time) und schließlich berechnet er das neue Bild und bringt es auf den Bildschirm (Presentation Delay). INP misst die Gesamtdauer dieser drei Phasen für die langsamste Interaktion und gibt damit ein realistisches Bild davon, wie flüssig sich eine Website anfühlt.

Als gut gilt ein INP-Wert von maximal 200 Millisekunden. Zwischen 200 und 500 Millisekunden besteht Verbesserungsbedarf, darüber hinaus gilt die Reaktionsfähigkeit als schlecht. INP ist aktuell die am häufigsten nicht bestandene Core Web Vital: Rund 43 Prozent aller Websites scheitern am 200-Millisekunden-Schwellenwert.

Cumulative Layout Shift (CLS)

Der Cumulative Layout Shift erfasst unerwartete Verschiebungen des Seitenlayouts während des Ladens. Das klassische Beispiel kennt jeder: Man beginnt, einen Text zu lesen und plötzlich springt der gesamte Inhalt nach unten, weil ein Bild oder eine Werbeanzeige nachgeladen wird. Solche Verschiebungen sind nicht nur ärgerlich, sondern können auch dazu führen, dass Nutzer versehentlich auf falsche Elemente klicken.

CLS wird als dimensionsloser Wert angegeben. Werte bis 0,1 gelten als gut, zwischen 0,1 und 0,25 als verbesserungswürdig und über 0,25 als schlecht.

2.2 Weitere wichtige Metriken

Neben den drei Core Web Vitals gibt es weitere Metriken, die bei der Analyse der Ladezeit wertvolle Einblicke liefern.

Die Time to First Byte (TTFB) misst die Zeitspanne vom Absenden der Anfrage bis zum Empfang des ersten Bytes der Server-Antwort. Sie ist ein direkter Indikator für die Geschwindigkeit des Servers und der Hosting-Infrastruktur. Ein guter TTFB-Wert liegt bei maximal 0,8 Sekunden. Wenn dieser Wert deutlich höher ausfällt, liegt das Problem meist nicht an der Website selbst, sondern am Server. Und keine noch so gute Frontend-Optimierung kann das ausgleichen.

Der First Contentful Paint (FCP) markiert den Moment, in dem der Browser den ersten sichtbaren Inhalt auf den Bildschirm bringt. Sei es ein Textstück, ein Bild oder eine SVG-Grafik. FCP beantwortet die Frage: "Tut sich überhaupt etwas?" Werte bis 1,8 Sekunden gelten als gut.

Die Total Blocking Time (TBT) summiert alle Zeitabschnitte auf, in denen der Haupt-Thread des Browsers zwischen dem First Contentful Paint und dem vollständigen Laden der Seite blockiert was und nicht auf Nutzereingaben reagieren konnte. TBT ist besonders relevant, weil sie in Lighthouse-Tests als Stellvertreter-Metrik für INP dient. INP erfordert echte Nutzerinteraktionen und kann in einer simulierten Testumgebung nicht zuverlässig gemessen werden. Ein guter TBT-Wert liegt unter 200 Millisekunden.

Der Speed Index beschreibt, wie schnell sichtbare Inhalte während des Ladevorgangs erscheinen. Anders als LCP, der nur das größte Element betrachtet, erfasst der Speed Index den gesamten visuellen Fortschritt. Er gibt damit einen guten Eindruck davon, wie sich das Laden der Seite subjektiv anfühlt. Werte unter 3 Sekunden gelten als gut.

2.3 Veraltete Metriken

Einige Metriken, die in älteren Anleitungen noch auftauchen, werden inzwischen nicht mehr empfohlen. Der First Meaningful Paint (FMP) wurde durch den präziseren LCP ersetzt. Der First Input Delay (FID) wurde im März 2024 offiziell durch INP abgelöst, weil FID nur die erste Interaktion gemessen hat und damit kein vollständiges Bild der Reaktionsfähigkeit liefern konnte. Auch die Time to Interative (TTI) wird als eigenständige Metrik kaum noch verwendet. Ihre Funktion übernimmt heute weitgehend die TBT. Wenn Sie in bestehenden Berichten auf diese Metriken stoßen, ist es sinnvoll, sie durch ihre aktuellen Nachfolger zu ersetzen.

Der schnellste und unkomplizierteste Weg, die Ladezeit einer Website zu analysieren, führt über die Entwicklertools, die in jedem modernen Browser eingebaut sind. Sie benötigen keine zusätzliche Software, kein Konto bei einem externen Dienst und können sofort loslegen.

3.1 Entwicklertools öffnen

In Chrome, Firefox und Edge öffnen Sie die Entwicklertools mit der Taste F12 oder dem Tastenkürzel Strg + Shift ⇧ + I (Windows/Linux) beziehungsweise Option ⎇ + Cmd ⌘ + I (macOS). Das Werkzeugfenster lässt sich am unteren oder rechten Rand des Browsers andocken oder als eigenständiges Fenster öffnen. Je nachdem, was für Ihren Bildschirm am besten passt.

3.2 Methode 1: Der Netzwerk-Tab

Der Netzwerk-Tab, im englischsprachigen Interface als "Network" bezeichnet, ist der naheliegendste Startpunkt für eine Ladezeit-Analyse. Er zeigt jede einzelne Ressource, die der Browser beim Laden einer Seite anfordert: HTML-Dokumente, Stylesheets, JavaScript-Dateien, Bilder, Schriftarten, API-Anfragen und mehr.

Um eine aussagekräftige Messung durchzuführen, öffnen Sie zunächst die Entwicklertools und wechseln zum Netzwerk-Tab. Bevor Sie die Seite laden, sollten Sie die Checkbox "Cache deaktivieren" (englisch: "Disable cache") aktivieren. Dadurch simulieren Sie einen Erstbesuch. So verwendet der Browser keine zuvor gespeicherten Dateien und lädt alles neu herunter. Anschließend laden Sie die Seite mit F5 oder Strg + R (beziehungsweise Cmd + R auf dem Mac) neu.

Nach dem Laden sehen Sie in der Statusleiste am unteren Rand mehrere Kennzahlen auf einen Blick: Die Anzahl der Anfragen (Requests) gibt an, wie viele einzelne Ressourcen geladen wurden. Jede Anfrage verursacht Overhead, daher ist weniger grundsätzlich besser. Daneben wird die übertragene Datenmenge angezeigt sowie zwei Zeitwerte: COMContentLoaded (der Zeitpunkt, an dem das HTML-Dokument vollständig geparst wurde) und Load (der Zeitpunkt, an dem alle Ressourcen einschließlich Bilder und Stylesheets geladen sind).

Das Wasserfall-Diagramm ist das Herzstück des Netzwerk-Tabs und das wichtigste Werkzeug zur Analyse der Ladezeit. Es stellt jede geladene Ressource als horizontalen Balken auf einer Zeitachse dar. Auf einen Blick erkennen Sie, in welcher Reihenfolge Ressourcen geladen werden, wie lange jede einzelne benötigt, wo Wartezeiten entstehen und welche externen Ressourcen, etwa von Plugins, Analytics-Tools oder Chat-Widgets, zusätzliche Anfragen verursachen.

Wenn Sie auf eine einzelne Ressource klicken, öffnet sich deren Detailansicht. Besonders aufschlussreich ist dort der Reiter "Timing", der die Ladezeit in ihre Einzelteile aufschlüsselt: DNS-Auflösung, Verbindungsaufbau (TCP/TLS), Wartezeit auf die Server-Antwort und tatsächliche Download-Dauer. So erkennen Sie präzise, wo ein Engpass liegt – etwa bei einem langsamen DNS-Server, einem verzögerten TLS-Handshake oder einer langsamen Server-Antwort. Über die Reiter "Header" und "Response" können Sie zudem die Antwort-Header des Servers (zum Beispiel Cache-Control oder Komprimierungseinstellungen) und den eigentlichen Inhalt der Ressource einsehen.

Seit Chrome 145 gibt es eine besonders nützliche Neuerung: die individuelle Drosselung einzelner Netzwerk-Anfragen. Per Rechtsklick auf eine beliebige Anfrage im Netzwerk-Tab und die Option "Throttle request" können Sie gezielt simulieren, wie sich eine langsam ladende Ressource auf die Gesamtladezeit auswirkt – zum Beispiel ein großes Hero-Bild oder eine träge reagierende API. Über URL-Patterns mit Wildcards lassen sich auch ganze Gruppen von Anfragen drosseln, etwa alle Ressourcen einer bestimmten CDN-Domain. Diese Funktion ist ideal, um LCP-relevante Bilder isoliert zu testen oder die Auswirkung langsamer Third-Party-Skripte zu verstehen.

3.3 Methode 2: Der Performance-Tab

Während der Netzwerk-Tab zeigt, was geladen wird, zeigt der Performance-Tab, was der Browser damit macht. Hier sehen Sie, wann JavaScript ausgeführt wird, wie lange Layout-Berechnungen dauern, wann der Browser rendert und wo der Haupt-Thread blockiert ist.

In Chrome hat das Performance-Panel in den letzten Jahren einen grundlegenden Umbau erfahren. Am oberen Rand zeigt es nun sogenannte Live Metrics an. Eine Echtzeitansicht der Core Web Vitals, die fortlaufend aktualisiert wird, ohne dass Sie eine Aufzeichnungen starten müssen. Für eine tiefere Analyse können Sie eine Aufzeichnung starten (über das Kreis-Symbol), dann die Seite laden oder mit ihr interagieren und die Aufzeichnung anschließend stoppen. Chrome zeigt Ihnen daraufhin eine detaillierte Timeline mit allen Aktivitäten des Browsers. Besonders hilfreich ist die Insights-Seitenleiste am rechten Rand, die automatisch Engpässe identifiziert und konkrete Lösungsvorschläge macht. In neueren Chrome-Versionen wird diese Analyse zusätzlich durch KI (Gemini) unterstützt, die Probleme in natürlicher Sprache erklärt und priorisiert.

Firefox geht einen etwas anderen Weg und setzt auf den eigenständigen Firefox Profiler, der unter profiler.firefox.com erreichbar ist. Nach einer Aufzeichnung öffnet sich ein neuer Browser-Tab mit einer umfassenden, interaktiven Profilanalyse. Der Firefox-Profiler eignet sich besonders gut, um JavaScript-Performance-Probleme im Detail zu untersuchen, da er die Ausführung von Funktionen auf der Zeitachse visualisiert und Stack-Traces bereitstellt.

Die Browser-Entwicklertools messen die Ladezeit von Ihrem eigenen Rechner aus, mit Ihrer Internetverbindung, Ihrer Hardware und Ihrem Standort. Das ist nützlich für die Fehlersuche, bildet aber nicht ab, wie die Website für Ihre tatsächlichen Besucher lädt. Genau hier kommen Online-Tools ins Spiel: Sie testen Ihre Website von externen Servern verschiedenen Standorten weltweit und geben Ihnen damit eine objektivere, besuchernahe Perspektive.

4.1 Google PageSpeed Insights

Google PageSpeed Insights unter pagespeed.web.dev ist das meistgenutzte Tool zur Messung der Website-Performance und das aus gutem Grund. Es kombiniert zwei Datenquellen, die zusammen ein besonders vollständiges Bild ergeben: Zum einen führt es einen Lighthouse-Test durch, der die Seite unter kontrollierten Bedingungen simuliert lädt und bewertet (sogenannte Lab-Daten). Zum anderen zeigt es, sofern ausreichend Traffic vorhanden ist, echte Messwerte von Chrome-Nutzern aus dem Chrome User Experience Report (CrUX). Diese Felddaten spiegeln wider, wie die Website unter realen Bedingungen performt, also auf unterschiedlichen Geräten, mit verschiedenen Verbindungsgeschwindigkeiten und aus verschiedenen Regionen.

PageSpeed Insights ist kostenlos, direkt von Google und liefert neben der Performance-Bewertung auch Einschätzungen zur Barrierefreiheit, Best Practices und SEO. Die größte Einschränkung besteht darin, dass nur von einem einzigen Teststandort aus gemessen wird und keine historischen Daten gespeichert werden.

4.2 GTmetrix

GTmetrix unter gtmetrix.com hat sich als eines der beliebtesten Performance-Tools im deutschsprachigen Raum etabliert. Seine große Stärke liegt im besonders detaillierten und übersichtlich gestalteten Wasserfall-Diagramm, das die Ladeabfolge jeder einzelnen Ressource visuell aufbereitet. Darüber hinaus ermöglicht GTmetrix Test von über 22 globalen Standorten mit mehr als 40 verschiedenen Geräteprofilen. So können Sie beispielsweise gezielt prüfen, wie Ihre Website auf einem typischen Smartphone in Tokio oder auf einem Desktop-Rechner in Frankfurt lädt.

Die kostenlose Basisversion reicht für gelegentliche Tests aus. Wer regelmäßig Überwachung, mehr Teststandorte oder erweiterte Analysen benötigt, kann auf die PRO-Pläne ab etwa 10,67 Euro monatlich zurückgreifen.

4.3 WebPageTest

WebpageTest unter webpagetest.org ist das Werkzeug der Wahl für fortgeschrittene Performance-Analysen. Als Open-Source-Projekt bietet es die mit Abstand tiefste Analysetiefe aller hier vorgestellten Tools. Der entscheidende Unterschied zu vielen anderen Diensten: WebPageTest verwendet echte Browser statt Simulationen und bietet über 50 verschiedene Performance-Metriken.

Besonders wertvoll ist die Möglichkeit, Custom Scripts zu schreiben, mit denen mehrstufige Nutzertransaktionen getestet werden können, etwa Login-Vorgang gefolgt von einer Navigation durch mehrere Seiten bis hin zum Checkout. Auch vergleichende A/B-Tests sind möglich, bei denen zwei Versionen einer Seite direkt gegenübergestellt werden. Die Lernkurve ist etwas steiler als bei anderen Tools, aber der Erkenntnisgewinn ist dafür umso größer.

4.4 Pingdom

Pingdom unter tools.pingdom.com bietet eine schnelle, unkomplizierte Leistungsprüfung, die sich besonders für einen ersten Überblick eignet. Neben dem eigentlichen Ladezeit-Test umfasst Pingdom auch ein Uptime-Monitoring, das die Erreichbarkeit Ihrer Website überwacht und Sie bei Ausfällen benachrichtigt.

Bei der Interpretation der Ergebnisse ist allerdings Vorsicht geboten: Pingdom wendet standardmäßig keine Netzwerk-Drosselung an. Das bedeutet, dass die Tests unter idealen Netzwerkbedingungen stattfinden und die Messwerte dadurch oft deutlich besser ausfallen als bei Diensten, die eine realistische Mobilfunkverbindung simulieren.

4.5 Weitere Tools

Neben den großen vier gibt es weitere spezialisierte Dienste, die je nach Anwendungsfall interessant sein können. DebugBear hat sich mit seinem Fokus auf Core Web Vitals und der Integration von CrUX-Tracking-Daten einen Namen gemacht und ist ab etwa 12 Euro monatlich erhältlich. SpeedCurve kombiniert synthetisches Monitoring mit Real User Monitoring (RUM) und eignet sich damit besonders für Unternehmen, die ihre Performance dauerhaft überwachen möchten (ab 15 Euro monatlich). Für deutschsprachige Nutzer bietet pagespeed.de ein kostenloses, leicht verständliches Tool für schnelle Core-Web-Vitals-Tests.

4.6 Lab-Daten vs. Felddaten

Ein Konzept, das beim Arbeiten mit Performance-Tools immer wieder auftaucht und das es sich lohnt zu verstehen, ist die Unterscheidung zwischen Lab-Daten und Felddaten.

Lab-Daten entstehen, wenn ein Tool wie Lighthouse oder GTmetrix Ihre Website unter kontrollierten, standardisierten Bedingungen lädt. Auf einer festgelegten Hardware, mit einer simulierten Verbindungsgeschwindigkeit und an einem bestimmten Standort. Der große Vorteil: Die Ergebnisse sind reproduzierbar und vergleichbar. Der Nachteil: Sie bilden nicht die gesamte Bandbreite realer Nutzererfahrungen ab.

Felddaten hingegen stammen von echten Nutzern, die Ihre Website mit ihren eigenen Geräten und Verbindungen besuchen. In PageSpeed Insights werden solche Daten aus dem Chrome User Experience Report (CrUX) angezeigt, sofern Ihre Website genügend Traffic hat. Felddaten sind repräsentativer, aber weniger kontrollierbar und erst ab einer gewissen Besucherzahl verfügbar.

Für eine fundierte Bewertung sollten Sie idealerweise beide Datenquellen heranziehen. Lab-Daten helfen beim Identifizieren und Beheben konkreter Probleme, Felddaten zeigen Ihnen, wie sich Ihre Optimierungen auf die tatsächliche Nutzererfahrung auswirken.

Lighthouse ist Googles eingebautes Audit-Tool, das direkt in den Chrome-Entwicklertools zur Verfügung steht. Es analysiert Ihre Website nicht nur hinsichtlich Performance, sondern bewertet auch Barrierefreiheit, Best Practices und Suchmaschinenoptimierung, alles in einem einzigen Durchlauf.

5.1 Lighthouse ausführen

Um einen Lighthouse-Audit durchzuführen, öffnen Sie die Entwicklertools mit F12 und wechseln zum Tab "Lighthouse". Dort wählen Sie das Zielgerät aus, Mobil oder Desktop, und aktivieren die gewünschten Kategorien. Ein Klick auf "Analyse der Seite erstellen" startet den Test. Lighthouse lädt die Seite in einer simulierten Umgebung, misst alle relevanten Metriken und präsentiert die Ergebnisse als übersichtlichen Bericht mit einem Score von 0 bis 100.

In neueren Chrome-Versionen findet eine schrittweise Integration von Lighthouse in das Performance-Panel statt. Die bisherigen Lighthouse-Audits werden dort als "Insights" direkt in die Performance-Timeline eingebettet, sodass Sie Probleme nicht nur erkennen, sondern auch sofort sehen, wo genau in der Lade-Sequenz sie auftreten. Alternativ können Sie Lighthouse auch über PageSpeed Insights im Browser ausführen, die Ergebnisse sind identisch.

5.2 Performance-Score verstehen

Der Lighthouse-Performance-Score errechnet sich aus fünf Metriken, die unterschiedlich stark gewichtet werden. Den größten Einfluss hat die Total Blocking Time (TBT) mit 30 Prozent, gefolgt von Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS) mit jeweils 25 Prozent. First Contentful Paint (FCP) und Speed Index (SI) tragen mit je 10 Prozent zum Gesamtscore bei.

Ein Score von 90 bis 100 gilt als gut, 50 bis 89 als verbesserungswürdig und alles unter 50 als schlecht. Google stellt unter googlechrome.github.io/lighthouse/scorecalc einen interaktiven Scoring-Rechner bereit, mit dem Sie nachvollziehen können, wie sich Verbesserungen einzelner Metriken auf den Gesamtscore auswirken.

5.3 Wichtige Hinweise zur Interpretation

Es gibt einige Besonderheiten, die Sie bei der Arbeit mit Lighthouse kennen sollten. Lighthouse misst TBT statt INP als Reaktionsfähigkeits-Metrik. Der Grund ist technischer Natur: INP erfordert echte Nutzerinteraktionen und kann in einer simulierten Lab-Umgebung nicht zuverlässig erfasst werden. TBT korreliert jedoch gut mit INP, sodass eine Verbesserung der TBT in der Regel auch zu einem besseren INP bei echten Nutzern führt.

Außerdem sollten Sie beachten, dass die Ergebnisse zwischen einzelnen Durchläufen schwanken können, je nach aktueller Auslastung des Rechners, Netzwerkbedingungen und anderen Faktoren. Führen Sie daher mehrere Tests durch und orientieren Sie sich am Durchschnitt statt an einem einzelnen Wert. Besonders wichtig: Testen Sie sowohl im Mobil- als auch im Desktop-Modus. Die mobilen Werte fallen fast immer deutlich schlechter aus, da Lighthouse dort eine langsamere Verbindung und schwächere Hardware simuliert. Und genau diese Bedingungen treffen auf einen Großteil Ihrer Besucher zu.

Messwerte zu erheben ist der erste Schritt. Der zweite, und oft schwierigere, besteht darin, die richtigen Schlüsse daraus zu ziehen. Nicht jede schlechte Metrik hat dieselbe Ursache, und nicht jede Optimierung wirkt sich auf alle Metriken gleichermaßen aus.

6.1 Die TTFB als Ausgangspunkt

Eine bewährte Vorgehensweise ist, die Analyse immer mit der Time to First Byte (TTFB) zu beginnen. Diese Metrik zeigt Ihnen, wie schnell der Server auf eine Anfrage reagiert, noch bevor der Browser überhaupt mit dem Rendern beginnen kann. Liegt der TTFB deutlich über 0,8 Sekunden, ist der Server zu langsam, und keine Optimierung am Frontend kann dieses Defizit vollständig kompensieren. In diesem Fall sollten Sie sich zunächst der Server-Konfiguration widmen: Ist die PHP-Version aktuell? Ist ein serverseitiger Cache aktiv? Ist die Datenbank optimiert? Passt das Hosting-Paket zur Größe der Website?

Ist die TTFB hingegen im grünen Bereich, können Sie sich auf die Frontend-Seite konzentrieren. Die Differenz zwischen TTFB und Gesamtladezeit zeigt Ihnen, wie viel Zeit die Website selbst, also Bilder, JavaScript, CSS und externe Ressourcen, in Anspruch nimmt.

6.2 Das Wasserfall-Diagramm lesen

Das Wasserfall-Diagramm ist Ihr wichtigstes Diagnosewerkzeug, und es lohnt sich, es sorgfältig zu lesen. Achten Sie auf folgende Muster:

Besonders lange einzelne Balken deuten darauf hin, dass eine bestimmte Ressource unverhältnismäßig groß ist oder dass der Server für diese Anfrage ungewöhnlich lange braucht. Ein einzelnes, nicht optimiertes Bild mit mehreren Megabyte kann die Gesamtladezeit einer ansonsten schnellen Seite drastisch verschlechtern.

Wenn viele Anfragen gleichzeitig starten und dabei Wartezeiten entstehen, hat der Browser alle verfügbaren Verbindungen ausgeschöpft. Neue Anfragen können erst beginnen, wenn bestehende abgeschlossen sind. Dieses Problem tritt besonders bei Seiten mit vielen kleinen Ressourcen auf und lässt sich durch das Zusammenfassen von Dateien oder den Einsatz eines CDN entschärfen.

Externe Ressourcen sind häufig ein unterschätzter Engpass. Third-Party-Skripte für Analytics, Chat-Widgets, Social-Media-Eiinbindungen oder Werbeanzeigen laden ihrerseits oft weitere Skripte nach und können das Laden der eigentlichen Website erheblich verzögern. Im Wasserfall-Diagramm erkennen Sie solche Kaskaden daran, dass eine Anfrage zu einer externen Domain weitere Anfragen zu anderen Domains nach sich zieht.

Kaskaden-Effekte entstehen auch bei eigenen Ressourcen, wenn eine Datei erst geladen werden kann, nachdem eine andere abgeschlossen ist. Ein typisches Beispiel: Eine CSS-Datei verweist auf eine Webfont-Datei, die wiederum erst heruntergeladen werden muss, bevor der Text gerendert werden kann. Solche Abhängigkeitsketten lassen sich durch Preloading kritischer Ressourcen durchbrechen.

6.3 Typische Problemquellen erkennen

In der Praxis kehren bestimmte Problemkonstellationen immer wieder. Eine hohe TTFB weist fast immer auf einen langsamen Server hin, sei es durch eine veraltete PHP-Version, fehlenden Cache oder ein überlastetes Hosting-Paket. Ein schlechter LCP entsteht häufig dann, wenn das Hero-Bild zu groß ist, in einem ineffizienten Format vorliegt oder zu spät priorisiert wird. Ein hoher INP ist meist die Folge von zu viel oder zu schwerem JavaScript, das den Haupt-Thread des Browsers blockiert und ihn daran hindert, auf Nutzereingaben zu reagieren. Ein hoher CLS deutet auf Bilder ohne angegebene Abmessungen, nachladende Werbeanzeigen oder Webfonts ohne geeignete Fallback-Darstellung hin. Und eine ungewöhnlich hohe Anzahl an Requests ist oft das Ergebnis zu vieler Plugins, nicht zusammengefasster Dateien oder überflüssiger externer Widgets.

Sobald Sie die Schwachstellen Ihrer Website identifiziert haben, geht es an die Optimierung. Die folgenden Maßnahmen sind nach Wirkungsbereich gegliedert, vom Server über die Medien bis hin zum Code.

7.1 Server und Hosting

Die Grundlage jeder schnellen Website ist ein schneller Server. Keine Frontend-Optimierung kann einen langsamen Server kompensieren, weshalb dieser Bereich immer zuerst betrachtet werden sollte.

CMS, Shop-System und PHP aktuell halten: Verwenden Sie stets die neueste stabile PHP-Version. Jede neue PHP-Hauptversion bringt messbare Performance-Verbesserungen mit sich, die sich ohne jede Änderung am Code Ihrer Website bemerkbar machen. Gleiches gilt für Ihr CMS oder Shop-System: WordPress, Joomla, Shopware und andere Content-Management- oder Shop-Systeme optimieren mit jedem Major-Update ihre interne Verarbeitung.

Server-seitiges Caching einsetzen: Caching auf dem Server reduziert die Arbeit, die bei jedem Seitenaufruf anfällt. Der Opcode-Cache (OPcache) speichert vorkompilierten PHP-Code und ist in den meisten Hosting-Umgebungen bereits aktiv. Ein Object-Cache wie Redis oder Memcached hält häufig benötigte Datenbankabfragen im Arbeitsspeicher bereit, sodass sie nicht bei jedem Seitenaufruf erneut an die Datenbank gestellt werden müssen. Am wirksamsten ist ein Full-Page-Cache, der die fertig gerenderte HTML-Seite zwischenspeichert und bei wiederholten Aufrufen direkt ausliefert, ohne dass PHP oder die Datenbank überhaupt angesprochen werden. Lösungen hierfür sind etwa nginx FastCGI Cache oder CMS-spezifische Caching-Plugins.

Komprimierung aktivieren: Die Übertragung von Text-basierten Dateien (HTML, CSS und JavaScript) lässt sich durch Komprimierung erheblich beschleunigen. Das älteste und am weitesten verbreitete Verfahren ist gzip, das die Dateigröße um etwa 70 Prozent reduziert. Moderner und effizienter ist Brotli, das 15 bis 25 Prozent bessere Komprimierungsraten als gzip erzielt und von allen aktuellen Browsern unterstützt wird. Am Horizont zeichnet sich mit Zstandard (zstd) ein weiteres Verfahren ab, das vergleichbare Komprimierungsraten wie Brotli bei deutlich höherer Geschwindigkeit bietet. Die Browser-Unterstützung wächst stetig.

HTTP/2 und HTTP/3: HTTP/2 sollte mittlerweile das Minimum sein. Es erlaubt dank Multiplexing, mehrere Anfragen gleichzeitig über eine einzige Verbindung abzuwickeln, und reduziert die Datenmenge durch Header-Komprimierung. HTTP/3, das auf dem QUIC-Protokoll basiert, geht noch einen Schritt weiter: Es ermöglicht einen schnelleren Verbindungsaufbau (0-RTT), vermeidet das sogenannte Head-of-Line-Blocking, bei dem in HTTP/2 ein einzelner Paketverlust alle parallelen Anfragen verzögern kann, und unterstützt Connection Migration, der nahtlose Wechsel zwischen WLAN und Mobilfunk, ohne dass die Verbindung neu aufgebaut werden muss. HTTP/3 wird bereits von etwa einem Drittel aller Websites unterstützt und ist besonders für mobile Nutzer auf instabilen Netzwerkverbindungen ein echter Gewinn.

103 Early Hints einsetzen: Eine vergleichsweise neue, aber wirkungsvolle Technik ist der HTTP-Statuscode 103 (Early Hints). Er ermöglicht es dem Server, dem Browser kritische Ressourcen wie Stylesheets, Schriftarten oder JavaScript-Dateien anzukündigen, noch bevor die eigentliche HTML-Antwort fertig generiert ist. Der Browser kann so bereits mit dem Download dieser Ressource beginnen, während der Server noch mit der Verarbeitung beschäftigt ist. 103 Early Hints ersetzen zunehmend das ältere HTTP/2 Server Push, das sich in der Praxis als schwierig zu handhaben erwiesen hat.

7.2 Bilder optimieren

Bilder sind in den meisten Fällen der größte Hebel für eine bessere Ladezeit. Sie machen durchschnittlich 50 bis 70 Prozent der gesamten Seitengröße aus, und entsprechend groß ist das Einsparpotenzial.

Der wichtigste Schritt ist die Verwendung moderner Bildformate. AVIF, basierend auf dem AV1-Video-Codec, erzeugt bei gleicher visueller Qualität 40 bis 60 Prozent kleinere Dateien als JPEG und wird inzwischen von über 85 Prozent aller Browser unterstützt (Chrome, Firefox, Safari ab Version 16 und Edge). WebP, das ältere moderne Format, bietet immer noch etwa 30 Prozent Einsparung gegenüber JPEG bei einer Browser-Unterstützung von über 97 Prozent. Die empfohlene Strategie ist, AVIF als primäres Format auszuliefern, WebP als Fallback für ältere Browser anzubieten und JPEG als letzte Rückfallebene beizubehalten. Mit dem HTML-Element <picture> lässt sich diese Kaskade elegant umsetzen:

<picture>
  <source srcset="bild.avif" type="image/avif">
  <source srcset="bild.webp" type="image/webp">
  <img src="bild.jpg" alt="Beschreibung" width="800" height="600" loading="lazy">
</picture>

Neben dem Format gibt es weitere wichtige Optimierungen. Für Bilder, diesich außerhalb des sichtbaren Bereichs befinden, sollten Sie das Attribut loading="lazy" verwenden. Der Browser lädt diese Bilder dann erst, wenn der Nutzer in ihre Nähe scrollt, und spart so wertvolle Bandbreite beim initialen Seitenaufbau. Für das Hauptbild der Seite, das sogenannte Hero-Bild, das in der Regel das LCP-Element ist, gilt allerdings das Gegenteil: Diese Bild sollte keinesfalls lazy geladen werden, sondern mithilfe von fetchpriority="high" und einem Preload-Link (<link rel="preload">) so früh wie möglich geladen werden.

Geben Sie außerdem für alle Bilder immer die Attribute width und height an. Ohne diese Angaben weiß der Browser nicht, wie viel Platz ein Bild einnehmen wird, bevor es geladen ist, und reserviert keinen Platz im Layout. Sobald das Bild dann erscheint, verschiebt sich der gesamte Seiteninhalt nach unten. Genau die Art von Layout-Sprung, die zu einem schlechten CLS-Wert führt.

Für Websites, die Bilder in vielen verschiedenen Größen ausliefern müssen, bieten die Attribute srcset und sizes eine elegante Lösung. Der Browser wählt damit automatisch die passende Bildgröße für die jeweilige Bildschirmauflösung und das Ausgabeformat, sodass auf einem Smartphone nicht dasselbe 200-Pixel-Bild geladen wird wie auf einem 4K-Monitor.

7.3 JavaScript und CSS optimieren

Nach den Bildern sind JavaScript und CSS die zweitgrößten Faktoren für die Ladezeit, und sie beeinflussen vor allem die Reaktionsfähigkeit (INP) und die Zeit bis zum ersten sichtbaren Inhalt (FCP).

Jedes Plugin und jedes externe Skript, das Sie in Ihre Website einbinden, erhöht die Ladezeit. Analytics-Tools, Chat-Widgets, Social-Media-Buttons, Cookie-Banner, A/B-Testing-Skripte, sie alle laden eigene JavaScript-Dateien und oft zusätzliche Ressourcen nach. Prüfen Sie deshalb regelmäßig, ob jedes eingebundene Plugin noch benötigt wird, ob es eine leichtgewichtigere Alternative gibt und ob das Skript wirklich sofort beim Seitenaufruf geladen werden muss oder ob ein verzögertes Laden mit den Attributen defer oder async ausreicht.

Auf der Code-Ebene gibt es mehrere Techniken, die die ausgelieferte Datenmenge reduzieren. Die Minifizierung entfernt überflüssige Zeichen wie Leerzeichen, Zeilenumbrüche und Kommentare aus JavaScript- und CSS-Dateien. In Kombination mit der bereits genannten Komprimierung (Brotli/gzip) können so bis zu 70 Prozent der Dateigröße eingespart werden. Code Splitting teilt große JavaScript-Bundles in kleinere Pakete auf, die nur bei Bedarf geladen werden, sodass der Browser beim ersten Seitenaufruf nur den Code lädt, der tatsächlich benötigt wird. Tree Shaking erkennt und entfernt automatisch Code, der zwar in einer Bibliothek vorhanden, aber in Ihrer Anwendung nirgends verwendet wird. Und für den ersten sichtbaren Bereich der Seite kann es sinnvoll sein, das kritische CSS, also die Styles, die für die sofort sichtbaren Elemente benötigt werden, direkt in den HTML-Code einzubetten und die restlichen Styles erst anschließend asynchron nachzuladen.

7.4 Caching im Browser

Richtiges Browser-Caching sorgt dafür, dass wiederkehrende Besucher Ihre Website deutlich schneller laden, weil bereits heruntergeladene Ressourcen wiederverwendet werden, statt sie erneut vom Server anzufordern.

Die Grundidee ist einfach: Statische Assets wie JavaScript-Dateien, Stylesheets und Bilder, die sich zwischen Deployments nicht ändern, sollten mit langen Cache-Laufzeiten versehen werden. Wenn Sie einen Content-Hash im Dateinamen verwenden (zum Beispiel style.a3b2c1.css), können Sie eine Laufzeit von einem Jahr setzen (Cache-Control: public, max-age=3153600, immutable), ohne befürchten zu müssen, dass Nutzer veraltete Versionen sehen. Bei Änderungen ändert sich der Hash und damit die URL, sodass der Browser automatisch die neue Version lädt.

Für HTML-Dokumente hingegen sollte der Cache so konfiguriert werden, dass der Browser bei jedem Aufruf beim Server nachfragt, ob eine neuere Version vorliegt (Cache-Control: no-cache, must-revalidate mit ETag). So stellen Sie sicher, dass Nutzer immer den aktuellen Inhalt sehen, während der Server durch ein kurzes "Nicht geändert"-Signal (HTTP 304) unnötige Datenübertragungen vermeidet.

7.5 CDN einsetzen

Ein Content Delivery Network (CDN) speichert Kopien Ihrer statischen Inhalte auf Servern, die über die ganze Welt verteilt sind, und liefert sie jeweils vom Standort aus, der dem anfragenden Nutzer am nächsten liegt. Dadurch sinkt die physische Entfernung zwischen Nutzer und Server, was sich direkt in einer niedrigeren TTFB und einer kürzeren Gesamtladezeit niederschlägt.

Dieser Effekt ist besonders spürbar bei Websites mit internationalem Publikum, aber auch innerhalb Deutschlands kann ein CDN die Ladezeit verbessern, indem es den eigenen Server entlastet und Lastspitzen abfängt. Gängige Anbieter wie Cloudflare, AWS CloudFront, Fastly oder Bunny.net bieten neben der reinen Auslieferung oft auch zusätzliche Funktionen wie automatische Bildoptimierung, DDoS-Schutz und Edge Computing.

7.6 Spekulative Navigation (Speculation Rules API)

Eine der spannendsten Neuerungen der letzten Jahre ist die Speculation Rules API. Sie ermöglicht es dem Browser, Seiten bereits im Hintergrund vorzuladen oder sogar vollständig zu rendern, noch bevor der Nutzer sie aufruft. Navigiert der Nutzer dann tatsächlich zu einer vorgeladenen Seite, erscheint diese nahezu sofort.

Die API kennt zwei Stufen: Beim Prefetch werden die Ressourcen einer Seite im Hintergrund heruntergeladen, aber noch nicht gerendert. Beim Prerender wird die Seite zusätzlich vollständig im Hintergrund aufgebaut. Beim Navigieren muss der Browser sie nur noch anzeigen, was zu einer wahrgenommenen Ladezeit von nahezu null führt.

WordPress hat diese Technologie in Version 6.8 (März 2025) nativ integriert, sodass WordPress-Websites automatisch von spekulativem Vorladen profitieren können. Die Browser-Unterstützung umfasst derzeit Chrome und Edge. Firefox und Safari unterstützen die API noch nicht.

7.7 Layout-Stabilität verbessern (CLS)

Layout-Verschiebungen lassen sich mit einigen gezielten Maßnahmen zuverlässig vermeiden. Geben Sie für alle Bilder und Videos feste Abmessungen über die Attribute width und height an, damit der Browser den benötigten Platz bereits reservieren kann, bevor die Ressource geladen ist. Reservieren Sie Platzhalter für Inhalte, die nachgeladen werden, etwa Werbeanzeigen oder eingebettete Inhalte von Drittanbietern. Verwenden Sie für Webfonts die CSS-Eigenschaft font-display: swap zusammen mit einer passenden System-Fallback-Schriftart, damit der Text sofort sichtbar ist und sich beim Laden der Webfont nicht verschiebt. Und vermeiden Sie es, Inhalte nachträglich oberhalb des bereits sichtbaren Bereichs einzufügen, da dies den gesamten darunterliegenden Inhalt nach unten drückt.

Die folgende Checkliste fasst die wichtigsten Maßnahmen zusammen und eignet sich als wiederkehrendes Prüfwerkzeug, etwa vor einem Relaunch, nach größeren Updates oder als Teil einer regelmäßigen Qualitätssicherung.

Server und Hosting

• Aktuelle PHP-Version im Einsatz
• CMS/Shop-System auf dem neuesten Stand
• Server-seitiges Caching aktiv (OPcache, Object-Cache, Full-Page-Cache)
• Komprimierung aktiviert (Brotli bevorzugt, mindestens gzip)
• HTTP/2 oder HTTP/3 aktiv
• CDN im Einsatz

Bilder

• Moderne Formate (AVIF/WebP) mit JPEG-Fallback
• Lazy Loading für Bilder außerhalb des Viewports
• Feste Dimensionen (width/height) für alle Bilder
• Hero-Bild mit fetchpriority="high"

JavaScript und CSS

• Unbenutzte Plugins deaktiviert und entfernt
• Lazy Loading für Bilder außerhalb des Viewports
• JavaScript minifiziert und gebündelt
• CSS minifiziert, kritisches CSS inlined
• Third-Party-Skripte auf das Nötigste reduziert
• Skripte mit defer oder async geladen

Caching

• Cache-Header für statische Assets gesetzt (lange Laufzeit)
• Cache-Header für HTML angemessen (Revalidierung)
• Browser-Cache bei Tests deaktiviert (für realistische Messungen)

Layout-Stabilität

• Bilder und Videos mit festen Dimensionen
• Platzhalter für nachladende Inhalte
• font-display: swap für Webfonts

Regelmäßige Überprüfung

• Core Web Vitals in der Google Search Console überwachen
• Monatlicher Lighthouse-Test (Mobil und Desktop)
• Wasserfall-Diagramm bei Änderungen prüfen
• Nach Plugin-/Theme-Updates erneut testen

Dieser Leitfaden wird regelmäßig aktualisiert. Letzte Aktualisierung: März 2026.