Was ist ein Performance Budget? Grenzen, die Ihre Website schnell halten

Kurz gesagt macht ein Performance Budget aus Geschwindigkeit eine dauerhafte Regel statt eines einmaligen Projekts. Wir, Talha Aslan und Team, sehen in der Praxis immer wieder dasselbe Muster. Zunächst startet eine Website schnell. Danach ergänzen Teams Monat für Monat einen Slider, ein Chatwidget und ein neues Tracking Tag. Ein Jahr später weiß niemand mehr, warum die Seite so schwer ist. Genau diesen schleichenden Zuwachs stoppt also ein Budget.

In diesem Leitfaden zeigen wir, aus welchen Metriken ein Budget besteht, wie Sie die ersten Grenzen festlegen, wie Sie das Budget im Team durchsetzen und wie Sie es in der Search Console beobachten. Alle Beispielzahlen kennzeichnen wir als "Beispielszenario". Ihre echten Zielwerte hängen von Ihrer Website und Ihren Nutzern ab.

Welche Probleme löst ein Performance Budget?

Die meisten Ladezeitprobleme entstehen nicht durch einen großen Fehler, sondern durch viele kleine Entscheidungen. Zum Beispiel wünscht sich das Marketing ein neues Tag, die Gestaltung schlägt ein größeres Titelbild vor und die Entwicklung bindet eine Bibliothek ein. Jede Entscheidung wirkt für sich zudem vernünftig. Allerdings bremst die Summe die Seite aus.

Ein Budget schafft deshalb eine gemeinsame Sprache. Die Diskussion wandert von "die Seite fühlt sich langsam an" zu "die Startseite liegt über ihrer JavaScript Grenze". Somit beruht die Entscheidung auf einer vereinbarten Grenze statt auf Geschmack. Auch der Artikel Performance Budgets 101 auf web.dev beschreibt ein Budget als Bezugspunkt für Entscheidungen zu Design, Technik und Funktionen.

• Geschwindigkeit bleibt bei jeder neuen Funktion sichtbar.
• Design, Entwicklung und Marketing verfolgen dasselbe Ziel.
• Rückschritte fallen vor der Veröffentlichung auf, nicht erst bei den Nutzern.
• Aus einem einmaligen Projekt wird eine dauerhafte Disziplin.

Welche Metrikarten gehören in ein Performance Budget?

web.dev teilt Budgetmetriken in drei Gruppen ein. Diese Aufteilung ist wichtig, denn sie zeigt Ihnen, wo Sie welche Grenze prüfen. Daher wählen Sie im ersten Schritt aus jeder Gruppe mindestens eine Metrik.

In der Praxis kombiniert das stabilste Budget alle drei Arten. Konkret steuern Mengengrenzen die tägliche Entwicklungsarbeit. Zeitgrenzen schützen die Nutzererfahrung. Zudem dient ein regelbasierter Score als schnelles Gesundheitssignal.

Wie legen Sie Grenzen für Seitengewicht und Anfragen fest?

Mengenbasierte Grenzen sind der greifbarste Teil eines Budgets. Zunächst teilen Sie die Ressourcen einer Seite nach Typ auf: Bilder, JavaScript, CSS, Schriften, Drittanbieter und Gesamtsumme. Dann vergeben Sie für jeden Typ eine eigene Obergrenze.

Für Teams ohne Zeit für eine Wettbewerbsanalyse nennt web.dev einen Startwert: weniger als 170 KB komprimierte und minifizierte Ressourcen im kritischen Pfad. Dieser Wert geht von einem langsamen Mobilnetz und einem Mittelklassegerät aus. Er ist also ein Ausgangspunkt, keine feste Regel. Deshalb braucht ein bildlastiger Katalog andere Grenzen als ein textlastiger Blog.

Auch die Anzahl der Anfragen verdient eine eigene Zeile. Vor allem Anfragen von Drittanbietern (Werbung, Analyse, Chat, Karten) wachsen mit der Zeit. Deshalb empfehlen wir eine eigene Grenze für Drittanbieteranfragen. Wie Sie das Bildgewicht senken, zeigt unser Leitfaden zur Bildoptimierung. Für einen schnellen Test eignet sich unser Werkzeug zum Bilder verkleinern.

Warum braucht JavaScript ein eigenes Budget?

Allerdings kostet JavaScript mehr als ein gleich großes Bild. Nach dem Download muss der Browser den Code nämlich noch parsen, kompilieren und ausführen. Diese Arbeit blockiert den Hauptthread (main thread), und die Seite reagiert dann verzögert auf Klicks. Daher lohnt sich eine eigene JavaScript Grenze, unabhängig vom Gesamtgewicht.

Eines der Beispielbudgets auf web.dev lautet: Eine Produktseite liefert mobil weniger als 170 KB JavaScript aus. Dieselbe Quelle rät außerdem bildlastigen Websites zu strengeren JavaScript Grenzen, weil Bilder bereits den größten Teil des Gesamtbudgets verbrauchen.

Mehr Hintergrund liefert unser Artikel zur JavaScript Ladezeit und Performance. Aus Budgetsicht bleibt die zentrale Frage daher einfach. Bringt jede neue Bibliothek den Nutzern genug Nutzen, um ihre Kosten zu rechtfertigen?

Welche LCP, INP und CLS Ziele sollte ein Performance Budget nutzen?

Die Core Web Vitals bilden das Rückgrat eines zeitbasierten Budgets. Laut der Web Vitals Seite auf web.dev bedeutet eine gute Erfahrung: LCP (Largest Contentful Paint) bei höchstens 2,5 Sekunden, INP (Interaction to Next Paint) bei höchstens 200 Millisekunden und CLS (Cumulative Layout Shift) bei höchstens 0,1.

Diese Schwellen bewerten Sie am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgerät und Desktop. Das heißt, der Großteil Ihrer Besucher sollte innerhalb des Ziels liegen. Eine Seite besteht nur, wenn alle drei Metriken ihr Ziel erreichen.

Was die einzelnen Metriken bedeuten, erklären wir in unserem Beitrag Core Web Vitals erklärt. Für das Budget gilt dann eine einfache Empfehlung. Nehmen Sie die offiziellen Schwellen als Obergrenze und setzen Sie Ihr eigenes Ziel etwas strenger. So rutscht ein kleiner Rückschritt nicht sofort in den schlechten Bereich.

Was verbraucht das LCP Budget?

Das LCP Element ist meist das größte Bild oder der größte Textblock einer Seite. Folglich verbrauchen Serverantwortzeit, Größe des Titelbilds, renderblockierendes CSS und spät entdeckte Ressourcen den größten Teil des LCP Budgets.

1. Messen Sie, wie lange der Server bis zum ersten Byte braucht.
2. Bestimmen Sie das LCP Element; meist handelt es sich um ein Bild.
3. Prüfen Sie Größe und Format dieses Bildes.
4. Stellen Sie sicher, dass es nicht verzögert lädt; nutzen Sie Lazy Loading nie für das Bild im ersten Sichtbereich.
5. Reduzieren Sie renderblockierendes CSS und Schriftdateien.

Liegt Ihr LCP Ziel für die Startseite beispielsweise bei 2 Sekunden, können Sie diese Zeit in Teile zerlegen. Vergeben Sie dann je einen Anteil an Serverantwort, Ressourcenerkennung, Download und Darstellung. Das ist allerdings nur ein Beispielszenario. Es zeigt Ihnen, welcher Teil das Budget sprengt. Konkrete Techniken finden Sie in unserem Leitfaden zur LCP Optimierung.

Warum lässt sich ein INP Budget nicht im Labor messen?

INP hängt von echter Nutzerinteraktion ab. Die Metrik misst die Verzögerung zwischen Klick, Tippen oder Tastendruck und dem nächsten Frame, den der Browser zeichnet. Laut web.dev gelten 200 Millisekunden oder weniger als gut. Zwischen 200 und 500 Millisekunden besteht Verbesserungsbedarf, und alles über 500 Millisekunden gilt als schlecht.

Laborwerkzeuge wie Lighthouse können INP allerdings nicht messen, denn im Test agiert kein echter Nutzer. Deshalb empfiehlt web.dev die Total Blocking Time (TBT) als Ersatzgröße im Labor. Ihr Budget braucht also zwei getrennte Zeilen: eine TBT Grenze für das Labor und ein INP Ziel für die Felddaten.

Aus Budgetsicht wirkt vor allem ein Schritt: Begrenzen Sie Skripte, die den Hauptthread lange beschäftigen. Lange Aufgaben stammen oft aus schweren Event Handlern, großen Drittanbieterpaketen oder Arbeit, die bis nach der ersten Interaktion warten könnte.

Wie legen Sie Ihr erstes Performance Budget Schritt für Schritt fest?

Der web.dev Leitfaden Your first performance budget empfiehlt, mit Messung und Vergleich zu beginnen. Bei Kundenprojekten gehen wir deshalb in einer ähnlichen Reihenfolge vor.

1. Wählen Sie Schlüsselseiten: Startseite, die Kategorie oder Produktseite mit dem meisten Traffic und die Landingpage mit den meisten Conversions.
2. Messen Sie die heutigen Werte, getrennt für Mobilgerät und Desktop.
3. Vergleichen Sie ähnliche Websites, indem Sie denselben Seitentyp einiger Wettbewerber unter gleichen Bedingungen testen.
4. Setzen Sie ein langfristiges Ziel; web.dev rät, mindestens 20 Prozent schneller als der schnellste Wettbewerber zu sein.
5. Setzen Sie ein realistisches erstes Budget; wirkt das Ziel weit entfernt, starten Sie 20 Prozent schneller als Ihr aktueller Wert.
6. Ergänzen Sie Mengengrenzen und regelbasierte Grenzen für JavaScript, Bilder, Anfragen und den Lighthouse Score.

Beispielszenario: Die Startseite von example.com hat heute einen mobilen LCP von 4 Sekunden. Das langfristige Ziel liegt unter 2,5 Sekunden, das erste Budget bei etwa 3,2 Sekunden. Erreicht das Team dieses Zwischenziel, verschärft es das Budget auf die nächste Stufe.

Brauchen unterschiedliche Seitentypen eigene Budgets?

Ja. Denn ein Blogartikel und eine Produktliste enthalten sehr unterschiedliche Inhalte. Folglich ist eine gemeinsame Grenze für die eine Seite zu streng und für die andere zu locker. Auch web.dev empfiehlt eigene Budgets je Seitentyp.

Die Grenzen in dieser Tabelle sind Beispielszenarien. Tragen Sie die Werte aus Ihren eigenen Messungen ein. Entscheidend ist also, dass Sie den kritischsten Posten jedes Seitentyps kennen.

Wie prüfen Sie ein Performance Budget mit Lighthouse?

Lighthouse kann ein Budget aus einer Datei lesen. Laut dem web.dev Leitfaden zu Lighthouse Budgets heißt diese Datei meist budget.json. Sie kann drei Arten von Grenzen enthalten: timings (in Millisekunden), resourceSizes (in KB je Ressourcentyp) und resourceCounts (Anfragen je Ressourcentyp).

Starten Sie Lighthouse über die Kommandozeile mit dieser Datei, zeigt der HTML Bericht unter der Kategorie Performance einen Abschnitt Budgets. So sehen Sie auf einen Blick, welcher Ressourcentyp die Grenze überschreitet und um wie viel. Derselbe Leitfaden macht zudem einen wichtigen Vorbehalt. Lighthouse erzeugt Labordaten, deshalb sollten Sie die Ergebnisse mit Felddaten echter Nutzer vergleichen.

Falls Lighthouse Berichte neu für Sie sind, starten Sie mit unserem Leitfaden zum Lighthouse Test. Auf der regelbasierten Seite nennt web.dev einen Lighthouse Performance Score von mindestens 85 von 100 als Beispielgrenze.

Wie verbinden Sie das Budget mit Ihrem Entwicklungsprozess?

Ein Budget, das nur in einem Dokument steht, gerät nach wenigen Wochen in Vergessenheit. Den echten Wert entfaltet es erst, wenn Sie es an Build und Veröffentlichung koppeln. web.dev nennt dafür drei quelloffene Optionen: die eingebauten Performance Hinweise von webpack, bundlesize zur Prüfung von Paketgrößen und Lighthouse CI zum Abgleich der Lighthouse Ergebnisse mit Ihrem Budget.

Läuft Lighthouse CI also bei jedem Pull Request, taucht eine Änderung, die die Grenze bricht, vor dem Zusammenführen auf. Dann wählt das Team einen von drei Wegen. Es optimiert die bestehende Funktion, entfernt etwas anderes oder verzichtet auf die neue Funktion. web.dev schlägt dieselben drei Optionen vor.

Selbst wenn Sie noch keine automatische Prüfung einrichten können, ist ein wöchentlicher manueller Test mit einer einfachen Tabelle deutlich besser als gar kein Budget.

Wie bringen Sie Ihr Team dazu, das Performance Budget einzuhalten?

Der technische Teil eines Budgets ist zunächst einfach. Schwierig ist, dass Menschen es respektieren. Positionieren Sie das Budget daher von Anfang an als gemeinsame Vereinbarung, nicht als "Sache der Entwicklung".

• Benennen Sie eine verantwortliche Person, die das Budget pflegt und Überschreitungen freigibt.
• Geben Sie dem Marketing eine Frage mit, bevor es ein Tag ergänzt: Aus welcher Budgetzeile zahlt dieses Tag?
• Teilen Sie Bild und Schriftgrenzen schon in der Designphase, damit die Gestaltung von Beginn an innerhalb der Grenzen arbeitet.
• Dokumentieren Sie Überschreitungen als Ausnahmen mit Datum, Grund und Rückbauplan.
• Prüfen Sie das Budget jedes Quartal und verschärfen Sie erreichte Ziele.

Den häufigsten Fehler sehen wir in der Praxis immer wieder: Nur eine Person kennt das Budget. Verlässt sie das Unternehmen, verschwindet auch das Budget. Deshalb empfehlen wir, die Grenzen in Projektdokumente, Designdateien und die Checkliste für Veröffentlichungen zu schreiben.

Wie sprengen Drittanbieterskripte das Budget?

Drittanbieterskripte sind die heimlichsten Verbraucher eines Budgets. Jemand bindet sie einmal ein, danach hinterfragt sie niemand mehr. Außerdem können diese Skripte selbst neue Anfragen auslösen und unbemerkt Gewicht hinzufügen.

Das Lighthouse Beispielbudget auf web.dev enthält eine eigene Grenze für die Anzahl der Drittanbieteranfragen. Deshalb empfehlen wir dasselbe in jedem Projekt. Zudem lohnt sich mindestens einmal im Jahr eine Inventur der Tags: Welches Tag ist aktiv, wer hat es angefordert und erfüllt es noch einen Zweck?

Andererseits sind manche Skripte wirklich nötig. Das Ziel ist nicht, alle zu entfernen. Stattdessen wählen Sie Ladezeitpunkt und Priorität bewusst. Lädt ein Chatwerkzeug etwa erst nach einer Nutzerinteraktion, gewinnt das Budget für den ersten Ladevorgang spürbar Luft.

Wie berechnen Sie ein Budget für Bilder und Schriften?

Auf den meisten Websites machen Bilder den größten Teil des Gesamtgewichts aus. Deshalb schlagen wir vor, das Bildbudget in zwei Teile zu trennen: den ersten Sichtbereich und den Rest der Seite. Bilder im ersten Sichtbereich wirken direkt auf den LCP, während Bilder weiter unten per Lazy Loading später laden dürfen.

Beispielszenario: Eine Leistungsseite zeigt im ersten Sichtbereich ein Titelbild und ein kleines Logo. Das Team gibt dem Titelbild eine feste Obergrenze in KB und dem Logo eine viel kleinere. Die Referenzbilder weiter unten verfolgt es dann über eine eigene Gesamtgrenze. Somit weiß eine Designerin, die ein Bild ergänzen möchte, aus welcher Zeile das Bild zahlt.

Außerdem verursachen Schriften leise Kosten. Jede zusätzliche Schriftstärke (leicht, fett, kursiv) bedeutet eine weitere Datei. Die mengenbasierten Beispiele auf web.dev nennen ebenfalls die Anzahl der Webfonts. In der Praxis schützen eine oder zwei Schriftfamilien mit wenigen Stärken das Budget und die gestalterische Einheit. Wählen Sie außerdem das Ladeverhalten der Schrift bewusst, damit Text während des Ladens nicht unsichtbar bleibt.

Zusammengefasst treffen Sie Entscheidungen zu Bildern und Schriften am besten schon im Design gemeinsam mit dem Budget. Nachträgliches Verkleinern kostet immer mehr als ein Entwurf innerhalb klarer Grenzen.

Warum sollte das mobile Budget strenger sein?

Mobilgeräte arbeiten bei Rechenleistung und Netz unter engeren Bedingungen. Dieselbe JavaScript Datei läuft auf einem starken Laptop schnell, kann den Hauptthread auf einem Mittelklassehandy aber deutlich länger blockieren. Daher ergibt ein eigenes, strengeres mobiles Budget Sinn.

Der web.dev Leitfaden zum ersten Budget zeigt diesen Unterschied. Er nennt eine kleinere Grenze für kritische Ressourcen im langsamen Mobilnetz und eine größere für Desktop im WLAN. Zudem bewerten Sie die Schwellen der Core Web Vitals getrennt für Mobilgerät und Desktop. Ein gutes Desktopergebnis kann ein mobiles Problem also nicht verdecken.

Woher wissen Sie, mit welchen Geräten Ihre Nutzer kommen? web.dev empfiehlt den Chrome User Experience Report, um die Geräteverteilung Ihres Publikums zu prüfen. Auch die Geräteaufteilung in Ihrem Analysetool hilft. Kommen die meisten Besuche von Mobilgeräten, testen Sie konsequent mit mobilem Profil und gedrosseltem Netz.

Was unterscheidet ein Performance Budget von Ladezeitoptimierung?

Ladezeitoptimierung umfasst alle Arbeiten, mit denen Sie ein bestehendes Problem lösen: Bilder komprimieren, ungenutzten Code entfernen, Cacheeinstellungen anpassen und so weiter. Ein Performance Budget ist dagegen die Regel, die verhindert, dass diese Gewinne mit der Zeit verloren gehen. Das eine ist Behandlung, das andere Vorsorge.

Ein Beispielszenario, das uns oft begegnet: Eine Website erreicht nach einem gründlichen Ladezeitprojekt gute Werte. Dann entspannt sich das Team, und innerhalb weniger Monate drücken neue Ergänzungen die Zahlen zurück auf den Ausgangswert. Das Problem liegt dann nicht in der Qualität der Optimierung. Vielmehr hat danach niemand ein Budget festgelegt.

Deshalb sollte der letzte Schritt jedes Ladezeitprojekts die neuen Werte als Budget festhalten. Messen Sie zum Beispiel nach der Optimierung die JavaScript Größe der Startseite und machen Sie diesen Wert plus kleinem Puffer zur Obergrenze. So halten Sie die gewonnene Geschwindigkeit. Für die übrigen technischen Prüfungen lesen Sie unsere Tipps zum technischen SEO.

Wie überwachen Sie ein Performance Budget in der Search Console?

Das Budget nur im Labor zu halten, reicht allerdings nicht. Sie müssen auch verfolgen, was echte Nutzer erleben, und dafür ist der Bericht Core Web Vitals in der Search Console der praktischste Ort. Laut der Search Console Hilfe nutzt der Bericht Felddaten echter Nutzer aus dem CrUX (Chrome User Experience Report). Er ordnet URL Gruppen als Poor (schlecht), Need improvement (Optimierung erforderlich) oder Good (gut) ein.

Jede Gruppe übernimmt den Status ihrer schwächsten Metrik. Selbst bei guten Werten für LCP und CLS zieht ein schlechter INP also die ganze Gruppe nach unten. Nach einer Korrektur starten Sie die Validierung mit Start Tracking auf der Detailseite des Problems. Google beobachtet dann 28 Tage lang, ob das Problem zurückkehrt.

Ist die Search Console neu für Sie, beginnen Sie mit unserer Search Console Anleitung für Einsteiger. Für die Budgetkontrolle empfehlen wir, diesen Bericht mindestens einmal im Monat zu öffnen.

Wie wirken Labordaten und Felddaten im Budget zusammen?

Labordaten entstehen in einer kontrollierten Umgebung mit festem Gerät und festem Netz. Daher eignen sie sich ideal, um Rückschritte während der Entwicklung zu erkennen. Felddaten zeigen dagegen, was echte Nutzer mit vielen Geräten und Verbindungen erleben. Allerdings brauchen sie Zeit, bis genug Daten vorliegen.

Ein gutes Budget verbindet beide Quellen. Laborgrenzen prüfen Sie bei jedem Pull Request, Feldziele verfolgen Sie im Monatsbericht. Widersprechen sich beide, bildet Ihr Laboraufbau Ihre echten Nutzer vermutlich nicht ab. Nutzen die meisten Besucher etwa Mittelklassehandys, täuscht ein Test auf einem starken Desktoprechner.

web.dev erwähnt zudem die offizielle Web Vitals Bibliothek für JavaScript, mit der Sie eigene Felddaten sammeln. Damit messen auch kleine Websites, denen genügend CrUX Daten fehlen, ihre echten Werte selbst.

Was gehört in einen monatlichen Bericht zum Performance Budget?

Überwachung lohnt sich nur mit einem regelmäßigen Bericht. Unseren Kunden schlagen wir ein kurzes, wiederholbares Format vor. Das Ziel lautet: Jede Person versteht den Stand in zwei Minuten.

• Budget und Istwert je Seitentyp für Gewicht, JavaScript und Anfragen.
• Laborergebnisse mit Lighthouse Performance Score und TBT.
• Feldergebnisse, also die Verteilung von Good, Need improvement und Poor im Bericht Core Web Vitals.
• Veränderung zum Vormonat und die Veröffentlichungen dahinter.
• Offene Überschreitungen mit verantwortlicher Person und Zieldatum.

Teilen Sie diesen Bericht auch mit Beteiligten ohne Technikhintergrund. Bringt das Marketing oder die Geschäftsführung dann eine neue Anfrage, kennt es den Stand des Budgets, und Sie entscheiden gemeinsam. Mit der Zeit entsteht außerdem ein wertvolles Archiv, das zeigt, welche Änderung die Geschwindigkeit wie stark beeinflusst hat.

Garantiert ein Performance Budget bessere Rankings?

Nein. Die Google Dokumentation zur Seitennutzung stellt klar, dass gute Ergebnisse in Berichten keine Spitzenplätze garantieren. Dieselbe Seite betont außerdem, dass Google stets die relevantesten Inhalte zeigen möchte, auch wenn die Nutzererfahrung schwächer ausfällt.

Warum zählt ein Budget dann trotzdem? Konkurrieren viele hilfreiche Seiten um dieselbe Suchanfrage, kann eine starke Nutzererfahrung den Unterschied machen. Zudem prägt Geschwindigkeit das Nutzerverhalten direkt. Wer eine langsame Seite verlässt, liest nichts und füllt kein Formular aus. Anders gesagt ist ein Budget kein Rankinghebel für sich allein. Es ist die Infrastruktur, die den Wert Ihrer Inhalte zu den Nutzern bringt.

In unserer SEO Arbeit betrachten wir Geschwindigkeit immer zusammen mit Inhalt, technischer Struktur und Links. Mit unserer SEO Beratung richten wir ein Performance Budget passend zu Ihrer Website ein und verfolgen Überschreitungen gemeinsam mit Ihren Teams.

In welcher Reihenfolge handeln Sie bei einer Budgetüberschreitung?

Eine Überschreitung ist keine Katastrophe, sondern ein Signal. Wichtig ist eine ruhige Reihenfolge statt hektisch installierter Plugins.

1. Finden Sie heraus, welche Zeile überschritten ist: Bilder, JavaScript, Drittanbieter oder Serverzeit.
2. Bestimmen Sie, wann die Überschreitung begann; aktuelle Veröffentlichungen und neue Tags liefern meist den Hinweis.
3. Suchen Sie schnelle Gewinne wie unkomprimierte Bilder, ungenutzten Code und überflüssige Schriften.
4. Reicht das nicht, wägen Sie den Nutzen der Funktion ab und entfernen oder verzögern Sie sie.
5. Bestätigen Sie die Korrektur im Labor und warten Sie dann, bis sich die Felddaten stabilisieren.

Halten Sie diese Reihenfolge ein, sinkt die Wahrscheinlichkeit, dass Sie dasselbe Problem einige Monate später erneut lösen müssen, denn Sie haben die Ursache dokumentiert.

Welche Fehler passieren bei einem Performance Budget am häufigsten?

Viele Teams, die ein Budget einführen, tappen in dieselben Fallen. Wer sie kennt, spart Zeit.

• Nur auf den Lighthouse Score schauen, während sich die echte Nutzererfahrung verschlechtert.
• Eine einzige Grenze für die ganze Website setzen und Unterschiede der Seitentypen ignorieren.
• Das Ziel am ersten Tag zu streng wählen, sodass das Team das Budget bald nicht mehr ernst nimmt.
• Nur am Desktop testen und die mobile Erfahrung übersehen.
• Nach dem Start mit dem Messen aufhören; auch web.dev rät, nach dem Launch weiter zu messen.

Kurz gesagt ist ein Budget ein lebendes Dokument. Ein Budget ohne Messung oder eines, das danach niemand mehr öffnet, ist nicht besser als gar keines.

Wer sollte Sie beim Performance Budget unterstützen?

Für eine kleine Website kann Ihr eigenes Team ein Grundbudget einrichten. Wählen Sie einige Seiten, messen Sie diese und setzen Sie einfache Grenzen. Bei Websites, an denen mehrere Teams arbeiten, die sich oft ändern oder komplex sind wie Onlineshops im E-Commerce, braucht die Verankerung im Prozess allerdings mehr Erfahrung.

Dann kann externe Unterstützung sinnvoll sein. Über unsere Seite zur SEO Beratung können Sie ein Angebot anfordern. Wir messen Ihre aktuellen Werte, schlagen Budgets je Seitentyp vor und verfolgen Überschreitungen mit Ihnen in einem monatlichen Bericht. Rankings garantieren wir nicht. Unser Ziel ist Geschwindigkeit, die Ihre Inhalte reibungslos zu den Nutzern bringt.

Welchen Weg Sie auch wählen, der erste Schritt bleibt gleich. Messen Sie Ihre aktuellen Werte, wählen Sie Ihre drei wichtigsten Seiten und schreiben Sie für jede eine Grenze auf. Schon ein kleines Budget, das Sie regelmäßig prüfen, hält Ihre Website über Jahre schnell.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.