JavaScript-Bloat im Jahr 2024
(tonsky.me)- Da es immer häufiger vorkommt, dass Webseiten unkomprimiertes JavaScript herunterladen, das viel größer ist als der eigentliche Inhalt, steigt die Belastung für den Browser – von einfachen Landingpages bis hin zu Business-Apps.
- Die Messung erfolgte mit Firefox auf macOS, deaktivierten Erweiterungen und deaktiviertem Cache; gezählt wurde nur JavaScript, um sich auf die Kosten für Codeausführung ohne Bilder, Videos und Styles zu konzentrieren.
- Wikipedia lag bei 0,2 MB, während selbst einfache Seiten auf mehrere MB bis zweistellige MB-Werte kommen, etwa Linear mit 3 MB, Zoom und Vercel mit 6 MB sowie GitLab mit 13 MB.
- Im App-Bereich zeigte sich zwischen Gmail mit 20 MB und FastMail mit 2 MB ein Faktor 10; besonders groß ist die Codemenge bei Chat- und Arbeits-Tools wie Jira mit rund 50 MB und Slack mit 55 MB.
- JavaScript verursacht auch nach dem Download Kosten für Parsing, Speicherhaltung und Ausführung; eine Architektur, die riesige Code-Bundles benötigt, um kleine Inhalte zu rendern, belastet Performance und Akku direkt.
Messmethode und Vergleichsmaßstab
- Die Messumgebung war Firefox auf macOS; zugrunde lag die Annahme, dass die Ergebnisse auch in anderen Browsern im Großen und Ganzen ähnlich ausfallen.
- Die Bedingungen waren wie folgt:
- normaler Modus, nicht privater Modus
- alle Erweiterungen deaktiviert
- Messung von nur JavaScript
- Basis: unkomprimierte Größe
- Service Worker aktiviert
- Cold Load mit deaktiviertem Cache
- Inhalte wurden vom Vergleich ausgeschlossen, weil sie je nach Website stark variieren.
- Videos bei YouTube und Textnachrichten bei Slack unterscheiden sich ihrer Natur nach stark in der Größe.
- JavaScript wurde als gemeinsame Kennzahl verwendet, um die Komplexität der Interaktion zu vergleichen.
- Entscheidend ist die Arbeitslast, die der Browser zum Parsen und Ausführen des Codes tragen muss.
- Als Referenzpunkt wurde der Blog tonsky.me selbst mit 0,004 MB gemessen.
Landingpages und statische Inhalte
- Bei einem Beispiel für eine normale Seite mit etwas Interaktion liegt Wikipedia bei etwa 0,2 MB.
- Schwerere Landingpages sehen so aus:
- Linear: 3 MB
- Zoom: 6 MB
- Vercel: 6 MB
- GitLab: 13 MB
- Diese Werte beziehen sich ausschließlich auf die Größe des JavaScript-Codes, ohne Bilder, Videos und Styles.
- Auch Websites, die statischen Text anzeigen, laden mehrere MB JavaScript herunter.
- Medium: 3 MB
- Substack: 4 MB
- Quora: 4,5 MB
- Pinterest: 10 MB
- Patreon: 11 MB
- Es gibt Fälle, in denen große JavaScript-Bundles für die Anzeige von Inhalten genutzt werden, die offenbar auch als statische Seite möglich wäre.
Suche und Apps mit einfacher Interaktion
- Suchzentrierte Apps bestehen vor allem aus Query-Eingabe und Ergebnislisten, ihre JavaScript-Größe ist aber nicht gering.
- StackOverflow: 3,5 MB
- NPM: 4 MB
- Airbnb: 7 MB
- Booking.com: 12 MB
- Die Google-Suche wurde trotz eines Bildschirms, der im Wesentlichen aus Textfeld und Linkliste besteht, mit 9 MB gemessen.
- Auch Dienste mit einfacher Eingabe-UI verwenden mehrere MB JavaScript.
- Google Translate: 2,5 MB
- ChatGPT: 7 MB
- Unabhängig davon, dass die Komplexität von ChatGPT auf der Serverseite liegt, werden 7 MB JavaScript an den Browser ausgeliefert.
Medienservices und E-Mail
- Die JavaScript-Größen von Videodiensten lauten:
- Loom: 7 MB
- YouTube: 12 MB
- Pornhub: 1,4 MB
- Bei Audiodiensten wurden SoundCloud und Spotify jeweils bei etwa 12 MB gemessen.
- Bei E-Mail-Diensten gehen die Werte stark auseinander:
- Google Mail: 20 MB
- FastMail: 2 MB
- FastMail verwendet in derselben Kategorie E-Mail-Dienst 10-mal weniger JavaScript als Google Mail.
- Die 20 MB von Google Mail sind ein so hoher Wert, dass er mit Apps wie Figma verglichen wird, die eigenes Rendering in C++/OpenGL enthalten.
Produktivitätstools und Dokumentbearbeitung
- Auch Produktivitäts-Apps haben im Verhältnis zu einfachen Aufgaben viel JavaScript.
- Todoist: 9 MB
- Dropbox: 10 MB
- 1Password: 13 MB
- Trello: 13,5 MB
- Discord: 21 MB
- Dropbox nutzt für Dateilisten in Ordnern, 1Password für Passwortlisten und Trello für die Anzeige von Karten jeweils mehr als 10 MB.
- Dienste zur Dokumentbearbeitung liegen im zweistelligen MB-Bereich.
- Google Docs: 13,5 MB
- Notion: 16 MB
- Dokumentbearbeitung hat schwierige Funktionen wie Cursorbewegung und Synchronisierung, dennoch sind die JavaScript-Größen der Vergleichsdienste weiterhin groß.
Soziale Netzwerke und extreme Beispiele
- Soziale Netzwerke verwenden für Likes, Feeds, Messaging und Ähnliches meist rund 12 MB JavaScript.
- Twitter: 11 MB
- Facebook: 12 MB
- TikTok: 12,5 MB
- Instagram: 16 MB
- LinkedIn: 31 MB
- LinkedIn umfasst Blog, Plattform, Suche, Messaging und Social-Funktionen und wurde mit 31 MB gemessen.
- Sehr große Web-Apps sind fast eine eigene Kategorie.
- Jira: fast 50 MB
- Slack: 55 MB
- Slack ist eine Chat-App, die Nutzerlisten, Nachrichten und Reaktionen verarbeitet, lädt aber 55 MB JavaScript herunter.
- react.dev beginnt anfangs mit 2 MB, beim wiederholten Scrollen wurde jedoch beobachtet, dass JavaScript weiter zunimmt.
- Im Beispiel ließ sich der Wert bis auf 100 MB erhöhen.
- Laut Update wird der eingebettete Code-Editor in der normalen User Experience nach dem ersten Laden im Cache gespeichert, sodass danach kein Netzwerkverkehr mehr sichtbar ist.
- Beim Scrollen können jedoch weiterhin 100 MB JavaScript geparst, ausgewertet und initialisiert werden.
Was 10 MB Code bedeuten
- 2015 näherte sich die durchschnittliche Größe einer Webseite den 2,5 MB der Shareware-Version von Doom 1.
- 2024 erreicht Slack allein mit JavaScript 55 MB, die Größe der gesamten Ressourcen des ursprünglichen Quake 1.
- 10 MB Code wirken inzwischen wie ein normaler Wert, entsprechen bei angenommenen 65 Zeichen pro durchschnittlicher Codezeile aber rund 150.000 Zeilen.
- Da dieser Code bereits minifiziert ist, könnten es bezogen auf den Quellcode mehr als 300.000 Zeilen sein.
- Google Maps gilt als Paradebeispiel einer SPA, wurde aber mit 4,5 MB gemessen und ist nach Maßstäben moderner Web-Apps im Vergleich eher klein.
- Bei Figma ist eine große JavaScript-Downloadgröße als komplexe Frontend-App naheliegend, Gmail liegt jedoch ähnlich hoch wie Figma, LinkedIn beim 1,5-Fachen und Slack beim 2,5-Fachen.
Die Kosten für den Browser
- Das Problem endet nicht bei der Downloadgröße.
- JavaScript muss vom Browser geparst, im Speicher gehalten und ausgeführt werden und erzeugt dadurch laufende Kosten.
- Nach dem Maßstab, dass die Inhaltsgröße größer sein sollte als die Codegröße, ist eine Struktur überzogen, die zum Rendern eines Blogartikels mit 10.000 Zeichen 1000-mal so viel JavaScript benötigt.
- Als gutes Beispiel genannte Sites funktionieren bereits mit 0,1 MB JavaScript ausreichend.
- Im selben Web-Umfeld wird GitLab als Fall gegenübergestellt, der für die Anzeige einer statischen Landingpage 13 MB beziehungsweise mehr als rund 500.000 Zeilen JavaScript benötigt.
1 Kommentare
Hacker-News-Kommentare
Man muss nur Dinge wie 10 MB oder 12 MB mit Pornhub 1,4 MB vergleichen, wo man Performance wirklich ernst nimmt
Porno-Seiten waren schon immer echte Web-Hightech und auch technisch gut umgesetzt, anders als diese scherzhaft als „Tech“-Großkonzerne bezeichneten Firmen
Ich kann mich kaum daran erinnern, dass dort grundlegende UI/UX, die Auslieferung von Inhalten oder vernünftiges Design ruiniert worden wären
Wegen echter Webanwendungen, bei denen ein Seiten-Reload unerwünschtes Verhalten ist, wirkt es plötzlich so, als hätten alle Angst vor dem Aktualisieren einer Webseite bekommen
Ich arbeite seit 20 Jahren mit Unternehmensanwendungen und habe sogar Systeme gesehen, die vor meiner Geburt gebaut wurden; für solche Systeme war React meiner Meinung nach das beste Frontend, um die früheren furchtbaren Client/Server-UIs zu ersetzen
Angular/Vue usw. sind im gleichen Kontext zu sehen. Für normale Webseiten ist das aber fast nie nötig, außer in Fällen wie Gmail oder Facebook, wo Interaktion und Echtzeit-Aktualisierung der Kern des Produkts sind
Für Seiten wie Pornhub reicht auch PHP völlig aus, und für die meisten Webseiten gilt das ebenso. Man sieht es schon daran, dass viele Leute immer noch HN oder old.reddit.com bevorzugen, und ich denke, viele würden auch old.Facebook dem inzwischen langsameren neuen Facebook vorziehen
Pop-ups, Pop-unders, Weiterleitungen auf ähnliche Aggregator-Seiten mit Fake-Content, das Öffnen von Affiliate-Seiten statt des eigentlichen Inhalts, das Verschmutzen von Suchergebnissen und solche Dinge
Pornografie ist nicht so stark eine technologietreibende Branche, wie oft behauptet wird; auch die Betamax-gegen-VHS-Stadtlegende stimmt nicht, und die Behauptung, sie habe Internet-Innovationen angeführt, ist übertrieben
Es gibt einige Akteure, die hochwertige Produkte bauen, aber sie stehen nicht für die ganze Branche. Es gibt viele Linkfarmen, Dummy-Inhalte, Kopierseiten, irreführende Werbung und Manipulation von Suchergebnissen
Dass die Top-Seiten heute schnell sind, scheint mir ein Ergebnis des Wettbewerbs zu sein. Wenn die UX schlecht ist, gibt es mehr als genug kostenlose Pornoseiten, zu denen Nutzer sofort wechseln, also muss für Bindung optimiert werden
Andere Webseiten haben andere Anreize wie Aktionäre, Inhaltsanbieter, Exklusivverträge oder Monopolstellungen und müssen die Nutzererfahrung daher nicht im gleichen Maß optimieren
Man verbringt unzählige Stunden damit, alles Mögliche zu optimieren: Video-Auslieferung, Livestreams (früher Flash, heute WebRTC), Seitengröße usw.
Ich frage mich, warum hier auf unkomprimierte Daten geschaut wird. Selbst einige der als schlechte Beispiele genannten Seiten werden komprimiert leicht kleiner als die 1,5 MB von GMaps
Dynamische Apps wie Spotify oder GMail sind meiner Meinung nach okay, wenn die Navigation nach dem Laden der Seite schnell ist
So etwas wie Discord, das beim Start ein paar Sekunden für Updates braucht, ist besser als GitLab, wo man bei jedem Klick bis zu 2 Sekunden warten muss
Ich denke, der heutige Fokus auf Cold Starts und statisches Rendering verschlechtert bei manchen Seiten die Erfahrung eher
Wenn man testweise den Dateibaum auf GitHub durchsucht, ist dieser auf meinem Gerät deutlich flotter als andere Teile von GitHub. Zufälligerweise ist das einer der fast einzigen Bereiche dort, die nicht statisch gerendert sind
Ich klicke jeden Tag auf Hunderte von GitHub-Seiten; statt mir jedes Mal den kompletten Footer neu zu schicken, nur um eine Pipeline anzusehen, hätte ich lieber einmal eine riesige Menge JavaScript und dann so viel Caching wie möglich
[1]: GMail und Spotify sind nur Beispiele, ich nutze sie tatsächlich nicht
In Diskussionen über Accessibility kommt das oft vor, weil die CPU-Leistung zwischen iOS und Android stark auseinandergeht und es bei günstigen Geräten, die von der Masse genutzt werden, sogar vorkommen kann, dass ein heute verkauftes neues Android-Gerät langsamer ist als ein iPhone von 2014
Wenn Entwickler nur aktuelle iPhones oder Flagship-Androids nutzen, übersehen sie leicht, wie stark Code-Bloat durchschnittliche Nutzer trifft
https://infrequently.org/2024/01/performance-inequality-gap-...
Caching senkt zwar die Energie- und Zeitkosten für Download und Dekomprimierung, beseitigt aber nicht die tatsächlichen Nutzungskosten
Meine persönliche Faustregel ist: Je größer das unkomprimierte JavaScript, desto mehr Code läuft weiter auf der CPU, wenn man die Maus bewegt, eine Taste drückt oder scrollt
Ich verzichte lieber auf etwas Zeiteffizienz und bekomme dafür bessere Energieeffizienz; wo es durch CSS ersetzt werden kann, bevorzuge ich statisches Verhalten gegenüber hübschen Effekten
Oder das noch größere Problem könnten Seiten sein, die auch bei vielen anderen Aktionen als einem Klick auf eine URL, die auf eine andere Seite führt, weitere Dateien nachladen. Das ist versteckter Bloat und auch sehr schlecht für die Archivierung
Ich wünschte, Seiten würden nicht mit JavaScript eine andere „Seite“ anzeigen, während die URL in der Adressleiste gleich bleibt. Auch das ist wirklich schlecht für die Archivierung
Eine weitere Faustregel ist: Je größer das unkomprimierte JavaScript, desto geringer die Wahrscheinlichkeit, dass eine archivierte Version der Seite korrekt funktioniert
Letzte Woche war mein Internet langsam, und wenn ich auf der GitHub-Webseite auf Dateien klickte, scheiterte das skriptgesteuerte Laden, sodass der Dateibaum buchstäblich nicht funktionierte
Wenn ich stattdessen die Datei-URL kopierte und in die Adressleiste des Browsers einfügte, wurde sie korrekt geladen
Spotify hat große Probleme mit der Netzwerkkonnektivität. Selbst wenn man ein Album heruntergeladen hat, gerät es bei einem Netzwerkwechsel komplett in Panik. Ein simpler Offline-Modus wäre besser, als ständig online bleiben zu wollen
Daran die gesamte Architektur zu beurteilen, ist schwierig; das ist ähnlich, wie auf eine sehr schlechte SPA zu zeigen und daraus abzuleiten, dass alle SPAs schlecht seien
Alle Software spiegelt die Struktur der Organisation wider, die sie gebaut hat
Der Großteil der übertragenen Daten ist wahrscheinlich nicht das JavaScript, das für die eigentliche Funktion der Seite nötig ist, sondern Analytics-Tools und allerlei Third-Party-Skripte
Nur die Kategorie „elephant“ würde auf Lazy-Loading-Module wie React entfallen
Ein erheblicher Teil davon wird von Marketing-Teams vorangetrieben, die dieses Problem entweder nicht kennen oder sich nicht darum kümmern
Entwickler hängen oft nur Google Tag Manager oder andere Dienste zum Einschleusen von Skripten an die Seite. In manchen Fällen tun nicht einmal das die Entwickler, sondern ein Proxy der Betriebsinfrastruktur verändert die Seite
Die bedeutsamere Sorge könnte sein, dass Marketing mehr Kontrolle über das Ergebnis hat als die Leute, die die eigentliche Arbeit machen
Bei „elephant“-Seiten liegt die Aufblähung in der Organisation selbst. Das Problem sind nicht ein paar Idioten, sondern skalierte Idioten
In meinem früheren Job lag Google Tag Manager in den Händen nichttechnischer Abteilungen, und wir mussten den Müll, der in Produktionsseiten injiziert wurde, ständig überwachen
Ich habe wirklich hart dafür gekämpft, ihn loszuwerden
Die Google-Suche war so im Vergleich zu Yahoo, und Chrome war es bei seinem Start im Vergleich zu IE/Firefox ebenfalls
Chrome selbst hatte fast keine UI, und genau das war ein Feature
Ich bin gerade von einem Roadtrip durch Neuseeland zurück, und in weiten Teilen des ländlichen Raums gibt es kaum oder gar keinen Mobilfunkempfang
Mit Roaming fühlt es sich noch einmal eine Schicht langsamer an, daher war es wirklich schwer, einen großen Teil des Webs zu nutzen
Falls es einen Spotify-PM gibt, sollte er sich bitte die Offline-UX ansehen. Offline ist eines der Kernfeatures von Premium, aber wenn man die App tatsächlich offline nutzt, ist sie in vieler Hinsicht einfach miserabel
Wenn Spotify glaubt, dass Internet vorhanden ist, fragt es den Server nach allen Inhalten der Kontextmenüs, wartet dann mehrere Sekunden auf eine Antwort und gibt manchmal die Anzeige des Menüs ganz auf, manchmal fällt es auf eine Aktion zurück, die im Offline-Modus sofort funktioniert hätte
Ich hasse diesen Player wirklich
In einem Zwischenzustand mit sehr hoher Latenz oder vielen Paketverlusten sollte es sich praktisch wie offline verhalten, aber Spotify glaubt, online zu sein
Solche Probleme sind allerdings sehr verbreitet, und nicht nur Spotify scheitert daran; den richtigen Schwellenwert festzulegen dürfte schwierig sein
Ich verstehe nicht, warum Spotify mich bei fehlendem Signal 30 Sekunden warten lässt, bis die App irgendetwas lädt. Ich will einfach nur weiter einen heruntergeladenen Podcast hören
Ich frage mich, welche Engineering-Entscheidung die Gewichtung solcher Szenarien so kompliziert gemacht hat
Dieser Artikel verfehlt vor allem völlig, dass er nicht aufschlüsselt, warum JavaScript-Dateien gerade in echten Webanwendungen so groß sind
Google Translate ist zum Beispiel bei näherer Betrachtung keine App, mit der man einmal interagiert und dann fertig ist. Es gibt Wörterbuch, Alternativvorschläge, Transliteration, Aussprache, mehrere Eingabemethoden usw.
Selbst wenn man das berücksichtigt, sind 2,5 MB zu groß, und einige optionale Funktionen könnten und sollten lazy geladen werden, aber der Artikel ist im Moment zu oberflächlich, um für eine tiefere Diskussion besonders hilfreich zu sein
Wie viel JavaScript braucht man schon für
if data.transliteration show icon with audio embed?Ich verstehe es, weil die Bilder groß und zahlreich gewesen sein könnten, aber es war ein wenig ironisch
Ich verstehe, dass die Implikation hier „zu viel JavaScript“ ist, aber man sollte auch darüber sprechen, wie viel davon reiner Tracking-Müll ist
Noch schlimmer ist, dass manche davon nicht an den Host-Code gebunden sind, sondern extern geladen werden, was Latenz und potenzielle Sicherheitsrisiken erhöht
Es war ein Tool, mit dem Marketer ohne Eingriff von Entwicklern jeden beliebigen Müll in die Webanwendung injizieren konnten
Die Beziehung hat auch etwas darunter gelitten, ich habe nicht gewonnen, und die Performance ist immer noch miserabel
Danach folgen als Performance-Probleme schwere Bibliotheken für Karten und Diagramme, die sich normalerweise mit intelligentem Lazy Loading lösen lassen
Was ich selbst erlebt habe: eine sehr kleine Funktion, die beim Start trotzdem eine QR-Code-Scan-Bibliothek und eine Kartenbibliothek lud; alle Internationalisierungs-Strings wurden beim Start in einer Kaskade angefragt, sodass noch vor der Ausführung irgendeines JS blockiert wurde; Zendesk hat die Seitenperformance komplett ruiniert, aber wegen einer Anweisung von oben konnten wir es nur lazy laden
Danach kommt schlecht entworfener Code, der zu viele DOM-Elemente, Re-Renders oder kaskadierende Requests verursacht
Erst danach kommt die Größe des App-Level-Codes, und auch das lässt sich mit Lazy Loading beheben, ist aber normalerweise nicht nötig, bevor die Anwendung wirklich riesig wird
Zum Beispiel sinkt die GitLab-Landingpage von 13 MB auf „nur noch“ 6 MB, wenn man Tracking-Skripte blockiert
Marketing-Abteilungen werden Software-Bloat immer verdoppeln
Ein Vergleich dazu, wie viel JavaScript beliebte Websites beim Cold Load laden. Die wichtigsten Punkte sind folgende:
PornHub lädt etwa 10-mal weniger JS als YouTube (1,4 MB gegenüber 12 MB).
Gmail hat einen kaum nachvollziehbar großen Footprint (20 MB). Fastmail ist mit 2 MB zehnmal schlanker, und Figma ist trotz der komplexeren App ähnlich bei 20 MB.
Jira ist mit 58 MB geradezu absurd groß.
Jira wird nach dem ersten Download bis zum nächsten Update wohl lokal wie eine Offline-App geladen.
Pornhub wird wahrscheinlich im Inkognito-Modus genutzt, daher hilft Caching nicht.
Jira ist ebenfalls furchtbar und langsam.
Alle Seiten auf https://wordsandbuttons.online/ sind trotz Animationen und Interaktionen immer noch unter 64 KB groß.
Zum Beispiel hat diese Seite https://wordsandbuttons.online/trippy_polynomials_in_arctang... 51 KB.
Der Code ist dabei überhaupt nicht sparsam. 80 % sind Copy-and-paste mit kleinen Variationen, und es gibt keinen Versuch, ihn clever zu verkleinern. Alles ist altes Vanilla-JS, ohne Kompression und ohne Minifizierung.
Öffnet man es mit „View page source“, ist der Code vollständig lesbar.
Das Geheimnis ist eine Null-Abhängigkeiten-Politik. Es gibt weder Third-Party- noch interne Abhängigkeiten. Der gesamte benötigte Code kommt zusammen mit der HTML-Datei.
Paradoxerweise ist Copy-and-paste langfristig nicht die Ursache von Bloat, sondern ein Schutz dagegen.
Auf Mobilgeräten sind die Ränder buchstäblich nicht sichtbar.
Abhängigkeiten sind nicht die Ursache, sondern das Symptom. Websites und Unternehmen haben einfach keinen Anreiz mehr, Bloat zu reduzieren, daher werden doppelte Abhängigkeiten kaum noch bereinigt.
Das erinnert mich an den Artikel The Website Obesity Crisis von 2015 [1]. Seitdem ist die Lage [2] noch schlimmer geworden, und es sind schon fast 10 Jahre vergangen.
Ist es wirklich so abwegig zu sagen, dass in weiteren 10 Jahren das Web auf PCs etwa aus dem Jahr 2015 nicht mehr benutzbar sein wird? Wenn sich nichts ändert, sieht es genau danach aus.
Selbst mit aktuellem Firefox auf einem alten MacBook von 2013 kommt man mit den 23,98 MB JavaScript der Seite https://civitai.com nicht klar; beim Versuch, dieses katastrophale Web-Frontend zu rendern, friert alles etwa 30 Sekunden lang ein.
Das ist nicht nur ein Web-Problem. Auch mobile All-in-one-Apps sind so groß geworden, dass sie auf einem Smartphone von 2013 genauso wenig laden, und die Hälfte davon ist ohnehin auf einem Web-Stack aufgebaut.
Ich verstehe nicht, warum Unternehmen mit großem Budget es sich angeblich nicht leisten können, native Anwendungen zu nutzen.
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Der Zustand des Webs ist wirklich traurig.
Die meisten Menschen mit Glasfaseranschluss merken gar nicht, wie langsam das Web geworden ist.
Aber wenn man noch mit einer 2-Mbit/s-Verbindung unterwegs ist, ist es wirklich grauenhaft. Ich bin in genau so einer Situation, und es ist schmerzhaft.
Deshalb ist es völlig undenkbar, keinen Werbe-/Tracking-Blocker zu verwenden.
Ich würde diesen Test gern mit aktiviertem Ublock Origin sehen.
Der Großteil dieses Codes dürfte wohl für Nutzer-Tracking und Werbeverwaltung da sein.
Ich verstehe nicht, warum man glaubt, dass wir uns nicht weiter darauf konzentrieren sollten, Apps und Websites kleiner zu machen, nur weil wir bessere und schnellere Computer und Netzwerke bekommen haben.
Dank Moore’s Law konnten Entwickler schneller vorankommen, dabei Optimierung opfern und immer mehr draufpacken, und solche Fälle sind die Folge.