Warum Websites langsam sind
Meistens an drei Stellen: zu große Bilder und Videos, zu viel JavaScript, und ein Server, der zu spät antwortet. Die Reihenfolge stimmt so oft, dass sie ein brauchbarer Startpunkt ist. Welche davon bei dir zutrifft, sagt dir eine Messung in zwei Minuten. Raten muss man hier nicht.
Ladezeit wird meist als eine Zahl diskutiert, und das ist der erste Fehler. Es sind drei Werte, sie messen verschiedene Dinge, und nur einer davon hat mit dem zu tun, was die meisten unter „langsam“ verstehen.
Drei Werte, die Google tatsächlich benutzt
Die Core Web Vitals sind drei Messwerte, und Google nennt für jeden eine Schwelle. Beurteilt wird nicht der Schnitt, sondern das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Übersetzt: Drei von vier Besuchern müssen es besser haben als die Schwelle, sonst gilt der Wert als nicht bestanden.
| Wert | Was er misst | Gut | Schlecht |
|---|---|---|---|
| LCP | Wann der größte sichtbare Inhalt steht | bis 2,5 s | über 4 s |
| INP | Wie träge die Seite auf Eingaben reagiert | bis 200 ms | über 500 ms |
| CLS | Wie stark das Layout beim Laden springt | bis 0,1 | über 0,25 |
Wo die Sekunden meistens hängen
Bilder und Videos sind fast immer der größte Posten, und fast immer der am leichtesten zu behebende. Ein Foto, das mit 4000 Pixeln Breite hochgeladen und dann per CSS auf 600 Pixel geschrumpft wird, überträgt ungefähr das Vierzigfache der nötigen Datenmenge. Der Besucher sieht davon nichts außer der Wartezeit.
JavaScript ist der zweite Posten und der unangenehmere. Es muss nicht nur geladen, sondern auch ausgeführt werden, und auf einem drei Jahre alten Android-Telefon dauert das ein Vielfaches dessen, was der Entwickler auf seinem Rechner sieht. Jedes Plugin, jedes Tracking-Skript und jeder Chat-Widget-Schnipsel zahlt hier ein. Das trifft besonders WordPress-Installationen, bei denen über Jahre Plugins dazugekommen sind, die niemand mehr entfernt.
Der dritte Posten ist die Zeit bis zur ersten Antwort des Servers. Bei billigem Shared Hosting sind mehrere hundert Millisekunden normal, bevor überhaupt ein Byte fließt. Diese Zeit steht am Anfang und verschiebt alles, was danach kommt.
Ein Beispiel, das schiefging: unsere eigene Seite
Diese Website misst sich jeden Morgen selbst mit Lighthouse und veröffentlicht das Ergebnis, auch wenn es schlecht ist. Am 19. August 2026 stand die mobile Bewertung bei 77 von 100, bei einem LCP von 3.097 Millisekunden.
Der Verdacht war schnell da. Die Startseite lud zwei Videos mit zusammen 7,8 Megabyte. Beide waren mit fester, viel zu hoher Bitrate kodiert, und eines schleppte eine Tonspur mit, obwohl es stumm und für Screenreader ausgeblendet läuft. Neu kodiert blieben davon 2,5 Megabyte übrig, ohne sichtbaren Unterschied: Einzelbilder aus altem und neuem Video sind nebeneinander nicht zu unterscheiden.
Am nächsten Morgen kam die Messung zurück: 78. Ein Punkt. LCP 3.090 Millisekunden statt 3.097, also praktisch unverändert. Besser wurden nur die Nebenwerte, Total Blocking Time und First Contentful Paint um je etwa 57 Millisekunden.
| 19.08., vorher | 20.08., nachher | |
|---|---|---|
| Performance mobil | 77 | 78 |
| LCP | 3.097 ms | 3.090 ms |
| TBT | 680 ms | 623 ms |
| FCP | 1.204 ms | 1.147 ms |
Warum das lehrreicher ist als ein Erfolg
Fünf Megabyte weniger und ein Punkt mehr. Die Vermutung war falsch, jedenfalls was die Hauptursache angeht. Die Videos waren Verschwendung und gehörten weg, aber sie waren nicht der Bremsklotz.
Der Grund liegt in der Mechanik von LCP: Gemessen wird, wann das größte sichtbare Element steht. Wenn das Element erst erscheint, nachdem JavaScript geladen, ausgewertet und ausgeführt wurde, hilft es wenig, die Videodatei zu verkleinern. Die Wartezeit entsteht davor. Genau darauf deutet auch die Total Blocking Time von 623 Millisekunden: Der Hauptthread ist beschäftigt, nicht die Leitung.
Die Lehre daraus gilt für jede Optimierung: Erst messen, welcher Wert hängt, und dann prüfen, wovon dieser Wert überhaupt abhängt. Wer die größte Datei sucht und sie verkleinert, arbeitet an der Datenmenge — das ist oft richtig, aber eben nicht immer der Wert, den Google bewertet.
Wir lassen diesen Abschnitt so stehen, weil er ehrlicher ist als die Version, die wir zuerst geschrieben hatten. Darin stand die Video-Diät als Lösung, bevor die Messung vom nächsten Morgen vorlag. Sie war es nicht.
Was du in zwanzig Minuten selbst tun kannst
Miss zuerst, rate nicht. PageSpeed Insights von Google ist kostenlos und nennt dir die drei Werte oben, getrennt nach Mobil und Desktop. Mobil ist der Wert, auf den es ankommt.
Sieh dir dann an, was am schwersten wiegt. Im Browser öffnest du die Entwicklerwerkzeuge, wechselst auf Netzwerk und lädst neu. Sortiert nach Größe steht ganz oben, was deine Seite ausbremst. In den meisten Fällen ist es ein Bild oder ein Video.
Und stell die einfache Frage, die selten gestellt wird: Braucht die Seite das überhaupt? Das Karussell mit acht Bildern, das Chat-Widget, die zweite Schriftfamilie, das Video im Kopfbereich. Jedes davon kostet Ladezeit. Manches verdient sie, vieles nicht.
- Bilder in der Größe ausliefern, in der sie angezeigt werden, und als WebP oder AVIF
- Videos ohne Tonspur kodieren, wenn sie stumm laufen
- Alles, was unterhalb des ersten Bildschirms liegt, erst dann laden
- Schriften auf die tatsächlich genutzten Schnitte begrenzen
- Skripte entfernen, die niemand mehr auswertet
Wann Optimieren nicht mehr reicht
Es gibt einen Punkt, an dem weitere Optimierung teurer wird als ein Neubau. Er ist erreicht, wenn die Seite auf einem Baukasten oder auf einem über Jahre gewachsenen Plugin-Stapel läuft und die großen Posten dort fest verdrahtet sind. Dann kämpfst du gegen das Fundament.
Das ehrlich zu sagen, ist unbequem, weil es nach Eigennutz klingt. Deshalb der Umkehrschluss dazu: Wenn deine Seite bei 85 liegt und du sie auf 95 bringen willst, lohnt sich der Neubau nicht. Dann sind es ein paar Bilder und ein Skript zu viel, und das machst du an einem Nachmittag selbst.
Was dabei noch aufkommt.
Wie wichtig ist Ladezeit fürs Ranking wirklich?
Sie ist ein Faktor unter vielen, und sie schlägt schlechten Inhalt nicht. Der wichtigere Effekt ist der direkte: Wer wartet, geht zurück. Diesen Besucher verlierst du unabhängig davon, wie Google die Seite bewertet.
Warum zeigt PageSpeed jedes Mal einen anderen Wert?
Weil der Test auf geteilter Infrastruktur läuft und schwankt. Deshalb messen wir bei uns dreimal und nehmen den mittleren Wert. Aus einer einzelnen Messung eine Aussage abzuleiten, führt in die Irre.
Warum habt ihr die Videos dann trotzdem verkleinert gelassen?
Weil fünf Megabyte Verschwendung Verschwendung bleiben, auch wenn sie die Note nicht bewegt haben. Wer über Mobilfunk lädt, zahlt sie trotzdem, und die Nebenwerte sind messbar besser geworden. Nur als Erfolgsgeschichte taugt es nicht, und deshalb steht es hier so.
Ist 100 von 100 das Ziel?
Nein. Die letzten Punkte kosten meist unverhältnismäßig viel und bringen dem Besucher nichts mehr. Alles im grünen Bereich ist gut genug; die Zeit steckt danach besser in Inhalt.