49-MB-Webseite

 (thatshubham.com)
2 Punkte von GN⁺ 2026-03-16 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Artikelseite auf der Website der New York Times erzeugt 422 Netzwerkanfragen und 49 MB Datenübertragung, sodass schon das bloße Lesen eines Artikels übermäßig viele Ressourcen erfordert
  • Während des Seitenladens werden Dutzende Werbegebotsanfragen und Tracking-Skripte gleichzeitig ausgeführt, was Browser-CPU und Akku belastet
  • Dieses feindselige UX-Design führt zu Cookie-Bannern, Abo-Pop-ups, automatisch abspielenden Videos und bildschirmfüllender Werbung, die das Leseerlebnis stören
  • Ein auf „Verweildauer“ und „Sichtbarkeit“ ausgerichtetes Geschäftsmodell zur Maximierung von Werbeerlösen opfert die Erfahrung der Leser, und selbst Ingenieure sind in diese Struktur eingebunden
  • Der Text nennt leichtgewichtige, textzentrierte Nachrichtenseiten (text.npr.org usw.) als Beispiel und betont die Wiederherstellung eines einfachen, respektvollen Web-Erlebnisses, in dem Leser und Geschäft koexistieren können

Die Realität einer 49-MB-Webseite

  • Beim Aufrufen der Website der New York Times entstehen 422 Anfragen und 49 MB Daten, und es dauert 2 Minuten, bis die Seite stabil ist
    • Das ist größer als die Gesamtkapazität von Windows 95 (28 Disketten) und entspricht 10–12 MP3-Songs
    • Um nur ein paar Absätze Text zu lesen, lädt man im Grunde ein ganzes Album herunter
  • Obwohl sich die Hardwareleistung im Vergleich zu früher massiv verbessert hat, neutralisieren werbe- und trackingzentrierte Web-Frameworks diesen Fortschritt

CPU-Last und Tracking-Struktur

  • Nachrichtenseiten führen programmatic Ad-Bidding-Systeme im Browser aus
    • Asynchrone Gebotsanfragen an Rubicon Project, Amazon Ad Systems und andere werden gleichzeitig ausgelöst
    • Der Browser muss mehrere MB JavaScript herunterladen, parsen und kompilieren, was zu Last auf dem Main Thread führt
  • Der Nutzer fordert Text an, aber der Browser verarbeitet zuerst 5 MB Tracking-Skripte, danach werden Anzeigen eingefügt
  • Gleichzeitig laufen Behavior-Tracking-Beacons (POST-Anfragen) und unsichtbare Pixel-Redirects (doubleclick.net, casalemedia), um eine Cross-Site-Identifikation durchzuführen
  • Dieser Prozess verursacht Hitzeentwicklung und Akkuverbrauch auf Mobilgeräten, und Nutzer nehmen unbemerkt an einem Markt für hochfrequenten Datenhandel teil

Feindselige UX und Interaktionskosten

  • Beim Betreten der Seite erscheinen nacheinander GDPR-Cookie-Banner, Newsletter-Abo-Modals und Pop-ups zur Benachrichtigungserlaubnis
    • Nutzer müssen mehrfach klicken und scrollen, bevor sie auf Inhalte zugreifen können
    • Das verstößt gegen die „Interaction Cost“ von NNgroup und das Prinzip des minimalistischen Designs
  • Im Fall von Economic Times können Nutzer erst auf den Haupttext zugreifen, nachdem sie drei Modals geschlossen und ein oberes Banner weggeklickt haben
  • Auch nach Googles Core Web Vitals sind solche intrusiven Interstitials ausdrücklich ein Faktor für SEO-Abwertungen

Instabiles Layout und Anzeigeneinblendung

  • Während Leser einen Absatz lesen, wird nach Abschluss des Ad-Biddings eine iframe-Anzeige eingefügt, wodurch der Text um 250 Pixel verschoben wird
    • Das wird als Cumulative Layout Shift (CLS) gemessen und steht in direktem Zusammenhang mit höheren Absprungraten
  • Google wertet dieses Problem offiziell ab, doch es besteht der Widerspruch, dass die eigenen Werbeprodukte dasselbe Problem verursachen
  • Automatisch abspielende Videos laufen auch nach dem Scrollen weiter, fixiert am unteren Bildschirmrand, und der Schließen-Button ist klein und schwer zu treffen
    • Das wird als Verstoß gegen Fitts’ Law angeführt

Platzverschwendung auf Mobilgeräten

  • Von einem durchschnittlichen mobilen Viewport mit 800 px nehmen Logo, Share-Bar und Browser-UI einen erheblichen Teil ein
    • Tatsächlicher Inhalt macht auf einer Guardian-Seite nur 11 % aus
  • Das Verhältnis von 89 % Werbung und Modals zu 11 % Inhalt erhöht visuelle Ermüdung und die Scroll-Häufigkeit
  • Es gibt auch die Strategie einer „fat-finger tax“, bei der der „X“-Button nahe am Anzeigen-Klickbereich platziert wird, um Fehlklicks zu provozieren
  • Einige indische Nachrichtenseiten wie Jagran behindern den Zugriff auf den Haupttext mit Modals zur App-Installation und Abo-Pop-ups

Vorschläge zur Verbesserung

  • Eine Struktur, die vor dem Anzeigen des Inhalts 3–4 Schließvorgänge erzwingt, verschwendet die kognitiven Ressourcen der Nutzer
    • Pop-ups sollten erst nach 60 Sekunden Verweildauer oder 50 % Scrolltiefe erscheinen
    • Cookie-Einwilligung und Newsletter-Abo könnten in einem nicht blockierenden Abschnitt am unteren Seitenrand zusammengeführt werden
  • Für Anzeigenplätze sollten Container mit fester Höhe reserviert werden, um Layout-Verschiebungen zu verhindern
    • Beispiel: min-height: 250px; background: var(--skeleton-loader);
    • Falls eine Anzeige nicht geladen wird, kann sie mit ResizeObserver nur in einem nicht sichtbaren Bereich verkleinert werden

Die Existenz leichtgewichtiger Nachrichtenseiten

  • text.npr.org, lite.cnn.com, cbc.ca/lite und andere bieten leichtgewichtige Versionen ohne Tracking und Modals an
    • Auch der Nachrichtenkonsum über RSS-Feeds ist weiterhin verbreitet
  • Diese Beispiele zeigen, dass die Nachfrage nach einem einfachen, inhaltszentrierten Web-Erlebnis weiterhin besteht

Fazit: Die Aufmerksamkeit der Leser ist eine Ressource

  • Aktuelle News-UIs betrachten Leser als Zielobjekte zur Bindung und sind darauf ausgelegt, Werbeeinblendungen zu maximieren
  • Doch Rentabilität und Zugänglichkeit können koexistieren, und auch Ingenieure sind mit dieser Struktur unzufrieden
  • Die Wurzel des Problems sind kurzfristige, CPM-zentrierte Geschäftsimpulse
  • Es hat sich ein System gebildet, das die Aufmerksamkeit der Leser als extrahierbare Ressource behandelt, und
    die Nutzung von RSS, das Schließen von Tabs und steigende Absprungraten werden als stärkste Formen des Widerstands dagegen genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-16
Hacker-News-Kommentare
  • Jedes Mal, wenn unsere Entwickler eine Website öffneten, wurden etwa 750 MB verbraucht.
    Als ein Ticket einging, dass der Server langsam sei, haben wir nachgesehen und festgestellt, dass alle Videos der Seite teilweise im Voraus per preload geladen wurden.
    Dass das überhaupt halbwegs funktionierte, lag nur daran, dass das Büro per Glasfaser direkt mit dem Rechenzentrum verbunden war.
    Ich finde, Webentwicklern sollte man keine Netzwerkgeschwindigkeit über 128 kbit geben. Alles darüber hinaus führt nur dazu, dass alles aus dem Ruder läuft.
    • Im Network-Tab von Chromium- oder Firefox-basierten Browsern kann man 3G- oder 4G-Geschwindigkeit simulieren.
      Zusammen mit CPU-Drosselung ist das gut geeignet, um die Performance einer Website unter schwacher Hardware zu prüfen.
    • Die 128-kbit-Begrenzung sollte auch für die Marketingabteilung gelten. Die sind schließlich die Hauptverantwortlichen für Tracking-Skripte.
    • Auch wenn man auf einem schnellen Rechner entwickelt, sollte man auf schwachen Geräten wie einem Chromebook testen.
    • Seiten wie mcmaster.com sind ein gutes Beispiel für sinnvoll umgesetztes kontextabhängiges Prefetching.
      Wenn man mit einem langsamen Entwicklungsserver arbeitet, lernt man ganz automatisch, unnötige Ressourcen zu vermeiden.
    • Früher habe ich das Text-Web wie text.npr.org mit Lyx genutzt.
      Das funktionierte auch in extrem langsamen Umgebungen mit Gopher, Gemini und IRC-basiertem Bitlbee gut.
      Auch Electron-App-Entwickler sollten auf PCs mit 2 GB RAM und altem Celeron testen, erst dann kann man von einer wirklich fertigen App sprechen.
  • Aus Neugier habe ich nytimes.com geöffnet, und die Tracking-Pixel sowie Werbeskripte waren wirklich grauenhaft.
    Nach übertragenem Datenvolumen betrachtet waren aber 36,3 MB von 44,47 MB journalistische Videos.
    Das heißt, weniger die übertriebene Werbung als vielmehr die videolastige Inhaltsstruktur ist das Problem.
    • Trotzdem frage ich mich, warum auf jeder Seite autoplay-Videos sein müssen.
      Dass Nutzer schon vor dem ersten Klick zum Download von 36 MB gezwungen werden, ist schwer nachvollziehbar.
  • In letzter Zeit geht die NYT komplett den Bach runter.
    Wegen der Werbung und der JavaScript-Massen lese ich sie gar nicht mehr. Stattdessen kopiere ich nur die Überschrift und lese den Artikel anderswo.
    Ich surfe grundsätzlich mit deaktiviertem JavaScript und sehe dadurch fast keine Werbung.
    Ohne JS sind Seiten deutlich schneller, und das Risiko von Datenschutzlecks sinkt ebenfalls.
    Ich halte dieses Verhalten nicht für unethisch. Die Websites haben zuerst unfair gehandelt.
    • Leichte News-Seiten wie lite.cnn.com, text.npr.org und newsminimalist.com sind deutlich angenehmer.
    • Die NYT weiß, dass solche Nutzer eine kleine Minderheit ohne Umsatzbeitrag sind.
      Für sie ist es wahrscheinlich sogar besser, wenn diese Leute gar nicht erst vorbeikommen.
    • Die meisten Menschen interessieren sich nicht für JS oder Megabytes.
      Wenn der Inhalt angezeigt wird und funktioniert, reicht ihnen das.
      Die NYT richtet sich an diese „technisch desinteressierte Mehrheit“.
    • Ich frage mich, ob YouTube künftig weiterhin alternative Clients zulassen wird oder ob alles per DRM blockiert wird.
  • Der erste Breitbandtarif meiner Familie im Jahr 2005 hatte ein Limit von 400 MB pro Monat.
    Das grundlegende Problem der Zeitungsbranche ist der Zusammenbruch des werbebasierten Wirtschaftsmodells.
    Früher zahlten Leser im Wesentlichen nur die Druckkosten, der Rest wurde durch Werbung gedeckt.
    Heute holen sich jedoch Facebook Marketplace, Craigslist und andere dieses Werbegeschäft.
    Nachrichten sind dadurch letztlich zu einem Nischenprodukt geworden, und der Verkauf von Leserdaten ist das letzte Aufbäumen.
    • Ich erinnere mich, dass ich 2010 ein 120-MB-Spielupdate heruntergeladen habe und dafür von meinen Eltern Ärger bekam.
      Bei einem Monatslimit von 250 MB ist das heute kaum noch vorstellbar.
  • Die heutige Webentwicklung ist wirklich die Hölle aus Werbung und Tracking.
    Seiten wie HN, auf denen jede einzelne JS-Zeile mit Bedacht eingesetzt wird, wirken fast wie ein Geschenk Gottes.
    Das Web muss wieder weniger aufgebläht werden.
    • Nur weil eine Website den ganzen Speicher belegen kann, heißt das nicht, dass sie es auch sollte.
    • Oft ist die Seite mit Pop-ups und Overlays überzogen, sodass man den Inhalt nicht einmal mehr sehen kann.
      Mit so einer UX kann man doch eigentlich kein Geld verdienen, und trotzdem wird es immer wieder gemacht.
  • Der Vergleich mit der Installationsgröße von Windows 95 (etwa 40 MB) ist witzig.
    Früher galt selbst Win95 als „aufgebläht“, heute sind Webseiten deutlich größer.
    Nicht die Werbung an sich ist das Hauptproblem, sondern Ressourcenverschwendung und Ablenkung.
    Sobald nach dem Aktivieren von JS der Bildschirm anfängt zu flackern und zu lärmen, bin ich sofort weg.
    • Mich interessiert die ökonomische Struktur der Werbeindustrie.
      Ich frage mich, ob ein paar Cent den Frust der Nutzer wirklich wert sind.
      Die meisten Menschen scheinen das einfach gleichgültig hinzunehmen.
      Ich bin ein Entwickler Ende 30 aus der Generation des „freien Internets“ und habe fast keine Geduld mehr für Werbung.
  • Fluggesellschafts-Websites sind besonders schlimm. Bei Air Canada ist selbst ein einfacher Buchungsvorgang mit mehreren MB JS überladen.
    Ich vermisse kommandozeilenbasierte Oberflächen wie das frühere Amadeus-Terminal.
    Ich frage mich, wie das Web wieder stärker auf die Nutzer ausgerichtet werden kann.
    • Die Website von China Southern war die schlimmste.
      Fehlerhafte Feldbezeichnungen, abgeschnittene Placeholder, ein Date-Picker auf Chinesisch
      und nach der Sitzplatzwahl die Meldung „nicht auswählbar“ — die UX war komplett kaputt.
    • Man sollte Entwickler kritisieren, die nur den Trends von Big Tech hinterherlaufen.
      Selbst mit einfachen HTML-Formularen kann man brauchbare Websites bauen.
      Der exzessive Einsatz von JS ist das Ergebnis von Gehirnwäsche.
    • Das heutige Web wirkt oft so, als würde es nur gebaut, um den Lebenslauf von Entwicklern aufzupolieren.
    • Ich denke, wir brauchen neue Erlösmodelle jenseits von Werbeklicks, aber ich kenne noch keine gute Alternative.
  • Schade, dass der Artikel keine DNS-Blocklisten erwähnt hat.
    Ich blockiere mit der Hagezi ultimate list fast alle Werbeanzeigen und feine auf dem Desktop mit uBlock nach.
    Auch Google- und Adobe-Font-Domains blockiere ich direkt, um Geschwindigkeit und Privatsphäre zu verbessern.
    • Ich habe es nicht exakt gemessen, aber es fühlt sich so an, als hätte sich der Traffic auf weniger als ein Zehntel reduziert.
  • Die Entscheidung, auf Websites die Ausführung von Skripten zu erlauben, war der größte Fehler der 90er.
    Es ist grundsätzlich falsch aufgebaut, dass ungeprüfte Programme auf dem Rechner des Nutzers ausgeführt werden.
    Dass Websites ohne JS kaputtgehen, liegt daran, dass Entwickler sie falsch entworfen haben.
    Wären HTML und ausführbarer Code getrennt worden, sähe die Welt deutlich besser aus.
    • Dass man zum Anzeigen von rein lesbarem Inhalt erst ausführbaren Code herunterladen muss, ist absurd.
      Es würde reichen, serverseitig zu rendern und nur das Ergebnis zu senden.
    • Andererseits wollten Nutzer das interaktive Web, also wäre Scripting wohl ohnehin eingeführt worden.
      Eine 49-MB-Seite ist letztlich nur ein Spiegel der Prioritäten.
      In einer Zeit mit allgegenwärtig schnellem Internet bemerken die meisten Nutzer das Problem gar nicht.
  • Ironischerweise laden selbst solche kritischen Beiträge unnötig Third-Party-Ressourcen wie Cloudflare Insights.
    Ich blockiere solche Ressourcen mit uBlock Origin im Hard Mode vollständig.