Eine schnelle Webseite ist kein Luxus, sondern eine Grundvoraussetzung. Studien zeigen seit Jahren denselben Zusammenhang: Je laenger eine Seite laedt, desto mehr Besucher springen ab, bevor sie ueberhaupt etwas gesehen haben. Doch wie lange braucht eine Seite eigentlich, um zu laden? Die Antwort haengt von zwei Groessen ab, die man gegeneinander aufrechnen muss: der Seitengroesse und der Bandbreite der Verbindung. Dieser Artikel zeigt, wie diese Rechnung funktioniert und wie du daraus ein realistisches Performance-Budget ableitest.
Die Grundrechnung: Groesse geteilt durch Bandbreite
Im Kern ist die Ladezeit einfache Mathematik: Uebertragungszeit = Datenmenge geteilt durch Bandbreite. Wichtig ist dabei, die Einheiten sauber zu trennen. Dateigroessen werden in Bytes angegeben (Kilobyte, Megabyte), Bandbreiten dagegen in Bit pro Sekunde (Mbit/s). Ein Byte besteht aus 8 Bit, dieser Faktor 8 ist die haeufigste Fehlerquelle bei der Schaetzung.
Ein Beispiel: Eine 2-MB-Seite ueber eine 16-Mbit/s-Verbindung. 2 MB sind 16 Megabit. Bei 16 Mbit/s ergibt das theoretisch eine Sekunde reine Uebertragungszeit. In der Praxis kommt Overhead hinzu, dazu spaeter mehr. Genau diese Umrechnung inklusive Bit-Byte-Faktor nimmt dir der Ladezeit Budget Rechner ab: Du gibst Seitengroesse und Verbindungstyp ein und bekommst die geschaetzte Ladezeit.
Bandbreite ist nicht alles: die Rolle der Latenz
Die reine Uebertragungszeit ist nur ein Teil der Wahrheit. Eine Webseite besteht selten aus einer einzigen Datei, sondern aus Dutzenden: HTML, CSS, JavaScript, Bildern, Schriften. Jede dieser Ressourcen muss angefordert werden, und jede Anfrage kostet Latenz, also die Zeit, die ein Signal zum Server und zurueck braucht.
Im Mobilfunk kann die Latenz 50 bis 150 Millisekunden betragen. Bei 50 einzelnen Anfragen summiert sich das schnell zu mehreren Sekunden, ganz unabhaengig von der Bandbreite. Deshalb gilt: Weniger und groessere Dateien laden oft schneller als viele kleine. Techniken wie Bundling, HTTP/2-Multiplexing und das Zusammenfassen von Ressourcen zielen genau darauf ab, die Zahl der Roundtrips zu senken.
Warum man mit der langsamen Verbindung rechnet
Ein haeufiger Fehler ist, die Performance nur auf dem eigenen schnellen Buero-Anschluss zu testen. Die Realitaet der Nutzer sieht anders aus: unterwegs im Zug, im Funkloch, auf einem aelteren Smartphone in einem ueberlasteten Netz. Google und die Web-Performance-Community haben sich deshalb auf eine Referenz geeinigt, die oft als Slow 4G oder frueher 3G bezeichnet wird, mit rund 1,6 Mbit/s und spuerbarer Latenz.
Wenn deine Seite auf dieser bewusst langsamen Verbindung schnell laedt, ist sie auf jeder besseren Verbindung erst recht schnell. Genau deshalb erlaubt der Ladezeit Budget Rechner die Auswahl verschiedener Verbindungstypen, von langsamem Mobilfunk bis Glasfaser. So siehst du auf einen Blick, wie unterschiedlich deine Nutzer dieselbe Seite erleben.
Ein realistisches Performance-Budget setzen
Ein Performance-Budget ist eine selbst gesetzte Obergrenze fuer die Seitengroesse, die du nicht ueberschreiten willst. Ein bewaehrter Richtwert: Die kritische Seite sollte auf einer mittleren Mobilfunkverbindung in unter drei Sekunden interaktiv sein. Rechnet man rueckwaerts, landet man oft bei einem Budget von etwa 1 bis 1,5 MB komprimierter Uebertragung fuer die erste Ansicht.
So teilst du ein solches Budget sinnvoll auf:
- Bilder sind fast immer der groesste Posten. Moderne Formate wie WebP oder AVIF und korrekte Groessen sparen oft die Haelfte ein.
- JavaScript ist doppelt teuer: Es muss geladen und danach auch noch ausgefuehrt werden, was besonders schwache Geraete belastet.
- Schriften blockieren schnell das Rendering. Zwei bis drei Schriftschnitte reichen meist voellig aus.
- CSS sollte minifiziert und idealerweise das kritische CSS inline ausgeliefert werden.
Bevor Dateien ueberhaupt das Budget belasten, lohnt sich das Minifizieren. Mit dem CSS Minifier und dem HTML Minifier entfernst du ueberfluessigen Leerraum und Kommentare und reduzierst so die Uebertragungsgroesse, oft ohne dass du etwas am Inhalt aenderst. Weitere Optimierungswerkzeuge findest du in den Webtools.
Komprimierung nicht vergessen
Ein entscheidender Faktor in der Praxis ist die Transportkomprimierung. Server liefern Textdateien wie HTML, CSS und JavaScript meist gzip- oder brotli-komprimiert aus. Das reduziert die tatsaechlich uebertragene Datenmenge oft um 70 bis 80 Prozent gegenueber der unkomprimierten Dateigroesse. Wenn du die Ladezeit schaetzt, solltest du daher mit der komprimierten Groesse rechnen, nicht mit der Groesse auf der Festplatte. Bilder und bereits komprimierte Formate profitieren davon allerdings kaum, sie sind schon dicht gepackt.
Haeufige Fragen
Warum laedt meine Seite langsamer als die Rechnung sagt?
Die reine Bandbreitenrechnung ist eine untere Grenze. In der Praxis kommen Latenz, langsame Server-Antwortzeiten, Render-Blocking durch CSS und JavaScript sowie Drittanbieter-Skripte hinzu. Tools wie Lighthouse oder WebPageTest zeigen die echte Aufschluesselung mit allen Verzoegerungen.
Zaehlt nur die erste Ansicht?
Die erste Ansicht ist am wichtigsten, weil hier ueber Abspruenge entschieden wird. Aber auch nachgeladene Inhalte beim Scrollen oder Klicken zaehlen zum Gesamterlebnis. Lazy Loading hilft, indem es nur das laedt, was gerade gebraucht wird, und so das Anfangsbudget schont.
Wie haengt das mit den Core Web Vitals zusammen?
Googles Core Web Vitals messen unter anderem den Largest Contentful Paint, also wann das groesste sichtbare Element erscheint. Eine kleine, schnell uebertragene Seite verbessert diesen Wert direkt. Das Performance-Budget ist damit nicht nur eine technische, sondern auch eine SEO-relevante Groesse.