Die Performance einer Website zu steuern, ist überschaubar. Die Performance über zehn Websites, fünf mobile Apps und mehrere Microservices zu steuern, ist komplex.
Eine einzelne Website: Das Dashboard zeigt LCP, CLS und INP. Das Team konzentriert sich auf eine Seite nach der anderen.
Großunternehmen: Das Dashboard zeigt Hunderte Seiten, mehrere Produkte und mehrere Plattformen. Das Team muss Prioritäten setzen.
Performance-Analysen zu skalieren heißt: entscheiden, was du misst, entscheiden, was du optimierst, und die Verantwortung auf Teams verteilen.
Beispiel: Ein Unternehmen hat fünf Produkte (Webplattform, mobile App, Dashboard, Analyse-Tool, API). Jedes Produkt hat ein anderes Performance-Profil. Jedes Produkt betreut ein anderes Team. Ein zentrales Performance-Team kann nicht alles optimieren. Die Lösung: Standards festlegen, jedes Team verantwortet die Performance seines Produkts, das zentrale Team überwacht die Gesamt-Performance.
Im Großunternehmen entscheiden, was du misst
Miss nur die kritischen Pfade. Onlineshop-Plattform: Startseite, Produktseite, Kasse (kritisch). Blog, Über-uns-Seite (nicht kritisch). Konzentriere dich auf die kritischen Pfade.
Miss nach Produktlinie. SaaS-Plattform: Anmeldeseite, Dashboard, Einstellungsseite. Jedes Team verantwortet seine Seiten. Jedes Team verfolgt seine Performance.
Miss nach Wirkung aufs Geschäft. Seiten, die Umsatz bringen, zählen am meisten. Seiten mit wenig Traffic zählen weniger. Konzentriere dich auf die Seiten, die Umsatz bringen.
Ein Praxisbeispiel: ein Unternehmen mit drei Produktlinien:
- Produkt A (Onlineshop): Startseite, Produkt, Kasse, Suche
- Produkt B (SaaS): Anmeldung, Dashboard, Einstellungen, Integration
- Produkt C (Inhalte): Blog-Startseite, Artikel, Kommentare, ähnliche Artikel
Priorität bei der Messung:
- Produkt A (meisten Traffic, höchster Umsatz): alle Seiten messen
- Produkt B (hoher Traffic, hoher Umsatz): kritische Seiten messen (Anmeldung, Dashboard)
- Produkt C (wenig Traffic, wenig Umsatz): nur die Startseite messen
Die Verantwortung für Performance verteilen
Das zentrale Team legt Standards fest. Jedes Team verantwortet die Performance seines Produkts.
Standards: Alle Seiten müssen einen LCP unter 2,5 Sekunden, einen CLS unter 0,1 und einen INP unter 200 Millisekunden haben.
Modell der Verantwortung:
- Team von Produkt A: verantwortet die Performance von Startseite, Produkt, Kasse und Suche
- Team von Produkt B: verantwortet die Performance von Anmeldung, Dashboard und Einstellungen
- Team von Produkt C: verantwortet die Performance der Blog-Startseite
- Zentrales Performance-Team: prüft die Einhaltung, warnt bei Verschlechterungen und stellt Tools bereit
Ein Praxisbeispiel: eine SaaS-Firma mit drei Entwicklungsteams.
Standards (vom zentralen Performance-Team festgelegt):
- LCP-Ziel: zwei Sekunden (produktspezifische Ziele können abweichen, die Basis sind zwei Sekunden)
- CLS-Ziel: 0,05
- INP-Ziel: 150 Millisekunden
Verantwortung der Produktteams:
- Plattform-Team: Das Dashboard muss einen LCP unter zwei Sekunden halten
- Integrations-Team: Die Integrationsseite muss einen LCP unter 2,5 Sekunden halten
- Analyse-Team: Die Analyseseite muss einen LCP unter zwei Sekunden halten
Jedes Team misst seine eigenen Seiten. Das Dashboard warnt, wenn die Seiten eines Teams die Standards überschreiten. Das Team ist in der Verantwortung.
Performance über Produkte hinweg bündeln
Das gebündelte Dashboard zeigt: alle Produkte, alle Seiten und die Einhaltung der Standards.
Das Dashboard zeigt den Anteil der Produkte, die den Standard erfüllen: 90 Prozent der Seiten haben einen LCP unter 2,5 Sekunden. Grüner Bereich.
Das Dashboard zeigt, welche Produkte den Standard verfehlen: Produkt B erfüllt ihn zu 80 Prozent (zwei Seiten überschreiten den Standard). Gelber Bereich.
Bericht an die Führung: Die Gesamt-Performance ist stark (90 Prozent der Seiten erfüllen den Standard). Ein Produkt braucht Aufmerksamkeit (Produkt B).
Maßnahme: Das Team von Produkt B wird gewarnt. Das Team untersucht die Ursachen. Das Team optimiert die Seiten, die den Standard verfehlen.
Ein Praxisbeispiel: gebündelte Performance eines Unternehmens mit drei Produkten.
Produkt A (Onlineshop):
- Startseite: LCP 1,2 s (erfüllt)
- Produktseite: LCP 1,8 s (erfüllt)
- Kasse: LCP 2,1 s (erfüllt)
- Suche: LCP 2,4 s (erfüllt)
- Einhaltung: 100 Prozent
Produkt B (SaaS):
- Anmeldung: LCP 1,9 s (erfüllt)
- Dashboard: LCP 2,6 s (nicht erfüllt)
- Einstellungen: LCP 2,5 s (nicht erfüllt)
- Einhaltung: 66 Prozent
Produkt C (Inhalte):
- Blog-Startseite: LCP 2,3 s (erfüllt)
- Einhaltung: 100 Prozent
Gesamt: 88 Prozent Einhaltung über alle Produkte.
Bericht an die Führung: Zwei von drei Produkten erfüllen den Standard vollständig. Produkt B braucht Aufmerksamkeit. Das Team arbeitet daran, die Performance von Dashboard und Einstellungen zu verbessern.
Performance-Standards nach Gerätetyp und Region
Standards können je nach Kontext abweichen. Am Desktop gelten andere als mobil. In den USA gelten andere als international.
LCP-Ziel am Desktop: zwei Sekunden (schnelles Internet, schnelle CPU).
LCP-Ziel mobil: drei Sekunden (langsameres Internet, langsamere CPU).
LCP-Ziel in den USA: zwei Sekunden (insgesamt schnelles Internet).
LCP-Ziel international: drei Sekunden (unterschiedlich schnelles Internet).
Ein Praxisbeispiel: ein globales SaaS-Unternehmen mit Betrieb in mehreren Regionen.
LCP-Standard nach Region:
- USA: 1,8 Sekunden (Ziel)
- EU: 2,2 Sekunden (Ziel, langsameres Internet als in den USA)
- Asien-Pazifik: 2,5 Sekunden (Ziel, stärker schwankendes Internet)
Performance nach Region (aktueller Stand):
- USA: 1,5 Sekunden (gut, übertrifft das Ziel)
- EU: 2,3 Sekunden (am Ziel, kleine Verbesserung nötig)
- Asien-Pazifik: 3,0 Sekunden (unter dem Ziel, muss besser werden)
Maßnahme: Das Team für Asien-Pazifik (oder das zentrale Performance-Team, wenn es kein regionales Team gibt) optimiert die Performance in Asien-Pazifik. Schwerpunkt: CDN-Optimierung für die Regionen in Asien-Pazifik und Bildoptimierung für geringere Bandbreite.
Häufig gestellte Fragen
Wie lege ich unterschiedliche Performance-Standards für verschiedene Produkte fest?
Orientiere dich an der Bedeutung fürs Geschäft und an den Erwartungen der Nutzer. Das Produkt mit dem meisten Umsatz bekommt das ehrgeizigste Ziel. Ein Produkt mit weniger Umsatz bekommt ein lockereres Ziel. Beispiel: Die Kasse im Onlineshop ist am wichtigsten (sie bringt Umsatz). Ziel: 1,5 Sekunden. Blogartikel sind weniger kritisch. Ziel: 2,5 Sekunden. Mit dem Website-Builder von WEMASY kannst du das direkt auf deiner Website einrichten.
Soll das zentrale Performance-Team alle Produkte optimieren oder nur Standards setzen?
Standards setzen und überwachen. Die Optimierung übernehmen die Produktteams. Das zentrale Team stellt Tools, Coaching und Eskalationswege bereit. Kann ein Produktteam den Standard nicht erfüllen, hilft das zentrale Team. Die tägliche Optimierung ist aber Sache des Produktteams.
Wie gehe ich mit Konflikten zwischen Produktentwicklung und Performance-Anforderungen um?
Performance gehört zu den Produktanforderungen. Eine neue Funktion muss die Performance-Standards erfüllen. Bringt eine Funktion Code mit, der die Performance verschlechtert, wird sie erst nach der Optimierung freigegeben. Bei Performance gibt es keinen Spielraum (außer die Führung stellt sie aus geschäftlichen Gründen ausdrücklich zurück).
Soll ich die Performance von Seiten mit wenig Traffic messen?
Nein. Konzentriere dich auf Seiten mit viel Traffic und großer Wirkung. Seiten mit wenig Traffic sind den Aufwand der Optimierung nicht wert. Traffic mal Wirkung aufs Geschäft bestimmt die Priorität. Miss dort, wo die Wirkung am größten ist.
Wie berücksichtige ich die unterschiedliche Netzwerkgeschwindigkeit in den Regionen?
Setze je nach Region unterschiedliche Ziele. In den USA sind die Netze schnell. Setze ein ehrgeiziges Ziel (1,5 Sekunden). In internationalen Regionen sind die Netze unterschiedlich. Setze realistische Ziele (2 bis 3 Sekunden). Miss die Performance nach Region. Warne, wenn eine Region ihr eigenes Ziel verfehlt (nicht ein absolutes Ziel).
Soll ich Performance-Budgets in die Deployment-Pipeline aller Teams einbauen?
Ja. Prüfe das Performance-Budget vor dem Deployment. Überschreitet der Code eines Teams das Budget, wird das Deployment blockiert. Das verhindert Verschlechterungen. Es sorgt auch für Verantwortung (das Team muss vor dem Release optimieren).