Timo Wessels
English

Performance

Ladezeit verstehen: was die Zahlen bedeuten und welche zählt

Dieser Artikel erklärt, welche Werte es gibt, was sie messen, warum zwei Messungen derselben Seite verschiedene Ergebnisse liefern und in welcher Reihenfolge sich Arbeit lohnt.

10 Min. Lesezeit

Von Timo Wessels Veröffentlicht am Aktualisiert am

„Meine Website hat 47 Punkte." Das ist der Satz, mit dem dieses Thema meistens anfängt. Und es ist der falsche Einstieg — weil die Punktzahl das Ergebnis ist und nicht die Ursache, und weil sie je nach Messung anders ausfällt.

Zur Einordnung vorweg: In der Auswertung des HTTP Archive für 2024 erreichten nur 43 Prozent der Websites auf dem Handy in allen drei Kernwerten gute Ergebnisse, am Desktop 54 Prozent. Mobil verfehlt also mehr als die Hälfte der Websites das Ziel. Es ist kein Nischenproblem, und ein schlechtes Ergebnis ist kein Grund für ein schlechtes Gewissen.

Warum Ladezeit zählt

Drei Wirkungen, die zusammenhängen:

Besucher springen ab. Eine langsame Seite fühlt sich kaputt an. Der Besucher weiß nicht, ob noch etwas kommt, und geht zurück zum Suchergebnis — bevor er irgendetwas von deinem Angebot gelesen hat.

Suchmaschinen bewerten es mit. Google schreibt selbst, dass gute Kernwerte zu dem passen, was seine Ranking-Systeme belohnen wollen. Ein garantierter Spitzenplatz ist das nicht — aber ein Faktor, den du im Gegensatz zu vielem anderen direkt beeinflussen kannst.

Es trifft zuerst die Mobilnutzer. Und die sind bei den meisten Betrieben die Mehrheit. Wer nur am Bürorechner mit Glasfaser prüft, sieht das Problem nie.

Dazu ein Zusammenhang, den man selten hört: Fast alles, was die Ladezeit verbessert, verbessert auch Wartbarkeit und Sicherheit. Weniger Skripte heißt weniger, was kaputtgehen kann. Weniger Plugins heißt weniger Angriffsfläche.

Die drei Kernwerte

Google fasst drei Messwerte zusammen, die die wahrgenommene Qualität einer Seite abbilden sollen — die Core Web Vitals. Jeder misst etwas anderes. Gemessen wird nicht der Durchschnitt, sondern der Wert, den drei Viertel aller Seitenaufrufe erreichen oder unterbieten, getrennt nach Handy und Desktop.

LCP — Largest Contentful Paint

Was gemessen wird: wie lange es dauert, bis das größte sichtbare Element im ersten Bildschirmausschnitt dargestellt ist. Meist ein großes Bild oder die Hauptüberschrift.

Was der Besucher erlebt: wann die Seite „da" ist. Nicht fertig geladen — aber sichtbar.

Bewertung Wert
gut bis 2,5 Sekunden
verbesserungsbedürftig 2,5 bis 4 Sekunden
schlecht über 4 Sekunden

Die drei Ursachen, die seit Jahren dieselben sind: überdimensionierte Bilder, renderblockierende Ressourcen im Seitenkopf, langsame Serverantwort.

CLS — Cumulative Layout Shift

Was gemessen wird: wie stark sich die Seite beim Laden noch verschiebt.

Was der Besucher erlebt: Er will auf einen Link tippen, im selben Moment lädt oben ein Bild nach, alles rutscht runter, und er tippt auf etwas anderes. Das ist der Wert, der die meiste echte Wut erzeugt — auf dem Telefon besonders.

Bewertung Wert
gut bis 0,1
verbesserungsbedürftig 0,1 bis 0,25
schlecht über 0,25

Die Ursache ist fast immer dieselbe: fehlende Größenangaben. Bilder ohne width und height, nachgeladene Banner, Cookie-Hinweise, die den Inhalt verschieben, und Schriften, die beim Umschalten von der Ersatzschrift die Zeilen anders umbrechen.

Gut zu beheben — und trotzdem am häufigsten ignoriert, weil es sich am Entwicklerrechner mit schneller Verbindung fast nie zeigt.

INP — Interaction to Next Paint

Was gemessen wird: wie schnell die Seite auf eine Eingabe reagiert. Über die gesamte Nutzungsdauer, nicht nur beim Laden.

Was der Besucher erlebt: Er tippt auf einen Menüpunkt, eine halbe Sekunde passiert nichts, also tippt er noch mal.

Bewertung Wert
gut bis 200 Millisekunden
verbesserungsbedürftig 200 bis 500 Millisekunden
schlecht über 500 Millisekunden

Wichtig: INP hat am 12. März 2024 den früheren Wert FID abgelöst. FID maß nur die allererste Interaktion beim Laden, INP misst über die ganze Sitzung. Jede Anleitung, die noch von FID spricht, ist veraltet.

Und eine Grenze, die Werkzeuge selten benennen: INP lässt sich ohne echte Interaktion gar nicht messen. Eine Labormessung gibt stattdessen die Total Blocking Time aus — die Zeit, in der der Hauptprozess während des Ladens blockiert war. Google nennt sie selbst einen brauchbaren Ersatz, aber keinen gleichwertigen.

Die Ursache ist meistens JavaScript von Plugins, die auf jeder Seite mitgeladen werden, obwohl sie nur auf einer gebraucht werden.

Die weiteren Werte im Bericht

TTFB — Time to First Byte. Wie lange der Server braucht, bis das erste Byte ankommt. Das passiert vor allem anderen: TTFB ist der erste Teil des LCP, und jede Zehntelsekunde, die der Server braucht, kommt auf jeden anderen Wert obendrauf. Google nennt 0,8 Sekunden oder weniger gut, über 1,8 Sekunden schlecht.

Dieser Wert hängt an Hosting und Serverkonfiguration. Durch Bildoptimierung lässt er sich nicht verbessern.

FCP — First Contentful Paint. Wann überhaupt das erste Element sichtbar wird. Gut ist bis 1,8 Sekunden.

TBT — Total Blocking Time. Wie lange der Hauptprozess des Browsers durch JavaScript blockiert war. Der Laborersatz für INP.

DOM-Größe. Kein Zeitwert, sondern eine Anzahl: wie viele Elemente die Seite hat. Lighthouse warnt ab etwa 800 Elementen und meldet ab etwa 1.400 einen Fehler. Dieser Wert explodiert bei Baukasten-Seiten regelmäßig, weil jeder Baustein noch mehrere verschachtelte Behälter mitbringt.

Der Punkt, den fast alle falsch verstehen: Labor gegen Wirklichkeit

Bei PageSpeed Insights bekommst du zwei verschiedene Datensätze. Das ist die häufigste Verwirrungsquelle in diesem Thema.

Felddaten stehen oben: echte Messungen echter Besucher deiner Seite über die letzten 28 Tage, gesammelt von Chrome im Chrome User Experience Report. Angegeben wird nicht der Durchschnitt, sondern der Wert, den 75 Prozent deiner Besucher erreichen oder unterbieten. Das ist die Realität.

Labordaten stehen darunter: eine einzelne Messung, gerade eben durchgeführt, unter künstlich gedrosselten Bedingungen. Simuliert wird für Mobil ein Mittelklasse-Telefon in einem Mobilfunknetz. Das ist die Diagnose.

Drei Folgerungen:

Wenn beide auseinandergehen, gilt das Feld.

Felddaten fehlen oft. Sie brauchen genug Besucher. Bei kleinen Websites steht dort schlicht nichts — kein Fehler, sondern der Hinweis, dass die Beurteilung sich auf die Labormessung stützen muss.

Die Labormessung ist absichtlich pessimistisch und schwankt. Sie drosselt Rechenleistung und Verbindung, liegt deshalb typischerweise deutlich unter einer Messung auf deinem eigenen Rechner, und zwei Durchläufe hintereinander liefern nicht dasselbe. Google rät selbst, die Leistung als Verteilung zu sehen und nicht als einzelne Zahl. Ein Sprung um ein paar Punkte ist keine Verbesserung, sondern Schwankung.

Und eine Einordnung, die für KI-Sichtbarkeit relevant ist: Die Felddaten stammen von Menschen, die mit Chrome deine Seite besuchen. Wie schnell dein Server einem Crawler aus einem Rechenzentrum antwortet, messen sie nicht. Ein guter PageSpeed-Wert sagt also nichts darüber aus, ob ein KI-Crawler deine Seite rechtzeitig bekommt. Das sind zwei verschiedene Fragen.

Die Punktzahl ist nicht das Ziel

Die große Zahl oben ist ein gewichteter Mischwert. Nützlich als grobe Peilung, irreführend als Ziel.

Sie verdeckt, was los ist. Zwei Seiten mit derselben Punktzahl können völlig unterschiedliche Probleme haben — die eine einen langsamen Server, die andere zu viel JavaScript. Die Maßnahmen sind gegensätzlich.

Die letzten Punkte sind die teuersten. Nach Googles eigener Bewertungskurve kostet der Schritt von 99 auf 100 so viel Verbesserung wie der von 90 auf 94. Die Arbeit, die sich für deine Besucher auszahlt, liegt weiter unten.

Man kann sie optimieren, ohne die Seite schneller zu machen. Wer die Zahl zum Ziel erklärt, bekommt genau das.

Mein Maßstab: die drei Kernwerte im grünen Bereich, und die Seite fühlt sich auf einem durchschnittlichen Telefon in einem durchschnittlichen Netz gut an.

Wie du selbst misst

PageSpeed Insights unter pagespeed.web.dev. Adresse eingeben, fertig. Fang immer mit Mobil an — dort ist am meisten zu holen. Interessanter als die Punktzahl ist der Abschnitt „Diagnose": Dort steht, welche konkreten Dateien wie viel Zeit kosten.

Lighthouse in den Entwicklerwerkzeugen. Rechtsklick, Untersuchen, Reiter Lighthouse. Gut zum Ausprobieren während der Arbeit. Schlecht für Vergleiche, weil dein Rechner und dein Netz einfließen.

Der Netzwerk-Reiter mit Drosselung. Verbindung künstlich auf eine langsame Mobilfunkverbindung stellen und die Seite neu laden. Das beste Werkzeug für die Ursachensuche bei Layoutverschiebungen: In Zeitlupe sieht man genau, welches Element nachlädt und alles verschiebt.

Die Search Console. Ihr Bericht zu den Core Web Vitals zeigt die Felddaten deiner Website gruppiert nach Seiten mit ähnlichem Verhalten — also welche Seitengruppe Probleme hat, nicht nur eine Einzelseite. Auch hier gilt: ohne genug Besucher keine Daten.

Ohne Werkzeug: eigenes Telefon, WLAN aus, Seite aufrufen, mitzählen. Das ist die Erfahrung, die deine Kunden machen. Und für CLS reicht Zuschauen: neu laden und beobachten, ob etwas springt.

Was zu tun ist — nach Hebelwirkung geordnet

Die Reihenfolge ist wichtiger als die Liste.

1. Bilder. Fast immer der größte Einzelposten und der beste Aufwand-Nutzen-Faktor.

  • in ein modernes Format bringen (WebP oder AVIF)
  • auf die tatsächliche Anzeigegröße skalieren — kein riesiges Kamerabild in einem kleinen Bereich
  • automatische Komprimierung beim Hochladen einrichten, damit das Problem nicht wiederkommt
  • width und height setzen, damit der Platz reserviert ist und nichts verrutscht
  • srcset und sizes verwenden, damit kleine Bildschirme kleine Dateien bekommen
  • Bilder unterhalb des sichtbaren Bereichs verzögert laden
  • das große Bild im Kopfbereich ausdrücklich nicht verzögert laden, sondern mit fetchpriority="high" bevorzugen — sonst verschlechterst du genau den Wert, den du verbessern wolltest

2. Serverantwortzeit. Wenn der TTFB hoch ist, hilft nichts anderes. Zu prüfen: Seiten-Cache aktiv, aktuelle PHP-Version, OPcache an, Komprimierung an, HTTP/2 oder HTTP/3. Wenn das alles stimmt und der Wert bleibt hoch, ist das Hosting zu schwach oder die Datenbank überladen.

3. Plugins. Der unterschätzte Posten. Jedes Plugin bringt eigene Skripte und Stile mit, und viele laden sie auf jeder Seite — auch dort, wo sie nichts tun. Ein Formular-Plugin lädt seine Dateien auf der Startseite, obwohl das Formular nur auf der Kontaktseite steht.

Der wirksamste Schritt ist nicht, ein Plugin zu optimieren, sondern es zu entfernen.

4. Schriften. Vom eigenen Server statt von einem fremden, auf die benötigten Zeichen reduziert, im Format WOFF2, so wenige Schnitte wie möglich, so eingebunden, dass der Text sofort sichtbar ist. Das hat zusätzlich eine datenschutzrechtliche Seite, wenn die Schrift sonst von einem fremden Server geladen wird.

5. Auslieferung. Zwei Server-Einstellungen ohne Inhaltsarbeit:

  • Komprimierung für Textdateien (HTML, CSS, JavaScript) über Gzip oder Brotli. Bilder, Schriften und Videos sind bereits komprimiert — sie noch einmal zu komprimieren kostet Rechenzeit und bringt nichts.
  • Cache-Header für statische Dateien mit langen Laufzeiten, damit ein wiederkehrender Besucher sie nicht erneut lädt.

6. CSS und JavaScript. Nicht Benötigtes entfernen, den Rest verkleinern, nicht kritische Skripte verzögert laden, kritisches CSS für den sichtbaren Bereich direkt mitliefern. Der Bereich mit dem meisten technischen Aufwand und dem geringsten Ertrag pro Stunde — deshalb hinten.

7. Aufräumen in WordPress. Emoji-Skript abschalten, überflüssige Einbettungen begrenzen, Revisionen begrenzen, Datenbank aufräumen. Einzeln kleine Effekte, zusammen spürbar.

Was ich Kunden zur Erwartung sage

Ladezeit ist kein Projekt mit Enddatum. Sie verschlechtert sich mit jedem neuen Plugin, jedem eingebundenen Dienst und jedem großen Bild, das jemand hochlädt. Eine einmal optimierte Website ist ohne Aufmerksamkeit nach einer Weile wieder da, wo sie war. Deshalb gehört die Messung in die laufende Pflege.

Der größte Teil des Ergebnisses kommt aus wenigen Entscheidungen: wie viele fremde Dienste eingebunden sind, wie das Theme gebaut ist, wie viele Plugins laufen. Wer diese drei richtig entscheidet, braucht die feine Optimierung meistens gar nicht.

Und die unangenehme Wahrheit bei alten Websites: Wenn eine Seite sehr viele Plugins hat und aus einem Baukasten kommt, der pro Abschnitt mehrere verschachtelte Behälter erzeugt, ist Optimierung Symptombehandlung. Dann steht die Frage im Raum, ob ein Neuaufbau nicht der günstigere Weg ist.

Quellen