Tempo ist kein Komfort, sondern ein Rankingfaktor
Google bewertet längst, wie schnell eine Seite reagiert und sich aufbaut. Der Grund ist simpel: Wer drei Sekunden auf eine Seite wartet, springt oft ab — und ein Suchmaschinen-Betreiber will niemanden auf langsame Seiten schicken. Geschwindigkeit ist damit doppelt wichtig: für die Besucher, die bleiben, und für die Sichtbarkeit, die darüber entscheidet, ob überhaupt jemand kommt.
Die erste Bremse sitzt am Server
Bevor der Browser auch nur ein Bild laden kann, muss der Server antworten. Diese erste Reaktionszeit — Fachbegriff TTFB, „Time To First Byte“ — ist die unsichtbarste und oft größte Bremse. Liegt sie bei mehreren Sekunden, hilft kein noch so schlankes Frontend mehr.
In einem Projekt haben wir die Auslieferungszeit eines Portals unter hoher Last von mehreren Sekunden auf rund eine Zehntelsekunde gebracht — etwa fünfzigmal schneller. Der Hebel lag nicht im Design, sondern in Caching, Datenbank und Server-Konfiguration. Ein dokumentierter Einzelfall, keine Pauschalzusage.
Die zweite Bremse sitzt im Frontend
Ist der Server schnell, entscheidet der Aufbau im Browser. Typische Bremsen:
- Riesige, unkomprimierte Bilder, die in voller Größe geladen und dann klein angezeigt werden
- Schriften und Skripte, die das Rendern blockieren, bis sie fertig geladen sind
- Layout, das nachträglich verspringt, weil Platz für Bilder oder Banner nicht reserviert wurde
Was wir messen, bevor wir etwas ändern
Tempo-Optimierung aus dem Bauch verschlimmbessert. Deshalb steht am Anfang die Messung: Wo geht die Zeit verloren — Server, Netzwerk, Browser? Erst wenn die größte Bremse benannt ist, lohnt sich der Eingriff. Alles andere ist teurer Aktionismus.
Schnell bleiben, nicht nur schnell werden
Eine Seite einmal zu beschleunigen reicht nicht. Neue Inhalte, neue Skripte, neue Banner bremsen mit der Zeit wieder. Wer Tempo halten will, braucht Caching, das automatisch greift, und einen Blick auf die Kennzahlen, der nicht nach dem ersten Erfolg endet.