Website Performance Optimierung Feste Zielwerte je Seitentyp, Priorisierung nach Ursache, Abnahme getrennt von der Umsetzung

Große Websites werden nicht von selbst schnell, und ohne feste Zielwerte bleiben sie es auch nicht. Diese Seite beschreibt, wie eine Optimierung abläuft, die nach der ersten Welle hält: Erst wird gemessen, was reale Besucher erleben, dann wird nach Ursache getrennt, dann werden Zielwerte je Seitentyp vereinbart, und am Ende steht eine Abnahme, die unabhängig von der Umsetzung stattfindet.

Adobe Experience Manager und Magnolia CMSDeutschland, Österreich und die Schweiz

Der Fehler, der die meiste Zeit kostet

Die verbreitete Reihenfolge lautet: Werkzeug aufrufen, Punktwert notieren, Liste abarbeiten. Das führt zu Arbeit an Bildern und Skripten, während die Zeit an anderer Stelle verloren geht. In der eigenen Erhebung über 4.222 Auftritte liegt bei 80,3 Prozent der zu langsamen Seiten bereits die Antwortzeit des Servers über dem Grenzwert. Dort wirkt keine Maßnahme im Frontend.

Die Arbeit beginnt deshalb mit einer Trennung: Entsteht die Verzögerung vor dem ersten Byte, ist es eine Aufgabe für Betrieb und Cache. Entsteht sie danach, für das Frontend. Diese eine Unterscheidung spart in den meisten Projekten mehrere Wochen.

Ablauf in vier Schritten

1. Messen, was Besucher erleben. Felddaten je Seitentyp, Markt und Gerät statt eines Durchschnitts über die Domain. Dazu ein Inventar aller Drittanbieter-Skripte mit ihrer Blockierzeit in Millisekunden.
2. Nach Ursache trennen. Antwortzeit des Servers gegen Verarbeitung im Browser, je Seitentyp. Das Ergebnis ist eine Liste, die nach Wirkung sortiert ist und nicht nach Aufwand.
3. Zielwerte vereinbaren. Ein Performance-Budget je Seitentyp mit einem Eigentümer je Wert, dazu Abnahmekriterien, die in ein Ticket passen.
4. Abnehmen und halten. Prüfung nach jedem Release gegen die vereinbarten Werte, Grenzwerte in der Auslieferungskette, Freigabe für neue Tags.

Warum Zielwerte je Seitentyp und nicht für die Domain

Ein Mittelwert über eine Plattform verdeckt die Stellen, an denen es klemmt. Startseiten tragen die meisten Kampagnenbausteine und damit das höchste Risiko für Layoutverschiebungen. Übersichtsseiten haben die teuersten Abfragen und die meisten Bilder. Detailseiten sind meist unkritisch und werden deshalb gern als Beleg dafür herangezogen, dass die Plattform schnell sei. Formularstrecken tragen die meiste Interaktion und damit die strengste Anforderung an die Reaktionszeit.

Vier Seitentypen, vier Zielwerte, vier unterschiedliche Ursachen. Dieselbe Aufteilung gilt für die Messung, sonst lässt sich eine Verschlechterung nicht zuordnen.

Was gemessen wird

Bewertet wird nach den Core Web Vitals: die Ladezeit des Hauptinhalts, die Reaktionszeit auf Eingaben und die Layoutstabilität. Dazu kommt die Antwortzeit des Servers als Diagnosewert, weil sie entscheidet, wo die Arbeit beginnt.

Quelle für die Bewertung sind Felddaten, nicht Laborwerte. Welche Werkzeuge welche Quelle nutzen, steht unter Core Web Vitals messen. Ein Punktwert aus einem Laborwerkzeug taugt zum Vergleich zweier Stände derselben Seite, nicht als vereinbartes Ziel.

Warum die Wirkung ohne Regeln verfällt

Nach der ersten Welle sind die offensichtlichen Posten erledigt, und die Werte steigen. Danach kommen Kampagnen, neue Tags, ein Testwerkzeug, ein Chat, ein zusätzliches Segment in der Personalisierung. Jedes einzelne ist begründbar, und in der Summe liegt die Plattform nach zwei bis drei Quartalen wieder da, wo sie war.

Dagegen helfen drei Regeln: feste Grenzwerte je Seitentyp in der Auslieferungskette, die einen Build ablehnen; eine Freigabe für jedes neue Tag und jeden neuen Dienst; und ein Real User Monitoring, das eine Verschlechterung binnen 24 Stunden meldet, statt sie erst nach vier Wochen in den Google-Daten sichtbar werden zu lassen.

Beratung statt Umsetzung

Die Umsetzung bleibt bei Ihrem Team oder Ihrem Implementierungspartner. Geliefert werden Zielwerte, Tickets mit Abnahmekriterien, Antworten auf Rückfragen und die Abnahme. Diese Trennung ist keine Arbeitsteilung aus Bequemlichkeit, sondern die Voraussetzung dafür, dass eine Abnahme unabhängig bleibt: Wer ein Ergebnis erzeugt, prüft es nicht selbst.

Die drei Leistungen, eine Bestandsaufnahme zum Festpreis ab 4.900 Euro netto, eine laufende Kontrolle im Betrieb und die Abnahme in Migrationsprojekten, stehen mit Preisen und Leistungsumfang unter Leistungen.

Systemnahe Besonderheiten

Was in einem konkreten System zu tun ist, unterscheidet sich. Für Adobe Experience Manager stehen Dispatcher, Client Libraries, Data Layer und Edge Delivery Services im Vordergrund, nachzulesen unter Adobe Experience Manager Performance. Für Magnolia CMS sind es der Cache vor den Public-Instanzen, Light Modules und die Personalisierung, nachzulesen unter Magnolia CMS Performance. Wie schnell Plattformen auf beiden Systemen tatsächlich sind, steht im Core Web Vitals Benchmark.

Kostenfreie Performance-Erstanalyse buchen

30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.

Häufige Fragen zur Performance-Optimierung