Medianes Seitengewicht 2025: 15 Jahre Web-Inflation

Von CaptainDNS
Veröffentlicht am 12. Februar 2026

Diagramm zur Entwicklung des medianen Seitengewichts von 2010 bis 2025

TL;DR

2025 erreicht das mediane Seitengewicht 2,6 MB auf Desktop und 2,3 MB auf Mobile: eine Verfünffachung in 15 Jahren.
Bilder machen noch ~40 % des Gesamtgewichts aus, aber JavaScript hat die Bilder bei der Anzahl der Anfragen überholt (24 JS-Dateien gegenüber 18 Bildern pro Seite).
Eine mobile Seite von 2025 wiegt so viel wie eine Desktop-Seite von 2022: Mobile "folgt" Desktop mit 2 Jahren Verzögerung.
Teste deine Seiten mit unserem Page Crawl Checker, um zu prüfen, ob sie die 2-MB-Grenze von Googlebot überschreiten.

2025 wiegt die mediane Webseite mehr als das Originalspiel Doom (2,39 MB von 1993). Das ist kein Witz: Laut HTTP Archive erreichte das mediane Gewicht einer Desktop-Seite Ende 2024 2.652 KB, also 2,6 MB. In 15 Jahren hat das Web zugelegt. Deutlich zugelegt.

Diese Inflation ist nicht trivial. Das Seitengewicht beeinflusst direkt die Ladezeit, die Core Web Vitals, das Crawl Budget von Google und sogar den CO2-Fußabdruck deiner Website. Bei Websites mit mehr als 10.000 Seiten multipliziert sich jedes zusätzliche Kilobyte in verbrauchter Bandbreite, CPU-Zeit und verschwendetem Crawl Budget.

Dieser Artikel zeichnet 15 Jahre Entwicklung des Seitengewichts nach (2010-2025), analysiert, was Seiten heute schwer macht, misst die Auswirkungen auf Performance und SEO und liefert Prognosen für die Zukunft. Alle Daten stammen aus dem HTTP Archive und dem Web Almanac.

Entwicklung des medianen Seitengewichts von 2010 bis 2025

Die Entwicklung des Seitengewichts (2010-2025)

Die großen Etappen der Inflation

Das HTTP Archive misst das Seitengewicht seit 2010. Hier sind die wichtigsten Meilensteine:

Jahr	Desktop (Median)	Mobile (Median)	Markantes Ereignis
2010	~500 KB	~200 KB	HTTP Archive beginnt die Erfassung
2012	~800 KB	~400 KB	Responsive Design verbreitet sich
2014	~1.200 KB	~500 KB	Erste Schlagzeilen: "Die Durchschnittsseite übersteigt 2 MB"
2016	~2.300 KB	~1.200 KB	Die Medianseite übersteigt den Doom-Installer (2,39 MB)
2018	~1.700 KB	~1.500 KB	Methodenwechsel bei HTTP Archive
2020	~2.000 KB	~1.800 KB	COVID beschleunigt die Digitalisierung
2022	~2.312 KB	~2.037 KB	JS-Frameworks dominieren, Google pusht die Core Web Vitals
2024	~2.652 KB	~2.311 KB	JavaScript überholt Bilder bei der Anzahl der Anfragen

In 14 Jahren hat sich das mediane Desktop-Gewicht um den Faktor 5,3 vervielfacht. Auf Mobile ist das Wachstum noch beeindruckender: um den Faktor 11,5.

Desktop vs. Mobile: eine schrittweise Annäherung

Der Abstand zwischen Desktop und Mobile schrumpft jedes Jahr. 2010 wog eine mobile Seite 2,5-mal weniger als eine Desktop-Seite. 2024 beträgt der Unterschied nur noch 13 % (2.652 KB vs. 2.311 KB).

Eine aufschlussreiche Feststellung: Das mobile Gewicht von 2024 (2.311 KB) ist nahezu identisch mit dem Desktop-Gewicht von 2022 (2.312 KB). Mobile folgt Desktop mit etwa 2 Jahren Verzögerung. Die mobilspezifischen Optimierungen (responsive Bilder, Lazy Loading) kompensieren das allgemeine Ressourcenwachstum nicht mehr.

Die technologischen Wendepunkte

Drei Perioden haben die Inflation beschleunigt:

2012-2015: Responsive Design. Die massive Einführung von Fluid Grids und Media Queries förderte das Laden identischer Ressourcen auf allen Geräten. Retina-Bilder (2x, 3x) haben das Gewicht visueller Assets verdoppelt bis verdreifacht.

2016-2019: die Ära der Single Page Applications. React, Angular und Vue.js verlagerten das Rendering auf die Client-Seite. Das für den Seitenbetrieb nötige JavaScript explodierte. Bundles von 500 KB+ wurden zur Norm.

2020-2025: die technische Schuld. Consent-Banner (DSGVO), Analytics-Scripts, Chat-Widgets, A/B-Testing-Tools und Third-Party-Tags stapelten sich. Jede Ergänzung erscheint harmlos, aber ihre Akkumulation macht oft 200 bis 500 KB pro Seite aus.

Anatomie einer Webseite 2025

Aufschlüsselung nach Ressourcentyp

Laut HTTP Archive (Oktober 2024) sieht die mediane Gewichtsverteilung nach Ressourcentyp auf Desktop wie folgt aus:

Ressourcentyp	Medianes Gewicht (Desktop)	Medianes Gewicht (Mobile)	Anteil am Gesamtgewicht
Bilder	1.054 KB	900 KB	~40 %
JavaScript	613 KB	558 KB	~23 %
Schriftarten (Fonts)	131 KB	111 KB	~5 %
CSS	78 KB	73 KB	~3 %
HTML	18 KB	18 KB	~1 %
Sonstige (Video, Audio, Daten)	~758 KB	~651 KB	~28 %

Aufschlüsselung des medianen Gewichts nach Ressourcentyp 2025

Das JavaScript-Paradoxon: weniger Bilder, mehr Scripts

2024 kam es zur Wende: JavaScript hat die Bilder bei der Anzahl der Anfragen überholt. Die mediane Desktop-Seite lädt inzwischen 24 JavaScript-Dateien gegenüber 18 Bildern. Beim reinen Gewicht dominieren Bilder noch (1.054 KB vs. 613 KB), aber der Trend ist eindeutig: JavaScript wird zum größten Posten nach Dateianzahl.

Dieses Paradoxon hat konkrete Folgen. Eine 50-KB-Bilddatei wird heruntergeladen und angezeigt. Eine 50-KB-JavaScript-Datei wird heruntergeladen, geparst, kompiliert und ausgeführt. Die Auswirkung auf CPU und Largest Contentful Paint (LCP) steht in keinem Verhältnis zum reinen Gewicht.

Perzentile: der Long Tail der übergewichtigen Seiten

Der Median erzählt nur einen Teil der Geschichte. Die oberen Perzentile zeigen das Ausmaß des Problems:

Perzentil	Desktop	Mobile
P50 (Median)	2.652 KB	2.311 KB
P75	~5.200 KB	~4.500 KB
P90	~10.000 KB	~8.500 KB

Am P90 wiegt eine Desktop-Seite 10 MB. Das ist das Fünffache der Trunkierungsgrenze von Googlebot (2 MB HTML). Diese extremen Seiten sind keine Seltenheit: 10 % des Webs gehören dazu.

Warum werden Webseiten immer schwerer?

Die Explosion der JavaScript-Frameworks

2015 wog das mediane JavaScript pro Seite ~300 KB. 2024 sind es 613 KB: eine Verdoppelung in 9 Jahren. Moderne Frameworks (React, Next.js, Nuxt, Svelte) sind performanter als ihre Vorgänger, bringen aber eine nicht komprimierbare Runtime mit. Ein "Hello World" in React wiegt bereits ~40 KB minifiziert und gzippt.

Tree Shaking und Code Splitting helfen, kompensieren aber nicht die Vermehrung der Abhängigkeiten. Ein typischer E-Commerce-Shop lädt 30+ npm-Module clientseitig.

HD-Bilder und noch unzureichend genutzte Formate

Bilder bleiben der größte Posten beim Gewicht (1.054 KB Median). Dabei ermöglichen moderne Formate (WebP, AVIF) Einsparungen von 25 bis 50 % gegenüber JPEG. Die Verbreitung nimmt zu, ist aber unvollständig: 2024 nutzen etwa 30 % der ausgelieferten Bilder WebP und weniger als 5 % AVIF.

Retina-Bilder (2x) und Hero Images in voller Breite sind die Hauptverantwortlichen. Ein Hero Image in JPEG mit 1920x1080 wiegt leicht 200-400 KB. In AVIF sinkt dasselbe Bild auf 80-150 KB.

Web-Fonts machen 131 KB pro Seite aus (Median Desktop). Eine Website, die 3-4 Varianten einer Google-Fonts-Schriftart nutzt, überschreitet leicht 200 KB. Das WOFF2-Format hat die Größe um ~30 % gegenüber WOFF reduziert, aber die Anzahl der geladenen Schriftarten ist gestiegen.

Third-Party-Scripts sind heimtückischer. Ein typisches Audit zeigt:

Google Analytics/Tag Manager: 50-80 KB
Cookie-Consent-Banner: 50-150 KB
Chat-Widget: 100-300 KB
Werbe- und Retargeting-Pixel: 100-200 KB
A/B Testing: 50-100 KB

Die Summe übersteigt oft 400 KB an Third-Party-Scripts - Ressourcen, die du nicht direkt kontrollierst.

Der Inhalt selbst: länger, reichhaltiger, interaktiver

Redaktionelle Inhalte werden länger. Ein "SEO-optimierter" Blogartikel umfasst inzwischen 2.000 bis 4.000 Wörter (statt 500-1.000 im Jahr 2010). E-Commerce-Produktseiten integrieren Karussells, Bewertungen, Empfehlungen, Videos. Jedes Element fügt HTML, CSS und JavaScript hinzu.

Auswirkungen des Gewichts auf Performance und SEO

Core Web Vitals und Seitengewicht

Google nutzt drei Hauptmetriken zur Bewertung der Nutzererfahrung:

Metrik	Was sie misst	Zusammenhang mit dem Gewicht
LCP (Largest Contentful Paint)	Ladegeschwindigkeit des größten sichtbaren Elements	Je schwerer die Seite, desto langsamer der LCP
INP (Interaction to Next Paint)	Reaktionsfähigkeit bei Interaktionen	Schweres JavaScript blockiert den Main Thread
CLS (Cumulative Layout Shift)	Visuelle Stabilität	Schriftarten und Bilder ohne Dimensionen verursachen Verschiebungen

Es besteht eine direkte Korrelation zwischen Gesamtgewicht und LCP. Seiten am P90 (10+ MB) haben einen medianen LCP von über 4 Sekunden - weit jenseits der "guten" Schwelle von 2,5 Sekunden, die Google festlegt.

Die realen Kosten schwerer Seiten

Das Gewicht hat messbare Kosten:

Zeit. Jede zusätzlichen 100 KB fügen ~50 ms Ladezeit bei einer 4G-Verbindung hinzu. Bei einer 5-MB-Seite gegenüber einer 2-MB-Seite beträgt der Unterschied 1,5 Sekunden.

Geld. Laut whatdoesmysitecost.com kostet das Laden einer 2,6-MB-Seite in manchen Ländern etwa 0,32 USD an mobilen Daten. Bei einer Website mit 100.000 Besuchern pro Monat steigt der Bandbreitenverbrauch auf dem Server proportional.

CO2-Fußabdruck. Der Transfer von 1 GB Daten verursacht etwa 0,3 g CO2 (Schätzung WebsiteCarbon). Eine Website mit 100.000 Seitenaufrufen pro Monat und 5-MB-Seiten erzeugt ~150 kg CO2 pro Jahr allein durch den Datentransfer.

Die 2-MB-Grenze von Googlebot

Ein oft vergessener Aspekt: Googlebot trunkiert HTML ab 2 MB. Diese Grenze betrifft nur den HTML-Quellcode (nicht externe Bilder oder JavaScript). Aber Seiten, die Inline-CSS oder Inline-JavaScript einbetten, können diese Grenze erreichen. Einen umfassenden Guide zu diesem Thema findest du in unserem Artikel zur 2-MB-Grenze von Googlebot.

Auswirkung des Seitengewichts auf die Web-Performance

So misst und reduzierst du das Gewicht deiner Seiten

Messen mit dem Page Crawl Checker

Bevor du optimierst, miss. Unser Page Crawl Checker ermöglicht es dir, das Gewicht beliebiger Seiten zu testen - als Googlebot-Simulation oder klassischer Browser. Du erhältst das Gesamtgewicht, die Aufschlüsselung nach Ressourcentyp und die Prüfung der 2-MB-Grenze.

5 vorrangige Optimierungstechniken

1. Bilder in WebP oder AVIF konvertieren. Der Gewinn ist sofort spürbar: 25-50 % weniger Gewicht ohne wahrnehmbaren Qualitätsverlust. Verwende das <picture>-Tag, um AVIF an kompatible Browser zu liefern, WebP als Fallback und JPEG als letzte Option.

2. Third-Party-Scripts auditieren und unnötige entfernen. Jedes Third-Party-Script macht 50-300 KB aus. Entferne diejenigen, die keinen messbaren Mehrwert bringen. Lade die übrigen mit async oder defer.

3. Komprimierung aktivieren (Brotli > gzip). Brotli reduziert den Transfer um 15-25 % mehr als gzip. Die meisten CDNs und modernen Server unterstützen es. Prüfe, dass dein Server Content-Encoding: br sendet.

4. Lazy Loading implementieren. Bilder und Iframes außerhalb des initialen Viewports sollten nicht sofort geladen werden. Das native Attribut loading="lazy" reicht in den meisten Fällen aus.

5. Web-Fonts subsetten. Wenn du eine Schriftart nur für lateinische Zeichen verwendest, liefere ein auf die benötigten Zeichen beschränktes Subset. Der Wechsel von vollständigem Latin-ext zu einem gezielten Subset kann eine Schriftart von 100 KB auf 20 KB reduzieren.

Gewichtsbudget: eine technische Disziplin

Ein Gewichtsbudget pro Seite zu definieren, ist eine bewährte Praxis. Zum Beispiel: maximal 500 KB JavaScript, maximal 1 MB Bilder, maximal 2 MB Gesamtgewicht. Dieses Budget lässt sich in deine CI/CD-Pipeline integrieren: Eine Überschreitung löst vor dem Deployment einen Alarm aus.

Alex Russell (Chrome-Ingenieur bei Google) empfiehlt ein JavaScript-Budget von 365 KB, um ein Laden in 3 Sekunden auf einem durchschnittlichen Mobilgerät zu garantieren. Der aktuelle Median (558 KB auf Mobile) überschreitet dieses Budget um 53 %.

Trends 2026-2028: wird das Web weiter zunehmen?

Faktoren, die das Gewicht erhöhen

Mehrere Trends treiben das Gewicht nach oben:

Generative KI. KI-generierte Inhalte sind länger und detaillierter. Eingebettete Chatbots bringen eigene Scripts mit (oft 200-500 KB). Clientseitige Personalisierungsfunktionen erfordern zusätzliches JavaScript.

Eingebettetes Video. Videovorschauen, animierte GIFs, die durch <video> ersetzt werden, und Video-Hintergründe sind immer häufiger. Selbst ein Poster-Bild plus Player fügt 200+ KB hinzu.

Die Komplexität der Oberflächen. Mikro-Interaktionen, fortgeschrittene CSS-Animationen, interaktive Komponenten (Konfiguratoren, Vergleichstools) fügen Code-Schichten hinzu. Jedes "nette Feature" hat seinen Preis in Kilobyte.

Faktoren, die das Gewicht senken

Es gibt auch Gegentrends:

Die Verbreitung von AVIF. Dieses Bildformat bietet 30-50 % bessere Kompression als WebP. Die Verbreitung wächst stark (Chrome, Firefox, Safari unterstützen es inzwischen). Bis 2028 könnte AVIF das Bildgewicht im gesamten Web um 30 % senken.

HTTP/3 und QUIC. Das neue Protokoll verbessert Verbindungszeiten und Multiplexing. Es reduziert nicht das Gewicht, verbessert aber die gefühlte Performance, was den Optimierungsdruck verringert.

Core Web Vitals als Selektionsdruck. Indem Google Performance-Metriken mit dem Ranking verknüpft, schafft es einen wirtschaftlichen Anreiz zur Optimierung. Websites, die das Gewicht ignorieren, werden in den SERPs schrittweise abgestraft.

Edge Computing. Serverseitiges Rendering am Netzwerkrand (Edge SSR) reduziert das an den Client gesendete JavaScript. Frameworks wie Astro, Qwik und React Server Components gehen in diese Richtung.

Prognosen

Basierend auf dem Trend der letzten 5 Jahre (+7-9 % pro Jahr) könnte das mediane Gewicht folgende Werte erreichen:

Jahr	Desktop (Prognose)	Mobile (Prognose)
2025	~2.850 KB	~2.500 KB
2026	~3.050 KB	~2.700 KB
2028	~3.500 KB	~3.100 KB

Diese Prognosen setzen einen technologischen Status quo voraus. Die breite Einführung von AVIF und Server Components könnte das Wachstum bremsen. Umgekehrt könnten eingebettete KI und Video es beschleunigen.

Empfohlener Aktionsplan

Das Gewicht deiner kritischen Seiten messen: Verwende den Page Crawl Checker für deine 10 meistbesuchten Seiten. Vergleiche sie mit den Marktmedianen (2,6 MB Desktop, 2,3 MB Mobile).
Die schwersten Ressourcen identifizieren: nicht optimierte Bilder, aufgeblähte JavaScript-Bundles, ungenutzte Third-Party-Scripts. Sortiere sie nach Auswirkung und Korrekturaufwand.
Optimierungen anwenden und ein Gewichtsbudget festlegen: Konvertiere in WebP/AVIF, entferne unnötige Scripts, aktiviere Brotli. Definiere ein Budget von 2 MB pro Seite und integriere es in deine Deployment-Pipeline.

FAQ

Wie schwer ist eine durchschnittliche Webseite 2025?

Laut HTTP Archive (Daten Oktober 2024) beträgt das mediane Gewicht einer Webseite 2.652 KB (2,6 MB) auf Desktop und 2.311 KB (2,3 MB) auf Mobile. Diese Zahlen umfassen alle Ressourcen: HTML, CSS, JavaScript, Bilder, Schriftarten und sonstige Medien.

Wie ermittle ich das Gewicht einer Webseite?

Es gibt mehrere Methoden. Die Chrome DevTools (Tab "Network") zeigen das Gesamtgewicht und die Aufschlüsselung nach Ressource. Der Page Crawl Checker von CaptainDNS testet das Gewicht aus Googlebot-Sicht. WebPageTest und Lighthouse liefern detaillierte Analysen mit Optimierungsempfehlungen.

Warum werden Webseiten immer schwerer?

Vier Hauptfaktoren erklären diese Inflation: JavaScript-Frameworks, die den clientseitigen Code erhöhen, hochauflösende Bilder (Retina), die Vermehrung von Third-Party-Scripts (Analytics, Consent-Banner, Widgets) und der Inhalt selbst, der länger wird und mit interaktiven Medien angereichert wird.

Wie schwer sollte eine Webseite idealerweise für SEO sein?

Ein universelles Idealgewicht gibt es nicht, aber ein Budget von 2 MB pro Seite ist ein guter Richtwert. Für JavaScript allein empfiehlt Alex Russell ein Maximum von 365 KB, um ein Laden in 3 Sekunden auf Mobile zu gewährleisten. Die kritische Grenze für SEO ist das 2-MB-HTML-Limit, das Googlebot bei der Indexierung ansetzt.

Wie groß ist der Gewichtsunterschied zwischen Mobile und Desktop?

Der Abstand schrumpft. 2024 wiegt eine mediane Desktop-Seite 2.652 KB und eine mobile Seite 2.311 KB - nur 13 % weniger. Mobile folgt Desktop mit etwa 2 Jahren Verzögerung. Die mobilspezifischen Optimierungen (responsive Bilder, Lazy Loading) kompensieren das allgemeine Wachstum nicht mehr.

Wie reduziere ich das Gewicht einer Webseite?

Die 5 wirksamsten Optimierungen sind: Bilder in WebP oder AVIF konvertieren (25-50 % Einsparung), unnötige Third-Party-Scripts entfernen (je 50-300 KB), Brotli-Komprimierung aktivieren, natives Lazy Loading implementieren und Web-Fonts subsetten. Zusammen können sie das Gewicht um 30 bis 60 % reduzieren.

Beeinflusst das Seitengewicht das Crawl Budget?

Ja. Je schwerer eine Seite ist, desto mehr Bandbreite und Downloadzeit verbraucht sie beim Crawling. Bei einer Website mit 100.000 Seiten bedeutet der Unterschied zwischen 1 MB und 3 MB pro Seite dreimal so viel benötigte Ressourcen. Bei großen Websites setzt die Optimierung des Gewichts Crawl Budget für wichtige Seiten frei.

Welchen Einfluss hat das Seitengewicht auf den CO2-Fußabdruck?

Datentransfer verbraucht auf jeder Stufe Energie: Server, Netzwerk und Endgerät. Eine gängige Schätzung liegt bei etwa 0,3 g CO2 pro übertragenem GB. Eine Website mit 100.000 Seitenaufrufen pro Monat und 5-MB-Seiten erzeugt etwa 150 kg CO2 pro Jahr allein durch den Datentransfer. Das Gewicht deiner Seiten zu reduzieren, senkt diesen Fußabdruck direkt.