Wer verantwortet die Speed-Zahl, wenn das Marketing selbst Seiten baut?

Kurz gesagt: niemand, solange das Performance-Budget nicht vorher als Team-Disziplin definiert ist. Genau das ist die Lücke, die 2026 sichtbar wird. Sobald Marketing-Teams Landingpages und Kampagnen-Seiten eigenständig im Editor komponieren, wandert die Verantwortung für Largest Contentful Paint (LCP) und Interaction to Next Paint (INP) in eine Grauzone. Das Marketing baut, aber misst die Speed-Zahl nicht. Das Engineering misst, aber baut die Seite nicht mehr. Und das Ergebnis landet als Ticket im nächsten Sprint, wenn die Conversion schon gelitten hat.

Dieser Artikel ist bewusst nicht der hundertste Speed-gleich-Umsatz-Text. Die Korrelation ist bekannt. Die offene Frage ist eine andere: Wem gehört das Budget, wenn die Komposition demokratisiert wird? Wir argumentieren für Performance-Budgets als bindende Disziplin mit klarer Ownership und automatischen Leitplanken im Editor, statt nachträglicher Dev-Feuerwehr. Adressiert sind CMO, CFO und Engineering-Lead, die gemeinsam diese Zahl verantworten.

Was ist ein Performance-Budget?

Ein Performance-Budget ist eine verbindliche Obergrenze für Kennzahlen, die die Ladegeschwindigkeit und Interaktivität einer Seite bestimmen. Es ist kein Wunschwert, sondern eine Regel, die im Build- und Publish-Prozess greift, bevor eine Seite live geht.

Die drei Kern-Metriken sind die Core Web Vitals von Google, weil sie öffentlich, messbar und ranking-relevant sind:

• LCP (Largest Contentful Paint): Zielwert unter 2,5 Sekunden. Misst, wann das größte sichtbare Element geladen ist.
• INP (Interaction to Next Paint): Zielwert unter 200 Millisekunden. Misst, wie schnell die Seite auf Nutzer-Eingaben reagiert. INP hat 2024 First Input Delay als Vital abgelöst und ist damit der relevante Reaktivitäts-Wert für 2026.
• CLS (Cumulative Layout Shift): Zielwert unter 0,1. Misst visuelle Stabilität, also ob Inhalte beim Laden springen.

Ein Performance-Budget schreibt diese Schwellen fest und definiert, was passiert, wenn eine Seite sie reißt. Genau dieser zweite Teil, die Konsequenz, fehlt in den meisten Setups. Ohne Konsequenz ist ein Budget nur eine Notiz im Confluence.

Die Ownership-Lücke: Wenn das Marketing Seiten komponiert

Klassisch war die Verantwortung sauber getrennt. Das Engineering baute die Seite, das Engineering verantwortete ihre Performance. Wenn eine Seite langsam war, war klar, wessen Backlog das Problem trug.

Mit dem Modell, in dem Marketing-Teams auf einer Frontend Management Platform (FMP) selbst komponieren, bricht diese saubere Trennung auf. Marketing wählt Komponenten, lädt Bilder hoch, setzt Hero-Videos ein, bindet ein drittes Tracking-Skript ein und veröffentlicht, ohne Entwickler-Ticket. Das ist genau der gewünschte Geschwindigkeitsgewinn. Aber jede dieser Entscheidungen hat Performance-Folgen:

• Ein unkomprimiertes Hero-Bild kippt den LCP.
• Ein zusätzliches Marketing-Skript verschlechtert den INP, weil der Main-Thread blockiert.
• Ein nachgeladener Banner ohne reservierte Höhe erzeugt Layout-Shift und treibt den CLS.

Die Ownership-Lücke entsteht, weil die Person, die die Seite baut, die Speed-Zahl weder sieht noch verantwortet, und die Person, die die Zahl verantwortet, die Seite nicht mehr baut. Das ist keine Schuldfrage gegen das Marketing. Es ist ein strukturelles Governance-Problem. Eine Verantwortung, die zwischen zwei Teams liegt, liegt faktisch bei keinem.

Das zeigt sich auch im Budget. Wer die Experience-Schicht 2027 als eigene Budget-Position plant, muss die Performance-Verantwortung explizit zuordnen, sonst taucht sie als ungeplanter Dev-Aufwand auf.

LCP, INP und CLS als Budget-Metriken, nicht als Quartals-Report

Der entscheidende Wechsel ist, diese drei Werte nicht als nachträglichen Report zu behandeln, sondern als Budget-Position mit Soll-Wert. Ein Quartals-Report sagt, dass die Seite letztes Quartal langsam war. Ein Budget verhindert, dass sie überhaupt langsam live geht.

Konkret heißt das, jede Metrik bekommt einen festen Schwellenwert, der im Publish-Prozess geprüft wird:

• Metrik | Was sie misst | Budget-Schwelle | Typischer Auslöser bei Verstoß
• LCP | Ladezeit größtes Element | < 2,5 s | Unkomprimierte Hero-Medien, blockierende Schriften
• INP | Reaktion auf Eingaben | < 200 ms | Zu viele Marketing-/Tracking-Skripte
• CLS | Visuelle Stabilität | < 0,1 | Nachgeladene Banner ohne reservierten Platz

Diese Werte sind keine Erfindung, es sind die öffentlichen Core-Web-Vitals-Schwellen von Google. Der Unterschied liegt nicht in den Zahlen, sondern darin, sie als bindende Regel im Workflow zu verankern statt als Kennzahl im Dashboard, die man am Quartalsende betrachtet.

Eine Verantwortungs-Matrix für Marketing, Dev und Leadership

Performance-Governance funktioniert nur, wenn jede Rolle weiß, was sie besitzt. Die folgende Matrix ist ein Startpunkt, den ihr an eure Organisation anpassen könnt. Wichtig ist die Logik dahinter: Das Budget wird gemeinsam gesetzt, aber im Alltag klar verteilt verantwortet.

• Verantwortungsbereich | Marketing / E-Commerce | Engineering | Leadership (CMO/CFO/Eng-Lead)
• Budget definieren (Schwellen festlegen) | beteiligt | beteiligt | entscheidet
• Komponenten bauen (Leitplanken) | nutzt | baut + pflegt | finanziert
• Seite komponieren + veröffentlichen | verantwortet | unterstützt | -
• Medien-Optimierung (Bilder, Video) | verantwortet im Editor | automatisiert im Layer | -
• Performance messen + Alarm | sieht im Editor | betreibt Monitoring | sieht im Report
• Budget-Verstoß beheben | erste Instanz im Editor | zweite Instanz bei Komponente | eskaliert bei Konflikt
• Trade-off Speed vs. Feature entscheiden | schlägt vor | bewertet technisch | entscheidet final

Der Kern dieser Matrix ist die Zeile Budget-Verstoß beheben. Wenn das Marketing ein zu großes Bild hochlädt, soll es das im Editor sofort sehen und selbst korrigieren, nicht erst nach dem Launch ein Dev-Ticket auslösen. Das Engineering verantwortet die Leitplanken, nicht jede einzelne Seite. Und das Leadership verantwortet, dass das Budget überhaupt existiert und bei einem Konflikt zwischen Kampagnen-Tempo und Speed-Zahl eine Entscheidung getroffen wird.

Wie eine FMP die Leitplanken in den Editor bringt

Der Unterschied zwischen einem Performance-Budget auf Papier und einem, das wirkt, liegt im Durchsetzungsort. Eine Frontend Management Platform kann das Budget direkt dort durchsetzen, wo die Seite entsteht, also im Editor selbst, statt im nachgelagerten Code-Review.

Konkret sieht das so aus, dass das Marketing innerhalb von Leitplanken komponiert, die das Engineering einmal definiert hat:

• Komponenten mit eingebautem Budget: Das Engineering pflegt eine zentrale Komponenten-Bibliothek, in der Performance schon enthalten ist. Wenn das Marketing daraus komponiert, erbt jede Seite diese Eigenschaften, statt sie pro Seite neu zu riskieren. Diese Logik gilt auch für Brand-Konsistenz, wenn das Marketing Seiten komponiert: Was zentral definiert ist, lässt sich dezentral nutzen, ohne dass die Qualität auseinanderläuft.
• Automatische Medien-Optimierung: Bilder werden im Layer in moderne Formate konvertiert, skaliert und lazy geladen. Das Marketing muss kein Bild-Tool bedienen, der LCP-Schutz greift automatisch.
• Budget-Feedback im Editor: Statt eines Quartals-Reports sieht die Person, die komponiert, direkt eine Warnung, wenn eine Aktion das Budget reißt. Die Korrektur passiert vor dem Veröffentlichen, nicht danach.
• Monitoring nach dem Launch: Ein Performance-Monitoring auf Basis von Field-Daten erkennt Regressionen pro Deploy und alarmiert, bevor sie zur Conversion-Delle werden.

Das Ergebnis ist eine Verschiebung der Logik. Performance ist nicht mehr eine Sprint-Aufgabe am Quartalsende, sondern eine Plattform-Eigenschaft, die im Moment der Komposition greift. Das Marketing behält sein Tempo, das Engineering behält die Kontrolle über die Leitplanken, und das Leadership bekommt eine Zahl, die nicht erst im Nachhinein erklärt werden muss.

FAQ

Wer sollte das Performance-Budget formal besitzen? Die Schwellen gehören ins Leadership, weil sie eine Trade-off-Entscheidung zwischen Marketing-Tempo und technischer Qualität sind. Die tägliche Einhaltung verteilt sich: Marketing für die Komposition, Engineering für die Leitplanken. Ein Budget ohne formalen Owner im Leadership bleibt unverbindlich.

Bremst ein Performance-Budget das Marketing aus? Nein, wenn es im Editor durchgesetzt wird statt im Code-Review. Eine Warnung beim Bild-Upload kostet Sekunden, ein Dev-Ticket nach dem Launch kostet einen Sprint. Das Budget schützt das Tempo, indem es Rework verhindert.

Reicht ein Monitoring-Tool nicht aus? Monitoring zeigt, dass eine Seite langsam ist, also nachdem sie live ist. Ein Budget verhindert, dass sie langsam live geht. Beides gehört zusammen: Leitplanken vor dem Launch, Monitoring danach.

Was unterscheidet INP von dem alten First Input Delay? INP misst die Reaktion über die gesamte Lebensdauer einer Seite, nicht nur die erste Interaktion. Es ist damit der strengere und realistischere Wert für interaktive Storefronts und seit 2024 das offizielle Core Web Vital.

Nächste Schritte

Performance-Budgets sind keine Tool-Frage, sondern eine Governance-Frage. Der erste Schritt ist nicht der Kauf einer Software, sondern eine klare Antwort auf die Eingangsfrage: Wer verantwortet bei euch die Speed-Zahl, wenn das Marketing selbst baut?

Wenn ihr diese Verantwortung sauber zuordnen und automatisch durchsetzen wollt, lohnt sich ein Blick darauf, wie eine Frontend Management Platform Leitplanken im Editor verankert und wie Performance und Core Web Vitals als Plattform-Eigenschaft funktionieren statt als Sprint-Aufgabe.

Weiterführende Links:

• Agentic Frontend Management Platform
• Performance und Core Web Vitals
• Das Frontend-Budget 2027: Die Experience-Schicht als eigene Position
• Brand-Konsistenz, wenn das Marketing Seiten komponiert
• Laioutr Startseite