Eine 14-kB-Seite kann deutlich schneller laden als eine 15-kB-Seite (2022)

• Wird die Größe einer Website unter 14 kB gehalten, kann sich die Ladegeschwindigkeit deutlich verbessern im Vergleich zu 15 kB
• Dieses Phänomen entsteht durch den TCP-Slow-Start-Algorithmus; wegen der Begrenzung der ersten Datenübertragung gibt es einen spürbaren Geschwindigkeitsunterschied
• 14 kB entsprechen bei den meisten Servern der Kapazität von 10 TCP-Paketen, die initial gesendet werden
• In Umgebungen mit hoher Latenz wie Satelliteninternet kann ein zusätzlicher Round Trip (RTT) zu einer Verzögerung von mehr als 612 ms führen
• In der Praxis ist es für die Web-Performance wirksam, die wichtigsten Inhalte unter 14 kB zu halten oder kritische Ressourcen innerhalb der ersten 14 kB zu platzieren

---

Überblick und Grundprinzip

• Dass eine kleinere Website schneller lädt, ist eine bekannte Tatsache
• Weniger offensichtlich ist jedoch, dass beim Sprung von 14 kB auf 15 kB ein gravierender Unterschied bei der Zeit bis zur ersten Antwort entstehen kann
• Zwischen einer 15-kB- und einer 16-kB-Seite ist der Geschwindigkeitsunterschied gering, zwischen 14 kB und 15 kB können jedoch bis zu 612 ms liegen

Was ist TCP?

• Transmission Control Protocol (TCP) arbeitet über IP (Internet Protocol) und ist für die zuverlässige Zustellung von Paketen zuständig
• Ein Webbrowser sendet bei einer HTTP-Anfrage mehrere TCP-Pakete
• Bei reinem IP-Einsatz lässt sich nicht feststellen, ob Pakete angekommen sind, daher stellt TCP die Empfangsbestätigung (ACK) bereit
• Der Server sendet zunächst eine kleine Menge an Paketen und überträgt weitere Pakete, sobald vom Browser ein ACK empfangen wurde
• Bleibt ein ACK aus, wird eine Paket-Neuübertragung ausgelöst

Was ist TCP Slow Start?

• TCP Slow Start ist ein Algorithmus, bei dem der Server die Menge der gesendeten Pakete schrittweise erhöht, um die Qualität der Netzwerkverbindung beziehungsweise die Bandbreite zu ermitteln
• Zu Beginn einer Verbindung sendet der Server nur eine kleine Menge an Paketen, in der Regel 10
• Wenn der Computer des Besuchers ACKs korrekt zurücksendet, wird die Paketmenge verdoppelt
• Fehlen ACKs, werden danach Pakete mit geringerer Geschwindigkeit gesendet
• Der genaue Algorithmus unterscheidet sich je nach Implementierung im Detail, das Grundprinzip bleibt aber gleich

Warum gerade 14 kB?

• Die meisten Server senden im Slow Start 10 TCP-Pakete auf einmal
• Die maximale Größe eines TCP-Pakets beträgt 1500 Byte, nach Abzug des Headers (40 Byte) bleiben 1460 Byte an Nutzdaten übrig
• Daher ist 10 x 1460 = 14600 Byte (etwa 14 kB) die Obergrenze der ersten Übertragung
• Wenn eine Website oder wichtige Ressourcen unter 14 kB bleiben, können sie ohne zusätzliche anfängliche Round-Trip-Verzögerung dargestellt werden; mit Komprimierung entspricht das im Original oft mehreren Dutzend kB

Wie stark kann ein einziger Round Trip verzögern?

Beispiel Satelliteninternet

• Ein typisches Beispiel für eine Umgebung mit hoher Latenz ist Satelliteninternet, etwa für Nutzer auf Ölbohrinseln oder Kreuzfahrtschiffen
• Wenn ein Smartphone eine Startseite anfordert, läuft der Weg über Router → Satellitenschüssel → Satellit im All → Bodenstation → Server; jeder Abschnitt kann mehrere Dutzend bis mehrere Hundert ms dauern
• Der gesamte Übertragungs-Round-Trip umfasst zwei Wege über den Weltraum, Netzwerkstrecken und die Serververarbeitung und verursacht etwa 612 ms zusätzliche Verzögerung
• Bei HTTPS kann sich das durch zusätzliche Handshakes auf 1836 ms erhöhen

Latenz in terrestrischen Netzen

• Auch in mobilen Netzen wie 2G oder 3G treten 100 bis 1000 ms Latenz auf
• Bei Überlastung, Serverengpässen, Paketverlust und in vielen anderen Situationen können zusätzliche Verzögerungen entstehen

Strategien zur Website-Optimierung mit der 14-kB-Regel

• Entscheidend ist, die Website oder Seite so klein wie möglich zu machen
• Ideal ist ein Design, bei dem das komprimierte Übertragungsvolumen jeder Seite unter 14 kB bleibt
  • Mit Komprimierung kann der tatsächliche Inhalt dabei bis zu ~50 kB umfassen
• Das lässt sich oft erreichen, indem automatisch abspielende Videos, Pop-ups, Tracker sowie unnötiges JS/CSS und andere überflüssige Elemente reduziert werden
• Falls sich nicht die gesamte Seite in 14 kB unterbringen lässt, ist es wichtig, kritische Ressourcen und Hauptinhalte in den ersten 14 kB zu platzieren, etwa CSS, JS und den wichtigsten Text
• Auch HTTP-Header (nicht komprimierbar) und Bilder zählen zu diesen 14 kB; bei Bildern sollte nur das Nötigste beziehungsweise der sichtbare Bereich geladen oder ein Placeholder verwendet werden

Ausnahmen der 14-kB-Regel und aktuelle Protokollthemen

• Die 14-kB-Regel ist keine übermäßige Vereinfachung, es gibt aber einige Ausnahmen
  • Manche Server erweitern das Initial Window auf 30 Pakete
  • Über den TLS-Handshake kann unter Umständen ein größeres Window erlaubt werden
  • Die pro Route mögliche Paketanzahl kann zwischengespeichert werden, sodass bei späteren Verbindungen mehr gesendet wird
• Auch bei HTTP/2 bleibt die Praxis meist bestehen, dass Server beim TCP Slow Start mit 10 Paketen beginnen
• Auch für HTTP/3 und QUIC wird die 14-kB-Regel offiziell empfohlen

Zusammenfassung und Referenzen

• Technische Hintergründe und zusätzliche Erläuterungen lassen sich über die jeweiligen Links nachlesen
• Erstveröffentlichung: 2022-08-25, zuletzt aktualisiert: 2022-08-26, Autor: Nathaniel, verwandte Tags: Web-Performance, HTTP, TCP

Weiterführende Links

• Zusätzliche Materialien zu Ethernet-Frames und TCP-Header-Strukturen, zu Latenz und Bandbreite sowie zu TCP-/QUIC-Spezifikationen

[GN⁺]

Hacker-News-Kommentare

• Softwareentwickler sollten sich etwas mehr für die Mediensicht bzw. Transportschicht interessieren, besonders die Punkte des Autors zu Zuverlässigkeit und Latenz bei 3G/5G waren beeindruckend. Bei Funkverbindungen gibt es fast immer Neuübertragungen, und bei den meisten HTTP-Kommunikationen müssen Pakete in der richtigen Reihenfolge eintreffen, damit die UI aktualisiert werden kann. Tatsächlich wird selbst ein einzelner REST-Request nur dann wirklich als ein Paket behandelt, wenn Request und Response jeweils unter 1400 Byte liegen. Darüber hinaus wird ein „einzelner“ Request in Wahrheit auf mehrere Pakete aufgeteilt. Wenn auch nur eines davon Probleme macht, muss alles in Reihenfolge ankommen, damit der Bildschirm korrekt aktualisiert wird. Wer damit experimentieren möchte, kann in den Chrome-Entwicklertools den 3G-Modus und Paketverlust aktivieren; dann sieht man, dass schon eine kleine Optimierung die Reaktionsfähigkeit der UI stark verbessern kann. Deshalb ist es ein überzeugendes Ziel, APIs und UIs so klein wie möglich zu halten

• Meine Homepage hat ein Übertragungsvolumen von 7,0 kB komprimiert

  • /
  • main.css
  • favicon.png
  • Summe 7,0 kB Die Blogliste und die gesamte Website wurden mit meinem eigenen statischen Site-Generator erstellt (offen verfügbar: site.lisp, in Common Lisp geschrieben). Für mathematische Beiträge nutze ich KaTeX mit Client-Rendering, was in diesem Fall weitere 347,5 kB hinzufügt
  • katex.min.css 23,6 kB
  • katex.min.js 277,0 kB
  • auto-render.min.js 3,7 kB
  • KaTeX_Main-Regular.woff2 26,5 kB
  • KaTeX_Main-Italic.woff2 16,7 kB
  • zusätzliche Summe 347,5 kB Ich überlege, KaTeX irgendwann auf Server-Rendering umzustellen. Dieser Blog ist mein persönliches Herzensprojekt seit meiner Zeit im Studentenwohnheim. Ich habe alles selbst geschrieben, von HTML und Templates bis CSS, und achte stets darauf, pro Seite nur das absolut Nötige einzubauen, damit die Größe klein bleibt
  • Meine Homepage
  • Sammlung mathematischer Beiträge
    • Das heißt nicht, dass man nicht einen besseren Ansatz verwenden sollte, aber die Verzögerung beim Laden dynamischer Komponenten wie LaTeX-Darstellung durch Client-Rendering ist für normale Nutzer fast gar nicht oder überhaupt nicht wahrnehmbar. Überoptimierung ist ebenfalls ein Problem. Diese ganze SEO-getriebene Jagd nach Performance bringt bei Services ohne Millionen von Views im Verhältnis zur investierten Zeit nur wenig. Das ist ungefähr so, als würde man ein unbemanntes Boot auf See mit Gezeiten steuern und sich zusätzlich noch über Aerodynamik Gedanken machen. Wenn Ressourcen begrenzt sind und man Gesamtkosten und Nutzen betrachtet, ist Optimierung nicht immer die beste Wahl
    • Wenn es nur wenig mathematische Inhalte gibt, aber man trotzdem KaTeX einsetzen will, könnte man stattdessen weitgehend MathML(mathml-core) in Betracht ziehen
    • Ich verstehe nicht, warum man mathematische Formeln oder LaTeX-Ausdrücke unbedingt per Client-JS rendern sollte. Warum wandelt man sie nicht vorab in HTML/CSS um und liefert sie bereits vorgeneriert aus?
    • Eine Idee wäre, schwere Bibliotheken erst nach dem initialen Rendern der Seite zu laden oder Formelgrafiken nur dann als SVG nachzuladen, wenn sie im Viewport sichtbar werden. Nur meine Meinung

• Das 14-kB-Ziel ist etwas ambitioniert, aber auch die Idee, innerhalb des anfänglichen 10-Paket-Fensters zu bleiben, ist interessant. Ein Projekt, das sich wie ich auf Website-Größe konzentriert, ist 512kb.club. Dort werden Seitengrößen wie Golf-Scores verglichen. Meine Seite(anderegg.ca) kam vor der Registrierung auf insgesamt 71 kB über alle Ressourcen. Durch dieses Projekt habe ich auch Cloudflare Radar entdeckt, das nützliche Tools für Site-Analysen und die Messung von Seitengrößen bietet. Der Hauptzweck ist zwar ein Dashboard für das gesamte Internet, aber ein Tool zur Analyse von Seitengrößen ist ebenfalls enthalten

  • Aus Nutzersicht würde ich gern fragen: Wofür sind die übrigen 500 kB gedacht? Ich brauche zu 90 % nur Text, und der Rest kann ruhig Vektorgrafik sein. Schon mit 14 kB bekommt man eine Menge Text und Grafik unter. Wofür sind also die restlichen 500?
  • 512 kB sind ein realistischer Maßstab. Ich setze diesen Standard auch für meine Website an. Webseiten auf 14-kB-Niveau sind bereits jenseits dessen, was im Web üblich ist
  • Für persönliche Websites sind 512 kB durchaus erreichbar. Mein nächstes Ziel sind 99 kB, also unter 100 kB. Mit ein paar investierten Wochenenden ist das gut machbar. Meine Seite hat bei 512kb den Orange-Status

• Wer damit etwas spielerischer experimentieren will: Die Größe des Initial Window (IW) lässt sich serverseitig setzen. Man kann sie zum Beispiel so anpassen

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 Wenn man danach sucht, findet man Hinweise darauf, dass CDNs heute teils ein Initial Window von 30 Paketen (45 kB) verwenden
  • Vor 13 Jahren galten schon 10 Pakete als „Schummeln“. Siehe dazu hier und den Ben-Strong-Blog (Archiv)
  • Mich würde interessieren, ob es eine Quelle dafür gibt, dass CDNs ein Initial Window von 30 Paketen nutzen
  • Man könnte es natürlich auch einfach wie ein „schlechter Netizen“ auf 1000 Pakete setzen ... der Nachteil wäre nur, dass es bei jemandem mit Einwahlverbindung oder einer Verbindung mit Bufferbloat zum Flaschenhals werden könnte

• Das gilt auch für den folgenden Artikel: Cloudflare-Blog - Russische ISPs lassen nur die ersten 16 KB durch, wodurch die meisten Webzugriffe unbrauchbar werden. Laut der Cloudflare-Analyse drosseln russische ISPs den Internetzugang ihrer Nutzer so, dass pro Web-Asset nur die ersten 16 KB geladen werden

• Die Schnittmenge zwischen Menschen, die nicht wissen, was TCP Slow Start ist, und Menschen, denen Ladeverzögerungen von Websites so wichtig sind, dass sie selbst Mikrooptimierungen betreiben, ist sehr klein. Startups sollten sich zuerst auf das Startup selbst konzentrieren, und nur große Unternehmen können es sich leisten, sich an solchen Optimierungen festzubeißen

  • Wenn man nach dem Muster vorgeht „Wir konzentrieren uns auf die wichtigen Dinge, also haben wir keine Zeit, uns um Performance-Optimierung zu kümmern“, dann wird man sich nie darum kümmern. Deshalb sind heute die meisten Apps und Websites langsam und miserabel
  • Wenn das wirklich stimmen würde, dann müsste Software von Unternehmen wie Microsoft immer perfekt und maximal effizient laufen
  • Konzeptuell klingt das plausibel. Aber wenn Evan Wallace von Figma nicht so besessen von Performance gewesen wäre, wäre Figma nie zu dem geworden, was es heute ist. Manchmal ist „Performance“ selbst ein zentrales Produktmerkmal
  • Das muss keine bewusste Entscheidung sein, man kann es auch einfach zum Standard machen. Sowohl mein Demo mit 1 Milliarde Zellen als auch das Checkbox-Demo[1] nutzen datastar und sind nur etwas über 10 kB groß. In mobilen Netzwerken und bei 3G macht das einen großen Unterschied. In meinen Experimenten dauerten Seiten über 14 kB bei schlechten Verbindungen 3 Sekunden länger. Dadurch, dass sich der datastar-Maintainer sogar um TCP Slow Start gekümmert hat, profitiere ich davon, ohne selbst zusätzliche Arbeit investieren zu müssen
    • checkboxes.andersmurphy.com
  • Ich glaube nicht, dass die Unternehmensgröße viel mit Performance-Optimierung zu tun hat. Im Gegenteil, große Unternehmen sind oft langsamer

• Meine Homepage ist 17,2 KB groß! (ohne Abhängigkeiten) Ich habe meine persönliche Seite wirklich stark optimiert und sogar 100 Punkte in Lighthouse erreicht. Früher hielt ich das für unmöglich, aber ich habe es geschafft. Zur Einordnung: Sie wurde mit Rails gebaut. Solche Optimierungen lohnen sich tatsächlich. Eine Seite, die blitzschnell erscheint und sich nie träge anfühlt, ist als Erfahrung an sich schon äußerst befriedigend

  • Wenn man erlebt, wie sofort news.ycombinator.com lädt, fühlt sich das psychologisch enorm angenehm an, sodass man die Seite in Pausen ganz automatisch öffnet
  • Ich habe den Template-Code für Tausende Websites massiv optimiert und Lighthouse-Werte von 100/100/100/100 erreicht. Auch mobil perfekte 100. Der Initial Load ist deutlich größer als 17,2 kB, eher um 120 kB, aber das Geheimnis ist, alle unnötigen HTTP-Requests zu eliminieren und nur im „above-the-fold“-Bereich JS auszuführen; der Rest wird per lazy eval, defer usw. so weit wie möglich verzögert geladen. JS/CSS ist inline, und selbst Third-Party-Widgets werden per „Facade“-Ansatz mit Popup-Icon usw. zunächst nur vorgetäuscht, sodass der eigentliche Request nach hinten verschoben wird. Auch das SSR-Backend hilft sehr. Sogar mit Vimeo-Hintergrundvideo hatte ich 100 Punkte, mit YouTube war das aber unmöglich. Um perfekte Werte zu erreichen, musste ich die Lighthouse-Ergebnisse interpretieren und die gesamte Codebasis praktisch neu schreiben. Dadurch sind geschwindigkeitsbezogene Kundenbeschwerden komplett verschwunden, und das ist sowohl bei SEO als auch bei den eigentlichen Messwerten ein großer Wettbewerbsvorteil
  • Rails hat mit Render-Optimierung keinen direkten Zusammenhang. Glückwunsch zum perfekten Lighthouse-Score

• Ich finde, der Artikel hat zwei logische Schwächen

  1. Es gibt dort eine Rechnung, nach der das Senden eines Pakets über Satellit etwa 1600 ms dauert, aber als Begründung für die 14-kB-Regel ist das schwach. Es fehlt der Vergleich mit großen Websites, also wird nicht gezeigt, dass 10 Pakete ≠ 16 Sekunden sind
  2. Es heißt, Bilder von Webseiten seien ebenfalls in der 14-kB-Regel enthalten, aber wie oft werden Bilder beim initialen Laden wirklich inline eingebunden? In der Praxis ist das ein sehr seltener Sonderfall, also sollte deutlicher gesagt werden, dass das auf 99,9 % der Fälle nicht zutrifft - „<i>Wann werden Bilder inline eingebunden?</i>“ Zum Beispiel bei niedrig aufgelösten Vorschaubildern, die nur im initialen Viewport erscheinen; dort fügt man ein CSS-Blur hinzu und blendet das echte Bild später asynchron ein. Wenn man es richtig macht, kostet das nur etwa 100–200 Byte zusätzlich. Ich nutze das in meinem Blog, und Plattformen wie WordPress oder Medium setzen es ebenfalls häufig ein. Das ist vor allem ein Trick für hyperoptimierte kommerzielle Frontends - Ich stimme auch nicht der Annahme zu, dass die meisten Nutzer Verbindungen mit niedriger Latenz über Satellit verwenden oder dass gerade meine Seite die einzige wäre, die in einer Welt voller mehrerer Megabyte großer Websites problematisch wäre

• Die heutige Generation neigt dazu, selbst einfache statische Websites mit Frameworks wie Next.js zu bauen. Es macht mich etwas traurig, dass die Zeit von HTML+CSS+js vorbei zu sein scheint

  • Stimme zu. Ich habe selbst schon minimalistische Ressourcen, handoptimiertes JavaScript und Websites nach der 14-kB-Regel gebaut, aber dieser Ansatz führt zu Einschränkungen bei Design und Architektur. Wenn die Funktionen zunehmen, werden all diese damaligen „Minimal“-Entscheidungen zu technischer Schuld. Die meisten romantisieren das „reine Web ohne Framework“, bis sie irgendwann merken, dass es mehr Mühe macht. Mit isomorphen JS-Frameworks kann man jedoch mit statischen Seiten starten, vernünftig optimieren und bei Bedarf zu einem Thick-Client-JS wechseln
  • Tatsächlich verschiebt sich der Trend bereits wieder. Die meisten aktuellen Frameworks unterstützen statische Sites sehr gut. Dinge wie Astro wurden sogar eigens für statische Websites geschaffen
  • Es wirkt so, als würde man das erst jetzt bemerken, aber eigentlich war das schon lange vor dem jQuery-Boom um 2010 so
  • Next.js optimiert Bundle-Code sehr aggressiv und eignet sich gut für Lambdas oder kleine Server-Launches. Auch statische Websites mit Next erzeugen sehr kleine Bundles

• Nicht nur Latenz, auch die Minimierung des Ressourcenverbrauchs ist eine notwendige Bedingung für eine nachhaltige Zukunft. Der Einfluss von Netzwerken auf die Umwelt ist keineswegs gering. Schade, dass der Ton in den Kommentaren etwas spöttisch wirkt. Diese Optimierung ist zwar nicht die ultimative Lösung für alles, aber der Effekt auf den geringeren Energieverbrauch hätte stärker betont werden können

  • Der Großteil des Internetverkehrs besteht aus Videostreaming. Ein paar Megabyte bei Webseiten zu optimieren, fällt da kaum ins Gewicht. Über Effizienz selbst sollte man aber trotzdem diskutieren; zugleich kann der Versuch, alles zu optimieren, Ressourcen von Bereichen abziehen, in denen Optimierung tatsächlich nötiger wäre
  • Das ist nicht einmal Fallobst. Während man daran optimiert, vielleicht 1–2 mWh pro Webseite zu sparen, verbraucht eine einzige Suchmaschinenanfrage 100-mal mehr und ein einzelner Chatbot-Aufruf 10.000-mal mehr. Durch Caching und Lazy Loading wird ohnehin schon einiges abgefedert
  • Sich um die Seitengröße von Webseiten zu kümmern, ist fast vergeudete Mühe. Selbst wenn man den jährlichen Stromverbrauch fürs Websurfen sicherheitshalber verzehnfacht, liegt er immer noch weit unter der Energie, die für die Herstellung eines Hamburgers nötig ist. Für die Umwelt hätte es mehr Effekt, wenn ein Entwickler eine Woche lang statt zu optimieren einen Salat isst
  • Stimme völlig zu. Ich war einmal bei der BBC und war schockiert, als ich sah, dass ein kleiner Textartikel allein 120 MB im Cache belegte. Das fördert eine Kultur unnötiger Energieverschwendung. Ich habe meine eigene Website ebenfalls so minimalistisch wie möglich gehalten und lade Videos auf YouTube nur in 1080P statt 4K hoch. 4K und 8K müssten nicht unbedingt existieren. Oft reden die Leute nur darüber, noch ein paar MW Solarleistung zusätzlich zu erzeugen, aber man sollte sich auch vorstellen, wie gut es wäre, einfach „weniger zu produzieren“. Ich vermisse die kleine Webgröße aus der Zeit der 56K-Modems; irgendwo gab es einmal einen Mittelweg, aber inzwischen sind wir weit darüber hinausgeschossen
  • Den Leuten wird es am Ende erst wichtig, wenn es sie direkt betrifft. Ich selbst achte ebenfalls auf Umweltaspekte. Als Gegenargument wird oft genannt, dass KI noch schlimmer sei, aber in Wahrheit crawlt KI ja auch diese schweren Seiten. Und der 14-kB-Richtwert liegt bei weniger als 1 % der durchschnittlichen mobilen Page-Payload