Page Weight überwachen: Wenn Seiten unbemerkt aufblähen

Was Page Weight ist und warum jedes Kilobyte zählt

Page Weight bezeichnet die gesamte Transfergröße aller Ressourcen, die ein Browser für eine einzelne Seite lädt: das HTML-Dokument, CSS, JavaScript, Bilder, Schriften, Videos und alle eingebundenen Drittanbieter-Ressourcen. Gemessen wird üblicherweise in Kilobyte oder Megabyte pro Seitenaufruf, ergänzt um die Anzahl der Requests, also wie viele einzelne Dateien überhaupt angefordert werden. Beide Größen zusammen bestimmen maßgeblich, wie schnell eine Seite auf einem durchschnittlichen Mobilgerät und einer durchschnittlichen Verbindung nutzbar wird.

Nicht jedes Byte wiegt gleich schwer. JavaScript ist laut Google Byte für Byte die teuerste Ressource im Web (web.dev/Google), weil der Browser das Skript nicht nur herunterladen, sondern auch parsen, kompilieren und auf dem Main Thread ausführen muss - besonders auf leistungsschwachen Geräten kostet das Zeit. Ein 200 KB großes Bild belastet das Gerät weit weniger als 200 KB JavaScript. Deshalb reicht es nicht, nur auf die Gesamtgröße zu schauen: Die Verteilung über die Ressourcentypen entscheidet über die tatsächliche Wirkung auf die Ladezeit.

Die Zahlen: Wie stark Seiten seit 2015 aufgeblaht sind

Der langfristige Trend ist eindeutig: Seiten werden Jahr für Jahr schwerer. Seit 2015 hat sich das mediane Seitengewicht um 202,8 % erhöht (Web Almanac 2025), allein im letzten Jahr kamen 8,4 % hinzu (Web Almanac 2025). Parallel wächst die Zahl der eingebundenen Drittanbieter-Ressourcen: Die mediane Seite bindet 83 Drittanbieter-Requests auf dem Desktop und 79 auf dem Handy ein (Web Almanac 2025). Jeder dieser Requests bedeutet eine zusätzliche DNS-Auflösung, einen Verbindungsaufbau und eine potenzielle Fehlerquelle außerhalb der eigenen Kontrolle.

Diese Medianwerte beschreiben die Mitte der Verteilung - die Hälfte aller Seiten liegt darunter, die andere Hälfte darüber. Am oberen Ende der Verteilung transportieren viele Seiten ein Vielfaches davon (Web Almanac 2025). Wichtig ist die Erkenntnis dahinter: Das Gewicht wächst nicht durch eine einzelne große Entscheidung, sondern durch viele kleine, unbeobachtete Zuwächse. Genau deshalb greift eine einmalige Optimierung zu kurz - ohne kontinuierliche Messung kriecht die Kurve nach jedem Sprint wieder nach oben.

Woher der Ballast kommt: JavaScript, Bilder, Fonts, Drittanbieter

Vier Ressourcentypen tragen den Großteil des Gewichts. Wer die Verteilung kennt, weiß, wo sich Optimierung und Überwachung am meisten lohnen.

Was Aufblähung geschäftlich kostet

Page Weight ist kein technisches Selbstgespräch, sondern eine Umsatzfrage. Google berichtet, dass 53 % der mobilen Besuche abgebrochen werden, wenn eine Seite länger als 3 Sekunden lädt (Google). Die Absprungwahrscheinlichkeit steigt laut Google/SOASTA um 32 %, wenn die Ladezeit von 1 auf 3 Sekunden wächst, und um 90 %, wenn sie von 1 auf 5 Sekunden steigt (Google/SOASTA). Schwerere Seiten laden auf realen Mobilverbindungen langsamer - der Zusammenhang zwischen Gewicht, Ladezeit und Absprung ist direkt.

Im E-Commerce trifft das doppelt: Die durchschnittlich dokumentierte Warenkorbabbruchrate liegt bei rund 70 % (Baymard), und langsame Seiten verschärfen dieses Muster. Da laut Branchenanalysen bereits über 60 % des Web-Traffics mobil stattfinden (Statista), entscheidet die Performance auf dem Smartphone über den Geschäftserfolg. Hinzu kommt der SEO-Hebel: Schwere Seiten verfehlen häufiger den LCP-Zielwert von 2,5 Sekunden (web.dev/Google) und rutschen damit in der Bewertung der Nutzererfahrung nach hinten.

Byte- und Request-Budgets definieren

Ein Performance-Budget ist eine selbst gesetzte Obergrenze, die nicht überschritten werden soll (web.dev/Google). Es macht Aufblähung sichtbar und verhandelbar: Wer ein neues Skript einbauen will, muss dafür an anderer Stelle Platz schaffen. Drei Budgetarten haben sich bewährt und lassen sich kombinieren:

• Mengenbasiert: feste Obergrenzen für Bytes und Request-Anzahl, etwa Gesamt-Transfergröße unter einem definierten Deckel und JavaScript unter einem eigenen Teilbudget.
• Zeitbasiert: Zielwerte für Meilensteine wie LCP unter 2,5 Sekunden (web.dev/Google) oder Time to Interactive, gemessen unter realistischen Bedingungen.
• Regelbasiert: Mindest-Scores, etwa ein Lighthouse-Performance-Score, der nicht unter einen Schwellenwert fallen darf - Details im Leitfaden zum Lighthouse-Score.

Ein sinnvoller Startpunkt orientiert sich an den Medianwerten der eigenen Branche und setzt das Budget bewusst unter den aktuellen Wert, damit die Kurve nicht weiter nach oben kriecht. Als maschinenlesbare Grundlage eignet sich eine einfache Budget-Datei je Ressourcentyp:

[
  {
    "path": "/*",
    "resourceSizes": [
      { "resourceType": "total",  "budget": 2000 },
      { "resourceType": "script", "budget": 500 },
      { "resourceType": "image",  "budget": 900 },
      { "resourceType": "font",   "budget": 150 },
      { "resourceType": "stylesheet", "budget": 100 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 40 },
      { "resourceType": "total",       "budget": 60 }
    ]
  }
]

Die Zahlen in diesem Beispiel sind bewusst als Richtwerte gewählt und sollten an die eigene Ausgangslage angepasst werden. Entscheidend ist weniger der exakte Deckel als die Tatsache, dass es überhaupt eine verbindliche Grenze gibt, gegen die jeder Deploy geprüft wird.

Page Weight kontinuierlich überwachen und alarmieren

Ein Budget entfaltet erst dann Wirkung, wenn seine Einhaltung automatisch gemessen wird. Ein einmaliger Test zeigt einen Momentwert, aber nicht den schleichenden Anstieg über Wochen. Kontinuierliches Monitoring lädt die Seite in regelmäßigen Abständen aus mehreren Regionen, misst Transfergröße und Request-Anzahl je Ressourcentyp und schlägt Alarm, sobald ein Wert das Budget überschreitet.

Ein Gewichtssprung geht oft mit weiteren Symptomen einher: Ein zu schweres Bundle kann die Serverantwort verlangsamen oder Timeouts provozieren, sichtbar über Monitoring der Server-Fehlerrate. Deshalb ergänzt XICTRAQ das Page-Weight-Monitoring um Alerting über mehrere Kanäle und um Reports und Statuspages, die den Trend über Wochen belegen. So wird aus einer einzelnen Messung ein Frühwarnsystem.

Wenn ein Deploy heimlich 400 KB nachlädt

Die gefährlichsten Zuwächse sind die unbeabsichtigten. Typische Auslöser für einen plötzlichen Sprung nach einem Release:

• Eine Abhängigkeit wird aktualisiert und bringt eine größere Bundle-Variante oder zusätzliche Sprachpakete mit.
• Tree-Shaking greift nach einer Konfigurationsänderung nicht mehr, sodass ungenutzter Code mit ausgeliefert wird.
• Ein Bild wird ohne Komprimierung oder ohne modernes Format hochgeladen und landet in voller Größe im Auslieferungspfad.
• Ein neues Marketing- oder Analyse-Tag wird eingebaut und lädt seinerseits weitere Skripte nach.
• Source Maps oder Debug-Artefakte gelangen versehentlich in das Produktions-Bundle - verwandt mit dem Muster ungewollter Deploy-Leaks, das der Beitrag zu versehentlich ausgespielten noindex-Tags beschreibt.

Ein Budget-Prozess in fünf Schritten

1. Bestandsaufnahme: Messen Sie die aktuelle Transfergröße und Request-Anzahl Ihrer wichtigsten Seiten je Ressourcentyp - Startseite, Produkt- und Kategorieseiten, Checkout.
2. Budget festlegen: Setzen Sie realistische, aber verbindliche Obergrenzen knapp unter dem Ist-Wert, getrennt nach Gesamtgewicht, JavaScript, Bildern und Drittanbieter-Requests.
3. Quick Wins heben: Bilder in moderne Formate konvertieren, Schriften reduzieren, ungenutzten Code entfernen und statische Assets über ein CDN ausliefern.
4. Monitoring einrichten: Lassen Sie die Budgets automatisch und regelmäßig prüfen, mit Alarm bei jeder Überschreitung statt manueller Stichproben.
5. Trend beobachten: Werten Sie den Verlauf über Wochen aus, erkennen Sie schleichende Zuwächse früh und behandeln Sie eine Budget-Verletzung wie einen Bug, nicht wie eine Randnotiz.

Page-Weight-Monitoring mit XICTRAQ einrichten

Page Weight ist kein statischer Wert, den man einmal optimiert und dann vergisst. Er verändert sich mit jedem Deploy, jeder neuen Abhängigkeit und jedem eingebundenen Drittanbieter-Skript. Deshalb gehört die Überwachung in denselben Werkzeugkasten wie die Kontrolle der Ladezeit: messen, budgetieren, alarmieren.

XICTRAQ misst Transfergröße und Request-Anzahl je Ressourcentyp aus mehreren Regionen, vergleicht sie mit Ihren Budgets und benachrichtigt Sie, sobald ein Deploy den Deckel reißt - kombiniert mit Performance-Monitoring, Lighthouse-Audits und Core-Web-Vitals-Tracking. So sehen Sie den Zuwachs am Tag des Releases statt Wochen später an der Conversion.

Starten Sie mit dem kostenlosen Test und prüfen Sie, wie schwer Ihre wichtigsten Seiten heute wirklich sind. Oder vereinbaren Sie eine persönliche Demo, um Budgets und Alerting in Aktion zu sehen.