Innovation kann das Web nicht schnell halten

Von Zeit zu Zeit tragen die Früchte der Innovation in Form von Verbesserungen an den grundlegenden Schichten des Webs Früchte. Im Jahr 2015 wurde HTTP/2 zu einem veröffentlichten Standard, um ein veraltetes Protokoll zu aktualisieren. Dies war sowohl notwendig als auch überfällig, da HTTP/1 die Web-Performance zu einer obskuren Disziplin in Form von seltsamen Umgehungslösungen für seine Einschränkungen machte. Obwohl die Verbreitung von HTTP/2 nicht absolut ist – und es noch Hürden zu überwinden gibt – denke ich, dass es keine Übertreibung ist zu sagen, dass das Web dadurch besser dasteht.

Leider hat die Einführung von HTTP/2 zu einem Mediananstieg von 102 % der übertragenden Bytes über Mobilgeräte in den letzten vier Jahren geführt. Wenn wir uns das 90. Perzentil desselben Datensatzes ansehen – denn es ist wirklich der lange Schwanz der Performance, den wir optimieren müssen –, sehen wir einen Anstieg von 239 %. Von 2016 (PDF-Warnung) bis 2019 hat sich die durchschnittliche mobile Download-Geschwindigkeit in den USA um 73 % erhöht. In Brasilien und Indien stiegen die durchschnittlichen mobilen Download-Geschwindigkeiten im gleichen Zeitraum um 75 % bzw. 28 %.

Während das Seiten-Gewicht allein nicht unbedingt die ganze Geschichte der Benutzererfahrung erzählt, ist es zumindest ein lose verwandtes Phänomen, das die *kollektive* Benutzererfahrung bedroht. Die Geschichte, die HTTPArchive erzählt, basierend auf Daten aus dem Chrome User Experience Export (CrUX), kann auf verschiedene Weise interpretiert werden, aber diese eine Tatsache ist fest und unnachgiebig: Die meisten Metriken, die aus CrUX in den letzten Jahren gewonnen wurden, zeigen trotz verschiedener Verbesserungen in Browsern, dem HTTP-Protokoll und dem Netzwerk selbst wenig bis gar keine Verbesserung.

Angesichts dieser Trends kann man zu diesem Zeitpunkt nur sagen, dass die Auswirkungen dieser Verbesserungen dazu beigetragen haben, die Flut unserer Exzesse einzudämmen, aber kaum dazu, sie zu *reduzieren*. Trotz jeder bedeutenden Verbesserung der Grundlagen des Webs und der Netzwerke, über die wir darauf zugreifen, bauen wir weiterhin auf eine Weise, die darauf hindeutet, dass wir uns mit dem nie endenden Jevons-Paradoxon, in dem wir uns abmühen, abgefunden haben.

Wenn wir Fortschritte auf dem Weg zu einem schnelleren Web für alle machen wollen, müssen wir einige der Hindernisse auf diesem Weg erkennen

1. Das unaufhörliche Verlangen, jeden Quadratzentimeter des Webs zu monetarisieren, sowie die Armee von Drittanbietern, die die Forschung für solche fieberhaften Bemühungen befeuern.
2. Arbeitsplatzkulturen, die eine ungezügelte funktionsgetriebene Entwicklung bevorzugen. Diese Praxis fügt dem hinzu – und nimmt selten etwas weg – was wir über die Leitung an die Nutzer senden.
3. Entwickler-Annehmlichkeiten, die die Arbeit des Entwicklers erleichtern, aber für den Kunden eine steigende Kostenbelastung darstellen können.

Kontraintuitiv gehen Besitzer etablierter Codebasen, die einige oder alle dieser Merkmale aufweisen, denselben nicht nachhaltigen Weg zur Rentabilität weiter, den sie immer hatten. Sie tun dies auf eigene Gefahr, anstatt die wiederholt festgestellte Tatsache anzuerkennen, dass leistungsorientierte Entwicklungspraktiken genauso viel – oder mehr – für ihre Bilanz *und* die Benutzererfahrung leisten werden.

Mit diesem Verständnis habe ich akzeptiert, dass unser aktueller Ansatz zur Behebung schlechter Performance größtenteils aus technischen Verfahren besteht, die aus den negativen Auswirkungen unserer Geschäfts-, Produktmanagement- und Entwicklungspraktiken resultieren. Wir sind gut darin, Tourniquets anzulegen, aber nicht so gut darin, tiefe Wunden zu nähen.

Es wird immer deutlicher, dass die Web-Performance kein reines technisches Problem ist, sondern ein *Menschen*-Problem. Dies ist eine unattraktive Einschätzung, teilweise weil technische Lösungen vergleichsweise unbestreitbar sind. Inhaltskomprimierung funktioniert. Minifizierung funktioniert. Tree-Shaking funktioniert. Code-Splitting funktioniert. Sie sind unbestreitbar wirksame Lösungen für Probleme, die auf den ersten Blick rein technisch erscheinen.

Die Schnittstelle zwischen Web-Performance und Menschen ist dagegen unübersichtlich und unbequem. Wie qualifizieren wir erfolgreiche Performance-Kulturen, im Gegensatz zu einer technisch so klar vorteilhaften Lösung wie HTTP/2? Wie qualifizieren wir erfolgreiche Ansätze, um dorthin zu gelangen? Ich weiß nicht *genau*, wie das aussieht, aber ich glaube, eine gute Vorlage ist die folgende Verbindung von kulturellen und technischen Grundsätzen

1. Eine Organisation kann nicht erfolgreich darin sein, Performance zu priorisieren, wenn sie *nicht die Unterstützung ihrer Führungskräfte* sichern kann. Ohne dieses entscheidende Element wird es für Organisationen extrem schwierig, eine Kultur zu schaffen, in der Performance das Hauptmerkmal ihres Produkts ist.
2. Selbst mit Führungsunterstützung kann Performance nicht effektiv priorisiert werden, wenn die Telemetrie zur Messung fehlt. Ohne Messung wird es unmöglich zu erklären, wie die Produktentwicklung die Performance beeinflusst. Wenn man die Zahlen nicht hat, wird sich niemand um Performance kümmern, bis eine offensichtliche Krise eintritt.
3. Wenn man die Unterstützung der Führung hat, um Performance zur Priorität zu machen, *und* die Telemetrie zur Messung vorhanden ist, kann man es *trotzdem* nicht schaffen, wenn nicht die gesamte Organisation das Thema Web-Performance versteht. Zu diesem Zeitpunkt entwickelt und führt man Schulungen, Dokumentationen, Best Practices und Standards ein, die die Organisation annehmen kann. In gewisser Weise ist dies der Bereich, in dem Organisationen bereits viel Zeit verbracht haben, aber die eigentliche Herausforderung liegt in der Einrichtung von Feedback-Schleifen, um zu bewerten, wie gut sie dieses Wissen verstanden und angewendet haben.
4. Wenn all die anderen Teile endlich vorhanden sind, kann man beginnen, die Verantwortlichkeit in der Organisation rund um die Performance zu schaffen. Verantwortung bedeutet nicht Repressalien, wenn Ihre Telemetrie zeigt, dass die Performance im Laufe der Zeit gelitten hat, sondern vielmehr in Form von Leitplanken, die im Bereitstellungsprozess eingerichtet werden, um Sie zu alarmieren, wenn Schwellenwerte überschritten wurden.

Jetzt kommt der Knackpunkt: **selbst wenn all diese Dinge in Ihrem Arbeitsumfeld zusammenkommen, sind gute Ergebnisse nicht garantiert.** Abgesehen von einer Regulierung, die uns zwingt, uns um die schlecht performenden Websites zu kümmern, für die wir verantwortlich sind – ähnlich wie der ADA uns in Bezug auf Barrierefreiheit auf Trab hält –, wird es weiterhin Evangelisierung und Druck erfordern, um sicherzustellen, dass Performance eine Priorität *bleibt*. Wie bei vielen Dingen, die wir im Web tun, ist die Arbeit, eine gute Benutzererfahrung in sich entwickelnden Codebasen aufrechtzuerhalten, nie abgeschlossen. Ich hoffe, 2020 ist das Jahr, in dem wir sinnvoll erkennen, dass es bei Performance um Menschen geht, und uns entsprechend anpassen.

Da technologische Innovationen wie HTTP/3 und 5G aufkommen, müssen wir darauf achten, uns nicht auf unseren Lorbeeren auszuruhen und einfach *anzunehmen*, dass sie unsere Probleme ein für alle Mal heilen werden. Wenn wir das tun, werden wir diese Diskussion sicherlich wieder führen, wenn die Nachfolger *dieser* Technologien am Horizont erscheinen. Innovation allein kann das Web nicht schnell halten, denn das Web schnell zu machen – und es auch so zu *halten* – ist die harte Arbeit, die wir nur durch gemeinsame Anstrengungen erreichen können.