JavaScript-Aufblähung im Jahr 2024

Das Größenproblem von JavaScript

• Ich war mit der modernen Frontend-Entwicklung nicht besonders vertraut und erinnerte mich an Berichte über Web-Aufblähung, bei denen Web-Seiten mehrere Megabyte groß sind.
• Ich hatte den Eindruck, dass bei einer durchschnittlichen Web-Seitengröße von 3 MB JavaScript-Bundles ungefähr 1 MB ausmachen würden.
• Um zu überprüfen, wie viel es tatsächlich ist, wurde ein Experiment durchgeführt.

Methode

• Verwendung von Firefox unter macOS (dürfte in anderen Browsern ähnlich sein)
• Normaler Modus statt Inkognito-Modus (ich wollte die Zahlen innerhalb der App sehen und hielt das für näher an der realen Erfahrung)
• Alle Erweiterungen deaktiviert
• Nur JavaScript gemessen
• Unkomprimiert
• Service Worker aktiviert (für ein realistischeres Szenario)
• Sämtliches Caching deaktiviert (Laden von Grund auf)

Landingpages

• Beispiel für eine typische Seite mit etwas Interaktion: Wikipedia, 0,2 MB
• Beispiel für eine etwas aufgeblähte Seite: Linear, 3 MB
• Beispiele für schlechte Landingpages: Zoom, 6 MB; Vercel, 6 MB; GitLab, 13 MB

Überwiegend statische Websites

• Einfacher geht es kaum, als eine statische Textwand anzuzeigen.
• Medium braucht allein dafür 3 MB.
• Substack benötigt 4 MB, Quora 4,5 MB, Pinterest 10 MB und Patreon 11 MB.

Suche

• Die Interaktion der App ist größtenteils auf die Suche beschränkt.
• StackOverflow benötigt 3,5 MB, NPM 4 MB, Airbnb 7 MB und Booking.com 12 MB.
• Google braucht 9 MB, um ein einfaches Textfeld und eine Liste von Links anzuzeigen.

App mit einer einzelnen Interaktion

• Google Translate benötigt 2,5 MB für zwei Textboxen.
• ChatGPT benötigt 7 MB für eine Textbox.

Video

• Loom benötigt 7 MB, YouTube 12 MB.
• Pornhub ist eine Site, die auf Performance achtet, und kommt mit nur 1,4 MB aus.

Audio

• SoundCloud und Spotify benötigen jeweils 12 MB.

E-Mail

• Google Mail benötigt 20 MB.
• FastMail bietet dieselbe Funktionalität und benötigt dabei nur 2 MB.

Produktivität

• Todoist benötigt 9 MB, Dropbox 10 MB, 1Password 13 MB und Trello 13,5 MB.
• Discord benötigt 21 MB fürs Chatten.

Dokumentbearbeitung

• Google Docs benötigt 13,5 MB, Notion 16 MB.

Soziale Netzwerke

• Twitter benötigt 11 MB, Facebook 12 MB, TikTok 12,5 MB, Instagram 16 MB und LinkedIn 31 MB.

Riesige Kategorie

• Jira benötigt fast 50 MB, Slack 55 MB.
• react.dev startet zunächst mit 2 MB, kann beim Scrollen aber unbegrenzt weiterwachsen.

Wird es immer schneller schlimmer?

• 2015 lag die durchschnittliche Web-Seitengröße nahe an der Shareware-Version von Doom 1 (2,5 MB).
• 2024 kommt Slack auf 55 MB, was allein an JavaScript der Größe des ursprünglichen Quake 1 entspricht.

Wie groß sind 10 MB?

• 10 MB wirken inzwischen nicht mehr besonders groß oder außergewöhnlich.
• Wenn man im Durchschnitt 65 Zeichen pro Zeile annimmt, werden pro Website ungefähr 150.000 Zeilen Code übertragen.
• Google Maps liegt mit 4,5 MB nach heutigen Maßstäben vergleichsweise bescheiden.

Fazit

• Nicht nur die Download-Größe ist das Problem.
• JavaScript muss vom Browser geparst, im Speicher gehalten und ausgeführt werden.
• Ich bin der Meinung, dass der Inhalt größer sein sollte als der Code.
• GitLab benötigt 13 MB Code und über 500K LoC an JS, um eine statische Landingpage anzuzeigen.

Meinung von GN⁺:

1. Eine realistische Diagnose des aktuellen Zustands der Webentwicklung, die hilft zu verstehen, wie sich die JavaScript-Größe von Websites auf Nutzererfahrung und Performance auswirkt.
2. Eine Erinnerung an Frontend-Entwickler, wie wichtig Optimierung ist, und ein Hinweis darauf, keine Ressourcen über das notwendige Maß hinaus zu verbrauchen.
3. Liefert interessante Daten, die Diskussionen innerhalb der Entwickler-Community über die Performance von Websites anstoßen können.

[GN⁺]

Hacker-News-Kommentare

• Websites für Erwachsene sind tatsächlich ein Beispiel dafür, dass auf Performance geachtet wird; Pornhub lädt nur 1,4 MB Daten. Das ist deutlich besser als die Performance, die manche Tech-Großkonzerne zeigen. Bei grundlegender UI/UX oder der Auslieferung von Inhalten macht Pornhub fast nie Fehler.
• Beim Nutzen von Roaming in ländlichen Regionen Neuseelands war die Web-Erfahrung sehr unangenehm. Auch die Offline-User-Experience (UX) von Spotify muss verbessert werden.
• Es wird die Frage aufgeworfen, warum man überhaupt unkomprimierte Daten betrachtet. Dynamische Apps wie Spotify und Gmail kann man entschuldigen, wenn nach dem Laden der Seite eine schnelle Navigation möglich ist. Manche Websites konzentrieren sich auf das initiale Laden und verschlechtern dabei die User Experience.
• Software spiegelt die Organisation wider, die sie entwickelt hat. Der Großteil der Datenübertragung besteht nicht aus JavaScript, das für die eigentliche Funktion der Seite nötig ist, sondern aus Analytics- und Drittanbieter-Skripten. Marketing-Teams sind sich dessen nicht bewusst oder es ist ihnen egal.
• Es fehlt eine Analyse der Dateigröße von JavaScript-Dateien in Webanwendungen. Google Translate ist zum Beispiel keine einfache interaktive App und enthält viele Funktionen, aber selbst dann sind 2,5 MB immer noch übertrieben.
• Alle Seiten der Website Wordsandbuttons.online sind trotz Animationen und Interaktivität kleiner als 64 KB. Das ist einer Politik ohne Drittanbieter-Abhängigkeiten zu verdanken.
• Man muss nicht nur über die übermäßige Nutzung von JavaScript sprechen, sondern auch über die Menge an Tracking-Skripten.
• Es wird die Menge des auf populären Websites geladenen JavaScripts verglichen. Pornhub lädt zum Beispiel etwa zehnmal weniger JavaScript als YouTube.
• Der aktuelle Zustand des Webs ist sehr traurig. Menschen mit schnellen Internetverbindungen merken nicht, wie langsam das Web geworden ist. Man kann es kaum in Betracht ziehen, keinen Werbe-/Tracker-Blocker zu verwenden.
• Es werden komplexe Frameworks und Abstraktionen gebaut und gepflegt, um die Wartung zu erleichtern, aber viele Entwickler kennen nicht einmal die Grundlagen von JavaScript. Webanwendungen werden übermäßig verkompliziert, und es entstehen zu viele Schichten, die die eigentliche Sprache verbergen. Wenn man JavaScript selbst lernt und statt Frameworks pures JavaScript verwendet, kann man die Größe einer JavaScript-Codebasis erheblich reduzieren.