Performance-Optimierung

Wir erheben Felddaten — Core Web Vitals so, wie echte Besucher sie erleben — und schlüsseln sie nach Seitentyp, Geräteklasse, Land und Verbindungsart auf, abgeglichen mit Analytics und der Search Console. Dieser Schritt wird am häufigsten übersprungen, und genau deshalb optimieren Teams wochenlang eine Seite, die für die relevante Zielgruppe längst schnell war.

Sobald die problematischen Seitentypen feststehen, reproduzieren wir das Verhalten unter gedrosselter CPU und Netzwerkverbindung, die einem Mittelklasse-Android entsprechen und nicht dem Entwicklerlaptop. Wasserfallanalyse, Long-Task-Traces und Server-Timing zeigen, welcher Anteil der Verzögerung auf das Netzwerk, welcher auf den Main Thread und welcher auf die Zeit vor dem ersten gesendeten Byte entfällt.

Wenn der Server eine Sekunde für die Antwort braucht, rettet keine Bildkomprimierung die Seite; deshalb schauen wir zuerst nach oben: Antwortzeit, Rendering-Strategie, Cache-Trefferquote und die Abfragen hinter der Seite. Auf unserer eigenen Plattform senkte der Wechsel von Volltabellen-Lesevorgängen zu schmalen Projektionen, gebündelten Inserts und aggregierendem SQL sowohl Antwortzeit als auch Datentransfer deutlich.

Anschließend nehmen wir uns vor, was der Browser laden und ausführen muss: ausgeliefertes, aber nie genutztes JavaScript, Hydration, die Interaktion blockiert, Schriften, die Text verzögern, und Bilder, die größer sind als ihr Container. Inhalte oberhalb der Falz sollten bereits aus der Serverantwort sichtbar sein und nicht erst nach dem Client-Bundle erscheinen — ein Fehlerbild, das wir in Produktion gefunden und behoben haben.

Wir legen fest, was am CDN-Edge, was im Server- oder Applikations-Cache liegt, was statisch regeneriert werden kann — und den meist übersprungenen Teil: wie jede Ebene bei Inhaltsänderungen exakt invalidiert wird. Caching ohne bewusste Invalidierung erzeugt das zweitschlechteste Ergebnis im Web-Engineering: schnelle Seiten mit falschen Daten.

Nach dem Rollout warten wir, bis die Felddaten nachziehen, denn Real-User-Metriken bewegen sich über Wochen statt Minuten, und vergleichen dann gegen die Baseline. Zurück bleiben Performance-Budgets und Monitoring, damit die nächste Verschlechterung im Deployment auffällt und nicht drei Monate später im Ranking.