Das Web ist gewachsen. Sowohl in seiner Weite als auch in seinem Gewicht. Nick Heers „The Bullshit Web“
Die durchschnittliche Internetverbindung in den Vereinigten Staaten ist etwa sechsmal schneller als vor zehn Jahren, aber anstatt damit die gleichen Arten von Websites schneller zu durchsuchen, füllen wir diese zusätzliche Bandbreite einfach mit mehr Zeug.
Nick erklärt klar, was er unter Bullshit versteht, und man kann eine Verbindung zu Brad Frosts ähnlich formuliertem Argument sehen. Nick spricht darüber, wie jede inkrementelle Interaktion eine Wahl ist und verbindet den Krempel des Webs mit dem Aufkommen und der Einführung von Frameworks wie AMP.
Ethan Marcotte beleuchtet die Dinge aus einem anderen Blickwinkel, indem er Anreize für Unternehmen betrachtet
...letztendlich ist das Performance-Problem des Webs ein Profitabilitätsproblem. Wenn wir über aufgeblähte Seiten sprechen wollen, sollten wir dies im Kontext tun: im Kontext eines Webs, in dem die Einnahmen aus digitaler Werbung für Publisher einbrechen, aber für Facebook und Google geradezu florieren. Wir sollten die zugrundeliegenden strukturellen Probleme betrachten, die ein Unternehmen dazu anregen, schwere Werbeskripte und lästige Overlays einzubinden, oder die Marktbedingungen untersuchen, die einen Publisher zwingen, etwas wie AMP zu übernehmen.
Mit anderen Worten: Die Art und Weise, wie wir über langsame Websites sprechen, muss viel, viel breiter sein. Wenn wir das tun können, werden wir ein schärferes Verständnis dafür entwickeln, wo – und wie – das Web schneller sein kann.
Es ist ein systemisches Zustand der Branche-Problem, das langsame Websites hervorbringt. Der kulturelle Kampf, dies zu beheben, ist vielleicht genauso wichtig wie die technischen Kämpfe. Nicht, dass es auf technischer Ebene nicht viel zu lernen und zu bewältigen gäbe.
Addy Osamai schrieb einen Deep Dive (ein 20-minütiger Lesestoff laut Medium), der die Kosten von JavaScript für die allgemeine Web-Performance untersucht. Alle scheinen sich einig zu sein, dass JavaScript der größte Problembereich für langsame Websites ist. Es ist nicht belehrend, sondern eine Reihe gut erklärter Prinzipien, denen man in dieser Ära folgen sollte, in der die Nutzung von JavaScript zunimmt
- Um schnell zu bleiben, laden Sie nur JavaScript, das für die aktuelle Seite benötigt wird.
- Akzeptieren Sie Performance-Budgets und lernen Sie, damit zu leben.
- Lernen Sie, Ihre JavaScript-Bundles zu überprüfen und zu reduzieren.
- Jede Interaktion ist der Beginn eines neuen 'Time-to-Interactive'; betrachten Sie Optimierungen in diesem Kontext.
- Wenn clientseitiges JavaScript die Benutzererfahrung nicht verbessert, fragen Sie sich, ob es wirklich notwendig ist.
Das ist nicht spezifisch für Websites: Der Rebound-Effekt ist die Reduzierung der erwarteten Gewinne aus neuen Technologien, die die Ressourcennutzungseffizienz steigern, aufgrund von Verhaltens- oder anderen systemischen Reaktionen.
https://de.wikipedia.org/wiki/Rebound-Effekt_(Ökonomie)
Es ist so erfrischend und freudig, wenn Leute die gleichen Gedanken und Bedenken über die „Langsamkeit des gemeinsamen Webs“ haben wie man selbst. Man fühlt sich immer wie Don Quijote, der gegen Riesen kämpft, die in Wirklichkeit Windmühlen sind. Die beste Form, Kunden heutzutage dazu zu bewegen, Web-Performance-Optimierungen zuzustimmen, ist, die Ladezeiten auf mobilen Plattformen zu erklären. Es ist immer noch traurig, dass man mit solchen Tricks arbeiten muss, um etwas so Wichtiges zu erreichen.
Ich arbeite gerade daran, eine Website für viel bessere Ladezeiten umzustellen, die im Moment die schrecklichsten On-Load-Zeiten hat, insbesondere die Startseite, die etwa 6,7 MB wiegt. Das Schlimmste an letzterer ist: Es gibt kaum Inhalte darauf, die diese riesige Datenmenge zum Laden rechtfertigen würden. Es ist nur eine sehr generische Startseite mit einer einfachen Header-Diashow, etwas Text, einer kleinen bildbasierten Subnavigation mit einigen Animationen, einem weiteren größeren Textblock und dann einer langen Galerie. Ich habe berechnet, dass wir anstelle von 6,7 MB die Ladezeiten auf etwa 800 KB reduzieren könnten, sowie Lazy-Loading / On-Demand-Loading von zusätzlichen Ressourcen (hauptsächlich Bilder) einführen. Dies wird erreicht, indem das derzeit verwendete multifunktionale Premium-Theme auf ein generischeres, reduziertes, reguläres Open-Source-Theme umgestellt wird, d.h. das klassische _s (underscores) :)
Als Nächstes sollten durch das Entfernen des aktuellen Page Builders und den Ersatz durch Advanced Custom Fields Pro sowie geschickt erstellte Seiten-Templates die Verarbeitungszeit um bis zu 80 % reduziert werden (was bedeutet: 1-2 Sekunden Ladezeit statt der aktuellen 4-6 Sekunden, vielleicht sogar knapp unter 0,9 Sekunden).
Einige der zusätzlichen Maßnahmen werden sein:
– hauptsächlich statisches CSS, generiert über SASS und optional ein einfaches Admin-UI-Options-Framework zur Änderung wichtiger Variablen (wie Grundfarben, Typografie und dergleichen)
– ein Bildoptimierungs-Plugin, das ich vor ein paar Jahren von CW Image Optimizer geforkt habe
– generell bessere Ressourcenverwaltung
– Laden aller Ressourcen vom selben Ort, einschließlich Schriftarten, mit dem Ziel, nahezu keine externen Anfragen zu stellen, um lokale Caching- und Statifizierungsmaßnahmen optimal zu nutzen
cu, w0lf.