Die Auswirkungen von Web-Bloat auf Nutzer langsamer Geräte

 (danluu.com)
1 Punkte von GN⁺ 2024-03-17 | 1 Kommentare | Auf WhatsApp teilen
  • Seit 2017 ist die Bandbreite zwar stärker gestiegen als die Übertragungsgröße gewöhnlicher Websites, aber die CPU-Anforderungen von Web-Apps sind schneller gewachsen als die Leistung günstiger Geräte, wodurch sich die Zugänglichkeit des Webs selbst bei schnellem Internet verschlechtert
  • Selbst bei einer 1Gbps-Verbindung kommt es auf dem Tecno Spark 8C in Discourse-Foren zu Browser-Abstürzen, und auf dem Itel P32 werden Websites wie Discourse, Reddit, Shopify, Substack, Wix, Mastodon und Bluesky zu FAIL oder sind praktisch unbenutzbar
  • Gemessen wurden LCP* und CPU-Zeit des Main Threads auf M3 Max, M1 Pro, mit Chrome-10x-CPU-Drosselung, auf dem Tecno Spark 8C und dem Itel P32; die PageSpeed-Insights-Bewertungen korrelierten nur schwach mit der tatsächlich empfundenen Geschwindigkeit
  • Einfache oder ältere Websites wie MyBB, phpBB, altes WordPress, HN und danluu.com funktionierten auch auf günstigen Mobilgeräten vergleichsweise gut, während Websites mit viel dynamischem Nachladen wie Discourse, Medium, Reddit und Substack durch Verzögerungen beim Scrollen, Suchen und Tippen auffielen
  • Nutzer günstiger Geräte in Regionen wie Nigeria, Indien und Lateinamerika sind reale Webnutzer; wenn das Web nur für iOS und schnelles Internet gebaut wird, schließt es nicht nur weniger wohlhabende Nutzer, sondern auch Desktop-Nutzer mit schwacher Hardware aus

Im Web ist nicht mehr die Bandbreite, sondern die CPU der Engpass

  • 2017 schadete Web-Bloat der Nutzbarkeit bei langsamen Verbindungen stark, danach stieg die Bandbreite hochwertiger Verbindungen nach Nielsen mit rund 50% pro Jahr schnell an
  • Es gibt weiterhin viele Nutzer mit langsamem Internet, und ein großer Teil des modernen Webs ist dort schwer nutzbar, aber bei gewöhnlichen Websites übertraf der Bandbreitenzuwachs den Anstieg der Übertragungsgröße zumindest teilweise
  • Dagegen verbesserten sich die CPU-Leistungsanforderungen von Web-Apps nicht im gleichen Tempo, sodass das Web auf schwachen Geräten selbst mit guter Internetverbindung schwer nutzbar wird
  • Ein auf Discourse basierendes „modernes“ Forum kann auf dem Tecno Spark 8C sogar den Browser abstürzen lassen, und die Reaktionsfähigkeit zwischen den Abstürzen wurde als schlechter gemessen als die Nutzung eines BBS mit einem 8 MHz 286 und einem 1200 baud-Modem
  • Die komprimierte Payload zum Laden der Nachrichtentitel in Discourse beträgt 2.6 MB, also etwa 1000x mehr Übertragungsvolumen als früher, ist bei einer 1Gbps-Verbindung aber relativ leichtgewichtig
  • Auf CPU-Seite reicht selbst ein 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) im Tecno Spark 8C nicht aus, um Discourse zu bewältigen; diese CPU ist grob geschätzt etwa 100000x schneller als ein 286

Messobjekte und Kennzahlen

  • Die Testgeräte waren ein M3 Max Macbook (14-core), ein M1 Pro Macbook (8-core), ein per Chrome DevTools auf 10x gedrosseltes M3 Max, ein Tecno Spark 8C und ein Itel P32
  • Für das Netzwerk wurde zugunsten der Geräte 1Gbps-Internet und ein WiFi-Router verwendet, der unter Last eine niedrige Latenz benchmarkte
  • Verglichen wurden Blogs und Microblogs, Foren sowie Plattformen für kleine Unternehmen
    • Blogs und Microblogs: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
    • Foren: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
    • Plattformen für kleine Unternehmen: Wix, Squarespace, Shopify, WordPress
  • Wichtige Kennzahlen waren komprimierte Übertragungsgröße (wire), entpackte Größe (raw), LCP* und CPU-Zeit des Main Threads
  • LCP* ist nicht der von Chrome gemessene Largest Contentful Paint, sondern orientiert sich daran, wann tatsächlich nützlicher Inhalt sichtbar wird, wenn große Bildschirmaktualisierungen für Nutzer wertlos sind
  • Die CPU-Zeit ist kein Core Web Vital, wurde aber als einfache Kennzahl verwendet, die stark mit der auf langsamen Geräten wahrgenommenen Nutzbarkeit zusammenhängt

Die in der Tabelle sichtbare Nutzbarkeitslücke

  • danluu.com und HN liefen auf allen Testgeräten schnell
    • danluu.com: 6kB wire / 18kB raw, auf dem Tecno Spark 8C 0.4s LCP* / 0.3s CPU
    • HN: 11kB wire / 50kB raw, auf dem Tecno Spark 8C 0.5s LCP* / 0.5s CPU
  • Alte PHP-basierte Foren schnitten auf langsamen Geräten deutlich besser ab als moderne Foren
    • MyBB: auf dem Tecno Spark 8C 0.8s LCP* / 0.8s CPU
    • phpBB: 1.7s LCP* / 1.5s CPU
    • vBulletin: 4.4s LCP* / 4.8s CPU
    • Discourse: 15s LCP* / 26s CPU, auf dem Itel P32 FAIL
  • Auch bei Blog-Plattformen war ein altes WordPress-Theme auf schwachen Geräten deutlich schneller als Medium und Substack
    • WordPress(old): auf dem Tecno Spark 8C 0.7s LCP* / 1.7s CPU
    • Medium: 2.8s LCP* / 33s CPU
    • Substack: 14s LCP* / 14s CPU
  • Mehrere moderne Websites scheiterten auf dem Itel P32 oder waren praktisch unbenutzbar
    • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse und Reddit: FAIL
    • Threads: 28s LCP* / 66s CPU, Twitter: 24s LCP* / 43s CPU, Medium: 3.2s LCP* / 63s CPU
  • Seiten mit 10s+ CPU liefern auch nach dem Laden noch eine schlechte Erfahrung
    • Das Scrollen fällt auf wenige FPS zurück, und die Verzögerung bei Tabs ist so groß, dass Nutzer kaum erkennen können, ob ein Tab registriert wurde
    • Tippt man erneut, kann der erste Tab verspätet registriert werden und der zweite anschließend eine unerwartete Aktion auslösen

Unterschiede zwischen echten Geräten und CPU-Drosselung

  • Die CPU-Drosselung in Chrome DevTools ist praktisch, nähert die Ergebnisse realer langsamer Geräte aber nicht konsistent an
  • Beim Vergleich von M3/10 und Tecno Spark 8C unterschieden sich die Websites stark
    • danluu.com und Ghost wurden einigermaßen gut angenähert
    • Medium, Substack und Twitter hatten auf dem Tecno Spark 8C etwa 3x längere CPU-Zeiten
    • Reddit und Discourse waren etwa 4x langsamer
    • Bei Shopify war das Tecno Spark 8C im Ergebnis sogar mehr als eine Größenordnung schneller als M3/10
  • Langsame Seiten können mit langsamerer Hardware überlinear noch langsamer werden, und die Langsamkeit einer Seite sagt die einer anderen oft nicht gut voraus
  • Discourse, Medium und Reddit wirken auf M3 und M1 nicht wie große CPU-Verbraucher, gehören auf dem Tecno Spark 8C aber zu den langsamsten
  • Reddit nutzt selbst ohne jede Interaktion ~90% CPU, weshalb die CPU mit ∞ angezeigt wird

Die Stärken alter Websites und einfacher Seiten

  • Ältere Websites waren im Allgemeinen schneller als neuere, und Websites, die sich optisch seit 10 bis 20 Jahren kaum verändert haben, gehörten zu den schnellsten
  • MyBB war gegenüber Discourse auf dem M3 3.6x / 5x und auf dem Tecno Spark 8C 19x / 33x schneller
  • WordPress(old) wurde gegenüber Medium auf dem M3 Max mit 17.5x / 10x und auf dem Tecno Spark 8C mit 4x / 19x schneller gemessen
  • Ghost ist zwar eine moderne Plattform, die ein Jahr nach Medium veröffentlicht wurde, aber eine Ausnahme mit Leistung, die mit älteren Plattformen konkurrieren kann
  • Auch NodeBB war in den Tests im Anhang fast eine Ausnahme unter modernen Foren
    • auf M1: 0.3s / 0.4s
    • auf dem Tecno Spark 8C: 3.4s / 7.2s
    • deutlich schneller als Discourse, und Scrollen sowie Tippen funktionieren nach dem Laden grundsätzlich

Die Fallen dynamischen Nachladens und der Metrik-Optimierung

  • Websites wie Discourse, Reddit und Substack, die zuerst nur Teile der Seite laden und den Rest dynamisch nachholen, sind in der Praxis noch weniger nutzbar, als es die Tabelle vermuten lässt
  • Auf langsamen Geräten ist die Scroll-Distanz schwer vorherzusagen; scrollt man zu weit, kann weiteres Nachladen ausgelöst werden und die Seite einfrieren
  • Seiten, die bereits gescrollte Inhalte wieder entfernen, sind auf langsamen Geräten praktisch unbenutzbar
  • Bei Seiten mit dynamischem Nachladen lässt sich die schnelle Browser-Suche mit Ctrl/Command+F kaum direkt nutzen, stattdessen muss eine eigene Suche implementiert werden
    • Die Suche in Google Docs lädt seit einigen Monaten oder etwa einem Jahr so spät, dass sie direkt nach dem Laden eines Dokuments kaum nutzbar ist
    • Die Discourse-Suche hat auf langsamen oder auch nur nicht sehr schnellen Geräten nie gut funktioniert
  • Theoretisch könnte hohe CPU-Arbeit beim initialen Laden spätere Interaktionen beschleunigen, aber die getesteten Seiten waren beim Erstladen, beim Nachladen und bei Interaktionen nach dem Laden allesamt langsam

LCP-Gaming

  • LCP soll eigentlich anzeigen, wann der Hauptinhalt einer Seite für Nutzer sichtbar wird, aber die Chrome-Messung liegt näher daran, wann ein großer Paint auf dem Bildschirm stattfindet
  • Manche Websites senken LCP, indem sie schnell einen großen Ladebildschirm anzeigen, der Nutzern nichts bringt, und den eigentlichen Inhalt danach in kleinere Aktualisierungen aufteilen, damit er nicht als LCP zählt
  • Discourse führte Discourse Splash öffentlich ein und erklärte, dass ein großer Splash-Screen bei langsamem Laden den LCP deutlich senke
  • Die offizielle Antwort von Discourse lief darauf hinaus, dass ein Banner mit dem eigentlichen Inhalt für LCP schlechter wäre, wenn es größer als der Splash ist
  • Besonders große Unterschiede zwischen inhaltlich nützlichem LCP* und dem von Chrome gemessenen LCP zeigten sich bei Wix und Discourse
    • Wix: auf M3 6x, auf M1 12x, auf dem Tecno Spark 8C 3x
    • Discourse: auf M3 10x, auf M1 12x, auf dem Tecno Spark 8C 4x

Die Auswirkungen von Performance-Optimierung aufs Geschäft

  • In großen Unternehmen hatte die Verbesserung der Website- und App-Performance einen finanziellen Wert, der sich per A/B-Test messen ließ
  • Auch in langfristigen Holdback-Tests erwiesen sich Performance-Verbesserungen als Eingriffe mit vergleichsweise großem Einfluss auf Wachstum und Bindung
  • Bei Twitter lag die beobachtete p99-Latenz aus Nutzersicht nicht nur in Indien und mehreren afrikanischen Ländern, sondern auch in den Vereinigten Staaten bei etwa 60s
  • In jedem Land gibt es genug Nutzer mit langsamen Geräten oder Verbindungen, sodass der begrenzende Faktor weniger die durchschnittliche Geräte- und Verbindungsverteilung der Gesamtbevölkerung als vielmehr die Geduld der Nutzer war
  • Eine Verbesserung von 60s auf 50s auf langsamen Geräten kann auch bei High-End-Geräten einer Reduktion von etwa 5s auf 4.5s entsprechen und damit Umsatz, Wachstum und Bindung beeinflussen

Für schwache Geräte entwerfen

  • Auf langsamen Geräten oder bei geringer Bandbreite und instabilen Verbindungen ist die Erfahrung meist am besten, wenn viel Inhalt auf einmal als statische Seite geladen wird
  • Geeignete Attribute wie width, height und alt bei Bildern helfen, progressive JPEGs brachten aber keinen besonders großen Vorteil
  • Bei schnellen Verbindungen und langsamen Geräten funktionieren leichte statische Seiten gut; auch leichte dynamische Seiten mit Fokus auf Performance können funktionieren
  • Auf schweren Seiten zerstören zusätzliches Nachladen beim Scrollen und das Abfangen der Suche nutzbare Interaktionsmodelle
  • Bei Substack kann das LCP eines Artikels auf einem iPhone 8 zwar schnell sein, doch zum Scrollen unter den Header muss man teils 6s auf das Laden der nächsten Seite warten und danach nochmals 1s~2s
  • Als Gegenbeispiel funktionieren große Plain-HTML-Seiten auch auf schwachen Geräten vergleichsweise gut
  • Die Dokumentation der Zig-Standardbibliothek lädt den gesamten Quellcode zunächst und rendert lokal, bleibt aber nach 4.7s CPU-Zeit auf dem Tecno Spark 8C noch vergleichsweise reaktionsfähig

Nutzer mit geringem Einkommen und Zugänglichkeit

  • Ein Tecno Spark 8C ist in Nigeria für etwa USD 50-60 und in Indien für etwa USD 100-110 erhältlich, aber gemessen am Medianeinkommen von Haushalten in diesen Regionen ist das deutlich teurer als ein aktuelles iPhone in den USA
  • Weltweit betrachtet ist das Tecno Spark 8C nicht annähernd ein absolutes Billiggerät, und auch das Itel P32 liegt über den tatsächlich genutzten Geräten am unteren Ende
  • Laut Alex Russell liegt der iOS-Anteil in Indien bei 7% und in Lateinamerika bei 6%
  • Laut Windows-Telemetrie nutzen die meisten Laptop- und Desktop-Nutzer wahrscheinlich schwächere Geräte als ein aktuelles iPhone
  • Unter den als „lifeline“ ausgegebenen Mobiltelefonen finden sich zwar auch iPhone 6 oder iPhone 8, aber viele liegen unter dem Niveau des Itel P32; mit kleinen Datenlimits kann nach deren Verbrauch sogar die Jobsuche, das Ausfüllen von Sozialformularen oder die Nutzung von Maps schwierig werden
  • Mobile Apps lassen sich bei guter Verbindung im Voraus herunterladen, aber wenn Web-Apps bei jedem Aufruf mehrere MB komprimiertes JavaScript laden müssen, sind sie über begrenzte Verbindungen nicht nutzbar

Versuchsbedingungen und Grenzen

  • Für jede Website wurde versucht, die möglichst „einfachste“ Erfahrung zu messen
    • WordPress nutzte die Demo des aktuellen Standard-Themes twentytwentyfour
    • Shopify nutzte das erste in der Themeliste sichtbare Theme
    • Für Discourse, vBulletin, XenForo, phpBB und MyBB wurden per Suche gefundene Seiten der offiziellen Foren verwendet
  • Die Arbeit war ein kurzes Projekt mit Datenerhebung und Analyse an einem einzigen Tag und bildet daher weder die häufigsten Themes noch die Verteilung realer Nutzeranpassungen vollständig ab
  • Die Laptops wurden bei etwa 60% Akkustand, ohne Netzteil und in einem 20°C warmen Raum nach Annäherung ans thermische Gleichgewicht getestet
  • Die Mobilgeräte wurden bei etwa 100% Ladestand, am Strom und ohne andere Apps oder Tabs getestet
  • Reale Nutzer werden auf denselben Geräten wegen zusätzlicher Apps und Hintergrundaktivitäten meist noch schlechtere Performance sehen
  • Die Größen wurden auf Mobilgeräten gemessen; wenn mobile und Desktop-Ansichten unterschiedliche Assets laden, spiegeln die Werte daher die mobilen Asset-Größen wider
  • CPU wurde als CPU-Zeit des Main Threads gemessen; Zeiten anderer Threads wurden zwar erfasst, aber nicht als Kennzahl verwendet

Auffällige Einzelfälle pro Website

  • Bei Wix stabilisiert sich das Scrollen auf dem Tecno Spark 8C nicht richtig, und auf dem Itel P32 tritt ein nichtdeterministisches FAIL auf
  • Bei Patreon ist die Scroll-Performance schlechter als die anfänglichen Ladezahlen vermuten lassen; das Auffinden alter Beiträge ist so mühsam, dass dafür ein separates Patreon-Posting-Index geführt wird
  • Bei Discourse ist LCP stark gegamed; selbst bei 1Gbps auf einem M3 Max lag der von Chrome gemessene LCP bei 115ms, während der eigentliche Inhalt erst nach 1.1s geladen war
  • Bluesky zeigt auf dem Itel P32 einen leeren Bildschirm
  • Die ersten beiden realen Shopify-Beispiele waren beide deutlich langsamer als die getestete Demo-Seite
  • Tumblr wirft auf dem Itel P32 einen JavaScript-Fehler, lädt die Seite dadurch aber schneller, und Scrollen sowie Link-Klicks funktionieren
  • MyBB bietet keine mobile Version, was für Google nachteilig sein könnte, aber auf langsamen Mobilgeräten funktionieren Scrollen und Tippen tatsächlich gut
  • Woo Commerce lässt sich anhand der anfänglichen Ladeperformance schwer mit Shopify vergleichen; dafür wäre ein separater Vergleich realer Abläufe wie Warenkorb und Checkout nötig, weshalb es aus der Tabelle ausgeschlossen wurde

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-17
Hacker-News-Kommentare

  • Nachdem ich vor Kurzem ein relativ langsames Android-Smartphone benutzt habe, wurde mir klar, dass selbst Webseiten, die nur aus Text und Bildern zu bestehen scheinen, beim Laden wirklich qualvoll langsam sein können
    Der eigentliche Flaschenhals ist eher nicht das Netzwerk, sondern Tracker, Werbung und aufgeblähtes JavaScript
    Langsame ältere Smartphones führen außerdem dazu, dass schon ein vollwertiger Browser wie mobiler Firefox zu schwergewichtig ist, sodass man zu einem leichten Browser wie Firefox Focus greift, dort aber keine Erweiterungen nutzen kann, also auch kein uBlock Origin, wodurch das Web-Erlebnis noch schlechter wird
    Manche Seiten beschweren sich, wenn man keinen „Standard“-Browser benutzt, und werden unbenutzbar, und Unternehmen drängen stattdessen zur Installation einer App
    Früher gab es vereinfachte Versionen für langsame Geräte und Verbindungen, aber die verschwinden zunehmend, vermutlich weil sich Werbe- und Tracking-Netzwerke ohne aufgeblähtes JavaScript schwerer betreiben lassen

    • Ohne Werbeblocker ist das moderne Web völlig unbrauchbar
      Besonders schlimm ist es, wenn endlos scrollende Seiten mit zufälliger Werbung vollgestopft sind
    • Selbst mit einem Standard-Browser machen Unternehmen ihre Websites manchmal absichtlich kaputt, um Nutzer in die App zu drängen
      Ein aktuelles Beispiel: Der Nike-Webshop zeigte beim Bezahlen einen nutzlosen Fehler an, und der Support sagte nur: „Versuchen Sie es mit der App“
      Auch Buchungsseiten europäischer Fluggesellschaften sind ein Paradebeispiel dafür, wie häufig Websites großer Unternehmen kaputt sind
      Dass man 2024 mit nahezu unbegrenzten Ressourcen keine funktionierende Website bauen kann und darin keinen Markenschaden sieht, ist seltsam
    • Auch diese Apps sind in neun von zehn Fällen wohl nur Browser-Hüllen mit einer teilweise offline gespeicherten Kopie der Website
    • Als ich vor 10 Jahren den Code für die Hauptseite von nokia.com schrieb, haben wir auf verschiedene Arten erkannt, ob das Laden von Ressourcen langsam war, und dann Flags gesetzt, die Zusatzfunktionen deaktivierten
      Es musste in allen Ländern funktionieren, und viele der langsamsten Handys waren Produkte dieses Unternehmens
    • Ich habe immer noch ein MacBook Pro von 2013, weil es die beste Tastatur ist, die Apple je gebaut hat
      Es ist nicht schnell, aber bei der Nutzung von Websites gibt es keine wirklichen Probleme; es reagiert nur nicht so unmittelbar wie neue Hardware und ist dennoch gut brauchbar
      Ich nutze allerdings uBlock Origin
      Ich frage mich, ob diese Android-Geräte in der Praxis wirklich schwächer sind als ein MacBook mit Basisausstattung, das 11 Jahre alt ist

  • Ich stimme Dans Kernaussage stark zu, dass man sich des Ausmaßes globaler Ungleichheit bewusst sein muss, aber dazu sollten auch Länder mit mittlerem Einkommen wie Lateinamerika und Südostasien zählen
    Dort gibt es zum Beispiel Nutzer mit monatlichen Datenlimits im einstelligen GB-Bereich und mit RAM/CPU auf dem Niveau früherer US-Flaggschiffe von vor 10 Jahren
    Discourse ist für sie nicht völlig unbenutzbar, aber das Erlebnis dürfte unangenehm langsam sein
    Ich denke, dass Dan den schrittweisen Verbesserungen bei CPU/RAM/Festplatte vor allem deshalb einen messbaren Einfluss auf die Beteiligung zuschreibt, weil er genau diese Nutzergruppe im Blick hat
    Dans Diagramm zeigt, dass Nutzer von Billigstgeräten wie dem Itel P32 von schrittweiser Optimierung kaum profitieren
    Was helfen könnte, wäre eine völlig andere Client-Architektur, die zugunsten möglichst schlanken Codes Funktionen und Eleganz opfert, also so etwas wie ein alternativer Leicht-/Basismodus
    Allerdings war dieser Ansatz selten erfolgreich, weil hier erneut ein Empathieproblem auftaucht: US-Entwickler entscheiden dann falsch, was man für bessere Performance beibehalten und was man weglassen sollte

    • Ich verstehe nicht, warum das eine „alternative“ Option sein muss
      Ich frage mich, was Discourse heute eigentlich bietet, was PhpBB oder DLang-Foren nicht bieten
      Abgesehen von mobilem Design sollte in einer vernünftigen Welt ein paar Anpassungen an responsivem CSS genügen
    • Ich lebe in einem armen südostasiatischen Land, und Menschen mit kleinen Datentarifen sparen ihr Volumen nicht dank effizienter Websites, sondern indem sie überall Wi-Fi nutzen
      30 GB mobile Daten im Monat kosten 3,64 $, das entspricht etwa 4 bis 6 Stunden zum Mindestlohn
      Wichtiger ist, dass die Leute nicht so verschwenderisch mit Daten umgehen wie im Westen
      In Cafés, Restaurants, Supermärkten und Einkaufszentren gibt es kostenloses Wi-Fi, und die meisten fragen zuerst nach dem Wi-Fi-Passwort statt nach der Speisekarte
      Ich habe nie gehört, dass sich jemand darüber beschwert, Websites würden das Datenvolumen zu schnell aufbrauchen
      Das klingt eher nach einer Sorge, die sich Menschen ausgedacht haben, die nie wirklich in einem Entwicklungsland gelebt haben
      Wenn hier das Datenvolumen aufgebraucht ist, dann wegen Videos auf TikTok, Instagram und Facebook, nicht wegen aufgeblähter Websites
    • Wenn alle Websites effizienter wären, könnte das auch die Lebensdauer von Laptops und PCs verlängern, weil nicht technische Nutzer später an den Punkt kämen, an dem sie denken: „Mein Computer ist langsam geworden, ich brauche einen neuen“
      Dasselbe gilt für Bloatware, die mit Computern vorinstalliert wird
      Ich habe mir vor Kurzem einen neuen Laptop gekauft und mir wurde ein „Tuning“ für 50 $ angeboten
      Wenn ein Neuwagenhändler so etwas anbieten würde, käme einem das seltsam vor
    • Selbst auf einem iPhone von vor einer Generation sind einige dieser Seiten wirklich kaum zu ertragen
      An Orten mit schlechtem Empfang ist das Problem zehnmal schlimmer
      Es geht nicht um komplexe UIs, bei denen man wegen fester Header und Werbung nur ein Drittel des Bildschirms sieht, sondern um die schiere Größe von Websites, die zusammengeklickt wurden, bis sie wie ein Design-Dokument aussehen
      Was selbst bei ordentlicher Umsetzung schon aufgebläht gewesen wäre, wird über eine langsame Internetverbindung unbenutzbar; von langsamer Hardware ganz zu schweigen
      Es ist schwer vorstellbar, wie es sich anfühlt, unter den beschriebenen Bedingungen ins Internet zu gehen, und man kann nur hoffen, dass diese Menschen lokale Seiten nutzen, die auf ihre Bandbreite und ihre Geräte zugeschnitten sind, statt sich mit demselben aufgeblähten Müll herumschlagen zu müssen wie wir
    • Ich lebe in Kanada, hatte ebenfalls einen Datentarif im einstelligen GB-Bereich und habe gerade erst von einem fast 10 Jahre alten Flaggschiffgerät aufgerüstet
      Die meisten Websites kommen Folter ziemlich nahe

  • Interessant ist, dass die meisten nur Vorgesetzte oder furchterregende Großkonzerne verantwortlich machen.
    Entwickler erkennen nicht an, dass es auch eine große Gruppe von unfähigen Webprogrammierern gibt, die Effizienz nicht wirklich verstehen und offenbar auch kein Interesse daran haben.
    So wie Vorgesetzte oder Führungsetagen in Unternehmen, die schlechte Software erzwingen, tragen auch sie Verantwortung für den traurigen Zustand der Websoftware.

    • Ich habe mit solchen Leuten gearbeitet.
      Wenn man sie nach konkreten Aspekten des „Ergebnisses“, also HTML, CSS, JS, fragte, schauten sie einen an, als würde man eine andere Sprache sprechen.
      Sie kamen aus der Welt der JavaScript-Frameworks und hatten sich über das eigentliche Resultat darunter kaum Gedanken gemacht.
      Meine Philosophie ist fast das genaue Gegenteil: Ich frage, was der minimale, noch wartbare Code ist, der das gleiche Ergebnis liefert wie eine von Hand gut geschriebene HTML+CSS+JS-Website.
      Meist wird das Ergebnis um mehrere Größenordnungen kleiner.
      Jemand fragte mich, wie ich 1000 Tabellenzeilen in Echtzeit filterbar gemacht habe und die Seite trotzdem auf Mobilgeräten schnell lädt und gut funktioniert; ich sagte, ich hätte einfach beim ersten Request alle Daten geschickt und dann Daten, die nicht zum Filter passen, dynamisch ausgeblendet.
      Der Webserver musste also nur dieselben gecachten Daten an alle ausliefern, und das war auch schon die gesamte JavaScript-Logik auf der Seite, weshalb es ihnen unnatürlich schnell vorkam.
      In ihrer Framework-basierten Lösung bestanden bei vergleichbaren HTML-Tabellenzeilen 80 % aus Boilerplate, die nie benutzt wurde.
      Webentwicklung ist zu starr geworden, und viele Menschen haben sich zu weit vom Wesen der Webtechnologien entfernt.
    • Vor etwa fünf Jahren habe ich mich bei einem Unternehmen beworben, das Menschen im ländlichen Afrika helfen wollte, die von ihnen produzierten Waren leichter zu verkaufen.
      Wenn die Hauptzielgruppe Nutzer in den USA oder der EU wären, könnte es noch nachvollziehbar sein, Hardware mit schwacher Leistung und instabile Verbindungen mit geringer Bandbreite und hoher Latenz nicht übermäßig zu optimieren.
      Aber wenn ländliches Afrika das Ziel ist, erscheint aggressive Optimierung selbstverständlich.
      Trotzdem lud die Startseite ein riesiges 2-MB-Bild, das per CSS auf 500×1000 Pixel verkleinert wurde, und danach wurde es noch schlimmer.
      An die genaue Größe der JS-Payload erinnere ich mich nicht mehr, aber es waren mehrere MB, und obwohl das meiste wie eine traditionelle templatebasierte Backend-App aussah, war das Frontend extrem schwergewichtig.
      Das Konzept war gut, deshalb habe ich mich beworben, aber die Technik war furchtbar.
      Ich kam nicht einmal zur ersten Interviewrunde, daher weiß ich nicht, warum es so war, aber außer dass west- und nordeuropäische Entwickler in dieser Hinsicht offenbar nicht wirklich begreifen, was sie tun, kann ich mir kaum etwas anderes vorstellen.
    • Aus Sicht von jemandem, der bei einem „furchterregenden Großkonzern“ gearbeitet hat, liegt die Verantwortung zu 100 % bei ihnen.
      Der Ausgangspunkt sind nicht die Entwickler, sondern das Budget.
      Wenn die Führungsebene nicht technikaffin ist oder keinen Engineering-Hintergrund hat, wird für neue Features meist Budget bereitgestellt, während Wartung und Abbau technischer Schulden zu knapp bemessen oder gar nicht eingeplant werden.
      Selbst wenn es ein Wartungsbudget gibt, landet es fast vollständig bei billigeren Offshore-Wartungsteams.
      Ein Feature-Team entwickelt sechs Monate lang Funktionen, macht danach eine einstündige „KT session“ mit dem Offshore-Wartungsteam und übergibt dann den Code.
      Das Offshore-Team hat etwas Wissen über die Features, aber nicht genug, um die bestehenden technischen Schulden zu verwalten, und hält das System im Grunde nur am Laufen.
      Wenn sich dieser Zyklus innerhalb der Organisation 100 bis 1000 Mal wiederholt, dauert es nicht lange, bis ein Frontend mit ursprünglich höchstens 250.000 Zeilen auf 2 Millionen Zeilen anwächst.
      Selbst wenn ein neues Feature-Team mit den besten Ingenieuren besetzt ist, muss es innerhalb der bereits gebauten Kiste arbeiten.
      Wenn Mockups und Elemente nicht zusammenpassen, kann es sein, dass das Mockup falsch ist, das UI-Kit aktualisiert wurde oder das bestehende UI-Kit refaktoriert werden müsste, aber dafür gibt es kein Budget.
      Also wird dem Team gesagt, es solle eine Komponente kopieren und für die eigene Funktion anpassen.
      Auch bei der Übergabe an das Wartungsteam lässt das neue Team die bestehenden Features lieber unberührt.
      Das nichttechnische Management erkennt den Unterschied nicht, und nachdem Teams über Jahre immer wieder Copy-and-paste betrieben haben, um neue Features passend zu machen, gibt es in der Codebasis am Ende mehr als 50 Komponenten namens „Button“.
    • Das ist nicht fair.
      Wenn in einem Team erfahrene Entwickler sitzen, die Effizienz ernst nehmen, kann eine Seite besser werden, wenn sie auf eine effizientere Umsetzung drängen oder sie von Anfang an effizienter bauen.
      Aber meistens ist es ein Problem der Anreize.
      Wenn das Management sich nicht dafür interessiert, werden Programmierer eher dazu neigen, etwas in der halben Zeit einfach nur irgendwie zum Laufen zu bringen und den Backlog weiter abzuarbeiten, statt Zeit in Effizienz zu investieren.
    • Schlechte Websoftware geht meist mit schlechtem Inhalt einher.
      Deshalb sind langsame Geräte ein hervorragender Filter, um Müll zu vermeiden.

  • Ich bin erst kürzlich von einem sechs Jahre alten LG-Flaggschiff auf ein neues Galaxy gewechselt, und der Leistungsunterschied war enorm.
    So sollte es nicht sein.
    Es war zum Erscheinungszeitpunkt ein sehr hochwertiges Gerät, ist noch nicht so alt und funktioniert immer noch wie neu.
    Dass unsere Galaxy-S9-Testgeräte dieselben Schwierigkeiten haben, zeigt, dass es nicht nur an meinem Telefon liegt.
    Ich wünschte, Amazon wäre im Test enthalten gewesen.
    Meiner Erfahrung nach gehört die Amazon-Website auf Mobilgeräten, die älter als vier Jahre sind, zum Allerschlimmsten.
    Selbst auf vergleichsweise neuer Premium-Mobilhardware war es die einzige Seite, die ich regelmäßig besuchte und die nahezu unbenutzbar war.

    • Nachdem ich zwei sieben Jahre alte Geräte mit Snapdragon 835 benutzt habe, habe ich den Eindruck gewonnen, dass RAM und eine aktuelle Android-Version einen großen Unterschied machen.
      Ich nutze ein OnePlus 5 mit Android 14 über LineageOS im Alltag, und die User Experience bei nicht spielbezogenen Aufgaben ist völlig in Ordnung.
      Dieses Telefon hat 6 GB RAM und liegt damit sogar auf dem Niveau heutiger Mittelklassegeräte.
      Mein einziger Kritikpunkt ist, dass ich den Akku austauschen musste und das Zerlegen des Telefons lästig ist.
      Dagegen ruckelt ein Galaxy S8 mit demselben SoC, aber 4 GB RAM und einem angepassten Stock-Android 9 von Samsung, endlos vor sich hin.
      Der Unterschied von 2 GB beim Speicher kann natürlich eine Rolle spielen, aber der Abstand zwischen den beiden Geräten ist wie Tag und Nacht.
      Ich weiß nicht, ob das Memory-Management von Android 14 einfach viel besser ist als das von Android 9 oder ob Samsungs langsame, aufgeblähte Software das Gerät ausbremst.
      In jedem Fall nervt es, dass viele Unternehmen nicht auf älteren oder günstigeren Geräten testen.
      Wenn man Nutzer weltweit anspricht, sollte man bedenken, dass der Großteil der Menschen auf der Welt keine aktuellen Flaggschiffe benutzt.
    • Ich frage mich, ob du bei Amazon einmal JavaScript deaktiviert hast.
      Tatsächlich funktioniert es dann gar nicht so schlecht.
      Natürlich stimme ich zu, dass das überhaupt nicht nötig sein sollte.
    • Ich war kürzlich in Brasilien, dort wurde mir das neue Handy aus der Hand gerissen, und jetzt benutze ich ein vier Jahre altes Ersatzgerät; ehrlich gesagt merke ich kaum einen Unterschied.
      Allerdings nutze ich in Firefox alle möglichen Werbeblocker, und das hilft vermutlich.
    • Ich habe ein Palm Phone, und aus heutiger Sicht ist Web-Browsing damit praktisch unmöglich.
    • Auf einem iPhone 8 mit aktuellem iOS 16 gibt es mit Amazon keine Probleme.

  • Heutzutage ist Technologie sogar gegenüber technisch wenig versierten Menschen viel zu gleichgültig.
    Smartphones sind dafür ein typisches Beispiel.
    Ich habe wirklich viele Menschen gesehen, die ihr eigenes Gerät kaum benutzen können oder praktisch nichts darüber wissen, und auf sie wirkt das alles wie schwarze Magie.
    Das größte Problem ist, dass man sich übermäßig auf Gestensteuerung verlässt, die unsichtbar ist und daher praktisch nicht existiert.
    Die Gestenleiste des iPhone kann man irgendwie noch herausfinden, aber ein Konzept von Mitteilungszentrale oder Kontrollzentrum gibt es nicht.
    Diese Menschen sind nicht dumm; in anderen Bereichen können sie mir weit überlegen sein.
    In der Technik ist nicht mangelnde Anstrengung das Problem, sondern das Fehlen intuitiver Interfaces.

    • Auch dass man beim Kauf eines neuen iPhone keine Dokumentation dazu bekommt, hilft nicht.
      Um überhaupt echte Dokumentation zu sehen, muss man erst die Dokumentationsseiten auf der Apple-Website finden, und mit etwas weiterem Suchen stößt man dann auf eine Seite, die nur ungefähr ein paar Gesten zeigt, die man mit etwas mehr Einarbeitung verwenden kann.
      Wann man welche Geste einsetzen sollte, wird nicht über ein einziges Beispielsätzchen hinaus erklärt.
      Und das betrifft nur das Betriebssystem selbst.
      Ich frage mich, wie viele Apps überhaupt Dokumentation mitliefern, die erklärt, wie Gestenfunktionen in der jeweiligen App verwendet werden.
      https://support.apple.com/guide/iphone/learn-basic-gestures-...
    • Ich habe Menschen mittleren und höheren Alters gesehen, die vermutlich auch mit Kassettendecks nicht umgehen konnten und Schreibmaschinen schwierig fanden.
      Sie sind eindeutig mit solchen Geräten aufgewachsen.
      Deshalb würde ich nicht sagen, dass das allein ein Problem moderner Technik ist.
    • Von außen betrachtet wirkt es so, als würden zumindest die Interfaces der schicken Produkte nach dem Prinzip eine Lösung für alle entworfen.
      Statt den Nutzern die Wahl eines für sie passenden Designs und Interaktionsmodells zu lassen, verhalten sich Designer oder Produktverantwortliche so, als wüssten sie, was für alle Nutzer am besten ist.
    • Das Problem der übermäßigen Abhängigkeit von Gestensteuerung ist kein Smartphone-Problem, sondern speziell ein iPhone-Problem.
      Das war nach meinem Wechsel von Android einer meiner größten Kritikpunkte.
      Wo ist die Zurück-Taste, wo ist die Home-Taste, und wo sind überhaupt die Tasten?
      Ich hasse Apples Besessenheit vom Minimalismus wirklich, und wenn dieses Telefon den Geist aufgibt, gehe ich zurück zu Android.

  • Dieser Artikel ist auf dem Desktop für mich mit 48 Jahren grundsätzlich schwer zu lesen.
    Wenn ich in den Entwicklertools Folgendes zu body hinzufüge, wird er lesbar:
    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    Dann sieht man, wie viel lesbarer und schöner es ist.
    Ich lese viele Texte von Dan Luu, muss sie aber jedes Mal auf diese Weise ändern.
    Im Ernst, Leute aus der Tech-Welt: Um eine Seite deutlich lesbarer zu machen, braucht es nur 64 Byte mehr.

    • Ich bin 53 und hätte seit mindestens fünf Jahren eine neue Brille gebraucht; selbst jetzt sitzt sie auf der Nasenspitze, und manchmal muss ich sogar den Winkel anpassen.
      Die Seite war fast in Ordnung, ich musste nur mit CTRL + hineinzoomen.
      Die Seite ist fast reiner Text und hat kaum Interaktion.
      Du hast eine Lösung, die zu deinem Anwendungsfall passt, und ich habe meine.
      Auch Leser mit Sehbehinderung können mit ihrer eigenen Lösung darauf zugreifen.
      Weil die Quelle einfach ist, bleiben auch die Accessibility-Lösungen vernünftig einfach.
      Ich denke, Dan weiß, wie man effektiv kommuniziert.
      Es einfach zu halten und nicht vorauszusetzen, dass es zwingend visuell gelesen wird.
      Man kann die Darstellung für den eigenen Zweck leicht anpassen.
      Wenn dir diese Darstellungsform nicht gefällt, kannst du sie vor dem Lesen selbst umformatieren.
      Dan liefert seine Botschaft also als einfachen Textstrom, der sich leicht weiterverarbeiten lässt.
    • Ich halte die Änderung für vernünftig, aber wenn Dan Luu diese CSS-Regeln selbst eingebaut hätte, wären hier Kommentare aufgetaucht, die die geringe Informationsdichte und den „übermäßigen Leerraum“ beklagen würden.
      Luus Leserschaft bevorzugt insgesamt wahrscheinlich eher einen relativ stilarmen Ansatz.
    • Stimme nicht zu.
      Nutzer können Fenstergröße, Schriftgröße, Farben usw. nach ihren Vorlieben anpassen.
      Das sollte nicht für jede einzelne Datei immer wieder nötig sein, und es sollte erlaubt sein, eine benutzerdefinierte CSS-Datei hinzuzufügen, die auf mehrere Dateien angewendet werden kann.
    • Wenn die Schrift zu klein ist, kann man die Standardschriftgröße des Browsers ändern.
      Das findet sich auf der Standard-Einstellungsseite von Firefox.
      Wenn eine Website font-size: 18px; erzwingt, kann der Text für Nutzer, die im Browser eine größere Schrift gewählt haben, sogar kleiner werden.
    • Ich stimme zu, dass man ein Minimum an CSS hinzufügen sollte.
      Allerdings kann man auch den Lesemodus des Browsers verwenden; das ist nur ein Klick statt mehrerer Schritte in den Entwicklertools.

  • Zur Einordnung: Auf einem Raspberry Pi 3 kann man YouTube nicht verwenden.
    Das ist erst im letzten Jahr so geworden; davor konnte man Videos mit etwa 10–15 FPS noch irgendwie „anschauen“, und das reichte aus, um in der Werkstatt Reparaturvideos zu sehen.
    Als das Raspberry Pi Model B, also das erste Modell, erschien, konnte man 1080p-Videos aus dem Repository abspielen, YouTube ansehen und sogar Spiele spielen.
    Ich weiß nicht, was YouTube da treibt und was andere Dienste ebenfalls treiben.
    Wenn wir die Klimakrise und den Wandel ernst nehmen, dann müssen wir solche Tricks von Google und Meta sehr streng unter die Lupe nehmen.
    Das Verbrennen von CPU-Zyklen für Profit — meine spontane Vermutung wäre Werbetechnik als Grund dafür, dass YouTube auf stromsparenden Geräten kaputtgeht — sollte in den Medien stark kritisiert werden, und wir sollten effizientere Dienste nutzen, selbst wenn die gesamte Nutzererfahrung schlechter ist.

    • Vielleicht liegt es am Fehlen von Hardware-Videodekodierung.
      Der Pi3 hat x264-Hardwarebeschleunigung, aber YouTube hat schon vor einiger Zeit begonnen, andere Codecs zu verwenden.
    • YouTube wird definitiv immer schwergewichtiger.
      Sogar auf einem Intel-MacBook Air aus dem Jahr 2021 bleiben Videos bei mittlerer Last zufällig stehen; früher ist das nie passiert.
    • Wenn man sich alle Daten ansieht, dann ist der Energieverbrauch der Client-Geräte im Hinblick auf den Beitrag zum Klimawandel fast ein Rundungsfehler.
      Das ausgerechnet dort anzugreifen, um den Klimawandel zu lösen, ist ungefähr so unsinnig wie das Verbot von Plastikstrohhalmen oder Plastiktüten.
    • Zum Navigieren auf der Seite nutze ich Invidious, und die eigentlichen Videos schaue ich mit einem Skript, das die Verschleierung aufhebt, die echte Stream-URL ermittelt und sie dann an VLC übergibt.
      Als weiterer Bezugspunkt: Das YouTube von vor 10 Jahren wäre auf dieser Hardware völlig in Ordnung gewesen.
      Der Schuldige ist die allgemeine Aufblähung des Webs und, noch konkreter, die inzwischen in JS üblichen Abstraktionsmonster.
      Selbst jemandem, der überhaupt nicht an die „Klimakrise“ glaubt, kann man sagen, dass mit der Zeit Handwerkskunst und Qualität verschwunden sind und daraus dieses Chaos entstanden ist.
      Deshalb denke ich, dass das ein Thema ist, dem über das gesamte politische Spektrum hinweg alle zustimmen können.
    • Wir brauchen eine Aufsichtsorganisation, die Seitengröße nach Website und Nutzer überwacht und die Namen öffentlich macht, um die Verantwortlichen zu beschämen.
      Das könnte nach dem Modell von Consumer Reports funktionieren oder als Add-on, das wie Nielsen-Einschaltquoten arbeitet.

  • Diese Person aus dem Discourse-Umfeld ist ein typisches Beispiel dafür, ein Produkt nicht für die Welt zu entwerfen, in der wir tatsächlich leben, sondern für die Welt, von der man sich wünscht, dass sie existiert.
    Es gibt Milliarden Geräte mit Qualcomm SoC, und es wird sie auch weiterhin geben, sie werden weiter hergestellt und verkauft werden.
    Daran ändert sich nichts, egal wie sehr man sich beschwert.
    Man muss das akzeptieren und für diese Geräte optimieren.
    Die Nutzer dieser Geräte interessieren sich nicht für das Gejammer von Entwicklern; wenn die Software abstürzt, halten sie die Softwareentwickler einfach für unfähig.

    • Oder man kann den Weg wählen und sagen: „Das ist nichts für Sie.“

  • Normalerweise mag ich Texte von Dan Luu, aber diesmal fand ich, dass er danebengelegen hat.
    Die LCP/CPU-Tabelle war gut, aber danach driftet es in Sesselpsychologie ab.
    Auf Grundlage einiger zufälliger Kommentare des Discourse-Gründers sollen Leser sich dann die Haltung von Softwareingenieuren ausmalen.
    Sogar Knuth wurde noch mit Verweisen auf Aussagen zu Single-Core- versus Multi-Core-Leistung und zu Itanium herangezogen, obwohl das eher Punkte einer alten akademischen Debatte sind.
    Der Text wirkt zu weich und stützt sich zu sehr auf Internetstreitigkeiten, um wirklich standzuhalten.

    • Aber gibt es diese Haltung nicht tatsächlich?
      Die Aussagen des Discourse-Gründers sind nur besonders aufschlussreich.
      Wenn man das heutige Web benutzt hat, dann sieht man doch, dass es in unvorstellbarem Maß aufgebläht ist, bis zu dem Punkt, an dem Google inzwischen Largest Contentful Paint von 2,4 Sekunden als schnell bezeichnet: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
      Das ist Material von vor vier Jahren, also ist es heute wahrscheinlich noch schlimmer.
      Man muss gar nicht weit schauen: vom Laden von 2,5 MB CSS durch YouTube auf dem Desktop bis dazu, dass der Gründer von Vercel eine Seite als extrem schnell anpreist, die mit nur kleinen Einschränkungen 20 Sekunden zum Laden braucht: https://x.com/dmitriid/status/1735338533303259571
    • Ich habe fast nie erlebt, dass ein Unternehmen Performance ernst nimmt.
      Selbst wenn die Antwortzeit eines einfachen API-Service für das Frontend 500 ms beträgt, wird niemand dafür ausgelacht.
      Ich frage mich auch, wie viele Ingenieure überhaupt wissen oder sich darum kümmern, wie hoch ihre Cloud-Kosten sind.
    • Ich denke, Knuth hatte teilweise recht.
      Die heutige Parallelität wird in 90 % der Software gar nicht genutzt, außer in spezialisierten Anwendungsfällen oder wenn man dasselbe Single-Thread-Programm auf mehrere Datenelemente ausführt.
      Weder Programmiersprachen noch Hardware unterstützen feingranulare Parallelität wirklich gut, und es ist extrem schwer, klassische Software durch parallele Ansätze schneller zu machen.
    • Ich verstehe nicht, worüber hier überhaupt gestritten wird.
      Luu hat im Gegenteil eher ziemlich wohlwollend geschrieben.
      Knuth hat eher darüber geklagt, dass das Gratis-Mittagessen nach Jahrzehnten zu Ende geht.
    • Ich finde, die Zusammenfassung ist ziemlich gelungen.
      Jeff Atwood wurde nur als Beispiel gewählt.
      Prominente Webentwicklungs-Vordenker mit vielen Followern verbreiten fortlaufend ähnliche Ansichten, und viele ihrer Follower übernehmen das einfach so.

  • Allen Unternehmen ist es inzwischen egal geworden, besonders Firmen wie Google und Apple, die früher an der Spitze von Standards und guten Webdesign-Praktiken standen
    Google hat kürzlich HTML Gmail eingestellt, das selbst auf Android-Handys von 2008 mit 256 MB RAM und in altem Firefox schnell und gut lief
    Natürlich bringt die neue aufgeblähte JavaScript-Version den Browser um
    Das ist zwar ein extremes Beispiel, aber günstige Smartphones haben 2 GB RAM, und inzwischen kann man beim Surfen im Web auf solchen Geräten kaum noch vernünftige Leistung erwarten
    Das mobile Web ist miserabel, und das ist Absicht, um Nutzer in „native“ Apps zu drängen
    Denn für Unternehmen wie Apple und Google ist es dann leichter, Daten zu sammeln und Werbung anzuzeigen

    • Teilweise stimmt das sicher, aber wie ist es mit Amazon oder der großen europäischen Sport- und Outdoor-Kette Decathlon?
      Deren Websites sind auf Mobilgeräten furchtbar, und Decathlon ist selbst auf Desktop-Rechnern ohne High-End-Leistung furchtbar
      Dabei drängen sie ihre Apps nicht einmal besonders auffällig auf, also wirkt es eher wie schlichte Inkompetenz
      Es scheint, als würden Entwickler alles nur auf High-End-Geräten mit Backbone-Anbindung testen
    • Am Donnerstag hat Google das einzige brauchbare „Produkt“ beendet
      RIP Google
      Das neue Reddit ist unbenutzbar, und old Reddit ist zu altbacken
      Twitch ist wegen Chat- und Videostream-Problemen gerade noch so benutzbar
      Die Liste wird immer länger
      Wenn man die endgültige Formel bereits hat, dann ist jede Änderung eine schlechte Änderung zur Arbeitsplatzsicherung
      Irgendwann werden diese Affen auf diesem Dreckklumpen erkennen, dass Jobs und Geld nicht existieren, aber dann wird es zu spät sein
      Nein, das ist jetzt
      RIP Humans