Als ich Mitte der 2000er Jahre meinen ersten „richtigen“ Job in diesem Bereich hatte, wurde im Webdev-Bereich stark darauf gedrängt, winzige Websites zu bauen (nicht mehr als 100 KB pro Seite), JavaScript nur für Spezialeffekte zu verwenden und sicherzustellen, dass alles – von Bildern bis zu Flash-Inhalten – einen Fallback hat, damit JavaScript-Funktionen progressiv verbessert werden. Wenn kein JavaScript vorhanden war, funktionierte die Website trotzdem zu 100 %, nur eben nicht so schick.
Der Grund für diesen Rat war einfach: In den frühen Tagen des Webs war jeder auf eine Dial-up-Internetverbindung beschränkt, die wirklich langsam war. Mann, es dauerte ein paar Minuten, nur um sich mit dem Internet zu verbinden, geschweige denn, um auf eine Website zuzugreifen. Klickte man auf den „Verbinden“-Button, ging man einen Kaffee holen oder rauchte eine Zigarette, denn es würde buchstäblich ein paar Minuten dauern. In diesem Sinne ist es absolut verständlich, dass die Schlüsselprinzipien des Erstellens einer guten Website Mitte der 2000er Jahre darin bestanden, die Website klein zu halten und solide Fallbacks für Inhalte zu haben.
Diese Zeiten vermisse ich sehr. Meiner Meinung nach haben diese Einschränkungen das Web besser gemacht. Aber im Laufe der Zeit, da die Technologie der Dienstanbieter in den USA mit Breitband (und schließlich Glasfaser) immer besser wird, werden die Einschränkungen nicht mehr als Problem angesehen.
Heute sind die Regeln der Webentwicklung komplett anders. Es geht mehr um die Entwicklererfahrung und weniger um die Benutzererfahrung: Build-Prozesse, die Entscheidung, welches Framework und welcher Tech-Stack verwendet wird, und die Ermittlung, wo die Website in den Google-Suchergebnissen landet. Traurigerweise haben Gatekeeping (d. h. du bist kein echter „x“, wenn du nicht „y“ machst) und Framework-Schlachten die Gespräche über „wie man dieses coole Ding ohne JavaScript macht“ ersetzt. Ich achte nicht wirklich auf diesen Kram, denn am Ende des Tages rendert sich alles im Browser zu HTML, CSS und JavaScript; benutze, was für dich funktioniert.
Was mich aber stört, ist die Tatsache, dass riesige Websites, die JavaScript nur zur Nutzung benötigen, zur akzeptierten Norm geworden sind. Aktuelle Statistiken zeigen, dass Websites durchschnittlich – ein großer Schluckauf – 2 MB pro Seite wiegen?! Und wenn du JavaScript nicht aktiviert hast, sei auf den Schneesturm vorbereitet (so nenne ich Websites, die nur einen weißen Bildschirm anzeigen).
JavaScript ist zu einer dritten Säule des Webs geworden. Ich weiß, dass JavaScript super nützlich ist, warum hacke ich dann darauf herum? Ich hacke darauf herum, dass viele Websites nicht einmal geladen werden können, wenn das JavaScript fehlt. Seit wann hängt das Laden von HTML und CSS von JavaScript ab?
Ich bin kürzlich in eine ländliche Gegend am Stadtrand einer Großstadt gezogen und werde an die frühen Webdev-Tage erinnert, denn ich habe wieder eine schreckliche Internetverbindung auf meinem Mobilgerät. Die Breitbandverbindung ist in Ordnung, aber wenn ich draußen bin oder der Strom ausfällt, bleibe ich mit der gleichen alten langsamen Erfahrung wie zu Dial-up-Zeiten zurück. Wenn ich im Web auf meinem Mobilgerät surfe, lebe ich für den Lesemodus und muss Dinge wie JavaScript (und die meisten Bilder, dank Lazy Loading von JavaScript) ausschalten, weil es zu viel zum Herunterladen und Ausführen ist. Aber indem ich einfach JavaScript ausschalte, laden viele Websites gar nicht mehr. Der weiße Bildschirm des Todes ist nicht das Ergebnis des Sterbens meines Telefons; es ist mein Zugang zum Internet. Und dieser weiße Bildschirm erscheint auf Website nach Website, daher der Schneesturm.
Zum größten Teil komme ich mit meinem WLAN zu Hause zurecht, um notwendige Internetangelegenheiten wie Arbeiten, Einkaufen und Rechnungsbezahlung zu erledigen. Aber Ende des Sommers fiel bei mir der Strom aus. Also ging ich auf die Website des Stromversorgers auf meinem Mobilgerät, um zu sehen, wann der Dienst wieder eingeschaltet wird, denn das gesamte Haus läuft mit Strom und ich muss wissen, ob wir Vorkehrungen für Dinge wie Lebensmittel und Wasser treffen müssen. Aber die mobile Website des Stromversorgers ist groß (3 MB übertragen und 8,6 MB an Ressourcen – autsch) und lädt nicht (selbst mit aktiviertem JavaScript).
Verärgert ging ich zu Twitter und postete meine Empörung.
Ich bekam einige ziemlich tolle Antworten, die mir zeigten, dass einige Websites Einschränkungen wirklich gut bewältigen, wie traintimes.org.uk und die nur-Text-Version von NPR. JA! Warum bieten sie keine reine Textversion der Ausfallseite an, damit die Leute diese Seite der Website nutzen können, wenn sie sie wirklich brauchen, auch wenn die Bedingungen am schlimmsten sind?
Mein Stromausfallszenario ist eine einmalige Situation, aber es gibt Menschen in den USA und auf der ganzen Welt, die mit unzuverlässigem Internet leben, weil es keine andere Option gibt. NPR veröffentlichte einen Artikel, der die Schwierigkeiten beim Unterrichten von Schülern während der Pandemie in Gebieten abdeckt, in denen Gemeinschaften unzuverlässiges Internet haben, und es ist schwer zu glauben, dass dies der aktuelle Stand der Internetverfügbarkeit in irgendeinem Teil der USA ist. Aber Tatsache bleibt, dass es so ist.
Es ist klar, dass viele Menschen von den Einschränkungen der frühen Tage der Webentwicklung profitieren würden. Die Schönheit von Websites, die vor der Verfügbarkeit von Breitbandnetzwerken gebaut wurden (wie die berüchtigte Space Jam-Website von 1996), ist, dass sie auf jedem Gerät von überall unter fast allen Umständen geladen werden können, weil sie mit diesen Einschränkungen im Hinterkopf gebaut wurden. Hoffentlich beginnen alle Entwickler, eine adaptive Ladestrategie anzuwenden, die Lösungen für Benutzer mit langsamen Netzwerken oder Geräten mit geringer Leistung bietet.
Ja! Ich wünschte, das wäre immer noch eine Überlegung.
Wo ich arbeite, wurde die Website von einem externen Unternehmen für das Marketingteam entwickelt und wiegt mit absurden
107 Anfragen,
7,3 MB übertragen,
16,8 Sekunden an meiner normalen Breitbandverbindung.
Amen. Ich erinnere mich, als eine empfohlene Größe für eine Webseite, einschließlich Assets, etwa 35 KB betrug, vielleicht 50 KB für eine Homepage. Die meisten JavaScript-Frameworks sind größer als das. Verdammt, ich habe Icons gesehen, die größer sind als das.
Das könnte von Interesse sein – auch ohne ungewöhnliches Wetter oder Katastrophen hat nicht jeder eine schnelle, günstige Verbindung: https://simonhearne.com/2021/inclusive-design/
Ich habe auch neulich von Leuten gelesen, die nach Katastrophen sehr wenig Bandbreite hatten und dringend Informationen benötigten. Ich glaube, die NPR- und CNN-Websites wurden darin erwähnt. Leider finde ich den Link nicht.
Das andere an solch schlanken Websites ist, dass sie blitzschnell sind, wenn man Bandbreite hat, und typischerweise sehr gut für Caching auf CDNs usw. geeignet sind. Eine 2-MB-Seite voller Bloat braucht immer noch Zeit zum Ankommen (und dann, gerade wenn man denkt, das Laden sei fertig, kommen all die GTM-Skripte, Analysen und der ganze Mist, mit dem Websites vollgestopft sind, an). Und letztendlich bezahlt jemand für diese Bandbreite.
Seit Jahren denke ich darüber nach, wie viel Bandbreite wir im Vergleich zu vor 25 Jahren haben – aber unsere Seiten sind nicht schneller geworden. Vielmehr haben wir sie mit Videos, ineffizienten Bildern, einer Menge CSS, mehr JavaScript-Frameworks, als man vernünftigerweise brauchen könnte, und verfluchten Marketinganalysen aufgebläht.
Sicher, einige dieser Dinge können wirklich nützlich sein; Webanwendungen können so viel mehr leisten, so viel reicher sein – aber es ist nicht zwingend erforderlich, und einige Anwendungen müssen einfach schnell, leicht und effizient sein.
Interessanter Artikel. Obwohl ich damals keinen Code geschrieben habe, glaube ich fest an Funktion über Mode. Eine Seite, auf der der Inhalt nicht einmal geladen wird, ist keines von beiden.
Tolle Einblicke