Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Web Performance mit Lucas Dohmen und Lisa Maria Schäfer

Hallo Lucas.

Hallo Lisa.

Wir haben Dich schon öfter gesehen zu verschiedenen Themen, auch vor relativ kurzer Zeit zu einem Thema von KI, aber ich würde mir wünschen, dass Du Dich einmal vorstellst für alle die, die Dich noch nicht kennen.

Aber gerne.

Genau, ich bin der Lucas.

Ich bin seit kurzem Principal Consultant bei Swaglab und genau, da beschäftige ich mich wieder mit allen Themen rund ums Web, also Web-Architektur, Web-Entwicklung, effektiv arbeiten zusammen am Web, aber auch so Themen wie Web-Performance, weil das auch ein immer wichtiger werdendes Thema wird.

Genau und ja, ich war schon ein paar Mal zu Gast zu verschiedensten Themen, aber heute wollen wir mal ein bisschen über Web-Performance sprechen.

Genau.

Sehr gut.

Genau, ich habe ganz vergessen zu sagen, Ihr könnt natürlich Eure Fragen gerne hier im Stream stellen, äh im Stream im Chat stellen und wir beantworten sie dann hier.

Lucas hat eine kleine Präsentation vorbereitet.

Ich mache sie schon mal auf und habe glaube ich auf das falsche Layout geklickt, aber das kriegen wir hin.

Genau, aber man kann meinen Stream schon sehen.

Perfekt.

Danke Dir Lisa.

Genau, also das ist ja die ganze Idee von diesem Stream ist ja, dass Ihr gerne jederzeit Fragen stellen könnt, also werft die einfach rein und die Lisa ist Eure Stimme und fragt mich dann, was Euch im Herzen liegt und das könnt Ihr auch jederzeit während dem Stream machen, also Ihr müsst jetzt nicht irgendwie bis zum Ende warten.

Kann halt nur sein, dass ich dann sage, okay, da kommen wir noch zu, machen wir später, aber genau, was auch immer Euch interessiert.

Und falls Ihr keine Fragen habt, unterbreche ich Lucas dann dauernd und frage ihn Sachen.

Können wir auch so machen, Lisa.

Genau.

Perfekt.

Alles klar, dann legen wir einfach mal so los, also das Thema ist Web Performance, wieso und wie und dafür, so jetzt funktionieren auch meine Pfeiltasten, habe ich mir folgende ungefähre Agenda überlegt, also erstmal reden wir über das Wieso, also warum braucht man das überhaupt, wieso ist das wichtig, dann reden wir über Metriken.

Es gibt sehr viele Webmetriken.

Ich habe jetzt einfach mal einen Teil, den ich persönlich auch für sehr wichtig halte, rausgesucht.

Man kann nicht über alle Metriken in so einem kurzen Slot sprechen, deswegen haben wir da so ein bisschen Fokus, aber ich erwähne auf jeden Fall auch noch ein paar andere Metriken.

Dann geht es ein bisschen um Tools.

Auch da gibt es unendlich viele, aber ich stelle einfach mal drei Stück vor, die ich gern benutze.

Und genau, dann gehen wir noch mal ein bisschen in die Praxis, ein bisschen aus, was ich so für Erfahrungen gemacht habe und dann in der Praxis auch, welche Sachen kann man benutzen, um genau die Metriken, über die wir gesprochen haben, dann auch zu verbessern.

Das ist so die Idee.

Aber fangen wir jetzt erstmal mit dem Wieso an.

Genau, also warum sollte man sich mit Web-Performance beschäftigen?

Ich glaube, es ist erstmal so, dass wenn man mit Web-Entwicklerinnen spricht, die wollen natürlich einfach eine schnelle Webseite bauen.

Ich glaube, das ist einfach erstmal so, hat man halt Lust drauf, man möchte, dass es schnell ist.

Da sage ich mal, aus Erfahrung ist es aber so, dass viele sehr schnelle Devices benutzen, wie zum Beispiel jetzt das allerneueste MacBook Pro und das iPhone Pro oder das Google Pixel.

Da lohnt es sich einfach auch mal, das auszupillen auf einem, weiß ich nicht, 300, 400 Euro Android-Telefon.

Mal gucken, wie die Webseite da so ist.

Aber ich glaube, erstmal ist da das Interesse für da.

Aber wie kann ich denn vielleicht auch andere Stakeholder davon überzeugen, dass das ein wichtiges Thema ist?

Und da habe ich jetzt einfach mal drei Aspekte rausgesucht.

Es gibt auch noch mehr, aber das sind jetzt drei, die für mich so mir ins Auge stechen.

Das eine ist halt wirklich, geht es ums Geld?

Also es gibt dazu viele verschiedene Untersuchungen, dass umso schneller die Webseite ist, umso eher kommt es zu Conversions in einem Prozess.

Also wenn die Leute dann merken, okay, es ist irgendwie lahm und laggy, dann brechen sie irgendwann auf dem Weg ab und dann haben wir die Leute halt verloren.

Ich habe jetzt hier mal einen Bericht dazu von Cloudflare verlinkt, aber da gibt es auch einen relativ bekannten noch von Amazon, der ein bisschen älter ist, die da halt auch Untersuchungen so angestellt haben.

Also wenn ihr diesen Punkt machen wollt bei Leuten, die ihr überzeugen wollt, da gibt es echt viele tolle Ressourcen zu, die ihr benutzen könnt, um Leute davon zu überzeugen.

Der zweite Aspekt, der noch nicht immer so war, aber jetzt halt seit ein paar Jahren schon so ist, ist, dass tatsächlich die Webperformance euer SEO-Ranking beeinflusst.

Es gibt eben ein paar Metriken, über die wir gleich sprechen werden, die benutzt Google, um das Ranking zu verbessern oder zu verschlechtern.

Also wenn eure Seite zu langsam ist, wird sie halt heruntergestuft.

Und das ist natürlich auch ein ausstattgebender Faktor für ganz viele Unternehmen, zu überlegen, hey, wir investieren da rein, einfach damit wir auf diesen Suchmaschinen, also vor allem jetzt in dem Fall Google, einfach sehr weit oben erscheinen.

Wie das jetzt bei allen anderen Suchmaschinen ist, muss man halt nochmal separat sich anschauen, aber es ist halt einfach, Google ist einfach immer noch die wichtigste Suchmaschine, deswegen einfach am wichtigsten.

Und dann ist es einfach auch eine Frage von User Experience.

Also wenn ich irgendwie eine Webseite benutze und die ist total lahm und so weiter, dann habe ich da auch irgendwann keinen Bock mehr drauf.

Dann werde ich auf jeden Fall auch nicht begeistert von diesem Produkt erzählen, weil ich einfach denke, jedes Mal klicke ich und es dauert 100 Jahre.

Aber das ganze Thema kann man auch noch viel weiter fassen.

Es ist auch ein Thema von Accessibility.

Wenn zum Beispiel die Seite total, also die Sachen sich verschieben, wenn die Seite nachlädt, dann kann es halt sein, dass jemand, der ein bisschen zittrige Hände hat, sich irgendwie verklickt und wo ganz anders landet.

Es geht auch darum, dass Leute, die langsame Devices haben, trotzdem unsere Webseite benutzen können, weil sie einfach so schnell ist, dass sie auch auf einem langsamen Device funktioniert.

Das eröffnet auch nochmal ein anderes Publikum, das vielleicht sonst unsere Webseite oder unsere Webapplikation gar nicht benutzen könnte oder wollte.

Das ist ein wirklich weites Feld.

Hier ist jetzt nochmal ein Blogpost von Google verlinkt, wo die eben den Einfluss auf Engagement, also wie sehr interagieren die Leute mit einem Produkt, beschreiben.

Aber da gibt es auch ganz viele Berichte von verschiedenen, auch großen und kleinen Firmen, dass das einfach einen riesigen Unterschied macht.

Und ich glaube, das kann auch jeder von uns nachempfinden.

Es macht einfach mehr Spaß, wenn man nicht dauernd irgendwie das Gefühl hat, alles dauert ewig, sondern es geht einfach super flüssig.

Das sind jetzt so drei Aspekte, aber es gibt natürlich auch noch jede Menge mehr, wenn man sich da was zu überlegen möchte.

Gut, also das ist das Wieso.

Dann würde ich sagen, schauen wir uns direkt erstmal Metriken an.

Was gibt es denn da so für Metriken?

Und ich hatte überlegt, dass wir das vielleicht einmal anhand dessen besprechen, wie sich so eine Webseite aufbaut.

Von ich gebe es irgendwie in die Suchmaske ein, bis ich fange an, sie zu benutzen.

Weil einige der Metriken sind quasi auf diesem Zeitstrahl von gestartet bis einsatzbereit untergebracht.

Und deswegen bietet sich das, glaube ich, an, das anhand dessen zu betrachten.

Also es startet damit, entweder ich mache meinen Webbrowser auf, tipps oben die Browserleiste, drücke Enter.

Oder ich komme von der Suchmaschine mit einem Link.

Oder ich bin innerhalb meiner Webanwendung und klicke irgendwo drauf und es passiert irgendwas.

Also das, was ich jetzt beschreibe, ein Teil davon ist wirklich nur für den ersten Kontakt mit unserer Webseite.

Also wenn man von außen kommt und nicht innerhalb der Webseite navigiert.

Aber einiges davon ist auch innerhalb von Navigation von der Webseite.

Aber das unterscheidet sich natürlich auch in eurer Architektur, je nachdem, ob ihr Frontend rendert oder ein Backend rendert.

Deswegen, wir nehmen jetzt mal den Fall, der wirklich für alles gilt, den ersten Besuch unserer Webseite.

Und da ist jetzt erstmal so, wir müssen erstmal die Verbindung aufbauen.

Klar, also der Webserver und unser Client, unser Browser, die müssen erstmal miteinander sprechen.

Dafür ist der erste Schritt die DNS-Auflösung.

Dann bauen wir eine TCP-IP-Verbindung auf, beziehungsweise, wenn es jetzt ganz fancy ist, auch eine UDP-Verbindung für das ganz moderne HTTP3.

Und dann gibt es eben auch noch den Schritt von der TLS-Negotiation, also das Aufbauen einer sicheren Verbindung zwischen dem Browser und dem Server.

Und das ist auch erstmal ein Punkt, der ist einfach ein Fakt quasi.

Also da kommen wir halt erstmal nicht drum rum.

Wir können da aber auch schon dran rumschrauben, können wir gerne nachher nochmal besprechen, wenn wir in die, wie kann ich das schneller machen, Diskussion einsteigen.

Genau, und nachdem die Verbindung aufgebaut war, schickt der Server eine Response zurück.

Und da passieren halt auch nochmal Dinge.

Also oftmals ist es irgendein Datenbankzugriff, der sucht jetzt irgendwie die Blogposts aus der Datenbank raus, die Titel oder was auch immer.

Dann gibt es irgendeine Logik, die das verarbeitet und am Ende wird HTML generiert.

Also das ist auch der Fall, wenn ihr eine Angular-App oder eine React-App baut.

Ihr müsst ja trotzdem erstmal irgendeine Art von HTML ausliefern.

Genau, also das passiert da alles.

Und wenn das alles passiert ist, oder je nachdem, wie es aufgebaut ist, auch während das noch passiert, schicken wir die ersten Bytes an unseren Browser.

Und wenn das erste Byte beim Browser ankommt, dann sprechen wir von der Time to First Byte.

Das erste Byte ist angekommen und jetzt kann der Browser irgendwas damit tun.

Und dann geht es halt von da aus weiter.

Genau.

Bisher keine Frage.

Doch, es gibt eine Frage und in dem Zuge stelle ich gleich die Frage und sage noch was.

Die Folien könnt ihr euch im Nachgang bei uns auf der Homepage runterladen, also www.software-architektur.tv.

Und die erste Frage kommt von Veritogen auf YouTube.

Warum ist ttfb im Vergleich zu Time to Last Byte interessant?

Damit ist ja nicht aller Inhalt direkt auf dem Endgerät, Nachladen von weiteren Inhalten via Paging oder ähnliches mal ausgeklammert.

Das ist eine sehr gute Frage.

Also aus meiner Sicht ist der Grund, warum das interessant ist, wir müssen nicht unbedingt eine vollständig aufgebaute Webseite haben, damit die Leute anfangen können, was davon zu haben.

Also sagen wir jetzt mal, die Seite wird schrittweise geschickt und die obersten drei Artikel in meinem Blog, da sind die Titel und alles, werden schon geschickt und der Rest wird ein bisschen später nachgeschickt.

Dann wäre es ja trotzdem so, dass wenn ich noch nicht scrolle, ich schon das sehen kann, was ich sehen möchte.

Und deswegen geht es nicht darum zu optimieren, dass der letzte Byte bei unserem Browser angekommen ist, sondern dass man schon die relevanten Inhalte sieht.

Dabei ist die Time to First Byte natürlich noch nicht relevant für unsere User, weil die wollen nicht einen Byte haben, die wollen irgendwas sehen können.

Aber, und darum kommen wir jetzt auch schrittweise dorthin, dass die Leute was sehen.

Wenn wir analysieren wollen, wo sind unsere Performance Probleme, dann ist es natürlich so, dass dieser Zeitrahmen, über den wir jetzt sprechen, also das erste Byte kommt an.

Wenn der schon sehr, sehr lang ist, dann ist auch alles danach langsam.

Aber dann wissen wir, da müssen wir untersuchen.

Hier müssen wir rausfinden, wie wir das schneller machen.

Und deswegen ist das aus meiner Sicht wichtig, das zu betrachten, auch wenn das vielleicht nicht eine Metrik ist, die jetzt direkt User Facing direkte Vorteile hat.

Aber sie hilft uns einfach, die Probleme zu erkennen.

Wir hatten das auch zum Beispiel bei Projekten, dass es immer das Problem war, also dass dieser initiale Aufbau, also der initiale Senden des ersten Teils der Response einfach sehr langsam war.

Und das hat alles andere verzögert.

Und dann ist es eben wichtig, das zu wissen.

Okay, dann mache ich weiter.

Ja, cool.

Wenn da noch andere Fragen sind, gerne weiterfragen.

Genau, das ist die Time to First Byte.

Jetzt ist die da.

Und jetzt passiert etwas ganz Wichtiges, und das ist, dass weitere Sachen noch geladen werden.

Das liegt daran, in HTML sind Sachen referenziert.

Und wenn der Browser die findet, dann fängt er an, neue Requests rauszuschicken.

Auch hier gibt es verschiedene Optimierungen, über die wir später sprechen können.

Aber erstmal müssen wir feststellen, dass es bestimmte Sachen gibt, die dafür sorgen, dass nicht weiter gerendert wird.

Das kann zum Beispiel sein, wenn ihr oben ein CSS ladet, ganz normal, dann stoppt das Rendern an der Stelle.

Er lädt erstmal das CSS, interpretiert es und erst dann macht es weiter.

Das hat den Vorteil, dass die Seite dann direkt so aussieht, wie sie aussehen soll, weil das CSS hinzugefügt wird.

Hat aber den Nachteil, dass wir darauf warten müssen.

Das heißt, wenn dieses CSS-Laden sehr lange dauert, dann verzögert das halt, dass man was sieht auf dem Bildschirm, weil erstmal nur CSS heruntergeladen wird.

Und damit verwandt es auch das Laden von Fonts.

Es gibt in Browsern, könnt ihr entweder einen Font benutzen, der auf dem System vorinstalliert ist.

Das sind diese Websave-Fonts.

Dann ist dieser Schritt vollständig übersprungen.

Dann brauchen wir darüber überhaupt nicht nachzudenken.

Aber wenn ihr jetzt einen Webfont herunterladet, dann machen das aktuell, glaube ich, alle Browser so, dass sie in der Standardeinstellung quasi den Text erstmal ausblenden, wenn der in diesem Font dargestellt werden soll.

Und dann erst einblenden, wenn der Font geladen ist.

Da gibt es auch wieder Einstellungen, das zu ändern.

Aber das ist auch erstmal etwas, was blockieren kann, dass man etwas sieht.

Weil der Text einfach noch nicht da ist, wenn der Font nicht geladen wurde.

Genau.

Und deswegen ist das halt eine kritische Zeit, in der wir überlegen müssen, also im Prinzip müssen wir darüber nachdenken, welche Sachen halten wir für so kritisch, dass sie jetzt das Laden aufhalten sollten, damit beispielsweise alles schon schick aussieht.

Und welche Sachen können wir vielleicht auch später laden, damit es eben uns nicht blockiert, bevor der erste Teil des Inhalts angezeigt wird.

Und wenn der angezeigt wird, dann reden wir über den First Contentful Paint.

Das ist quasi das erste Mal, dass irgendwas Inhaltliches auf der Webseite zu sehen ist.

Also könnte der Titel sein, könnte auch ein erster Werbeblock sein, je nachdem, was ihr da so gebaut habt.

Aber genau, das ist dieser Zeitpunkt, der FCP-Zeitpunkt.

Genau.

Das ist unsere zweite Metrik.

Also wir haben jetzt schon zwei kennengelernt.

Die dritte Metrik kommt, nachdem wir…

Also jetzt laden sich verschiedene Sachen.

Und das ist halt auch wichtig, auch um mal auf die Frage zurückzukommen von eben.

Es gibt einfach Sachen, die müssen nicht alle geladen sein, damit wir die Webseite schon sehen können.

Also ein gutes Beispiel dafür sind so Lazy Images, die sich erst laden, wenn wir hinscrollen.

Das wäre jetzt ein Beispiel.

Die laden sich, nachdem die Seite schon da ist irgendwie.

Aber wenn wir sagen, hey, das Bild soll sofort geladen werden, dann ist es halt wieder ein anderer Fall, weil dann warten wir halt da drauf.

Und deswegen, das ist, glaube ich, eine Metrik, die sehr stark von Google getrieben wurde, gibt es halt diese Idee, wann ist das größte Element zu sehen, das im Viewport zu sehen ist?

Und das ist erst mal, das kann alles Mögliche sein eigentlich.

Also wenn wir uns jetzt überlegen, ohne dass ich scrolle, das ist der Viewport, ohne dass ich scrolle, was kann ich sehen und was davon ist am größten?

Und so in diesen klassischen Designs wäre das zum Beispiel so ein Hero Image.

Wir haben jetzt irgendwie oben so ein Bild, was irgendwie die Leute dazu anregen soll, unseren Blogpost zu lesen oder so.

Das kann oft das große Bild sein.

Lustigerweise ist es auch sehr oft der Cookie Banner, weil der Cookie Banner, der ist ja auch auf jeden Fall zu sehen, aus rechtlichen Gründen.

Und der ist ja manchmal sehr, sehr groß.

Und wenn der jetzt die Hälfte des Bildschirms einnimmt, dann ist das das largest Content for Paint, weil das einfach sehr, sehr groß ist.

Es kann aber auch Text sein.

Ihr habt einen sehr, sehr großen Font gewählt und da steht irgendein großer Text und der ist größer als euer Logo.

Dann wäre das das largest Content for Paint.

Ich finde diese Metrik so ein bisschen blöd, weil die eigentlich, wird da viel rumgetrickst, damit man dann halt dieses eine Element irgendwie schneller lädt.

Eigentlich wollen wir ja ausdrücken, man kann irgendwie schon die wichtigsten Sachen sehen.

Aber das Größte ist immer das Wichtigste.

Aber es ist halt die beste Annäherung, die man automatisiert irgendwie finden kann, weil das eben nachempfindbar ist.

Dabei ist auch wichtig zu verstehen, dass das LCP auf verschiedenen Bildschirmgrößen durchaus ein verschiedenes Element sein kann.

Stellt euch vor, ihr habt in eurer mobilen Ansicht, ist das Logo ganz, ganz klein und darunter ist irgendwie ein Titel ganz groß.

Und auf eurem Desktop Ansicht habt ihr euer Logo richtig groß gezogen.

Dann wäre halt das LCP Element unterschiedlich.

Aber deswegen ist halt das LCP Element abhängig von der Bildschirmgröße.

Wir haben im Chat eine Anmerkung, eine Frage und noch eine Anmerkung.

Ich würde das mal nacheinander vorlesen.

Sven schreibt, es geht um Web-Performance.

Was mich am meisten stört, ist der Layout-Shift.

Darauf muss man achten.

Provokant Neugierig hat dann geantwortet.

Ich glaube, das war darauf vielleicht, aber auch auf was du gesagt hast.

Wurden die Probleme nicht mit HTTP 2 gefixt?

Ich bin da nicht im Detail drin.

Vielleicht möchtest du da schon was zu sagen, weil danach der Kommentar ist zu Bilder.

Genau, also grundsätzlich das Layout-Shift, da kommen wir gleich noch zu.

Es ist auf jeden Fall etwas, was viele Leute stört.

Definitiv.

Aber sprechen wir gleich nochmal drüber.

HTTP 2 hat ein paar Dinge gefixt, aber definitiv kann es bestimmte Sachen nicht fixen.

Ich glaube, das ist irgendwie im Kopf bei manchen abgespeichert.

Seit HTTP 2 müssen wir uns um ganz viele Sachen gar keine Sorgen mehr machen.

Das stimmt nicht so ganz, weil wenn ihr euch überlegt, ihr schickt ein Request an den Server, er kriegt HTML zurück und in dem HTML steht eine CSS-Datei verlinkt.

Dann kann erst ab dem Zeitpunkt, wo man weiß, diese CSS-Datei wird benötigt, kann diese CSS-Datei heruntergeladen werden.

Und in der CSS-Datei ist jetzt ein Font verlinkt.

Dann kann auch erst dann der Font heruntergeladen werden.

Man kann das eben mit Early Hints und so weiter machen.

Da kommen wir gerne in der Diskussion zu.

Aber HTTP 2 löst das nicht magisch.

Also wenn ihr nichts tut, dann sind all diese Probleme nicht gelöst.

Das, was HTTP 2 gelöst hat, ist, dass wir leichter mehrere Sachen parallel herunterladen können, ohne dass sie sich blockieren.

Und das ist bei HTTP 3 tatsächlich noch besser.

Aber es ist keine magische Lösung, die dazu führt, dass ihr euch darum keinen Gedanken mehr machen müsst.

Das ist ganz wichtig.

Wenn es nicht hilft, sagt Bescheid, dann stellen wir mal eine Nachfrage.

Sven hat sich schon bedankt, dass du später noch auf das Layout-Shift zurückkommen wirst.

Und er hatte noch geschrieben, Bilder würde ich immer im WebP machen.

Genau.

Wenn wir über Optimierungsmaßnahmen sprechen und wir reden zum Beispiel über, dass Bilder ein Problem sind, weil die zu groß sind, dann ist definitiv WebP eine Option, um die Bilder kleiner zu bekommen. weil Latenz ein größeres Problem ist als Bandbreite.

Aber es ist trotzdem ein wichtiger Hinweis.

Also ich würde trotzdem empfehlen, Bilder zu optimieren, ganz klar.

Aber es ist nicht die vollständige Lösung für das Problem.

Und ihr könnt euch mittlerweile auch noch andere Optionen angucken, wie zum Beispiel AVIF, A-V-I-F.

Das ist ein alternatives modernes Bildformat, was auch noch, also teilweise kleiner ist als VP, auch noch als Option.

Und da entwickelt sich auch immer noch mehr.

Also das ist noch nicht abgeschlossen, das Thema Bildformate.

Das denkt man immer zwischendurch, aber es kommen immer doch noch mal neue Sachen raus.

Und der Browsersupport ist halt mittlerweile für sowohl AVIF als auch VP extrem gut.

Das heißt, wir sind, glaube ich, jetzt bei 95 Prozent für beide.

Das heißt, da könnt ihr schon davon ausgehen, dass die meisten Leute diese Bilder sehen können.

Wenn wir jetzt über sowas wie JPEG XL reden oder so, dann ist es halt leider irgendwie 20 Prozent.

Auch wenn das eben vielleicht noch kleiner wäre.

Ist halt schade.

Genau.

Super.

Provokant neugierig bedankt sich noch für die Early Hints.

Das war neu für die Person.

Freut mich.

Cool.

Genau, ich hatte, glaube ich, zuletzt gesagt, das ist der Largest Contentful Paint.

Und das ist die erste von den drei sogenannten Core Web Vitals.

Die Core Web Vitals ist einfach eine Definition von Google.

Das ist kein allgemeiner Industriestandard.

Aber dadurch, dass Google sehr einflussreich ist, ist es im Prinzip zu so einem quasi Standard geworden, wie man Web Performance betrachtet.

Und Google versucht, in drei Metriken abzubilden, wie performant, wie schnell fühlt sich diese Seite an.

Das wollen sie quasi abbilden.

Und sie haben sich dafür entschieden, Largest Contentful Paint als eines dieser Ziele zu definieren.

Und wenn ihr eben ein gutes Search Ranking haben wollt, dann möchte Google, dass ihr das innerhalb von unter 2,5 Sekunden der Largest Contentful Paint abgeschlossen wird.

Das ist quasi der erste Timestamp, der sie interessiert.

Und warum reden wir dann überhaupt über sowas wie die Time to First Byte?

Wie gesagt, weil wenn die langsam ist, dann wird auch euer Largest Contentful Paint langsam sein.

Das ist einfach nur noch mal quasi diese Zeit runtergebrochen in kleinere Stücke, damit ihr besser untersuchen könnt, wo ist das Problem.

Weil sagen wir jetzt mal, eure Time to First Byte ist sensationell gut, dann wird irgendwas anderes das Problem sein, was danach passiert.

Und deswegen ist es so interessant, noch mal mehr kleinere Timestamps sich zu betrachten und nicht nur den einen, wo Google halt den Stempel drauf gesetzt hat.

Oder ich habe jetzt ein Sternchen draus gemacht.

Genau.

Waren da noch weitere Fragen?

Sven hat nur geschrieben, ja, finde ich sehr wichtig.

Loading State macht einen Unterschied.

Die Browser entwickeln sich weiter.

Es geht um Priorität.

Genau.

Also über deine Bildvariation.

Genau.

Danke Sven.

Dann schauen wir uns weiter an, was passiert.

Also jetzt ist der Largest Contentful Paint abgeschlossen.

Und jetzt gibt es einen Zeitpunkt, der heißt Time to Interactive.

Und das ist der Zeitpunkt, wo eure Webseite bereit dazu ist, User Input entgegenzunehmen.

Sagen wir jetzt mal, wir haben einen Link.

Den kann ich anklicken und es passiert etwas.

Oder wir haben einen Button und ich kann draufklicken und es passiert etwas.

Oder ich habe ein Textfeld und ich kann dort Text eintippen.

Das ist halt die Zeit, bis es interaktiv wird.

Und hier muss man sich einfach noch mal klar machen, wenn wir in der gesamten Seite kein JavaScript verwenden würden, dann ist der Zeitpunkt derselbe.

Weil jetzt ist, also die Seite kannst du direkt mit interagieren.

Aber es gibt eben, je nachdem wie wir JavaScript verwenden, kann es eben sein, dass diese Events abgefangen werden und man eben noch nicht mit der Seite interagieren kann und erst später damit interagieren kann.

Da gibt es ganz viele verschiedene Optionen, wie wir unsere Seite entwerfen können, wie das funktioniert.

Aber wir sollten uns einfach darüber bewusst sein, dass das hier eigentlich das ist, was die meisten Leute wollen.

Die wollen irgendwas mit eurer Webseite machen.

Es ist vielleicht noch mal ein bisschen was anderes, wenn ihr eine Content-Seite habt, wie jetzt eine Zeitung.

Da wollen die meisten Leute einfach nur scrollen und lesen, was da steht.

Die wollen gar nicht so viel interagieren.

Aber wenn ihr so eine Anwendung habt, mit der man interagiert, dann ist das ja der entscheidende Punkt.

Wann kann ich jetzt auf diesen Knopf drücken?

Und deswegen ist es einfach wichtig, das im Blick zu halten.

Und da würde ich behaupten, ist der Hauptfaktor immer das JavaScript.

Also wie kann ich dafür sorgen, dass das JavaScript so gebaut ist, dass dieser Main-Thread im Browser nicht blockiert ist?

Weil das bedeutet, dass man interagieren kann mit der Webseite.

Wenn der blockiert ist, dann passiert nichts, wenn ich rumklicke und so weiter.

Und das ist eben der Punkt, mit dem ihr euch beschäftigen solltet.

Und da gibt es verschiedenste Lösungsersätze.

Dafür reicht die Zeit heute auf jeden Fall nicht, das alles zu besprechen.

Aber ich finde es wichtig, den zu messen und zu betrachten.

Genau.

Hier gab es noch eine Anmerkung zu Lighthouse.

Lighthouse als Begriff, kommen wir nachher nochmal drauf zurück.

Aber da kommen halt alle Sachen, die ich jetzt als Core Web Vitals bezeichne, die fließen da halt mit ein in diesen Score, den es da so gibt.

Jetzt höre ich auf zu lesen, dieser Versprochen.

Sehr gut.

Gut, dann sprechen wir jetzt mal über diese Core Web Vitals.

Wir haben das erste jetzt schon kennengelernt.

Das war der Largest Contentful Paint.

Das ist, wie gesagt, war ja auch die Frage am Anfang, gar nicht der Zeitpunkt, wo die gesamte Seite geladen ist, sondern wirklich nur, also mental würde ich sagen, es geht darum, dass man alles sieht, was im Viewport zu sehen ist.

Das ist quasi das Ziel.

Und so, wie das gemessen wird, ist es halt das größte Element, weil das war halt wahrscheinlich am einfachsten automatisch zu messen für Google.

Aber es gibt noch zwei weitere Core Web Vitals.

Der zweite ist das, wo, ich glaube, das war provokant neugierig, zugefragt hatte, das ist eben diese Layout-Verschiebung.

Und ich glaube, das hat jeder von uns schon mal frustriert festgestellt.

Also oftmals ist das Schuldige dafür, sind irgendwelche Werbe-Banner, die nachgeladen werden.

Also wir lesen irgendwie einen Zeitungsartikel und auf einmal rückt der ganze Text runter, weil jetzt noch irgendwie so ein Werbeblock nachgeladen wurde oder sowas.

Und erst mal kann sich, glaube ich, jeder reinversetzen, dass es einfach nur eine frustrierende User Experience ist.

Du willst halt auch auf etwas draufklicken und auf einmal klickst du daneben, weil sich alles verschoben hat.

Das ist halt total nervig.

Und dafür, das soll das eben abbilden, weil das einfach eine frustrierende User Experience ist, wenn sich alles verschiebt.

Genau.

Und das ist im Prinzip, könnt ihr euch das vorstellen, das ist eine Zahl, die versucht abzubilden, wie viel hat sich quasi verschoben.

Aber das ist keine Zeiteinheit.

Deswegen habe ich es auch nicht auf diesen Zeitstrahl eingetragen, sondern es ist halt quasi ein Verschiebungsfaktor, wie sich alles verschoben hat.

Genau.

Und die dritte Metrik ist die Interaction-to-Next-Paint.

Und die ist so ein bisschen so ähnlich wie das, was ich hier eben vorgestellt habe, die Time-to-Interactive.

Also ab wann kann ich mit der Seite interagieren.

Das wurde aber durch Interaction-to-Next-Paint ersetzt in den Core Web Vitals vor, ich kann mich nicht mehr daran erinnern, zwei, drei Jahren, weil es oft so war, dass Webseiten rumgetrickst haben, um diesen Zeitpunkt super schnell zu bekommen, damit sie einen guten Score bekommen, aber trotzdem die User Experience so war, dass man nicht mit der Seite interagieren kann.

Und deswegen hat Google quasi nachgelegt und versucht, das nochmal anders darzustellen.

Und da sind auch ganz viele Webseiten auf einmal abgesackt in ihren Core Web Vitals, weil IMP gerade bei Single-Page-Applications oft ein Problem ist.

Also weil es eben misst, wenn ich mit bestimmten Elementen interagiere, wie schnell passiert dann auch etwas, nachdem ich da drauf geklickt habe.

Und zwar macht es das nicht mit einem Element, sondern mit mehreren Elementen und bildet daraus dann eine Zahl, und zwar die langsamste von diesen Interaktionen.

Und das ist dann oft ein Problem, weil dann passiert halt nichts, nachdem ich auf irgendwas drauf geklickt habe.

Genau.

Und deswegen ist IMP jetzt ein größerer Faktor geworden oder ein schwierigerer Faktor geworden für einige Webseiten.

Aus meiner Sicht ist IMP quasi, könnten wir nochmal einen ganzen Stream draus machen für eine Stunde, nur um darüber zu sprechen, weil es ein bisschen komplizierter ist, da auf die Details einzugehen.

Aber das ist das, was dahinter steckt.

Es geht einfach darum, abzubilden, wie schnell wird die Seite interaktiv.

Darum geht es.

Gab es noch was?

Sven hat geschrieben, dass er sich wünschen würde, dass mehr Leute dieses Thema ernst nehmen, ein besseres Web.

Und dann hat er noch geschrieben, Layout-Shifts sind mein Erzfeld.

Ja, auf jeden Fall.

Kann ich nachvollziehen.

Sind auf jeden Fall ein großes Problem bei ganz vielen Seiten.

Ist auch ganz interessant, nur so als Nebenanmerkung, geht auch mal auf Webseiten und macht euren Adblocker aus, weil die meisten Leute haben keinen Adblocker und die nehmen das Web ganz anders wahr, weil Adblocker halt auch oft dafür sorgen, dass es weniger Layout-Shifting gibt, weil halt die Werbebanner nicht mehr da sind und die shiften halt oft euren Inhalt.

Aber es gibt auch andere Sachen, die den Layout-Shift beeinflussen können.

Darüber reden wir auf jeden Fall heute auch noch.

Nur als Anmerkung.

Aber ja, ich möchte auch, dass das mehr Leute ernst nimmt.

Deswegen mache ich diesen Vortrag.

Bin ich deiner Meinung.

Cool.

Dann reden wir mal ein bisschen über Tools.

Also es gibt viele verschiedene Werkzeuge, also echt unendlich viele.

Ich habe jetzt einfach mal drei mitgebracht, die ich einfach schon oft benutzt habe und mit denen ich einfach gut zurechtkomme.

Soll nicht heißen, dass die anderen schlecht sind.

Also es gibt einfach unendlich viele und jeder sucht sich da irgendwie was raus.

Genau.

Und das Erste auf der linken Seite, was da abgebildet ist, ist Lighthouse.

Und das ist das, was eben auch schon im Chat erwähnt wurde.

Das glaube ich, so ein bisschen zu so einem Wettbewerb geworden ist.

Wie schaffe ich es, dass da oben 400 stehen?

Und dann habe ich es geschafft.

Dann gibt es auch so ein kleines Feuerwerk und dann freut man sich.

Also das ist so ein bisschen eine Gamification von dem Thema.

Und dabei ist es wichtig zu betonen, wie man hier auf diesem Screenshot sieht, Performance ist nur eine von den vier Lighthouse-Metriken, über die wir sprechen.

Es gibt eben auch noch eine Accessibility-Metrik, Best Practices und eine Seometrik.

Und das geht über unser Thema heute hinaus.

Wir reden jetzt wirklich nur über die linke Bubble.

Aber trotzdem kann euch Lighthouse schon mal ein paar Informationen bieten.

Und Lighthouse könnt ihr benutzen in jedem Chromium-basierten Browser.

Also beispielsweise Vivaldi oder der hippe Browser, der ARC und was weiß ich.

Die sind ja alle Chrome-basiert.

Die haben das alle drin, wenn ihr einfach aufmacht.

Und da sind auch schon erste Informationen drin.

Ich zeige euch das jetzt einfach mal an einer Webseite, die, glaube ich, die meisten kennen.

Die Tagesschau, da habe ich das jetzt einfach schon mal ausgeführt, damit wir jetzt nicht zusammen auf den Ladebildschirm warten.

Aber grundsätzlich gehe ich halt hier auf Lighthouse und dann führe ich das aus.

Und dann sehe ich halt hier, okay, der hat einen Performance-Score von 49 und hier kommen jetzt schon Begriffe, die wir jetzt kennengelernt haben.

Hier steht jetzt sowas wie First Contentful Paint, und so weiter.

Das heißt also, wir sehen, darum ist das relevant, weil die brechen das auch genauso wieder runter wie wir.

Und dann gibt es uns sogar schon erste Tipps oder erste Hinweise, was ist besonders kaputt an unserer Webseite, um es jetzt ein bisschen überspitzt auszudrücken.

Das ist auf jeden Fall ein super Werkzeug, wenn ihr Sachen auf eurem eigenen Rechner schon mal untersuchen wollt.

Also ihr entwickelt lokal die Webseite und wollt schon mal gucken, wie sieht es aus, könnt ihr das einfach lokal laufen lassen.

Total praktisch.

Und es ist eben das, was nachher auf den SEO-Score Einfluss hat.

Aber und das ist der Grund, warum wir uns nicht nur darauf verlassen sollten, ist eben, das ist unser eigener Rechner.

Sagen wir jetzt mal, wir sitzen in einem Büro mit einer Glasfaser und so weiter, dann sind die Scores auf jeden Fall schon mal besser, weil das Laden natürlich schon mal schneller geht.

Das heißt, wir dürfen uns hier nicht von unserer sehr guten Inhaltsverbindung und unserer sehr guten Hardware in Sicherheit bieten lassen, dass wir jetzt einen guten Score haben.

Der könnte schlecht sein, auf einem langsamen Rechner in einem ömmeligen DSL-Netz oder sowas.

Also das als Hinweis.

Und das bringt uns auch direkt zum zweiten Tool.

Das heißt aber auch, wenn ich jetzt bei mir Tagesschau noch mal untersuchen würde, könnte es sein, dass sie gar nicht so schlecht ausfallen, sondern dass wir bei mir vielleicht ein 80 kriegen, weil du besonders schlechtes Internet hast.

Genau, auf jeden Fall.

Das kann passieren.

Und das habt schon auch jeder schon mal festgestellt, wenn man es dreimal hintereinander macht, kommen auch dreimal hintereinander verschiedene Scores raus, weil es gibt ja immer so ein bisschen Wackel.

Also gerade ist der Server vielleicht überlastet, dann ist es langsamer und dann ist er schneller.

Also das ist kein kein Laboratory-Wert.

Also das ist ja wirklich nur jetzt diese Sekunde.

Wie ist es jetzt gerade?

Aber ja, genau das ist der Punkt.

Und darauf zu reagieren, hat Google angefangen, etwas zu sammeln, was sie CrUX nennen.

Das ist ein Score, der wird von eurem Browser anonym für jede Webseite, also wenn ihr einen Chrome-Browser, aber nur Chrome, nicht Chrome-basiert, sondern nur Chrome- Browser benutzt und ihr besucht Webseiten, dann wird anonym quasi diese Daten erfasst und zu Google geschickt.

Und die sammeln die dann alle für eine Domain und sagen, hey, das ist das, was die Leute, die diese Webseite benutzen, sehen.

Und das nennt man CrUX, also Chrome UX Report heißt das.

Und der, den gibt es einmal von Google.

Die Webseite, die die da zur Verfügung stellt, ist aber furchtbar hässlich und furchtbar schwer zu benutzen.

Deswegen gibt es gleich mehrere Anbieter, die einfach diese CrUX-Daten von Google nehmen und einfach schöner darstellen.

Und da habe ich jetzt einfach mal Treo mitgebracht, weil ich die Darstellung tatsächlich ganz gut finde.

Das basiert einfach auf diesen Daten von Google und dann sehen wir alle Leute, die Tagesschau mit einem Chrome-Browser besucht haben, was haben die denn für eine Time-to-First-Byte gehabt im Durchschnitt, was haben die für eine First Contentful Paint gehabt.

Und das gibt uns einfach nochmal ein bisschen besseren Eindruck davon, wie ist das.

Hinweis, die geben erst diese Daten raus, wenn diese Domain genug Besucher hatte.

Wenn ihr jetzt eine ganz neue Webseite habt, dann seid ihr einfach noch nicht dort.

Das ist der Nachteil daran.

Und es dauert natürlich auch ein bisschen länger, bis ihr die Veränderungen seht.

Also sagen wir jetzt mal, ihr macht heute eine Performance-Verbesserung, ihr habt irgendwas euch mitgenommen und sagt, hey, das machen wir.

Dann müsst ihr ein bisschen warten, bis sich das auch in den Daten widerspiegelt, weil das dauert natürlich, bis das alles gesammelt wurde.

Genau.

Das ist CrUX und das ist jetzt halt Treo, aber da gibt es auch noch andere Darstellungen von.

Genau.

Also es gab ein paar Anmerkungen, die sind aber so mixt zu anderen Themen.

Ich würde es jetzt aber trotzdem gerne einmal vorlesen.

Alle von Sven.

Das eine ist Richtung Layout-Shifting, glaube ich nochmal.

Eines der geilsten Befehle ist Scrollbar-Gutter-Stable.

Ist nicht so einfach, aber wenn, dann ist es gut.

Geht es darum, abhängig von eurem Betriebssystem, ist es ja so, dass die Scrollbar immer ausgeblendet ist, wenn sie nicht benutzt wird, aktuell.

Ich habe jetzt hier Gnome auf Linux, da ist es halt einfach eingeblendet, deswegen gibt es das hier nicht.

Aber auf macOS wird die Scrollbar nur eingeblendet, wenn ihr scrollt.

Und ich glaube, auf Windows ist das auch so.

Und je nachdem, ich glaube, ich weiß nicht mehr genau, wie es war.

Ich glaube, bei Windows war es so, dass es tatsächlich auch das Layout verschiebt.

Das heißt, dadurch, dass ihr scrollt, könnte es passieren, dass das Layout sich verändert.

Und man kann eben sagen, hey, reserviere diesen Platz für die Scrollbar und dann passiert das eben nicht.

Super.

Ich hoffe, das war nicht richtig vom Fehler gegeben, Sven.

Sonst korrigiere ich mich gerne.

Genau.

Und Sven hatte noch geschrieben, dass für ihn Accessibility wichtig ist.

Er möchte es halt jedem zugänglich machen.

Die Website ist schwierig, aber naja.

Und dann hat er noch achte auf ARIA und TITLE geschrieben.

Genau.

Ist jetzt halt einfach nicht der Inhalt von diesem Talk.

Sehe ich aber genauso.

Ist ein super wichtiges Thema.

Und auch gerade Lighthouse zeigt halt, dass es da auch eine Überschneidung gibt in den Toolings, die halt beides reporten.

Stimme ich hundertprozentig zu.

Wäre aber jetzt ein anderer Talk.

Das dritte Tool, was ich euch noch zeigen wollte, ist Webpagetest.

Das ist ein gehosteter Service, wo man auch bezahlen für muss, wenn man mehr damit macht.

Da könnt ihr eben eine URL angeben und die führen dann halt verschiedene Tests darauf aus.

Und das ist wesentlich ausführlicher, was ihr da bekommt, als das, was ihr jetzt von Lighthouse beispielsweise bekommt.

Und da gibt es dann eben eine Summary, wo das zusammengefasst ist, welche Sachen sind gut.

Also ihr sagt jetzt zum Beispiel bei der Tagesschau ist die Usability schlecht.

Die sollte sehr viel verbessert werden und die anderen beiden sind okay.

Also schnell und resilient.

Da seht ihr jetzt halt so Breakdowns von zum Beispiel diesen ganzen Zeitpunkten, über die wir auch schon gesprochen haben.

Und sammelt auch noch mal die CrUX Daten, also das Real World Usage Matrix, das ist quasi das, was CrUX ist.

Das heißt dann immer unterschiedlich, das ist das Verwirrende.

Aber eigentlich ist es fast immer CrUX, weil alle anderen Datensammler sammeln nicht so viel wie Chrome, weil Chrome einfach so ein dominanter Browser ist.

Sorry fürs Unterbrechen.

Das heißt bei Lighthouse, da habe ich quasi nur eine Momentaufnahme.

Bei diesem Treo SE, das basiert auf den CrUX Daten, also habe ich nur in Anführungsstrichen die historischen Werte von Chrome Usern.

Und hier dieses Mixed quasi in Lighthouse und das andere, weil ich habe oben diese Momentaufnahme, die die aufgenommen haben und unten basieren sie auf CrUX.

Genau, exakt.

Das hast du gut zusammengefasst.

Und dabei ist auch noch mal einfach zu beachten, es benutzen natürlich nicht alle eure Besucher Chrome.

Das heißt also, wenn ihr euch zu sehr auf CrUX verlasst, dann könnte es halt sein, dass Performance-Probleme, die nur in Firefox auftreten, da gar nicht zu sehen sind, weil keine Ahnung, bei Firefox halt irgendein Layouting langsamer funktioniert als beim anderen oder das Ladeverhalten ein bisschen anders funktioniert.

Deswegen ist immer so ein bisschen gemischte Tüte, wie viel man sich auf CrUX verlässt.

Der Vorteil an CrUX ist eben, dass ihr eine realistische Mischung von den Geschwindigkeiten von Devices und Internet-Geschwindigkeiten eurer Kunden quasi seht.

Und das ist eben das, was es halt einzigartig macht, was halt sehr schwer nachzubilden ist mit anderen Tools.

Die Zeit reicht nicht, wenn wir noch andere Sachen mit sprechen müssen, alles durchzugehen, aber es gibt zum Beispiel auch noch diesen Opportunities Tab.

Da sind dann halt wirklich konkrete Ideen, wie ihr das besser machen könnt.

Aber wie gesagt, das würde ich jetzt mit einem Blick auf die Uhr nicht alles durchgehen, aber einfach als Idee, ihr könnt kostenlos irgendwie fünf Tests oder so ohne euch anzumelden, mal durchführen.

Das heißt, wenn ihr jetzt eure Unternehmenswebsite oder eure Homepage untersuchen wollt, dann geht da mal drauf und werft die da mal rein und dann habt ihr schon mal irgendwie einen Eindruck, wie das so funktioniert.

Das sind diese drei Tools hier, die ich vorgestellt habe.

Genau.

So, jetzt hat er den Vollbildmodus verlassen.

Wie nett.

Dann jetzt möchte er wieder, ich möchte wieder in den Vollbildmodus zurück, bitte.

Geht nicht mehr, okay.

Na gut, dann scrollen wir jetzt einfach so.

Neben diesen konkreten Tools gibt es eben auch noch Sachen, die ich noch mal vorlesen möchte.

Das sind die verhindert Rekression.

Sagen wir jetzt mal, ihr habt euch super viel Mühe gegeben und ihr habt euren Largest Contentful Paint unter 2,5 Sekunden gebracht.

Dann wollt ihr natürlich das monitoren, damit falls es jetzt auf einmal hoch springt, durch ein neues Deployment, durch, weiß ich nicht, ein neues Tool, was irgendwo eingebunden hat, dass ihr es sofort merkt, weil dann wisst ihr noch, was es kaputt gemacht hat.

Das ist der große Vorteil, weil wenn man da einfach nur ab und zu mal drauf guckt, einmal im Monat, dann sieht man, oh Mist, jetzt sind wir auf einmal wieder bei 3 Sekunden.

Wie ist das denn passiert?

Und dann kannst du es gar nicht mehr rekonstruieren.

Und wenn du es quasi live mitbekommst, weil ihr, weiß ich nicht, mindestens mal einmal am Tag so diese Maßzeilen von einem Tool erfassen lasst und ein Alert rausschickt, wenn sie schlechter werden, dann könnt ihr einfach dafür sorgen, dass auch wenn ihr vielleicht gerade noch nicht besser werdet, ihr zumindest nicht schlechter werdet und wenn irgendwas Blödes passiert, ihr das auch sofort mitbekommt.

Das halte ich für ein super wichtiges Tool in eurem Werkzeugkasten.

Und da gibt es auch noch andere Optionen.

Also das wäre jetzt zum Beispiel so ein zeitbasiertes, wo ihr sagt, okay, unsere Time-to-First-Bytes muss immer unterhalb von diesem Threshold sein oder unser Lighthouse-Score, der sollte niemals unter 90 gehen, weil den haben wir jetzt erreicht.

Baut da immer ein bisschen Atemluft ein, sagt man glaube ich auf Deutsch, weil es kann immer ein bisschen flackern.

Sonst alertet es zu oft und dann guckt ihr auch nicht mehr auf die Alerts.

Aber wenn es ein bisschen stärker ausschlägt, dann soll es auf jeden Fall alerten und dann solltet ihr darauf reagieren, weil dann könnt ihr noch viel besser wissen, was jetzt passiert ist.

Nicht immer, aber zumindest meistens.

Könnte man zumindest auch vielleicht in GitHub Actions oder so das GitHub, das automatisiert prüft werden, wenn man ein Commit macht oder ein Push oder was auch immer.

Genau.

Also das würde zum Beispiel gut mit wirklichen Zeitmetriken.

Also ihr habt jetzt vielleicht in eurem CI-Prozess sowieso automatisierte Tests, die da durchlaufen.

Dann könnten die nebenher auch noch irgendwelche Lighthouse-Scores oder sowas ermitteln.

Also das ist zum Beispiel nicht bei Puppeteer, bei dem anderen automatisierten Browser-Testing-Tool, kannst du tatsächlich einfach anschalten, gib mir die Lighthouse-Scores zurück und dann könntet ihr den Build failen lassen, wenn es schlechter wird.

Oder ihr könnt zum Beispiel sagen, wir wollen maximal so und so viel Kilobyte JavaScript ausliefern und sonst fehlt der Build.

Das ist zum Beispiel viel, viel einfacher noch, weil das ist ja deterministisch.

Ihr macht ein Webpack- oder Vite-Build und dann sagt ihr, wie groß ist denn jetzt die ganzen Dateien zusammen und dann machen wir den Build kaputt.

Selenium, war das das wohl der Name, den ich einfiel?

Nee, das ist das noch ältere.

Er kommt mir bestimmt gleich.

Okay, dann rufst du es einfach rein.

Genau, ich rufe es einfach mir selbst rein.

Genau.

So, das waren hier diese Maßnahmen.

Und dann reden wir nochmal über die Praxis und ich lade mal ganz kurz neu.

Vielleicht kann ich dann ja wieder präsentieren drücken, weil das ist ein bisschen angenehmer.

Ja, jetzt darfst du wieder.

Danke.

Vielen Dank.

Sven sagt Playwright.

Ja, genau.

Dankeschön.

Vielen Dank.

Manchmal hat man so diese Namensverwirrung.

Genau, also wie sieht das denn jetzt in der Praxis aus?

Also erst mal, bevor ich bei Swaglab angefangen habe, habe ich bei Komoot das Webteam geleitet.

Das ist eine App, mit der man Wanderungen und Radfahrten planen und finden kann.

Und das ist eine sehr komplexe React-Anwendung, weil es halt irgendwie eine Karte ist, auf der man seine Route planen kann und so weiter und so fort.

Und wir hatten uns halt als Ziel gesetzt, dort eben die Web Performance zu verbessern.

Ein bisschen als Fokus hatten wir uns gesetzt eben die Core Web Vitals, weil das sich eben immer leicht auch messen lässt und verfolgen lässt.

Und da haben wir eben über die Zeit den LCP von über drei Sekunden auf ungefähr 2,6 Sekunden verringert.

Ganz unter die 2,5 Sekunden, die ja das Grün sind.

Bei Google haben wir es leider nicht geschafft, aber vielleicht kommt das ja noch.

Genau, dann haben wir den INP konstant auf unter 200 Millisekunden gebracht, was uns sehr gefreut hat, weil das halt gerade bei React-Anwendungen immer so ein bisschen ein Thema ist.

Und wir haben tatsächlich einfach als ein Beispiel, ich kann jetzt auch nicht so viel über die konkreten Maßnahmen sprechen, ist ja einfach intern von Komoot, aber als ein Beispiel ist der Build halt fehlgeschlagen, wenn das Javascript Bundle zu groß wurde.

Dann ist es einfach auch nicht deployed vor.

Und das jetzt mal als Beispiel, wenn man darauf fokussiert und als Team daran zusammenarbeitet, dann kann man das halt schaffen.

Aber es ist auf jeden Fall auch ein Ding, was man jetzt nicht innerhalb von einer halben Stunde macht.

Das ist eine konstante Arbeit und auch eine Art von Fokussierung, wo man als Team sich gemeinsam überlegen muss, hey, wie schaffen wir das?

Genau, schon mal als Hinweis, also wenn ihr noch mehr Lust auf solche Themen habt und noch mehr dazu hören wollt, habe ich noch drei Sachen für euch mitgebracht.

Einmal machen wir bei Swaglab einen Impuls.

Das ist auch nochmal so ein einstündiges Online-Format, das kostenlos ist.

Da könnt ihr euch einfach für anmelden.

Da will ich das also im Gegensatz hier, wo ich das jetzt allgemein erkläre, ein konkretes Beispiel mal durchspielen und schauen, hey, was kann man daran machen?

Und da könnt ihr dann auch gerne eure Beispiele mitbringen, die wir dann diskutieren können.

Dann zusammen mit SoCreatory haben wir eine Schulung oder ein Web-Performance-Workshop, ganz neu jetzt im Angebot.

Genau, der findet das erste Mal im Dezember statt.

Und da haben wir euch auch hier diesen Rabatt-Code Performance-25 mitgebracht.

Damit kriegt ihr 20 Prozent Rabatt und damit ist das dann ungefähr so 480 Euro nach dem Rabatt.

Wenn ihr dazu Lust habt, das ist dann ein ganzer Tag.

Da schaffen wir natürlich dann auch mehr zu besprechen, was da an konkreten Maßnahmen und sowas passiert, weil das ist natürlich in einer Stunde ein bisschen schwierig.

Und als letztes Angebot, auch wieder kostenlos, wäre der QuickCheck, den wir von Swaglab anbieten.

Da schickt ihr uns eine Webseite, an der ihr arbeitet und sagt, hey, wie kann ich die schneller bekommen?

Und dann besprechen wir die mal zusammen.

Genau, das einfach mal dazu.

Und dann würde ich jetzt, wenn es keine Fragen gibt, einmal zu den konkreten Tipps, wie kann ich jetzt schneller werden, kommen.

Es gab nur den Hinweis, dass es cool ist, was du dabei, Kumut, machen konntest.

Dankeschön.

Und Sven schrieb noch Vollzeit, sich um sowas zu kümmern muss schon Spaß machen.

Ja, das stimmt.

Ich war der Teamlead und ich habe daran viel gearbeitet und ein anderer Kollege, der hat auch sehr, sehr viel von seiner Zeit investiert.

Es ist auch immer Teamwork.

Das schafft man auch nicht alles ganz allein, definitiv.

Um das jetzt zu betrachten, welche Tipps gibt es, habe ich gedacht, wir gucken uns das jetzt noch mal als Gesamtbild an.

Also wir hatten ja hier diese ganzen Stufen von URL in den Browser eingegeben bis Time to Interactive und dann hatten wir nochmal diese drei Core Web Vitals.

Und da habe ich jetzt einfach im Vorhinein schon mal ein paar Sticky Notes draufgeklebt.

Aber werft gerne eure Fragen oder eure Ideen ein.

Finde ich immer cool.

Da gibt es super viele Sachen, die man ausprobieren kann.

Aber ich starte jetzt einfach mal mit einem Beispiel, bis irgendjemand eine Frage hat.

Also der Server schickt die Response zurück.

Eine Sache, das war auch schon mal ein Thema bei Bildern, aber allgemein Kompression.

Also wenn ihr die Antwort kleiner bekommt, dann ist sie auch schneller vollständig da.

Das erste Byte vielleicht nicht, aber die ist dann schneller vollständig da.

Und da gibt es eben mittlerweile nicht nur Gzip, das, was jeder und jede kennt, sondern da gibt es halt auch noch sowas wie Brotli, was eben mittlerweile auch in quasi dem Browser unterstützt wird und nochmal ein gutes Stück kleiner ist als Gzip.

Nur einfach mal als Hinweis.

Und der andere Teil ist eben Caching.

Auch wieder ein Thema.

Das schafft man noch nicht mehr in einer Stunde.

Das ist wahrscheinlich auch ein Tagesworkshop.

Wie mache ich eine Caching-Strategie?

Weil Caching bedeutet ja potenziell, dass ein Request noch nicht mal stattfindet.

Und das bedeutet eben, wir sparen uns ganz, ganz viel Zeit, weil eben gar kein Request passieren muss.

Genau.

Und zusammengefasst kann man in dem Teil auch noch darüber sprechen über Latenz.

Weil wenn ihr euch vorstellt, ihr schickt all eure Bilder aus eurem Rechenzentrum in Frankfurt und die Leute sitzen in Argentinien, dann ist das definitiv einfach eine Latenzfrage, weil jeder einzelne Request muss ja erstmal von Argentinien nach Frankfurt und dann die Antwort wieder zurückgeschickt werden.

Und alleine das dauert halt.

Und das ist eben der Grund, warum auch im Performance-Bereich so oft über CDNs gesprochen wird, weil die euch eben ermöglichen, einfach die Latenz zwischen eurem Browser und dem ersten Punkt in eurer Infrastruktur zu verringern.

Ist aber auch kein Allheilmittel.

Das wird dann von diesen CDN-Anbietern immer so verkauft, als wäre jetzt alles gelöst.

Ist aber leider auch nicht so, weil wenn dann halt vom CDN nochmal der Request an euch geht und der ist langsam, hilft euch das am Ende auch nicht viel, wenn ihr da nicht die richtigen Strategien habt.

Also einfach nur so zum einsortieren.

Sven hat im Chat geschrieben, auch HTTP 2 und dann 3.

Ich glaube, ich verstehe nicht ganz, worauf sich das bezieht.

Aber genau, also grundsätzlich.

Ach so, jetzt habe ich es verstanden.

Sorry.

Wenn ihr hier stattdessen HTTP 2 und oder 3 anbietet, dann kann das halt das auch nochmal schneller machen, weil gerade HTTP 3 kombiniert eben den Verbindungsaufbau und die TLS-Negotiation in einen Schritt als Beispiel.

Das ist halt schneller und dadurch ist dieser Kasten, der lange quasi konstant war, wird auf einmal kleiner.

Aber das ist ein guter Punkt, Sven.

Oh, das ist ein sehr großes Keynote.

Den packe ich da mal dazu.

Das wäre auch eine Möglichkeit, hier für mehr Geschwindigkeit zu sorgen.

Auf diesem Level.

Also nicht hier unbedingt, aber gerade auf diesem Verbindungsaufbau-Level macht das einen großen Unterschied.

Im Chat bei Twitch gab es noch einen Hinweis von Tarumis.

CDN ist aber auch wieder Plus 1 Point of Failure.

Klar, also wenn das CDN ausfällt, dann haben wir ein Problem.

Und ich glaube, das kennen wir mittlerweile auch.

Wenn Cloudflare anfängt ein Husten zu haben, dann stürzt quasi die Hälfte des Internets ab.

Auf einmal funktioniert gar nichts mehr.

Und das ist ja schon ein paar Mal passiert.

Ich weise nur darauf hin, dass es wahrscheinlich trotzdem häufiger passiert, dass euer Server ausfällt, als das Cloudflare ausfällt.

Aber ich gebe dir grundsätzlich recht.

Das kann passieren und das sollte man auf jeden Fall in seinen Szenarien mit beachten.

Also was passiert, wenn die wirklich ausfallen?

Können wir dann ausweichen auf was anderes?

Das ist ein super wichtiger Hinweis.

Ich möchte glaube ich die Kompression noch mal hier runter ziehen, weil eigentlich ist es dabei nochmal viel entscheidender.

Wenn wir jetzt die ganzen Dateien laden, dann müssen wir die komprimieren.

Ein Hinweis da auch die Fonts.

Das sehe ich immer noch sehr oft, was mich ein bisschen wundert, weil es eigentlich auch sehr einfach ist.

Bei Fonts gibt es Autokomprimierung, die heißt WOFF 2 oder auch WOFF war die erste Version.

Das ist im Prinzip einfach der Font wird mit Brotli komprimiert und dann ausgeliefert.

Das etwas vereinfacht das, was WOFF macht und ihr solltet eure Fonts einfach immer als WOFF 2 ausliefern, weil mittlerweile hat das halt auch irgendwie 98 Prozent Browserverbreitung.

Also das kann wirklich jeder.

Es lohnt sich noch nicht mal mehr die Unterscheidung zwischen WOFF 1 und WOFF 2, weil die, die kein WOFF 2 können, die können wahrscheinlich auch kein WOFF 1 und dann müsst ihr wirklich den Font quasi per Fax rüberschicken.

Aber das kostet wirklich fast nichts, euren Font einfach in WOFF 2 einmal umzuwandeln und den als WOFF 2 auszuliefern.

Macht das einfach.

Es gibt halt immer Sachen, die sind zwar vielleicht nicht die Riesenauswirkung, aber die sind so günstig, dass es sich auf jeden Fall lohnt.

Und das ist halt sowas wie im Webserver Brotli-Kompression mit einschalten, die Fonts mit WOFF 2 zu komprimieren.

Das sind so Frequenz, die sollte man auf jeden Fall mitnehmen.

Und in der Summe lohnt es sich dann auch wieder, auch wenn jetzt kein Einzelnes davon jetzt den Riesenunterschied macht.

Aber alles zusammen ist es dann doch nachher wieder ein Un-Ding.

Herr Ruhmes hat noch auf deinen Einwand mit dem eigenen Server reagiert, deswegen musste ich eben kurz lachen.

Der schrieb, wenn der eigene Server ausfällt, ist es wurscht, ob man Cloudflare hat oder nicht.

Stimmt.

Ja, also grundsätzlich gebe ich dir recht.

Es kann natürlich trotzdem so sein, wenn ihr beispielsweise statische Seiten ausliefert und ihr habt Cloud.

Also es muss auch nicht Cloudflare sein.

Es gibt auch andere Anbieter.

Aber ihr habt ein CDN davor geschaltet, dann könnte es sein, dass das eine gecached Version ausliefern kann, während euer Server sich recovert.

Oder einfach, dass die Load auf euren Server runtergeht und die Wahrscheinlichkeit sinkt, dass er abstürzt.

Aber ich möchte auch gar kein CDN-Sales-Guy sein, der sagt, ihr müsst ein CDN benutzen.

Also auf keinen Fall.

Das ist auch sehr abhängig davon, was ihr für Sicherheitsanforderungen habt.

Es gibt zwei verschiedene Arten von CDNs.

Es gibt CDNs, die tut ihr vor eure Webseite und dann gehen alle Requests in das CDN und von dort aus an eure Server.

Das ist das, was Cloudflare macht, aber auch andere.

Und es gibt die, die neben eurer Webanwendung sind.

Das ist so ein bisschen der Klassiker.

Das ist das, was Akamai z.B. macht.

Da legt ihr dann halt eure CSS-Dateien und eure JavaScript-Dateien und so weiter drauf und die sind dann schnell geladen.

Der erste Fall hat halt einfach Implikationen darauf, dass ihr einen weiteren Anbieter habt, der Zugriff auf alle Requests hat, weil die gehen da auf jeden Fall im Klartext durch.

Sonst kann Cloudflare nicht arbeiten und da müsst ihr wissen, ob das in eurer Industrie, in eurem Anwendungsfall okay ist, dass Cloudflare diese ganzen Informationen als US-Unternehmen auch noch mitliest.

Das müsst ihr entscheiden.

Bei sowas wie einem Akamai-Style CDN ist das weniger kritisch, weil die CSS- und JavaScript-Dateien sind meistens nicht besonders geheim.

Da ist es okay, aber da bildet ihr natürlich auch nur einen Teil davon ab, weil ihr nur diese Sachen schneller werdet, aber nicht euer HTML mit einer geringeren Latenz beim Kunden landet.

Das ist einfach eine Abwägungsfrage.

Da gibt es keine richtige Antwort.

Das ist einfach total abhängig von euren Anforderungen, sag ich mal.

Weil ich das eben schon mal erwähnt hatte, es gibt verschiedene Möglichkeiten, den Browser zu bringen, bestimmte Sachen früher zu laden.

Es gab am Anfang von der ganzen HTTP2-Entwicklung diese Idee von einem Web-Push.

Das war die Idee, dass wenn jemand die Webseite anfordert, ihr nicht nur die Webseite zurückschickt, sondern tatsächlich auch schon das CSS und das Hero-Image und so weiter einfach schon direkt mitschickt.

Das hat halt einen großen Nachteil und das war eigentlich auch von Anfang an klar.

Wenn der schon gecached ist, dieser Kram, dann schickt der ja Sachen, die der schon hat, der Client.

Deswegen gab es dann halt Möglichkeiten zu sagen, Abbruch, ich habe die Datei schon, schicke sie mir nicht.

Aber je nachdem, wie dieser Ablauf ist, ist das halt schon zu spät gewesen.

Dann waren die Daten halt schon da hingeschickt.

Und deswegen hat es das in der Praxis fast keiner benutzt.

Was sich stattdessen etabliert hat, ist die Idee, dass es so etwas wie Early Hints gibt, dass euer Web-Server sagt, hey, übrigens, wenn du diese Webseite anforderst, dann wirst du wahrscheinlich auch noch folgende Dateien brauchen, nur schon mal als Hinweis.

Und dann erst das HTML anfängt zu schicken und dann kann der Browser entscheiden, aha, die habe ich ja noch gar nicht in meinem Cache, dann fordere ich die jetzt an.

Und das geht halt früher, als wenn ihr dann erst das HTML lesen müsst.

Das heißt halt Early Hints.

Das kann helfen.

Das hat ganz viele Nuancen, die wir jetzt nicht in drei Minuten besprechen können, aber es ist auf jeden Fall ein Werkzeug im Werkzeugkasten, das ihr euch anschauen müsst, solltet, nicht müsst.

Und der Vorgänger davon, der auch immer noch existiert, sind so Meta-Tags, die so etwas sagen wie Preconnect oder Prefetch.

Da sagt man, hol dir schon mal diese Datei.

Die kannst du auch als HTTP-Header setzen, an HTTP-Header setzen und sag bitte, mach schon mal die DNS-Auflösung von dieser Domain, weil da liegen unsere Fonts zum Beispiel.

Oder connecte dich schon mal an diesen Server, weil den werden wir brauchen.

Das ist auch weiterhin die Empfehlung, das zu machen, also gerade diese Preconnections, wenn sich der Browser mit mehr als einem Server verbinden soll.

Dann wäre das gut, weil dann habt ihr jetzt schon mal diesen Verbindungsaufbau-Teil erledigt.

Das DNS wurde aufgelöst, die Verbindung steht und man kann anfangen, dort Requests zu setzen, ohne dass ihr das Risiko eingeht, dass eine Datei runtergeladen wird, die gar nicht gebraucht wird.

Aber die Verbindung steht schon mal und das ist auch ein Zeitaufwand.

Und in der HTTP-2- und 3-Welt, in der wir jetzt leben, kannst du halt diese Verbindung für ganz viele Requests an denselben Server verwenden.

Und das ist eben der Grund, warum das jetzt noch viel attraktiver geworden ist.

Aber es gibt einfach da verschiedene Optionen, die uns HTTP und HTML zur Verfügung stellen und die sollten wir halt kennen und dann abwägen können, welche zu unserem Use-Case gut passen.

Wir haben noch einen Kommentar aus dem Chat.

Sven schreibt, früher haben wir immer alles vor den Header gemacht.

Vor den Header sogar?

Interessant.

Darüber muss ich nachdenken.

Genau, das wäre jetzt einfach mal so ein paar Tipps, weil also, wie gesagt, wir haben heute eine Stunde, da schafft man nicht so viel, die alle durchzusprechen.

Ich hoffe, es hilft trotzdem einfach schon mal einzuschätzen, an welche Stellen müsst ihr mal in euren Ladeprozess reingucken.

Welche Tools könnt ihr benutzen, um zu schauen, haben wir ein Problem und wo sind unsere größten Probleme?

Das ist so ein bisschen die Idee, einfach da die Aufmerksamkeit draufzusetzen auf dieses Thema, damit ihr da so ein bisschen mehr darauf achtet, wenn ihr solche Sachen baut.

Ja, cool.

Also, das war eine sehr, sehr kurzweilige Stunde, lieber Lucas.

Es kam etwas überraschend, dass schon zwei Uhr ist gleich.

Also, ich möchte jetzt am Montag, achso, warte, Sven schreibt, ja, das war ein Trick, haha, natürlich am Ende des Bodies, haha.

Achso.

Ah, okay, jetzt habe ich verstanden, was du meinst, ja.

Genau.

Jetzt habe ich mich selber wieder rausgebracht.

Genau.

Also, am Montag werden wahrscheinlich hier die Seiten von Lighthouse und diesen CrUX-Geschichten heiß laufen, weil alle Leute, die heute den Stream schauen oder im Podcast hören, erstmal ihre Webseiten checken.

Dann finden wir auch alle super viel raus, was wir ändern können.

Du hast am Anfang schon so drei Dinge gesagt, mit denen man eventuell Stakeholder überzeugen könnte, dass es sinnvoll ist, die Website zu verbessern.

Hast du vielleicht so einen Go-To-Satz für alle, die jetzt keine Zeit haben, sich die Ressourcen anzuschauen?

Also, sowas wie, lieber Stakeholder, ich habe herausgefunden, unsere Webperformance muss verbessert werden.

Wenn wir das machen, dann steigern wir unseren Umsatz auf jeden Fall um 30.000 Prozent oder so.

Genau.

Also, ich bin immer nicht so gut in solchen Zahlen ausfündig gelernt.

Ich würde dann auf die Links verweisen, die ich am Anfang gemacht habe.

Die können wir auch gerne dann in die Shownotes geben, die Leute, die das jetzt als Podcast hören packen oder so.

Aber es lohnt sich einfach noch mal anzuschauen, was gerade so Firmen wie Amazon, Google, Cloudflare dazu berichten, was es bei denen für einen großen Unterschied macht in der Praxis, in dem Umsatz.

Das ist meistens Argument genug, um Stakeholder davon zu überzeugen, dass man sich vielleicht das Thema doch mal angucken sollte.

Es klingt immer als erstes, weil es so technisch ist, klingt es immer nach so, die Techies wollen halt hier irgendwas machen.

Aber es hat Auswirkungen auf Umsatz.

Es hat Auswirkungen auf die Zufriedenheit unserer Kunden und Kundinnen.

Und deswegen lohnt es sich allein.

Ich finde, der zweite Punkt ist fast auch noch wichtiger.

Wenn euer Produkt dafür bekannt ist, lahm zu sein, wer empfiehlt denn euer Produkt?

Dann sagen die Leute, das ist dieses lahme Ding, das keiner benutzen will.

Das will ja keiner.

Ihr wollt, dass die Leute sagen, hey, das macht richtig Spaß, damit zu arbeiten.

Du hast gerade noch so einen schönen Kommentar aus dem Chat bekommen.

Ich kann ihn dir nicht vorenthalten.

Sven schreibt, Lucas, du bist ein geiler Typ, mach weiter so.

Das Thema ist wirklich wichtig.

Danke, Sven.

Das sind auch schöne Schlussworte.

Genau.

Also, Lucas, vielen, vielen Dank, dass du mit dem Thema gekommen bist, dass du es so cool vorgestellt hast.

Euch da draußen, vielen Dank, dass ihr dabei wart.

Und ich würde sagen, schönes Wochenende an alle.

Genau.

Dankeschön und danke dir, Lisa.

Gern.

Tschüss.