Smashing Podcast Episode 34 mit Harry Roberts: Wie ist der Stand der Web-Performance?

In dieser Folge sprechen wir über Web-Performance. Wie sieht die Leistungslandschaft im Jahr 2021 aus? Ich habe mit dem Experten Harry Roberts gesprochen, um das herauszufinden.

Notizen anzeigen

Harry veranstaltet im Mai 2021 einen Web Performance Masterclass-Workshop mit Smashing. Zum Zeitpunkt der Veröffentlichung sind noch große Frühbucherrabatte verfügbar.

• Harry auf Twitter
• Harrys Beratungsseite CSS Wizardry
• Videokurs Everything I Have Done to Make CSS Wizardry Fast inklusive 15% Rabatt
• Questions for Consultants eBook inklusive 15% Rabatt
• Web.dev-Anleitung zu Web Vitals
• Drews Lieblings-OXO GoodGrips Schneebesen

Wöchentliches Update

• Webdesign-Trends 2021: Der Bericht von Suzanne Scacca
• Verwenden von Grommet in React-Anwendungen, die von Fortune Ikechi geschrieben wurden
• So erstellen Sie eine Node.js-API für die Ethereum-Blockchain, geschrieben von John Agbanusi
• Wie wir die Leistung von SmashingMag verbessert haben geschrieben von Vitaly Friedman
• Wann man zu freiberuflichen Projekten Nein sagen sollte, geschrieben von Becca Kennedy

Abschrift

Drew McLellan: Er ist ein unabhängiger beratender Web Performance Engineer aus Leeds in Großbritannien. In seiner Rolle hilft er einigen der weltweit größten und angesehensten Unternehmen, ihren Kunden schnellere und zuverlässigere Erfahrungen zu liefern. Er ist ein eingeladener Google Developer Expert, ein Cloudinary Media Developer Expert, ein preisgekrönter Entwickler und ein internationaler Redner. Wir wissen also, dass er sich mit Web-Performance auskennt, aber wussten Sie, dass er 14 Arme und sieben Beine hat? Meine Smashing-Freunde, bitte heißen Sie Harry Roberts willkommen. Hallo Harry, wie geht es dir?

Harry Roberts: Hey, ich danke dir sehr. Offensichtlich werfen die 14 Arme, sieben Beine… immer noch ihre üblichen Probleme auf. Unmöglich, Hosen zu kaufen.

Drew: Und Fahrräder.

Harry: Ja. Nun, ich habe dreieinhalb Fahrräder.

Drew: Also ich wollte heute mit dir reden, leider nicht über Fahrräder, obwohl das an sich schon Spaß machen würde. Ich wollte mit Ihnen über Web-Performance sprechen. Es ist ein Thema, das mir persönlich sehr am Herzen liegt, aber es ist einer dieser Bereiche, in denen ich mir Sorgen mache, wenn ich meine Augen vom Ball nehme und mich auf irgendeine andere Arbeit einlasse und dann wieder ein bisschen Performancearbeit mache, Ich mache mir Sorgen, dass das Wissen, mit dem ich arbeite, sehr schnell veraltet … Ist die Web-Performance heutzutage so schnelllebig, wie ich es wahrnehme?

Harry: Das ist… ich sage das nicht nur, um nett zu dir zu sein, das ist so eine gute Frage, weil ich in letzter Zeit ziemlich viel darüber nachgedacht habe und ich würde sagen, es gibt zwei Hälften davon. Eine Sache, die ich versuchen würde, den Kunden zu sagen, ist, dass es eigentlich nicht so schnell geht. Vor allem, weil, und das ist der Soundbite, den ich immer benutze, Sie auf den Browser setzen können. Browser dürfen ihre Funktionsweise nicht wirklich grundlegend ändern, denn natürlich gibt es zwei Jahrzehnte altes Erbe, das sie aufrechterhalten müssen. Wenn Sie also im Allgemeinen auf den Browser setzen und wissen, wie diese Interna funktionieren, und TCP/IP, das sich nie ändert … Also die bestimmten Dinge, die ziemlich in Stein gemeißelt sind, was bedeutet, dass Best Practice im Großen und Ganzen immer so sein wird Best Practice, wenn es um die Grundlagen geht.

Harry: Wo es interessanter wird, ist … Was ich immer öfter sehe, ist, dass wir uns selbst in die Enge treiben, wenn es um Probleme mit der Seitengeschwindigkeit geht. Wir schaffen uns also tatsächlich viele Probleme. Was das realistisch bedeutet, ist Leistung … es ist der bewegliche Torpfosten, nehme ich an. Je mehr sich die Landschaft oder die Topografie des Webs ändert, und je mehr sich die Art und Weise, wie es aufgebaut ist und wie wir arbeiten, verändert, stellen wir uns selbst vor neue Herausforderungen. Das Aufkommen von viel mehr Arbeit am Client wirft also andere Leistungsprobleme auf, als wir sie vor fünf Jahren lösen würden, aber diese Leistungsprobleme betreffen immer noch Browser-Interna, die sich im Großen und Ganzen in fünf Jahren nicht geändert haben. Vieles hängt also davon ab … Und ich würde sagen, es gibt definitiv zwei klare Seiten … Ich ermutige meine Kunden, sich auf den Browser zu verlassen, sich auf die Standards zu verlassen, denn sie können nicht einfach geändert werden, die Torpfosten bewegen sich nicht wirklich . Aber das muss natürlich mit moderneren und vielleicht etwas interessanteren Entwicklungspraktiken verschmelzen. Also behältst du deine … Nun, ich wollte sagen „Ein Fuß in beiden Lagern“, aber mit meinen sieben Füßen müsste ich … vier und drei.

Drew: Du hast erwähnt, dass sich die Grundlagen nicht ändern und Dinge wie TCP/IP sich nicht ändern. Eines der Dinge, die sich geändert haben in… ich sage „den letzten Jahren“, das geht jetzt wahrscheinlich ein bisschen zurück, aber HTTP ist dahingehend, dass wir dieses etablierte Protokoll HTTP für die Kommunikation zwischen Clients und Servern hatten, und das hat sich dann geändert wir haben H2, das dann alles binär und anders ist. Und das hat vieles geändert… Es war aus Leistungsgründen, es sollte einige der bestehenden Einschränkungen beseitigen, aber das war eine Änderung und die Art und Weise, wie wir für dieses Protokoll optimieren mussten, hat sich geändert. Ist das jetzt stabil? Oder wird es sich wieder ändern, oder…

Harry: Also eine Sache, über die ich gerne mehr lernen würde, ist die zweite Hälfte der Frage, die erneute Veränderung. Ich muss mich mehr mit QUIC und H3 befassen, aber es ist ein bisschen zu weit um die Ecke, um für meine Kunden nützlich zu sein. Wenn es um H2 geht, haben sich die Dinge ziemlich verändert, aber ich denke wirklich, dass H2 viele falsche Versprechungen sind, und ich glaube, es wurde überstürzt, was bemerkenswert ist, wenn man bedenkt, dass H1 gestartet wurde … Und ich meine 1.1, war 1997, Wir haben also viel Zeit, um an H2 zu arbeiten.

Harry: Ich denke, der Hauptnutzen sind Webentwickler, die es verstehen oder wahrnehmen, dass es jetzt unbegrenzte Fluganfragen gibt. Anstelle von sechs gesendeten und/oder sechs In-Flight-Anfragen gleichzeitig, potenziell unbegrenzt, unendlich. Bringt aber wirklich interessante Probleme mit sich, weil… es ohne visuelle Hilfsmittel ziemlich schwer zu beschreiben ist, aber Sie haben immer noch die gleiche Menge an Bandbreite zur Verfügung, egal ob Sie H1 oder H2 verwenden, das Protokoll macht Ihre Verbindung nicht schneller. Es ist also durchaus möglich, dass Sie das Netzwerk überschwemmen, indem Sie 24 Dateien auf einmal anfordern, aber Sie haben nicht genug Bandbreite dafür. Schneller wird man also eigentlich nicht, weil man vielleicht nur einen Bruchteil davon auf einmal schafft.

Harry: Und Sie müssen auch darüber nachdenken, wie die Dateien reagieren. Und das ist ein weiterer Profi-Tipp, den ich bei Kunden-Workshops und so weiter durchgehe. Die Leute werden sich einen H2-Wasserfall ansehen und sehen, dass sie statt der traditionellen sechs Versandanfragen möglicherweise 24 sehen. Das Versenden von 24 Anfragen ist eigentlich nicht so nützlich. Was nützlich ist, ist, wenn diese Antworten zurückgegeben werden. Und was Sie bemerken werden, ist, dass Sie möglicherweise 24 Anfragen senden, sodass Ihre linke Seite Ihres Wasserfalls wirklich schön und steil aussieht, aber sie alle in einer ziemlich gestaffelten, sequenziellen Weise zurückkehren, weil Sie die Bandbreite entsprechend begrenzen müssen Sie können nicht alle Antworten gleichzeitig erfüllen.

Harry: Nun, die andere Sache ist, wenn Sie alle Antworten gleichzeitig erfüllen würden, würden Sie Antworten verschachteln. Sie erhalten also nachts die ersten 10 % jeder Datei und die nächsten 20 % … 20 % einer JavaScript-Datei sind nutzlos. JavaScript ist erst verwendbar, wenn es zu 100 % angekommen ist. Was Sie also tatsächlich sehen werden, ist die Art und Weise, wie sich ein H2-Wasserfall manifestiert, wenn Sie sich die Reaktion ansehen … Es sieht sowieso viel mehr wie H1 aus, es ist viel versetzter. Also, H2, ich denke, es war überverkauft, oder vielleicht wurden Ingenieure nicht dazu gebracht zu glauben, dass es Obergrenzen dafür gibt, wie effektiv es sein könnte. Weil Sie sehen werden, wie Leute ihre Assets übermäßig fragmentieren und vielleicht zwanzig haben ... lassen Sie uns die Zahl 24 beibehalten. Anstatt zwei große JS-Dateien zu haben, haben Sie vielleicht 24 kleine Bündel. Sie werden immer noch ziemlich nacheinander zurückkehren. Sie werden nicht alle gleichzeitig ankommen, weil Sie sich nicht mehr Bandbreite gezaubert haben.

Harry: Und das andere Problem ist, dass jede Anfrage eine konstante Latenz hat. Nehmen wir also an, Sie fordern zwei große Dateien an und es sind hundert Millisekunden Roundtrip und 250 Millisekunden Download, das sind zweimal 250 Millisekunden. Wenn Sie bis zu 24 Anfragen multiplizieren, haben Sie immer noch eine konstante Latenzzeit, die wir auf 100 Millisekunden festgelegt haben, also haben Sie jetzt 2400 Millisekunden Latenzzeit und 24 Mal … statt 250 Millisekunden Download, sagen wir, es sind 25 Millisekunden Download, Es dauert tatsächlich länger, weil die Latenz konstant bleibt und Sie diese Latenz einfach mit mehr Anfragen multiplizieren. Ich werde also Kunden sehen, die gelesen haben, dass H2 diese Wunderwaffe ist. Sie werden splittern … Oh! Sie konnten den Entwicklungsprozess nicht vereinfachen, wir brauchen keine Bündelung oder Verkettung und so weiter, und so weiter. Und letztendlich wird es langsamer, weil Sie es geschafft haben, Ihre Anfragen zu verteilen, was das Versprechen war, aber Ihre Latenz bleibt konstant, sodass Sie tatsächlich nur n-mal mehr Latenz im Browser haben. Wie ich schon sagte, wirklich schwer, wahrscheinlich sinnlos, das ohne Bilder erklären zu wollen, aber es ist bemerkenswert, wie sich H2 manifestiert, verglichen mit dem, was die Leute hoffen.

Drew: Gibt es noch Vorteile in diesem Sharding-Prozess, okay, um das ganze Los zu bekommen, dauert es immer noch die gleiche Zeit, aber wenn Sie 100% des ersten 24. zurückbekommen, können Sie damit beginnen, daran zu arbeiten, und Sie können Beginnen Sie mit der Ausführung, bevor der 24. durch ist.

Harry: Oh Mann, noch eine tolle Frage. Also, absolut, wenn die Dinge richtig laufen und es sich in einer H1-ähnlicheren Antwort manifestiert, wäre die Idee, Datei eins zuerst zurückzugeben, zwei, drei, vier, und dann können sie in der Reihenfolge ausgeführt werden, in der sie ankommen. Sie können also die Gesamtzeit verkürzen, indem Sie sicherstellen, dass die Dinge zur gleichen Zeit ankommen. Wenn wir uns anstelle des Wasserfalls eine Webseite ansehen und Sie feststellen, dass Anfragen verschachtelt sind, sind das schlechte Nachrichten. Denn wie gesagt, 10 % einer JavaScript-Datei sind nutzlos.

Harry: Wenn der Server seine Arbeit ordentlich macht und sendet, sendet, sendet, sendet, sendet, dann wird er schneller. Und dann haben Sie die Folgevorteile Ihrer Cache-Strategie, die granularer sein kann. Es wäre also wirklich ärgerlich, wenn Sie die Schriftgröße in Ihrem Datumsauswahl-Widget aktualisieren würden. In der H1-Welt müssen Sie vielleicht 200 Kilowatt des breiten CSS Ihrer Website zwischenspeichern. Während Sie jetzt nur die Datei bust datepicker.css zwischenspeichern. Wir haben also Ablegervorteile wie diesen, die definitiv, definitiv sehr wertvoll sind.

Drew: Ich denke, in dem Szenario, in dem Sie auf magische Weise alle Ihre Anfragen auf einmal zurückbekommen haben, würde das den Client offensichtlich möglicherweise verlangsamen, nicht wahr?

Harry: Ja, möglicherweise. Was dann tatsächlich passieren würde, ist, dass der Client eine Menge Ressourcenplanung durchführen müsste, sodass Sie am Ende einen Wasserfall erhalten würden, bei dem alle Ihre Antworten gleichzeitig zurückkommen, dann hätten Sie eine ziemlich große Lücke zwischen den Antworten zuletzt eintreffende Antwort und ihre Fähigkeit zur Ausführung. Wenn wir über JavaScript sprechen, möchten Sie also idealerweise, dass der Browser sie alle in der Anforderungsreihenfolge anfordert, im Grunde in der Reihenfolge, in der Sie sie definiert haben, und der Server sie alle in der richtigen Reihenfolge zurückgibt, damit der Browser sie ausführen kann sie in der richtigen Reihenfolge. Denn, wie Sie sagen, wenn sie alle zur gleichen Zeit zurückkehren, müssen Sie nur ein riesiges JavaScript auf einmal ausführen, aber es muss noch geplant werden. Sie könnten also einen Zweifel von bis zu einer Sekunde zwischen dem Eintreffen einer Datei und ihrer Verwendung haben. Also eigentlich H1 … Ich schätze, was Sie im Idealfall suchen, ist H2-Anforderungsplanung, H1-artige Antworten, damit die Dinge nützlich gemacht werden können, sobald sie ankommen.

Drew: Du suchst also im Grunde nach einem Reaktionswasserfall, der aussieht, als könntest du ihn hinunterfahren.

Harry: Ja, genau.

Drew: Aber du würdest keinen Fallschirm brauchen.

Harry: Ja. Und es ist wirklich schwierig … Ich denke, es klingt wirklich trivial, um es laut auszusprechen, aber angesichts der Art und Weise, wie H2 verkauft wurde, finde ich es ziemlich … nicht herausfordernd, weil das meinen Kunden … dumm klingen lässt … aber es ist ziemlich schwer zu erklären für sie … wenn man darüber nachdenkt, wie H1 funktioniert, war es nicht so schlimm. Und wenn wir Antworten bekommen, die so aussehen und „Oh ja, ich kann es jetzt sehen“. Das musste ich Leistungsingenieuren schon früher beibringen. Menschen, die tun, was ich tue. Ich musste Leistungsingenieuren beibringen, dass es uns nicht allzu sehr stört, wenn Anfragen gestellt werden, wir kümmern uns wirklich darum, wann Antworten nützlich werden.

Drew: Einer der Gründe, warum sich die Dinge ziemlich schnell zu entwickeln scheinen, insbesondere in den letzten fünf Jahren, ist, dass Leistung ein großes Thema für Google ist. Und wenn Google auf so etwas Wert legt, gewinnt es an Zugkraft. Im Wesentlichen ist die Leistung jedoch ein Aspekt der Benutzererfahrung, nicht wahr?

Harry: Oh, ich meine… das ist ein wirklich guter Podcast, ich habe vor einer halben Stunde darüber nachgedacht, ich verspreche dir, ich habe vor einer halben Stunde darüber nachgedacht. Leistung ist angewandte Barrierefreiheit. Sie garantieren oder erhöhen die Chancen, dass jemand auf Ihre Inhalte zugreifen kann, und ich denke, Barrierefreiheit ist immer nur … Oh, es sind Screenreader, richtig? Es sind Menschen ohne Sehvermögen. Die Entscheidungen, eher eine Website als eine App zu erstellen … die Entscheidungen sind eher der Zugang zu einem Publikum. Also ja, Leistung ist angewandte Barrierefreiheit, also die Benutzererfahrung. Und diese Benutzererfahrung könnte auf den Punkt „Könnte jemand Ihre Website überhaupt erleben“ hinauslaufen. Oder es könnte lauten: „War diese Erfahrung herrlich? Wenn ich auf eine Schaltfläche geklickt habe, hat sie rechtzeitig reagiert?“. Also stimme ich zu 100 % zu und ich denke, das ist einer der Gründe, warum Google darauf Wert legt, weil es die Benutzererfahrung beeinflusst, und wenn jemand den Suchergebnissen vertraut, wollen wir versuchen, dieser Person eine Website zu geben, die das ist sie werden nicht hassen.

Drew: Und es ist … alles, woran Sie denken, alle Vorteile, an die Sie denken, Benutzererfahrung, Dinge wie erhöhtes Engagement, es ist definitiv wahr, nicht wahr? Es gibt nichts, was den Benutzer schneller von einer Website wegtreibt als eine träge Erfahrung. Es ist so frustrierend, nicht wahr? Wenn Sie eine Website verwenden, von der Sie wissen, dass die Navigation möglicherweise nicht so klar ist, und wenn Sie sich zu einem Link durchklicken und denken: „Ist es das, was ich will? Es ist nicht?" Und nur die Kosten für diesen Klick, nur das Warten, und dann müssen Sie auf die Schaltfläche „Zurück“ klicken und dann das Warten, und es ist nur … Sie geben auf.

Harry: Ja, und es macht Sinn. Wenn Sie in den Supermarkt gehen und sehen, dass er mit Menschen vollgestopft ist, tun Sie das Nötigste. Du wirst dort nicht viel Geld ausgeben, es ist wie „Oh, ich brauche nur Milch“, rein und raus. Wohingegen, wenn es eine schöne Erfahrung ist, Sie haben „Oh, gut, während ich hier bin, werde ich sehen, ob… Oh, ja, sie haben das… Oh, ich werde das morgen Abend kochen“ oder was auch immer. Ich denke, auch drei Jahrzehnte nach dem Web haben selbst Leute, die für das Web bauen, Probleme, weil es nicht greifbar ist. Sie kämpfen damit, wirklich zu glauben, dass das, was Sie in einem echten Geschäft ärgern würde, Sie online ärgern würde, und das tut es, und die Statistiken zeigen, dass es so ist.

Drew: Ich denke, dass wir in den ganz frühen Tagen, ich denke an die späten 90er, um mein Alter zu zeigen, sehr viel über Leistung nachgedacht haben, als wir Websites erstellten, aber wir dachten über Leistung unter dem Gesichtspunkt der Verbindungen, die Menschen waren mit waren so langsam. Wir sprechen über DFÜ, Modems, Telefonleitungen, 28K-, 56K-Modems, und es gab irgendwann einen Trend bei der Gestaltung von Bildern, dass jede zweite Zeile des Bildes mit einer Volltonfarbe ausgeblendet wurde, um dies zu geben … wenn man kann sich das so vorstellen, als würde man durch eine jalousie auf das bild blicken. Und wir haben das gemacht, weil es bei der Komprimierung geholfen hat. Da jede zweite Zeile der Komprimierungsalgorithmus könnte-

Harry: In einen Zeiger zusammenbrechen.

Drew: Ja. Und so haben Sie Ihre Bildgröße erheblich reduziert, während Sie immer noch in der Lage sind, … Und es wurde zu einem Designelement. Alle taten es. Ich denke, vielleicht war Jeffrey Zeldman einer der ersten, der diesen Ansatz vorangetrieben hat. Aber woran wir dort gedacht haben, war in erster Linie, wie schnell wir die Dinge auf den Weg bringen können. Nicht für die Benutzererfahrung, weil wir nicht darüber nachgedacht haben … Ich meine, ich denke, es war die Benutzererfahrung, weil wir im Wesentlichen nicht wollten, dass die Leute unsere Websites verlassen. Aber wir haben darüber nachgedacht, die Dinge nicht so zu optimieren, dass sie wirklich schnell sind, sondern zu vermeiden, dass sie wirklich langsam sind, wenn das Sinn macht.

Harry: Ja, ja.

Drew: Und ich denke, als sich Geschwindigkeiten wie ADSL-Leitungen durchsetzten, hörten wir auf, in diesen Begriffen zu denken, und fingen an, überhaupt nicht mehr darüber nachzudenken. Und jetzt sind wir in der Situation, dass wir mobile Geräte verwenden und sie eingeschränkte Verbindungen und vielleicht langsamere CPUs haben, und wir müssen noch einmal darüber nachdenken, aber dieses Mal, um einen Vorteil zu erzielen. Neben der Seite der Benutzererfahrung kann es echte geschäftliche Vorteile in Bezug auf Kosten und Gewinnmöglichkeiten haben. Nicht wahr?

Harry: Ja, enorm. Ich meine, ich bin mir nicht sicher, wie ich es formulieren soll. Ich will mir hier nicht selbst ins Knie schießen, aber eine Sache, die ich versuche und den Kunden gegenüber hervorhebe, ist, dass die Geschwindigkeit der Website Ihnen einen Wettbewerbsvorteil verschaffen wird, aber es ist nur eine Sache, die Ihnen einen Wettbewerbsvorteil verschaffen könnte. Wenn Sie ein Produkt haben, das niemand kaufen möchte, spielt es keine Rolle, wie schnell Ihre Website ist. Und ebenso, wenn jemand wirklich die schnellste Website der Welt haben möchte, müssen Sie Ihre Bilder löschen, Ihr CSS löschen, Ihr JavaScript löschen und dann sehen, wie viele Produkte Sie anbieten, denn ich garantiere, dass die Geschwindigkeit der Website nicht der Faktor war. Studien haben jedoch gezeigt, dass es enorme Vorteile in Millionenhöhe hat, schnell zu sein. Ich arbeite gerade mit einem Kunden. Wir haben für sie ausgerechnet, dass es 1,8 Millionen pro Jahr wert ist, wenn sie eine bestimmte Seite eine Sekunde schneller rendern könnten, oder besser gesagt, ihr größter Inhalt für Farbe wäre eine Sekunde schneller, was … das ist eine große Zahl.

Drew: Das würde fast dein Honorar bezahlen.

Harry: Hey! Ja, fast. Ich habe ihnen gesagt: „Seht mal, nach zwei Jahren ist das alles abbezahlt. Sie werden die Gewinnschwelle erreichen“. Ich wünsche. Aber ja, ist der kundenorientierte Aspekt … Entschuldigung, der kundenorientierte Aspekt, wenn Sie eine E-Com-Site haben, werden sie mehr Geld ausgeben. Wenn Sie ein Publisher sind, werden sie mehr von einem Artikel lesen oder mehr Minuten Inhalt ansehen, oder was auch immer Sie tun, das ist Ihr KPI, den Sie messen. Es könnte auf der Smashing-Site sein, es könnte sein, dass sie nicht abgesprungen sind, sie haben sich tatsächlich durch ein paar weitere Artikel geklickt, weil wir es wirklich einfach und schnell gemacht haben. Und dann sind schnellere Websites billiger zu betreiben. Wenn Sie Ihre Cache-Strategie im Griff haben, werden Sie Leute von Ihren Servern fernhalten. Wenn Sie Ihre Assets optimieren, wird alles, was von Ihrem Server kommen muss, viel weniger wiegen. So viel billiger zu laufen.

Harry: Die Sache ist die, es kostet etwas, dorthin zu gelangen. Ich denke, Scott Jehl hat wahrscheinlich einen der wichtigsten gesagt … Und ich habe es zuerst von ihm gehört, also gehe ich davon aus, dass er darauf gekommen ist, aber das Sprichwort lautet: „Es ist einfach, eine schnelle Website zu erstellen, aber es ist schwierig, eine Website zu erstellen schnell". Und das ist so knapp. Weil der Grund, warum Web Perf auf der Liste der zu erledigenden Aufgaben nach unten geschoben wird, darin besteht, dass Sie möglicherweise zu einem Kunden sagen können: „Wenn ich Ihre Website eine Sekunde schneller mache, verdienen Sie zusätzliche 1,8 Millionen pro Jahr“ oder es sein kann „Wenn Sie gerade Apple Pay zu Ihrer Kasse hinzugefügt haben, werden Sie fünf Millionen zusätzlich verdienen.“ Es geht also nicht nur um Web-Performance und es ist nicht der entscheidende Faktor, es ist Teil einer viel größeren Strategie, insbesondere für E-Com online. Aber der Beweis ist, dass ich es aus erster Hand mit meinen Privatkunden, meinen E-Com-Kunden, gemessen habe. Das Argument dafür ist genau dort, Sie haben vollkommen Recht. Es ist ein Wettbewerbsvorteil, es wird Ihnen mehr Geld einbringen.

Drew: Damals, wieder einmal, schaukele ich auf eine vergangene Zeit zurück, aber Leute wie Steve Souders waren einige der ersten Leute, die wirklich anfingen, über Web-Performance zu schreiben und zu sprechen. Und Leute wie Steve sagten im Grunde: „Vergiss die Backend-Infrastruktur, wo alle Vorteile im Browser liegen, im Frontend, dort passiert alles langsam.“ Ist das nach 15 Jahren immer noch so?

Harry: Ja, ja. Er hat den Test damals und heute zwischendurch wiederholt, und die Lücke hatte sich tatsächlich vergrößert, also ist es über den Draht tatsächlich teurer. Aber es gibt einen Konter dagegen, nämlich wenn Sie eine wirklich schlechte Backend-Performance haben, wenn Sie sich langsam aus dem Tor begeben, gibt es nur so viel, was Sie am Frontend zurückbekommen können. Ich habe im Moment einen Client, dessen Zeit bis zum ersten Byte 1,5 Sekunden beträgt. Wir können daher nie schneller als 1,5 Sekunden rendern, das wird also eine Obergrenze sein. Wir können immer noch Zeit am Frontend zurückholen, aber wenn Sie eine wirklich, wirklich schlechte Zeit bis zum ersten Byte haben, Sie Backend-Verlangsamungen haben, gibt es eine Grenze dafür, wie viel schneller Sie Ihre Frontend-Performance-Bemühungen machen könnten. Aber absolut.

Harry: Das ändert sich jedoch, weil … Nun, nein, es ändert sich nicht, denke ich, es wird schlimmer. Wir drängen mehr auf den Kunden. Früher hieß es: „Ihr Server ist so schnell wie er ist, aber danach haben wir ein paar Fragezeichen.“ weil ich das die ganze Zeit höre: „Alle unsere Benutzer verwenden WLAN. Sie haben alle Desktop-Computer, weil sie alle von unserem Büro aus arbeiten.“ Nun, nein, jetzt arbeiten sie alle von zu Hause aus. Du kannst nicht wählen. Hier kommen also all die Fragezeichen ins Spiel, wo die Verlangsamungen auftreten, wo man es nicht wirklich kontrollieren kann. Danach die Tatsache, dass wir jetzt dazu neigen, mehr auf den Kunden zu setzen. Damit meine ich ganze Laufzeiten auf dem Client. Sie haben sowieso Ihre gesamte Anwendungslogik von einem Server verschoben, daher sollte Ihre Zeit bis zum ersten Byte sehr, sehr gering sein. Es sollte ein Fall sein, einige Bündel von einem CDM an meine zu senden … aber Sie haben sich von der Möglichkeit, Ihre eigenen Server zu spezifizieren, zu der Hoffnung entwickelt, dass jemand Netflix nicht auf demselben Computer ausgeführt hat, auf dem er versucht, Ihre Website anzuzeigen .

Drew: Es ist ein wirklich guter Punkt in Bezug auf die Art und Weise, wie wir Websites entwerfen, und ich denke, die traditionelle Best Practice war immer, dass Sie versuchen sollten, alle Arten von Browsern, alle Arten von Verbindungsgeschwindigkeiten und alle Arten von Bildschirmgrößen zu bedienen, weil Sie es nicht tun Ich weiß nicht, was der Benutzer erwartet. Und, wie Sie sagten, Sie haben diese Szenarien, in denen die Leute sagen: „Oh nein, wir wissen, dass alle unsere Benutzer auf ihrem von der Arbeit ausgegebenen Desktop-Computer sind, sie führen diesen Browser aus, es ist die neueste Version, sie sind fest mit dem LAN verbunden.“ aber dann passiert was. Einer der großen Vorteile von Web-Apps besteht darin, dass wir unsere Arbeitskräfte plötzlich wieder nach Hause verteilen können und sie weiterarbeiten können, aber das gilt nur, wenn die Qualität der Technik so hoch ist, dass dann jemand mitdreht ob die Qualität der Arbeit vorhanden ist, die tatsächlich bedeutet, dass das Web sein Potenzial erfüllt, ein wirklich barrierefreies Medium zu sein.

Drew: Wie du schon sagst, es gibt diesen Trend, immer mehr Sachen in den Browser zu verlagern, und natürlich, wenn der Browser langsam ist, kommt es zu der Langsamkeit. Man muss sich fragen: „Ist das ein guter Trend? Sollen wir das tun?“ Mir ist eine Seite aufgefallen, die mir besonders aufgefallen ist und die zu fast 100 % vom Server gerendert ist. Es gibt sehr wenig JavaScript und es ist blitzschnell. Jedes Mal, wenn ich darauf gehe, denke ich: „Oh, das ist schnell, wer hat das geschrieben?“ Und dann merke ich „Oh ja, das war ich“.

Harry: Das liegt daran, dass du auf Localhost bist, kein Wunder, dass es sich schnell anfühlt. Es ist Ihre Entwicklerseite.

Drew: Dann bauen wir in meiner täglichen Arbeit unsere Single-Page-Anwendung aus und verlagern Dinge vom Server weg, weil der Server in diesem Fall der Engpass ist. Können Sie sagen, dass es performanter ist, im Browser zu sein? Oder performanter auf dem Server sein? Ist es nur eine Frage des Messens und Nehmens von Fall zu Fall?

Harry: Ich denke, Sie müssen sich Ihres Kontextes sehr, sehr, sehr bewusst sein und… ehrlich gesagt denke ich, dass ein Fehler… Narzissmus ist, wenn die Leute denken „Oh, mein Blog verdient es, in jemandes Browser gerendert zu werden. Mein Blog mit einer Absprungrate von 89% braucht eine eigene Laufzeit im Browser, weil ich die nachfolgenden Navigationen schnell brauche, ich will nur ein … im Grunde ein Diff der Daten abrufen.“ Niemand klickt sowieso auf Ihren nächsten Artikel, Kumpel, schieben Sie keine Laufzeit in die Röhre. Sie müssen sich also Ihres Kontextes sehr bewusst sein.

Harry: Und ich weiß, dass … wenn Jeremy Keith sich das anhört, wird er wahrscheinlich einen Schlag auf mich machen, aber es gibt, würde ich sagen, einen Unterschied zwischen einer Website und einer Web-App, und die Definition davon ist sehr, sehr trüb. Aber wenn Sie eine stark lesende und schreibende Anwendung haben, also etwas, wo Sie Daten eingeben, Daten manipulieren und so weiter. Grundsätzlich ist meine Website keine Web-App, sondern eine Website, die nur gelesen werden kann und die ich fest in das Website-Lager einordnen würde. So etwas wie meine Buchhaltungssoftware ist eine Web-App, ich würde sagen, es ist eine Web-App, und ich bin bereit, ein bisschen Startzeit zu tragen, weil ich weiß, dass ich 20 Minuten, eine Stunde oder was auch immer dort sein werde. Sie brauchen also ein bisschen Kontext, und vielleicht ist Narzissmus ein bisschen hart, aber Sie brauchen ein echtes „Müssen wir diese Zeitung zu einer clientseitigen Anwendung machen?“ Nein, tust du nicht. Nein, tust du nicht. Die Leute haben Werbeblocker aktiviert, die Leute mögen sowieso keine Pendlerzeitungsseiten. Sie werden wahrscheinlich nicht einmal den Artikel lesen und auf Facebook darüber schimpfen. Bauen Sie so etwas einfach nicht als Client-gerenderte Anwendung, es ist nicht geeignet.

Harry: Ich denke also, dass es definitiv einen Punkt gibt, an dem es hilfreich wäre, sich mehr auf den Kunden zu konzentrieren, und das ist der Punkt, an dem Sie weniger empfindlich auf Abwanderung reagieren. Also jeder Kommunikationstyp, ich führe zum Beispiel für einen Moment ein Audit für eine Website durch, die… Ich denke, es ist eine E-Com-Website, aber es geht zu 100 % um den Kunden. Sie deaktivieren JavaScript und sehen nichts, nur ein leeres div id="app". E-Com ist … Sie sind sehr sensibel für alle Probleme. Ihr Checkout-Flow ist sogar subtil falsch, ich bin woanders. Es ist zu langsam, ich bin woanders unterwegs. Sie haben nicht den Kontext, in dem jemand bereit ist, sich für eine Weile in diese App einzubetten.

Harry: Photoshop. Ich öffne Photoshop und bin ziemlich froh zu wissen, dass es 45 Sekunden Startbildschirm dauern wird, weil ich da drin sein werde für … im Grunde sind die 45 Sekunden die 45 Minuten wert. Und es ist so schwer zu definieren, weshalb ich wirklich Mühe habe, Kunden davon zu überzeugen, „Bitte tu das nicht“, weil ich nicht einfach sagen kann: „Wie lange, denkst du, wird dein Benutzer dort bleiben“. Und Sie können davon ausgehen … wenn Ihre Absprungrate von 89 % nicht für einen zweiten Seitenaufruf optimiert ist. Verringern Sie zuerst diese Absprungrate. Ich denke, es gibt definitiv eine Spaltung, aber was ich sagen würde, ist, dass die meisten Leute auf die falsche Seite dieser Linie fallen. Die meisten Leute legen Sachen in den Client, die dort nicht sein sollten. Bei CNN beispielsweise können Sie keine einzige Überschrift auf der CNN-Website lesen, bis eine JavaScript-Anwendung vollständig gestartet wurde. Das einzige, was vom Server gerendert wird, ist die Kopf- und Fußzeile, was das einzige ist, worum sich die Leute nicht kümmern.

Harry: Und ich habe das Gefühl, das ist einfach… Ich weiß nicht, wie wir zu diesem Punkt kommen. Es wird nie die bessere Option sein. Sie liefern eine faktisch nutzlose Seite, die dann sagen muss: „Cool, ich hole etwas, das eine Web-App gewesen wäre, aber wir werden es im Browser ausführen, dann gehe ich und frage nach einer Überschrift , dann kannst du anfangen zu … oh, du bist weg.“ Das ärgert mich wirklich sehr.

Harry: Und es ist niemandes Schuld, ich denke, es ist die Kindheit dieser Art von JavaScript-Ökosystem, der Hype darum, und außerdem, das wird wirklich hart klingen, aber… Es ist im Grunde eine Menge naiver Implementierung. Sicher, Facebook hat React erfunden und was auch immer, es funktioniert für sie. In neun von zehn Fällen arbeiten Sie nicht im Facebook-Maßstab, in 95 von 100 Fällen sind Sie wahrscheinlich nicht die klügsten Facebook-Ingenieure, und das ist wirklich, wirklich grausam und es klingt schrecklich zu sagen, aber Sie können nur … Nichts davon bekommen Diese Dinge sind standardmäßig schnell. Sie brauchen eine sehr, sehr elegante Implementierung dieser Dinge, um sie richtig zu machen.

Harry: Ich hatte diese Diskussion mit meinem alten … er war ein leitender Ingenieur in dem Kader, in dem ich vor 10 Jahren bei Sky war. Ich habe neulich mit ihm darüber gesprochen und er musste sehr hart arbeiten, um eine vom Client gerenderte App schnell zu machen, während Sie nichts tun müssen, um eine vom Server gerenderte App schnell zu machen. Sie müssen es nur nicht wieder langsam machen. Und ich habe das Gefühl, es gibt eine Menge rosarote Brille, Naivität, Marketing … Ich klinge so düster, wir müssen weitermachen, bevor ich anfange, wirklich Leute hier zu verlieren.

Drew: Glauben Sie, dass wir als Branche dazu neigen, uns manchmal mehr auf die Entwicklererfahrung als auf die Benutzererfahrung zu konzentrieren?

Harry: Nicht als Ganzes, aber ich denke, dieses Problem taucht an einer Stelle auf, die man erwarten würde. Wenn Sie sich die Diskrepanz ansehen … Ich weiß nicht, ob Sie das gesehen haben, aber ich nehme an, Sie scheinen sehr genau am Puls der Zeit zu sein, die Diskrepanz zwischen den Daten des HTTP-Archivs darüber, welche Frameworks und JavaScript-Bibliotheken werden in freier Wildbahn im Vergleich zum Stand der JavaScript-Umfrage verwendet. Wenn Sie dem Stand der JavaScript-Umfrage folgen, würde es sagen: „Oh ja, 75 % der Entwickler verwenden React“, während weniger als 5 % der Websites React verwenden. Ich habe also das Gefühl, dass es im Großen und Ganzen kein Problem ist, aber ich denke, in den Bereichen, in denen Sie es erwarten würden, z. B. starke Loyalität zu einem Framework, wird die Entwicklererfahrung … wahrscheinlich vor dem Benutzer evangelisiert. Ich denke nicht, dass die Entwicklererfahrung übersehen werden sollte, ich meine, alles hat Wartungskosten. Dein Auto. Als es entworfen wurde, gab es eine Entscheidung: „Nun, wenn wir diesen Schlüssel, diese Funktionalität vor einem Mechaniker verstecken, wird dieser Mechaniker viel länger brauchen, um es zu reparieren, deshalb machen wir solche Dinge nicht“. Es muss also ein Gleichgewicht zwischen Ergonomie und Benutzerfreundlichkeit geben, das halte ich für wichtig. Ich denke, dass es für mich einfach verwirrend ist, sich hauptsächlich auf die Entwicklererfahrung zu konzentrieren. Optimieren Sie nicht für Sie, optimieren Sie für Ihren Kunden, Ihr Kunde bezahlt Sie, nicht umgekehrt.

Drew: Die Online-Echokammer ist also nicht gerade repräsentativ für die Realität, wenn Sie sehen, dass jeder sagt: „Oh, Sie sollten das verwenden, Sie sollten das tun“, dann ist das tatsächlich nur ein sehr kleiner Prozentsatz der Leute.

Harry: Richtig, und das ist auch gut so, das ist beruhigend. Die Echokammer… es ist vielleicht nicht gesund, eine solche Monokultur zu haben, wenn man es so nennen will. Aber ich habe auch das Gefühl ... und ich habe es in vielen meiner eigenen Arbeiten gesehen, bei vielen Entwicklern ... Als Berater arbeite ich mit vielen verschiedenen Unternehmen zusammen. Viele Leute leisten erstaunliche Arbeit in WordPress. Und WordPress macht 24 % des Webs aus. Und ich habe das Gefühl, dass es für einen Entwickler wie diesen, der an etwas wie WordPress oder PHP im Backend arbeitet, benutzerdefiniertem Code, was auch immer es ist, ziemlich einfach sein könnte, ein bisschen zu denken: „Oh, ich denke, jeder verwendet React und wir nicht “ aber eigentlich nein. Alle reden über React, aber du schwimmst immer noch mit dem Strom, du bist immer noch bei der Mehrheit. Es ist ziemlich beruhigend, die schweigende Mehrheit zu finden.

Drew: Der Trend zu statischen Website-Generatoren und dem anschließenden Hosten von Websites vollständig auf einem CDN, einer Art JAMstack-Ansatz, ich denke, wenn wir über diese Art von Veröffentlichungs-Websites sprechen, und nicht über Software-Websites, denke ich, dass das ein wirklich gesunder Trend ist , würden Sie denken?

Harry: Ich liebe das, absolut. Sie erinnern sich, als wir SSG früher „Flap File“ nannten, richtig?

Drew: Ja.

Harry: Also, ich habe CSS Wizardry auf Jekyll gebaut, als Jekyll noch als Flap-File-Website bezeichnet wurde. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Drew: Ja.

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? This is so good. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: Er hat Respekt gezollt, aber er war einer der Jungs, wir alle mochten ihn wirklich. Aber er war in jeder Dimension massiv. Weit über 1,80 m groß, aber nur ein großer Junge. Großer, großer, großer, großer Mann. Und er sagte zu uns: „Wenn Sie eine Tür entwerfen müssten, würden Sie sie für die durchschnittliche Person entwerfen?“ Und 15-jährige Gehirne sagen: „Nun ja, wenn alle ungefähr 5 Fuß 9 groß sind, dann ja.“ Er sagte: „Nun, sofort, Harry kann diese Tür nicht benutzen.“ Sie entwerfen nicht für die durchschnittliche Person, Sie entwerfen für die Extremitäten, weil Sie möchten, dass es für die meisten Menschen nützlich ist. Wenn Sie einen Stuhl für die durchschnittliche Person entwerfen würden, würde Mr. Brocklesby nicht hineinpassen. Also lehrte er mich von einem wirklich, wirklichen Alter an, Design bis in die Extremitäten.

Harry: Und wo das wirklich interessant in der Web-Performance wird, ist … Wenn du dir eine Leiter vorstellst und die Leiter vom Bot aufhebst … Okay, mir ist gerade klar geworden, dass meine Metapher … Ich bleibe dabei und du kannst darüber lachen mich danach. Stellen Sie sich eine Leiter vor und heben Sie die Leiter an den unteren Sprossen hoch. Und das sind deine schlimmsten Erfahrungen. Sie wählen die unterste Sprosse in der Leiter, um sie anzuheben. Die ganze Leiter kommt mit, wie eine steigende Flut alle Boote schwimmt. Der Grund, warum diese Metapher nicht funktioniert, ist, dass wenn Sie eine Leiter an der obersten Sprosse hochheben, sich alles ebenfalls hebt, es ist eine Leiter. Und die Metapher funktioniert nicht einmal, wenn ich sie in eine Strickleiter verwandle, denn dann hebt man bei einer Strickleiter die unterste Sprosse an und nichts passiert, aber … mein Punkt ist, wenn man die Erfahrung für sein 90. Perzentil verbessern kann, muss es sein Holen Sie sich das für Ihr 10. Perzentil, richtig?

Harry: Und das ist der Grund, warum ich Kunden sage, dass sie Dinge zu mir sagen werden wie „Na ja, die meisten unserer Benutzer verwenden 4G auf iPhones“, also gut, okay, und wir fangen an, 3G auf Android zu testen, wie „Nein, Nein, die meisten unserer Nutzer sind iPhones.“ Okay… das bedeutet, dass Ihr durchschnittlicher Nutzer eine bessere Erfahrung machen wird, aber jeder, der nicht bereits im 50. Perzentil ist, wird nur noch weiter zurückgelassen. Setzen Sie sich also die Messlatte ziemlich hoch, indem Sie die Erwartungen ziemlich niedrig ansetzen.

Harry: Tut mir leid, ich habe eine wirklich schlechte Angewohnheit, sehr lange Antworten auf kurze Fragen zu geben. Aber es war eine fantastische Frage, und um es kurz zu machen, ich stimme Ihnen zu 100 % zu, dass Sie sich diesen Long-Tail ansehen möchten, Sie möchten sich das ansehen … Ihr 80. Perzentil, denn wenn Sie alle Erfahrungen berücksichtigen die Website und schauen Sie sich den Median an, und Sie verbessern den Median, das heißt, Sie haben es noch besser gemacht für Leute, die bereits recht zufrieden waren. 50 % der Menschen effektiv ignoriert zu werden, ist nicht der richtige Ansatz. Und ja, es kommt immer wieder darauf zurück, dass Herr Brocklesby mir sagt: „Designe nicht für die durchschnittliche Person, denn dann kann Harry die Tür nicht benutzen“. Oh, für alle, die zuhören, ich bin 193 Zentimeter groß, also bin ich ziemlich schlaksig, das ist es.

Drew: Und all diese Arme und Beine.

Harry: Ja. Hier ist auch noch ein guter. Meine Freundin hat kürzlich die Einstellungen für die Barrierefreiheit in iOS entdeckt … also hat jeder sein Telefon auf lautlos, richtig? Niemand hat wirklich ein Telefon, das wirklich klingelt, alle haben es auf lautlos gestellt. Sie fand heraus: „Oh, weißt du, du kannst es so einstellen, dass der Blitz aufleuchtet, wenn du eine Nachricht erhältst. Und wenn Sie zweimal auf die Rückseite des Telefons tippen, wird ein Screenshot erstellt.“ Und dies sind Zugänglichkeitseinstellungen, die für das 95. Perzentil ausgelegt sind. Trotzdem sagt sie: „Oh, das ist wirklich nützlich“.

Harry: Dasselbe gilt für OXO Good Grips. OXO Good Grips, die Küchenutensilien. Ich habe eine Menge davon in der Küche. Sie wurden entworfen, weil die Frau des Gründers Arthritis hatte und er bequemere Utensilien herstellen wollte. Er entwarf für das 99. Perzentil, die meisten Menschen haben keine Arthritis. Aber durch das Entwerfen für das 99. Perzentil denken alle anderen versehentlich: „Oh mein Gott, warum können nicht alle Kartoffelschäler so bequem sein?“ Und ich habe das Gefühl, dass es wirklich, wirklich … Ich mag eine gute Laune oder Anekdote, die ich gerne in diese Art von Szenarien einbaue. Aber ja, wenn Sie für sie optimieren … Nun, eine steigende Flut schwimmt alle Boote und das optimiert daher das Ende der Menschen und Sie werden darüber hinaus viele noch glücklichere Kunden gewinnen.

Drew: Hast du den manuellen Schneebesen OXO Good Grips?

Harry: Ich nicht. Ich nicht, ist es gut?

Drew: Sehen Sie sich das an. Es ist so gut.

Harry: Ich habe den OXO Good Grips Mandolinenhobel, der mir letzte Woche das Ende meines Fingers abgerissen hat.

Drew: Ja, ich komme nicht in die Nähe von denen.

Harry: Ja, es ist meine eigene dumme Schuld.

Drew: Ein weiteres Beispiel aus meiner eigenen Erfahrung mit dem Catering für diesen Long-Tail ist, dass in dem Projekt, an dem ich gerade arbeite, dieser Long-Tail ganz am Ende steht, man hat Leute mit der langsamsten Leistung, aber wenn sich herausstellt, wer diese Kunden sind, sind sie die wertvollsten Kunden für das Unternehmen.

Harry: Okay.

Drew: … weil sie die größten Organisationen mit den meisten Datenmengen sind.

Harry: Richtig.

Drew: Und so stoßen sie auf Engpässe, weil sie so viele Daten auf einer Seite anzeigen müssen und diese Seiten ein wenig umgestaltet werden müssen, um diesen Anwendungsfall zu unterstützen. Sie haben also die langsamste Erfahrung und sie zahlen, wenn es darauf ankommt, das meiste Geld und machen so viel mehr Unterschied als all die Leute, die eine wirklich schnelle Erfahrung haben, weil sie kostenlose Benutzer mit a sind winzige Datenmenge und alles funktioniert gut und es ist schnell.

Harry: Das ist eine faszinierende Dimension, nicht wahr? Tatsächlich hatte ich ein ähnliches … Ich hatte bei weitem nicht die geschäftlichen Auswirkungen, die Sie gerade beschrieben haben, aber ich habe vor ein paar Jahren mit einem Kunden zusammengearbeitet, und sein CEO hat sich gemeldet, weil seine Website langsam war. Wie, langsam, langsam, langsam. Auch ein wirklich netter Typ, er ist einfach ein wirklich netter, bodenständiger Typ, aber er wird betreut, wie ein richtiger Reicher. Und er hat das neuste iPhone, das kann er sich leisten. Er ist Multimillionär und verbringt viel Zeit damit, zwischen Australien, wo er herkommt, und Estland, wo er jetzt lebt, zu fliegen.

Harry: Und er fliegt erste Klasse, natürlich. Aber es bedeutet, dass er die meiste Zeit auf seinem schönen, glänzenden iPhone 12 Pro Max, was auch immer, über Flugzeug-WLAN verbringt, was schrecklich ist. Und es war diese wirklich erstaunliche Gegenüberstellung, wo ihm die Seite gehört und er sie oft benutzt, es ist eine Seite, die er benutzt. Und er hat es vorangetrieben … Ich meine, ihr reichster Kunde war mit Sicherheit ihr CEO. Und er ist in dieser seltsam privilegierten Position, in der er eine schlechtere Verbindung hat als Joe Public, weil er irgendwo über Singapur in einem Quantas-Flug ist und Champagner in den Hals gegossen wird, und er kämpft. Und das war eine wirklich faszinierende Erkenntnis, dass … Oh ja, weil Sie Ihr 95. Perzentil haben, können Sie im Grunde in beide Richtungen gehen.

Drew: Ja, wenn Sie mit der Optimierung für die Nutzung einer Website mit einem Glas Champagner in der Hand beginnen, denken Sie: „Vielleicht verlieren wir uns ein wenig vom Weg.“

Harry: Ja, genau.

Drew: Wir haben ein wenig über die Leistungsmessung gesprochen, und meiner eigenen Erfahrung nach ist es bei der Leistungsarbeit wirklich wichtig, alles zu messen: A, damit Sie erkennen können, wo Probleme liegen, aber B, damit Sie sagen können, ob, wenn Sie tatsächlich anfangen, etwas anzugehen du einen Unterschied machst und wie viel Unterschied du machst. Wie sollten wir vorgehen, um die Leistung unserer Websites zu messen? Welche Tools können wir verwenden und wo sollten wir anfangen?

Harry: Oh Mann, noch eine tolle Frage. Es gibt also eine Reihe von Antworten, je nachdem, wie viel Zeit, Ressourcen und Neigung zur Behebung der Website-Geschwindigkeit vorhanden sind. Was ich also mit dem Kunden versuchen werde, ist … Bestimmte Standardmetriken sind wirklich gut. Ladezeit, kümmere dich nicht mehr darum. Es ist sehr, sehr, sehr ... Ich meine, es ist ein guter Proxy, wenn Ihre Ladezeit 120 Sekunden beträgt. Ich nehme an, Sie haben keine sehr schnelle Website, aber sie ist zu obskur und nicht wirklich kundenorientiert. Ich denke tatsächlich, dass Vitals ein wirklich guter Schritt in die richtige Richtung sind, weil sie zwar die Benutzererfahrung messen, aber auf technischem Input basieren. Largest Contentful Paint ist eine wirklich schöne visuelle Sache, aber die technischen Dinge, die es gibt, entsperren Ihren kritischen Pfad, stellen sicher, dass Heldenbilder schnell ankommen, und stellen Sie sicher, dass Ihre Webfont-Strategie anständig ist. Diese Metriken haben eine technische Unterströmung. Die sind wirklich gut von der Stange.

Harry: Wenn Kunden jedoch Zeit haben, ist es normalerweise Zeit, weil Sie die Daten erfassen möchten, aber Sie brauchen Zeit, um die Daten tatsächlich zu erfassen. Was ich also mit Kunden versuche, ist: „Schauen Sie, wir können die nächsten drei Monate nicht zusammenarbeiten, weil ich ausgebucht bin. Was wir also tun können, ist, Ihnen ganz schnell eine kostenlose Testversion von Speedcurve einzurichten, einige benutzerdefinierte Metriken einzurichten“, was bedeutet, dass ich für einen Verlagskunden, eine Zeitung, messen würde: „Wie schnell war die Überschrift der Artikel gerendert? Wie schnell wurde das Leitbild für den Artikel gerendert?“ Für einen E-Commerce-Kunden möchte ich messen, da Sie offensichtlich Dinge wie den Start des passiven Renderns messen. Sobald Sie beginnen, eine Leistungsüberwachungssoftware zu verwenden, erfassen Sie Ihre tatsächlichen Leistungskennzahlen kostenlos. Also Ihre erste zufriedene Farbe, größte zufriedene usw. Was ich wirklich festhalten möchte, sind Dinge, die für sie als Unternehmen wichtig sind.

Harry: Also, arbeiten wir im Moment mit einem E-Com-Kunden, wo wir in der Lage sind zu korrelieren… Je schneller Sie mit dem Rendern beginnen, wie hoch ist die Wahrscheinlichkeit, dass Sie in den Warenkorb gelegt werden. Wenn Sie ihnen ein Produkt früher zeigen können, werden sie es eher kaufen. Und das ist eine Menge Aufwand, das einzurichten, das ist eine Art Stretch Goal für Kunden, die wirklich ambitioniert sind, aber alles, was Sie wirklich messen wollen, denn wie ich schon sagte, Sie wollen nicht wirklich messen, was Ihr Größtes ist Contentful Paint ist, Sie möchten Ihren Umsatz messen und wurde dieser von Large Contentful Paint beeinflusst? Das ultimative Ziel wäre also alles, was Sie als KPI für dieses Unternehmen sehen würden. Bei Zeitungen könnte es sein, wie weit jemand im Artikel nach unten gescrollt hat. Und korreliert das in irgendeiner Weise mit der ersten Eingangsverzögerung? Haben die Leute mehr Artikel gelesen, wenn CLS niedriger war? Aber bevor wir mit benutzerdefinierten, benutzerdefinierten Metriken beginnen, denke ich ehrlich gesagt, dass Web Vitals ein wirklich guter Ausgangspunkt ist und auch ziemlich gut normalisiert wurde. Es wird ein … Ich weiß nicht, was das Wort ist. Kleinster gemeinsamer Nenner, schätze ich, wo jeder in der Branche jetzt die Leistung auf diesem Level-Playing-Field diskutieren kann.

Harry: Ein Problem, das ich habe, und ich muss eigentlich ein Meeting mit dem Vitals-Team vereinbaren, ist, dass ich Lighthouse auch wirklich großartig finde, aber CLS macht 33 % der Web-Vitals aus. Sie haben LCP, FID, CLS. CLS macht 33 % Ihrer Vitalwerte aus. Vitals ist das, was normalerweise vor Ihrem Marketingteam, Ihrer Analyseabteilung, vorkommt, weil es in der Suchkonsole auftaucht, es wird im Zusammenhang mit Suchergebnisseiten erwähnt, während Vitals betroffen ist, haben Sie eine hohe Gewichtung, 33 %, ein Drittel von Vitals ist CLS, es macht nur 5 % unseres Lighthouse-Scores aus. Was Sie also bekommen werden, sind Entwickler, die um Lighthouse herum bauen, weil es in Tools integriert werden kann, es ist eine Labormetrik. Vitals sind Felddaten, es ist Rum.

Harry: Sie haben also diese massive Unterbrechung, bei der Ihr Marketingteam sagt „CLS ist wirklich schlecht“ und die Entwickler denken: „Nun, es sind 5 % der Lighthouse-Punktzahl, die DevTools mir gibt, es sind 5 % der Punktzahl diese Lighthouse CLI gibt uns in CircleCI“ oder was auch immer Sie verwenden, aber für das Marketingteam sind es 33 % dessen, was ihnen wichtig ist. Das Problem dort ist also ein bisschen wie eine Trennung, weil ich denke, dass Lighthouse sehr wertvoll ist, aber ich weiß nicht, wie sie diesen ziemlich massiven Unterschied in Einklang bringen, bei dem CLS bei den Vitalwerten 33% Ihrer Punktzahl ausmacht … nun, nicht wegen Ihnen haben nicht wirklich einen, und Lighthouse macht nur 5 % aus, und solche Dinge müssen noch ausgebügelt werden, bevor wir diese Diskussion nahtlos führen können.

Harry: Aber wieder lange Antwort auf eine kurze Frage. Vitals ist wirklich gut. LCP ist eine gute Metrik für die Benutzererfahrung, die auf technische Lösungen reduziert werden kann, ebenso wie CLS. Also ich denke, das ist ein wirklich guter Ausgangspunkt. Darüber hinaus sind es benutzerdefinierte Metriken. Was ich versuche, meine Kunden an einen Punkt zu bringen, an dem es ihnen egal ist, wie schnell ihre Website ist, sie kümmern sich nur darum, dass sie seit gestern mehr Geld verdienen, und wenn, dann weil sie schnell lief? Wenn es weniger gemacht hat, weil es langsamer lief? Ich möchte nicht, dass sie einem mystischen Zwei-Sekunden-LCP nachjagen, ich möchte, dass sie dem optimalen LCP nachjagen. Und wenn das tatsächlich langsamer ist, als Sie denken, dann ist das in Ordnung.

Drew: Also, für den Webentwickler, der nur daran interessiert ist… er hat kein Budget, das er für Tools wie Speedcurve und ähnliches ausgeben kann, er kann natürlich Tools wie Lighthouse einfach in seinem Browser ausführen, um eine gute Messung zu erhalten… sind Dinge wie Google Analytics für dieses Niveau nützlich?

Harry: Das sind sie und sie können nützlicher gemacht werden. Analytics erfasst seit vielen Jahren rudimentäre Leistungsinformationen. Und das wird die DNS-Zeit, TCP und TLS, die Zeit bis zum ersten Byte, die Seiten-Download-Zeit sein, die ein Proxy ist … naja, was auch immer, nur die Seiten-Download-Zeit und die Ladezeit. Also ziemlich klobige Metriken. Aber es ist ein guter Ausgangspunkt und normalerweise sage ich bei jedem Projekt, das ich mit einem Kunden beginne, wenn er New Relic oder Speedcurve oder was auch immer nicht hat, einfach „Nun, lassen Sie mich einen Blick auf Ihre Analysen werfen“, weil ich kann zumindest stellvertretend für die Situation von dort. Und es wird nie annähernd so gut sein wie etwas wie Speedcurve oder New Relic oder Dynatrace oder was auch immer. Sie können benutzerdefinierte Metriken sehr, sehr, sehr einfach an Analytics senden. Wenn jemand, der zuhört, in der Lage sein möchte, zu senden … meine Seite zum Beispiel. Ich habe Metriken wie „Wie schnell können Sie die Überschrift eines meiner Artikel lesen? An welchem ​​Punkt wurde das Bild der About-Seite gerendert? An welchem ​​Punkt war der Aufruf zum Handeln, der Sie anfleht, mich einzustellen? Wie schnell wird das auf den Bildschirm gerendert?“ Wirklich trivial, diese Daten zu erfassen und fast ebenso trivial, sie an die Analytik zu senden. Wenn also jemand die Quelle auf meiner Website anzeigen möchte, scrollen Sie nach unten zum abschließenden Body-Tag und suchen Sie das Analyse-Snippet. Sie werden sehen, wie einfach es für mich ist, benutzerdefinierte Daten zu erfassen und an Analytics zu senden. Und in der Analytics-Benutzeroberfläche müssen Sie nichts tun. Normalerweise müssten Sie benutzerdefinierte Berichte einrichten und die Daten auswerten und präsentabel machen. Diese sind ein erstklassiger Bürger in Google Analytics. Sobald Sie also mit der Erfassung benutzerdefinierter Analysen beginnen, gibt es einen ganzen Abschnitt des Dashboards, der diesem gewidmet ist. Es gibt kein Setup, kein schweres Heben in GA selbst, also ist es wirklich trivial, und wenn Kunden ein echtes Budget haben oder ich ihnen vielleicht die Leistungsfähigkeit der benutzerdefinierten Überwachung zeigen möchte, möchte ich nicht sagen „Oh ja, versprochen Es wird wirklich gut, kann ich nur 24 Riesen für Speedcurve haben?“ Ich kann damit beginnen, einfach zu sagen: „Schau, das ist rudimentär. Sehen wir uns hier die Möglichkeiten an, jetzt können wir Sie vielleicht davon überzeugen, auf so etwas wie Speedcurve aufzurüsten.“

Drew: Ich habe oft festgestellt, dass mein Bauchgefühl, wie schnell etwas sein sollte oder welche Auswirkungen eine Änderung haben sollte, falsch sein kann. Ich nehme eine Änderung vor und denke, ich mache die Dinge schneller, und dann messe ich es und tatsächlich habe ich die Dinge langsamer gemacht. Bin das nur ich, der bei Web Perf Müll ist?

Harry: Überhaupt nicht. Ich habe ein wirklich passendes Beispiel dafür. Preload… eine wirklich schnelle Einführung für alle, die noch nichts von Preload gehört haben, das Laden bestimmter Assets im Web ist von Natur aus sehr langsam und die beiden Hauptkandidaten hier sind Hintergrundbilder in CSS und Webfonts, denn bevor Sie ein Hintergrundbild herunterladen können, müssen Sie um das HTML herunterzuladen, das dann das CSS herunterlädt, und dann sagt das CSS: „Oh, dieses div auf der Homepage braucht dieses Hintergrundbild.“ Es ist also von Natur aus sehr langsam, weil Sie diesen ganzen Teil der CSS-Zeit dazwischen haben. Mit Preload können Sie eine HTML-Zeile in das Head-Tag einfügen, die besagt: „Hey, Sie wissen es noch nicht, aber glauben Sie mir, Sie werden dieses Bild wirklich, wirklich, sehr bald brauchen.“ Sie können also einen Preload in den HTML-Code einfügen, der diesen Download präventiv auslöst. Bis das CSS das Hintergrundbild benötigt, ist es wie „Oh cool, wir haben es schon, das ist schnell.“ Und das wird als dieser Web-Performer Messiah angepriesen… Hier ist das Ding, und ich verspreche Ihnen, ich habe das letzte Woche getwittert und seitdem habe ich zweimal recht behalten. Die Leute hören von Preload und dem Versprechen, das es gibt, und es wird auch sehr stark von Lighthouse vorangetrieben, theoretisch macht es Ihre Website schneller. Die Leute sind so mit der Idee des Vorladens verheiratet, dass sie es nicht wieder entfernen werden, selbst wenn ich beweisen kann, dass es nicht funktioniert. Denn „Nein, aber Lighthouse hat gesagt.“ Nun, dies ist eines dieser Dinge, bei denen die Theorie stichhaltig ist. Wenn Sie auf Ihre Webschriftart warten müssen, anstatt sie früher herunterzuladen, werden Sie die Dinge schneller sehen. Das Problem ist, wenn Sie daran denken, wie das Web tatsächlich funktioniert, jede Seite, die Sie zuerst besuchen, jede brandneue Domain, die Sie besuchen, haben Sie eine begrenzte Menge an Bandbreite und der Browser ist sehr schlau und gibt diese Bandbreite richtig aus. Es durchsucht Ihren HTML-Code sehr schnell und erstellt eine Einkaufsliste. Das Wichtigste ist CSS, dann ist es dieses jQuery, dann ist es das … und dann haben die nächsten paar Dinge diese, diese und diese weniger Priorität. Sobald Sie anfangen, Ihr HTML mit Preloads zu laden, sagen Sie dem Browser „Nein, nein, nein, das ist nicht mehr Ihre Einkaufsliste, Kumpel, das ist meine. Du musst gehen und diese holen.“ Diese begrenzte Menge an Bandbreite ist immer noch begrenzt, aber sie wird nicht für mehr Assets ausgegeben, sodass alles geringfügig langsamer wird. Und ich musste das in der letzten Woche zweimal ausbuhen, und immer noch sagen die Leute: „Ja, aber nein, es liegt daran, dass es früher heruntergeladen wird.“ Nein, es wird früher angefordert, aber es stiehlt Bandbreite von Ihrem CSS. Sie können buchstäblich sehen, dass Ihre Webfonts Bandbreite von Ihrem CSS stehlen. Es ist also eines dieser Dinge, wo man den Zahlen folgen muss, muss, muss. Ich habe es schon mal bei einem Großkunden gemacht. Wenn Sie sich das anhören, haben Sie von diesem Kunden gehört, und ich habe ziemlich darauf bestanden: „Nein, nein, Ihre Head-Tags sind in der falschen Reihenfolge, weil es so sein sollte und Sie sie in dieser haben müssen Ordnung, weil es theoretisch darauf hindeutet …“ Sogar in dem, was ich für den Kunden war, wusste ich, dass ich mich für einen Narren hielt. Aufgrund der Funktionsweise von Browsern muss es schneller sein. Also mache ich den Trick, diese Änderung ... für viele Millionen Menschen, und es wurde langsamer. Es wurde langsamer. Und dass ich da sitze und empört darauf beharre „Nein, aber, Browser funktionieren so“, ist nutzlos, weil es nicht funktioniert. Und wir haben es rückgängig gemacht und ich dachte: „Entschuldigung! Ich werde Ihnen das trotzdem in Rechnung stellen!“ Du bist es also überhaupt nicht.

Drew: Folgen Sie diesen Nummern.

Harry: Ja, genau. „Eigentlich muss ich Ihnen mehr berechnen, weil ich viel Zeit damit verbracht habe, es zurückzusetzen, es hat länger gedauert.“ Aber ja, du hast absolut Recht, du bist es nicht, es ist eines dieser Dinge, bei denen … ich es ein paar Mal in viel kleinerem Maßstab gemacht habe, wo ich sagen werde: „Nun, das muss theoretisch funktionieren“ und es funktioniert 'T. Sie müssen nur verfolgen, was in der realen Welt passiert. Deshalb ist diese Überwachung wirklich wichtig.

Drew: Da sich die Landschaft ändert und sich die Technologie weiterentwickelt, führt Google neue Technologien ein, die uns helfen, die Dinge schneller zu machen. Gibt es eine gute Möglichkeit, mit den Änderungen Schritt zu halten? Gibt es Ressourcen, die wir uns ansehen sollten, um unsere Fähigkeiten in Bezug auf Web-Performance auf dem neuesten Stand zu halten?

Harry: Um schnell auf das ganze „Google-Machen“ einzugehen… Ich weiß, es ist ein bisschen augenzwinkernd, aber ich werde mich darauf konzentrieren. Ich tippe gleich zu Beginn auf den Browser. Dinge wie AMP zum Beispiel sind bestenfalls ein nachgedachter Fang einer Lösung. Es gibt keinen Ersatz für den Aufbau einer schnellen Website, und in dem Moment, in dem Sie anfangen, Dinge wie AMP zu verwenden, müssen Sie an diesen nicht standardmäßigen Standards festhalten, die Gnade des AMP-Teams, das seine Meinung ändert. Ich hatte einen Kunden, der ein Vermögen ausgab, um eine Schriftart von einem AMP-Schriftartanbieter zu lizenzieren, der auf der Zulassungsliste von AMP stand, dann entschied AMP irgendwann: „Oh, eigentlich nein, diese Schriftart wird bereitgestellt, wir werden sie jetzt auf die Sperrliste setzen.“ Also hatte ich einen Kunden der stark in AMP und diesen Font-Anbieter investiert hat und sich entscheiden musste: „Nun, machen wir die ganze AMP-Arbeit rückgängig oder verschwenden wir einfach diese sehr große Zahl pro Jahr mit Webfonts?“ bla, bla, bla. Ich wäre also sehr vorsichtig mit jedem … Ich bin ein Google-Entwickler-Experte, aber ich kenne keine Würgeordnung … Ich kann kritisch sein, und ich würde sagen … Vermeiden Sie Dinge, die als Einheitsgröße gefeiert werden -fits-all-Lösung, Dinge wie AMP.

Harry: Und um für eine Sekunde auf jemand anderen loszugehen, Cloudflare hat ein Ding namens Rocket Loader, das in seinem Bestreben AMP-artig ist. Es ist so konzipiert: „Oh, schalten Sie dieses Ding einfach in Ihrem CDN ein, es wird Ihre Website schneller machen.“ Und eigentlich ist es nur ein Ersatz dafür, dass Sie Ihre Website überhaupt erst richtig erstellt haben. Also … um diesen Aspekt anzusprechen, versuchen Sie, so unabhängig wie möglich zu bleiben, wissen Sie, wie Browser funktionieren, was sofort bedeutet, dass Chrome-Monokultur, Sie sind wieder im Schoß von Google, aber wissen Sie, wie Browser funktionieren, halten Sie sich an einige grundlegende Ideologien. Wenn Sie eine Website erstellen, sehen Sie sich die Seite an. Ob in Figma oder Sketch oder wo auch immer, schauen Sie sich das Design an und sagen Sie: „Nun, das ist es, was ein Benutzer zuerst sehen möchte, also werde ich dem nichts entgegensetzen. Ich werde dieses Hauptbild nicht faul laden, weil das dumm ist, warum sollte ich das tun? Denken Sie also nur an „Was möchten Sie, dass der Benutzer zuerst ist?“ Auf einer E-Com-Website wird es dieses Produktbild sein, wahrscheinlich gleichzeitig nav, aber Bewertungen des Produkts, Fragen und Antworten zum Produkt, faules Laden. Stecken Sie das hinter JavaScript.

Harry: Bestimmte grundlegende Arbeitsweisen, die Ihnen unabhängig von der Technologie, über die Sie sich informieren, immer recht geben werden, nämlich „Priorisieren Sie, was Ihr Kunde priorisiert“. Mehr daran zu arbeiten wäre schneller, also stellen Sie dem nichts in den Weg, aber dann mehr taktische Dinge, die die Leute beachten müssen, um auf dem Laufenden zu bleiben … und wieder direkt zurück zu Google, aber web.dev erweist sich als phänomenale Ressource für Framework-unabhängige, Stack-unabhängige Erkenntnisse … Wenn Sie also etwas über Vitals lernen möchten, möchten Sie etwas über PWAs lernen, also ist web.dev wirklich großartig.

Harry: Es gibt tatsächlich sehr wenige leistungsorientierte Publikationen. Calibres E-Mail ist, ich denke, seine vierzehntägige Perf-E-Mail ist einfach phänomenal, es ist eine wirklich gute Zusammenfassung. Behalten Sie die Webplattform im Allgemeinen im Auge, also gibt es die Performance Working Group, die eine Menge Zeug zu GitHub-Vorschlägen hat. Nochmals zurück zu Google, aber niemand kennt diese Website und ihre phänomenale: chromestatus.com. Es sagt Ihnen genau, woran Chrome arbeitet, was die Signale von anderen Browsern sind. Wenn Sie also sehen möchten, was an Prioritätshinweisen gearbeitet wird, können Sie Links zu allen relevanten Bug-Trackern abrufen. Chrome Status zeigt Ihnen Meilensteine ​​für jeden … „Das kommt in MAT8 heraus, das wurde '67 veröffentlicht“ oder was auch immer, das ist eine wirklich gute Sache für ziemlich technische Einblicke.

Harry: Aber ich komme immer wieder auf diese Sache zurück, und ich weiß, dass ich wahrscheinlich klinge wie „Alter Mann schreit Cloud an“, aber bleibe bei den Grundlagen, fast jedes einzelne Pfund oder Dollar, Euro, das ich jemals verdient habe, hat Kunden unterrichtet dass „Sie wissen, dass der Browser das bereits tut, richtig“ oder „Sie wissen, dass das nicht schneller sein könnte“ und das klingt wirklich gerecht von mir … Ich habe noch nie einen Cent davon verdient, zusätzliche Technologie zu verkaufen. Bei jedem bisschen Geld, das ich verdiene, geht es ums Entfernen, Subtrahieren. Wenn Sie feststellen, dass Sie Dinge hinzufügen, um Ihre Website schneller zu machen, sind Sie auf dem falschen Weg.

Harry: Ein typisches Beispiel, ich werde… die großen Werbe-/Suchmaschinen-/Browser-Unternehmen überhaupt nicht nennen, sie nicht nennen, und ich werde das JavaScript-Framework nicht nennen, aber ich bin gerade dabei Diskussionen mit einem sehr, sehr großen, sehr beliebten JavaScript-Framework über das Entfernen von etwas, das aktiv Schaden anrichtet, oder optional über das Entfernen von etwas, das die Leistung einer großen Anzahl von Websites beeinträchtigen würde. Und sie sagten: „Oh, wir werden … jemanden von dieser großen Firma einschalten, weil sie etwas recherchiert haben … und es ist wie „Wir brauchen eine Option, um dieses Ding zu entfernen, weil Sie hier und hier und sehen können hier macht es diese Seite langsamer.“ Und ihre Lösung bestand darin, mehr hinzuzufügen, wie „Oh, aber wenn Sie das auch tun, dann können Sie das umgehen“ und es ist wie „Nein, nein, mehr hinzuzufügen, um eine Website schneller zu machen, muss die falsche Lösung sein. Sie können sicherlich sehen, dass Sie in die falsche Richtung gehen, wenn mehr Code benötigt wird, um eine schnellere Website zu erhalten.“

Harry: Weil es am Anfang schnell war und alles, was Sie hinzufügen, es langsamer macht. Und die Idee, mehr hinzuzufügen, um sie schneller zu machen, obwohl … es sich in einer schnelleren Website manifestieren könnte, ist der falsche Weg. Es ist ein Rennen nach unten. Tut mir leid, ich werde langsam richtig aufgeregt, man merkt, dass ich schon eine Weile nicht mehr geschimpft habe. Das ist also die andere Sache, wenn Sie feststellen, dass Sie Funktionen hinzufügen, um eine Website schneller zu machen, gehen Sie wahrscheinlich in die falsche Richtung. Es ist weitaus effektiver, eine schnellere Website zu erstellen, indem Sie Dinge entfernen, als sie hinzuzufügen.

Drew: Sie haben einen Videokurs mit dem Titel „Alles, was ich getan habe, um CSS Wizardry Fast zu machen“ zusammengestellt.

Harry: Ja!

Drew: Es ist ein bisschen anders als herkömmliche Online-Videokurse, nicht wahr?

Harry: Das ist es. Ich bin ehrlich, es ist teilweise… Ich möchte nicht Faulheit meinerseits sagen, aber ich wollte keinen Lehrplan entwerfen, der sehr starr sein muss und Sie von Null auf Helden bringen muss, weil das so viel Zeit in Anspruch nimmt ist enorm und ich wusste nicht, ob ich Zeit hätte. Was ich also haben wollte, war fertiges Material, nur einen Screencast von mir, wie ich es durchspreche, damit es nicht mit „Hier ist ein Browser und so funktioniert es“ beginnt, also müssen Sie sich dessen zumindest bewusst sein Web-Perf-Grundlagen, aber es sind Hacks und Profi-Tipps und Beispiele aus dem wirklichen Leben.

Harry: Und weil ich keinen vollständigen Lehrplan machen musste, konnte ich den Preis weit nach unten drücken. Es ist also kein großer 10-Stunden-Kurs, der Sie von Null zum Helden bringt, es ist ein Hin und Her, wie Sie es für richtig halten. Es geht im Grunde nur darum, sich meine Website anzusehen, die ein ausgezeichneter Spielplatz für Dinge ist, die instabil sind, oder… es ist sehr risikoarm für mich, dort zu experimentieren. Also habe ich gerade Videoserien gemacht. Es hat eine Menge Spaß gemacht, es aufzunehmen. Ich reiße nur meine eigene Seite herunter und spreche von „Nun, so funktioniert das und so können Sie es verwenden“.

Drew: Ich finde es wirklich toll, wie es in die Lösung verschiedener Probleme aufgeteilt wird. Wenn ich mehr über das Optimieren von Bildern oder was auch immer erfahren möchte, kann ich denken „Ja, was sagt mein Kumpel Harry dazu?“, in das Video über Bilder eintauchen und loslegen. Auf diese Weise ist es wirklich zugänglich, Sie müssen sich nicht stundenlang mit Zeug abfinden, Sie können einfach zu dem Teil gehen, den Sie möchten, und lernen, was Sie lernen müssen, und dann aussteigen.

Harry: Ich glaube, ich habe versucht, es mehr beizubehalten … Der Vorteil, keinen starren Lehrplan zu erstellen, ist, dass Sie sich nicht zuerst ein bestimmtes Video ansehen müssen, es gibt kein Intro, es ist nur „Gehen Sie und sehen Sie sich um und sehen Sie, was Sie interessant finden.“ was bedeutet, dass jemand, der unter LTP-Problemen leidet, sagt: „Oh, nun, ich muss in diesen Ordner hier eintauchen“, oder wenn er unter CSS-Problemen leidet, kann er in diesen Ordner eintauchen. Offensichtlich habe ich keine Statistiken, aber ich kann mir vorstellen, dass es eine hohe Abbruchrate bei Kursen gibt, nur weil Sie sich durch drei Stunden Einführung quälen müssen, falls Sie etwas verpassen, und es ist wie „Oh, weißt du was, ich kann nicht Mach das jeden Tag weiter“ und die Leute brechen vielleicht einfach viele Kurse ab. Mein Gedanke war also, einfach einzutauchen, Sie müssen die vorangegangenen drei Stunden nicht gesehen haben, Sie können einfach gehen und finden, was Sie wollen. Und das Feedback war wirklich, wirklich … Eigentlich werde ich tun, dass es noch nicht existiert, aber ich werde es direkt nach dem Anruf tun, jeder, der den Rabattcode SMASHING15 verwendet, bekommt 15 % Rabatt davon.

Drew: Es ist also fast so, als hätten Sie den Kurs selbst leistungsoptimiert, weil Sie einfach direkt zu dem gewünschten Teil gehen können und nicht alle Verhandlungen führen müssen und-

Harry: Ja, unbeabsichtigt, aber das muss ich mir anrechnen.

Drew: Also, ich habe alles über Web-Performance gelernt, was hast du in letzter Zeit gelernt, Harry?

Harry: Technisches Zeug… nicht wirklich. Ich habe viel auf meiner „zu lernen“-Liste, also QUIC, H3-Sachen, ich würde gerne ein bisschen mehr praktische Kenntnisse darüber bekommen, aber ich habe während der ersten Sperrung in Großbritannien ein E-Book geschrieben, also habe ich gelernt wie man E-Books erstellt, was eine Menge Spaß gemacht hat, weil sie nur aus HTML und CSS bestehen und ich mich damit auskenne, also hat es eine Menge Spaß gemacht. Ich habe für den Kurs sehr rudimentäre Videobearbeitung gelernt, und was mir daran gefallen hat, ist keine konzeptionelle Arbeit. Offensichtlich muss man beim Erlernen einer Programmiersprache mit Konzepten ringen, während das Erlernen eines E-Books nur aus Workflows und… Sachen bestand, an denen ich noch nie herumgebastelt habe, also war es interessant zu lernen, aber es erforderte keinen Berufswechsel , das war also ganz nett.

Harry: Und dann, nicht technisches Zeug… Ich fahre viel Fahrrad, ich falle von vielen Fahrrädern… und weil ich seit letztem März, fast einem Jahr, überhaupt nicht mehr gereist bin, mache ich viel mehr Rad fahren und mich viel mehr darauf konzentrieren… das zu verbessern. Also habe ich viel über Leistungsabgaben und funktionelle Schwellenkräfte geforscht, ich mache gerade ein Trainingsprogramm, also ständig, ständig erschöpfte Beine, aber ich lerne viel über die Physiologie rund ums Radfahren. Ich weiß nicht warum, weil ich nicht vorhabe, etwas anderes damit zu tun, als weiterzufahren. Es war wirklich faszinierend. Ich habe das Gefühl, dass ich während des Lockdowns sehr viel Glück hatte, Plural, aber ich habe es geschafft, aktiv zu bleiben. Viele Menschen werden einfache Dinge wie den täglichen Weg ins Büro verpassen, eine gute Gelegenheit, sich die Beine zu vertreten. Wie Sie wissen, wurde in Großbritannien das Radfahren sehr gefördert, also habe ich viel mehr daran herumgebastelt, mehr über das Fahrradfahren aus einem physiologischeren Aspekt heraus zu lernen, was bedeutet … weiß nicht, ich bin nur ein Nerd mal was anderes zur Abwechslung.

Drew: Gibt es vielleicht nicht einen so großen Unterschied zwischen der Leistungsoptimierung im Web und der Leistungsoptimierung im Radsport, es sind alles marginale Gewinne, oder?

Harry: Ja, genau. Und die Menge an Diagrammen, die ich mir auf dem Fahrrad angesehen habe … Ich habe Leistungsdaten vom Fahrrad, ich gehe auf eine Fahrt und komme zurück wie „Oh, wenn ich hier fünf Watt mehr hätte, aber dann 10 gespart habe Watt dort, ich könnte dies, dies und dies am schnellsten aller Zeiten tun“ und… war ein riesiger Anorak darüber. Aber ja, du hast Recht. Weißt du was, ich glaube, du bist da auf etwas wirklich Interessantes gestoßen. Ich denke, so etwas ist ein guter Sport/Zeitvertreib für jemanden, der ein bisschen obsessiv ist und gerne Zahlen hinterherjagt. Es laufen Dinge, ich meine, das wirst du wissen, aber Strava, du hast deine KOMs. Ich habe letztes Jahr 19 davon eingesackt, was für mich eine phänomenale Menge ist. Und es ist fast alles von der Besessenheit über verfügbare Daten und dem Betrachten von „Dieser Typ, den ich zu schlagen versuche, er hat an diesem Punkt 700 Watt verbraucht, wenn ich auf 1000 kommen und dann abschalten könnte“ und bla, bla, bla … es ist obsessiv. Nerd. Aber du hast recht, ich schätze, es ist eine ähnliche Sache, oder? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

Harry: Ja. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.