Seitengewicht

Das Seitengewicht ist die Gesamtmenge an Bytes, die ein Browser laden muss, um eine Seite anzuzeigen: das HTML, jedes Stylesheet, Skript, jede Schrift, jedes Bild und Video, dazu alles, was Drittanbieter-Tags nachladen. Es ist die älteste Kennzahl der Web-Performance und bis heute eine der nützlichsten, denn jedes Byte kostet Zeit im Netz, Akku auf dem Gerät und bei Besuchern mit Volumentarif Geld. Es ist kein Core Web Vital, und eine schwere Seite kann alle drei bestehen. Aber das Gewicht legt bei langsamen Verbindungen den Boden unter den Largest Contentful Paint und ist das Erste, was Sie prüfen sollten, wenn eine Seite überall langsam ist.

Aus den Messungen von PerfDelta: Eine Startseite überträgt im mobilen Labortest im Median 4,3 MB, die mittlere Hälfte liegt zwischen 2,5 MB und 7,4 MB. 84 % der 4.108 Startseiten sind schwerer als 2 MB, 45 % schwerer als 5 MB. Mehr dazu im Datenblock unten.

Wie das Seitengewicht gemessen wird

Zwei Zahlen werden leicht verwechselt. Die Übertragungsgröße ist das, was nach der Komprimierung über das Netz geht. Die Ressourcengröße ist die unkomprimierte Größe, mit der der Browser arbeitet. Lighthouse und Pagespeed Insights zeigen die Übertragungsgröße je Ressourcentyp in der Ressourcenübersicht; die Chrome DevTools zeigen im Netzwerk-Panel beides. Die Reports von PerfDelta nutzen die Übertragungsgröße aus dem mobilen Laborlauf der Startseite, und das ist auch die Grundlage der Zahlen im Datenblock unten.

Das Gewicht hängt außerdem davon ab, wann man aufhört zu zählen. Verzögert geladene Bilder und Skripte, die erst beim Scrollen oder bei einer Interaktion laden, gehören nicht zum ersten Ladevorgang. Eine Seite, die beim Laden 2 MB überträgt und beim Scrollen weitere 6 MB, ist in Summe schwer, kann sich aber schnell anfühlen; genau das ist der Sinn des verzögerten Ladens.

Wohin die Bytes gehen

Im gesamten Web sind Bilder nach Bytes meist die größte Kategorie und JavaScript die zweitgrößte, wobei JavaScript laut dem jährlichen Web Almanac des HTTP Archive seit Jahren stetig wächst. Auf den großen Markenseiten in unseren Messungen ist die Reihenfolge oft umgekehrt: JavaScript ist auf der mittleren Startseite der größte Posten, vor den Bildern, weil Tag Manager, Frameworks, A/B-Tests und Personalisierung schneller zulegen, als die Bildoptimierung einspart. Schriften, CSS und das HTML-Dokument sind im Vergleich klein, liegen aber auf dem kritischen Pfad, deshalb zählt dort jedes Byte mehr als bei einem Bild unterhalb des sichtbaren Bereichs.

Was eine gute Seitengröße ist

Einen offiziellen Grenzwert gibt es nicht. Hilfreich ist ein Budget, abgeleitet von der Verbindung, die Sie gut bedienen wollen. Auf einer langsamen 4G-Verbindung mit grob 1,5 Mbit/s effektivem Durchsatz kostet jedes Megabyte rund fünf Sekunden reine Übertragung. Liegt das LCP-Ziel bei 2,5 Sekunden, müssen die Ressourcen für den ersten Paint, also HTML, kritisches CSS, die Schriften des sichtbaren Bereichs und das LCP-Bild, in wenige hundert Kilobyte passen, und alles andere muss später kommen. Für die ganze Seite gilt: unter 1 MB ist schlank, 1 bis 3 MB ist für Inhaltsseiten üblich, über 5 MB ist nach jedem Maßstab schwer. Der Datenblock unten zeigt, wo die gemessenen Startseiten im Verhältnis zu diesen Linien liegen.

So senken Sie das Seitengewicht

1. Zuerst die Bilder. In der angezeigten Größe ausliefern (Bilder richtig dimensionieren), als AVIF oder WebP, und alles unterhalb des sichtbaren Bereichs per Lazy Loading verzögert laden. Auf den meisten Seiten sparen diese drei Schritte mehr Bytes als alles andere zusammen.
2. Dann das JavaScript. Ungenutzten Code entfernen, Bundles je Route aufteilen und die Drittanbieter-Tags prüfen, die oft die größten und am wenigsten beachteten Skripte sind.
3. Text komprimieren und minimieren. Brotli oder Gzip für jede Textantwort, dazu im Build CSS und JavaScript minimieren. Billig, überall möglich und bei einem Serverumzug leicht verloren.
4. Schriften. Nur WOFF2, auf die genutzten Zeichen beschränkt, variable Schriften statt mehrerer Schnitte und höchstens zwei Familien.
5. Video. Nie eine Videodatei als Hero-Hintergrund auf Mobilgeräten automatisch abspielen. Nutzen Sie ein Vorschaubild und laden Sie das Video bei Interaktion, oder einen kurzen, stark komprimierten Clip mit preload="none".
6. Cachen, was sich wiederholt. Für wiederkehrende Besucher sinkt das Gewicht auf fast null, wenn statische Dateien lange Cache-Laufzeiten tragen (Browser-Caching).

Ein Performance-Budget festlegen

Ein Budget macht aus dem Seitengewicht statt einer einmaligen Aufräumaktion eine Regel. Legen Sie je Seitentyp eine Grenze fest, etwa 1,5 MB beim Laden für Produktseiten und 1 MB für Artikel, teilen Sie sie nach Ressourcentyp auf und lassen Sie den Build scheitern oder einen Alarm auslösen, wenn eine Änderung sie überschreitet. Lighthouse CI unterstützt Budgets über eine budget.json, und das Monitoring von PerfDelta verfolgt das Seitengewicht jeder URL über die Zeit, sodass eine neue App oder ein Marketing-Tag als Stufe im Diagramm auffällt statt Monate später als Überraschung.

Häufige Fragen

Beeinflusst das Seitengewicht das Google-Ranking?

Nicht als eigene Kennzahl. Es beeinflusst den Largest Contentful Paint, der ein Core Web Vital ist, besonders bei Besuchern mit langsamer Verbindung. Eine leichtere Seite ist der zuverlässigste Weg zu einem schnellen LCP auf Mobilgeräten.

Was ist wichtiger: weniger Anfragen oder weniger Bytes?

Mit HTTP/2 und HTTP/3 zählen Bytes mehr als die Zahl der Anfragen. Viele kleine Anfragen sind billig, wenige große Dateien nicht. Konzentrieren Sie sich auf die Größe, dann auf den kritischen Pfad.

Wie messe ich das Seitengewicht meiner Website?

Mit einem Test in Pagespeed Insights und der Ressourcenübersicht, oder im Netzwerk-Panel der Chrome DevTools mit deaktiviertem Cache. PerfDelta-Reports zeigen die Übertragungsgröße je Ressourcentyp für jede getestete Seite.

Warum ist meine Seite mobil schwerer als am Desktop?

Meist, weil das mobile Layout trotzdem die Desktop-Bilder lädt oder weil ein mobilspezifisches Skript oder eine App obendrauf kommt. Prüfen Sie zuerst die Bildgrößen, die an kleine Viewports gehen.