Deep Dive 206 – Web Performance mit Christian Schaefer

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

Web Performance ist kein Nice-to-have, sondern die Grundlage für gute User Experience. In dieser Folge sprechen Fabian und Garrelt mit Christian „Schepp“ Schaefer über die großen und kleinen Hebel für schnelle Webanwendungen. Der freiberufliche Web-UI-/UX-Engineer und Co-Host des Working Draft Podcasts bringt nicht nur tiefes technisches Wissen mit, sondern auch eine klare Haltung: Performance entsteht nicht nebenbei – sie ist eine bewusste Architekturentscheidung.

Gemeinsam gehen wir zurück zu den Wurzeln der Web Performance und klären, warum die bekannte 80/20-Regel von Steve Souders auch heute noch gilt: Die meisten Bottlenecks entstehen im Frontend. Wir diskutieren, warum wir uns seit Jahren zwischen Server-Side Rendering und Client-Side-Logik hin- und herbewegen und was das für moderne Web-Architekturen bedeutet.

Im Gespräch wird deutlich, dass Performance mehr ist als Ladezeit. Schepp erklärt die drei zentralen Dimensionen: Ladezeit, Runtime Performance und Layout-Stabilität – ein Faktor, der in der Praxis oft unterschätzt wird. Wir sprechen darüber, wie sich rechenintensive Aufgaben mithilfe von Web Workern und dem Actor Model aus dem Main Thread auslagern lassen, um Interaktionen flüssig zu halten. Dabei geht es auch um konkrete Tools wie Comlink und die Frage, wie man Rendering, Filter oder Übersetzungen sinnvoll parallelisiert.

Ein weiterer Schwerpunkt liegt auf dem Einsatz moderner Browser-Features. Schepp zeigt, warum viele Probleme heute besser mit CSS als mit JavaScript gelöst werden können, etwa durch Scroll Snapping oder die neue Carousel API, die klassische Slider-Libraries überflüssig macht. Ergänzt wird das durch einen Blick auf Tooling und Messmethoden, von WebPageTest über die Chrome DevTools bis hin zu Real User Monitoring mit Sentry.

Auch architektonische Entscheidungen werden kritisch beleuchtet. Anhand von Erfahrungen aus realen Projekten diskutieren wir, warum BEM in großen Codebases an Grenzen stoßen kann und weshalb ein Utility-First-Ansatz wie Tailwind CSS unter bestimmten Bedingungen Performance-Vorteile bringt. Schepp gibt außerdem Einblicke in seinen eigenen Stack rund um PHP und Twig und teilt Learnings aus der Praxis, inklusive der Frage, wie viel JavaScript wir Nutzer:innen heute eigentlich noch zumuten sollten.

Wenn ihr verstehen wollt, wie ihr eure Webanwendung wirklich schneller macht – und nicht nur theoretisch darüber nachdenkt – ist diese Folge genau das Richtige für euch. Habt ihr Feedback zur Folge oder eigene Performance-Tricks? Schreibt uns auf Discord oder nutzt den Hashtag #GarreltMockRockt!

Weitere Links aus der Folge:

Transcript

SPEAKER_01 0:08

Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der Programmierbar. Mein Name ist Fabian Fink und mit mir im Studio ist der Geld Smok. Hi Geralt, wir wollen heute über Web-Performance sprechen. Und dafür haben wir uns einen ganz besonderen Gast eingeladen, den lieben Christian Schäfer, auch genannt der Schepp oder einfach nur Schep. Wir freuen uns sehr, dass du da bist. Hi.

SPEAKER_03 0:32

Ja, hallo ihr zwei und danke für die Einladung. Schön, dass ich da sein darf.

SPEAKER_01 0:36

Wir freuen uns ebenfalls. Du schreibst ja auf deiner eigenen Webseite so, dass du generell so ein bisschen nicht so sehr an die oder nicht so viel mit den Standard.js-Frameworks nutzt, sondern sehr Barebones irgendwie unterwegs bist, eher so auf traditionelle Server Rendered Components setzt und irgendwie Bleeding Edge CSS bist und auch sagst, du bist auf jeden Fall, was Loading ⁇ Runtimes Performance an der Seite angeht, auf jeden Fall so ein bisschen dein Steckenpferd ist. Und werde ich jetzt nicht, kann gut sein, dass man dich hier nicht zum ersten Mal deine Stimme hört, sondern du bist ja auch als bekannt über den Working Draft Podcast, einen Co-Host vom Working Draft Podcast, den wir auch schon mehrmals hier referenziert haben, in unserem Podcast ansonsten auch breit unterwegs, bist bei der Frontiers-Konferenz, organisierst du aber auch das Webworker Meetup NRW und auch bei anderen Konferenzen mit unterwegs. Das heißt, du treibst dich viel rum und das Thema Web-Performance ist auf jeden Fall, wenn ich das jetzt hier so richtig wiedergebe, so ein bisschen auch mit dein Steckenpferd. Deswegen freuen wir uns natürlich heute mit dir, da so ein bisschen drüber zu reden. Und vielleicht, ich meine, Web-Performance ist erstmal ein super weiter Begriff. Und ich glaube, vielleicht für unsere Zuhörer wäre es super, wenn du mal probieren könntest, für dich so den Begriff oder was du unter Web-Performance verstehst. Wenn jetzt jemand sagt hier, okay, wir müssen die Web-Performance optimieren, an welche Bereiche denkst du da?

SPEAKER_03 1:56

Genau, so Web-Performance ist eigentlich, also ich habe mich neulich mal gefragt, warum ich überhaupt so ein Web Performance-Nerd bin und gleichzeitig aber auch zum Beispiel ein CSS-Nerd. Also irgendwie passt das ja überhaupt gar nicht zusammen. Das eine, da geht es ja um Styling, das andere ist ja schon sehr technisch. Beides zahlt aber auf die User Experience ein. Das ist irgendwie der gemeinsame Nenner. Also ein Interface muss gut aussehen, charmant sein, gut funktionieren und eben auch schnell sein. Genau, und dafür sind so verschiedene Bestandteile, die da in die Webperformance reinlaufen. Wo auch immer dann die Ursache für eine gute oder eine schlechte Webperformance liegt, ist gar nicht, ist erstmal nebensächlich. Aber das eine ist Ladezeit, also wie lange dauert das, wenn ich eine Webseite aufrufe, bis sie da ist und idealerweise sogar betriebsbereit. Der andere große Block ist Runtime-Performance, weil ich kann natürlich auch eine Webseite haben, die sehr schnell lädt, aber die, die danach wahnsinnig ressourcintensiv ist und ruckelt. Ihr kennt das, ihr kennt das aus dem Spielebereich. Da werdet ihr wahrscheinlich viel mit der Runtime-Performance euch beschäftigen, vielleicht weniger mit der Ladezeit, also die nimmt man dann vielleicht für so ein Spiel ja auch in Kauf. Genau, und dann gibt es noch so einen dritten Aspekt, der ist vielleicht einfach die, also Layout-Stabilität. Das heißt, also wenn ich was habe und ich bewege mich über diese Oberfläche, über dieses UI drüber, egal ob es jetzt ein Spiel ist oder eine Webseite. Bei Spielen nervt es ja total, wenn man jetzt irgendwie so ein 3D-Spiel hat, man geht durch eine Landschaft und Bäume und so poppen halt super spät erst ins Bild. Also es sieht irgendwie kacke aus und nervt. Und bei Webseiten gibt es das eben auch. Also das ist dann zum Beispiel, dass ein lazy ladendes Bild spät kommt, der Browser ein Relayout durchführt oder Werbung reinkommt und Layout-Shifts passieren. Das wäre so dieser dritte Aspekt, der vielleicht so ein bisschen immer unter den Tisch fällt, aber der irgendwie auch wichtig ist und auch sozusagen unter diesen Web-Performance-Schirm gepackt werden kann.

SPEAKER_01 4:10

Und weil du jetzt sagst, du hast dich gefragt, wie passt es denn zusammen, dass du gleichzeitig CSS und Performance-Nerd bist? Vielleicht, damit unsere Zuhörer dich noch ein bisschen besser kennenlernen, woher woher kommt denn dieser Performance-Nerdtum? Wie kommt es, dass du dich irgendwie gerne damit beschäftigst? Gab es da irgendeinen, gab es da einen Auslöser oder eine schlechte Seite, die nicht gut geladen hat?

SPEAKER_03 4:31

Ja, nee, die gab es nicht, aber ich glaube, ich bin einfach irgendwann über Steve Sauders Werke gestolpert. Das ist ja so der Grand Seigneur der Webperformance, der hat damals noch bei Yahoo gearbeitet und Yahoo hat, also Yahoo war ja sowieso, also ich sag mal vor, vielleicht, das wird dann 20 Jahre her gewesen sein, da war Yahoo das, was heute Google ist. Und da waren alle großen Leute, die arbeiteten bei Yahoo und Yahoo war auch führend und prägend für die Webentwicklung. Also es gab die YUI, Pattern Library, wo die damals schon im Grunde Interface-Bausteine gezeigt haben, wie sie die entwickelt haben und warum die so am besten funktionieren. Und die hatten eben auch dieses Yahoo Exceptional Performance Team, wo Steve Sauders eben der Leiter war und wo noch ein paar andere Leute dabei waren. Und genau, das war ja noch die Zeit der Blogs. Da gab es ja Podcasts gab es, glaube ich, schon, aber eben noch nicht so viele, Videos schon mal gar nicht. Und auch auf Konferenzen hat man noch nicht so viele Leute gesehen. Aber der hat eben viel gebloggt und auch ein Buch geschrieben oder sogar zwei Performant-Websites, glaube ich, hieß es einfach nur. Und ja, ich fand das, also ich bin, ich bin so gekommen, also ich war natürlich früher auch Webmaster und Generalist und habe mich dann irgendwie immer weiter in Richtung Frontend bewegt und dessen Kernaussage war eigentlich, dass 80% der Webperformance Bottlenecks im Frontend entstehen und nur 20 im Backend. Das heißt also, wenn ich meine Datenbank tune und ein super eingestelltes PHP habe mit Caching und ZIP und Zap, aber mein Frontend ist eben einfach nicht sauber aufgebaut, dann ist meine Seite trotzdem langsam. Also es lohnt sich eher den Blick aufs Frontend zu richten und da aufzuräumen, bevor man irgendwie im Backend versucht, Dinge zu optimieren, wenn eine Seite langsam ist.

SPEAKER_00 6:38

Würdest du denn sagen, das hält sich bis heute so, dieses 8020-Verhältnis? Weil ich meine, es wird ja versucht, viel mehr ins Backend zu shiften. Server-Side-Rendering mal als ein Beispiel. Würdest du sagen, das hat das auch ein bisschen geändert? Oder ist es eigentlich dasselbe Thema, weil selbst Server-Side-Rendering eigentlich Frontend-Arbeit ist in dem Sinne?

SPEAKER_03 6:58

Also ich glaube, daran hat sich im Grunde nichts geändert. Also es ist natürlich wieder entspannt, aber die Zeit, also als dieses Buch rauskam, da hat man auch Server-Side gerendert. Also wir haben ja immer diese, also nennt man ja Schweinezyklen. Also sagen wir mal so, alle zehn Jahre landet man wieder da, wo man vor zehn Jahren war. Immer auf der Suche nach dem, also auf der anderen Seite ist das Gras ja immer grüner. Und so merkt man ja immer, was man in seinen aktuellen Situationen für Probleme hat und versucht sich daraus wegzuentwickeln hin zu einem besseren Konzept. Und das passiert eben über zehn Jahre so lange, bis man im Grunde wieder da ankommt, also alter Wein in neuen Schläuchen und natürlich hat das dann andere Begrifflichkeiten, aber von den Grundkonzepten hat es das immer alles schon gegeben. Und wir werden uns auch wieder mehr in den Client bewegen, wahrscheinlich. Also, wenn man so zurückblickt und das sieht, wie das gelaufen ist, wenn wir uns, jetzt bewegen wir uns erstmal wieder zum Server zurück und dann werden wir uns wieder irgendwie zum Client bewegen. So ist das wahrscheinlich. So muss das sein.

SPEAKER_01 8:03

Okay. Und vielleicht kannst du uns ja mal so ein bisschen, vielleicht können wir mal ausgehen davon, so wenn du jetzt, du bist ja selbstständiger Frontend-Developer und vielleicht mal ein bisschen darüber erzählen, was so dein Standard-Web-Stack ist und daraus vielleicht mal so ein bisschen ausgehend zu gehen, wo du, wo du vielleicht aktuell irgendwie Bottleneck siehst, wenn du es so, wenn du es von der von der Pike auf sozusagen designst, dein Frontend so, an welchem Punkt, vielleicht kann man es, also was ist dein Stack und an welchem Punkt mache ich mir eigentlich Gedanken um die Performance so? Also ist das was, wofür ich die richtige, also von vornherein die richtige Entscheidung treffen muss? Oder ist es was, ich könnte ja auch genauso gut sagen, wo es eigentlich sind einige da draußen, die sagen, ey Leute, mittlerweile mit den Devices auch gerade irgendwie Mobile-Desktop, wie du irgendwie unterwegs bist, die sind alle stark genug. Performance ist eigentlich was, auf das muss ich heutzutage gar nicht mehr groß achten. Und die paar alten Devices, naja, komm, lass es doch mal. Also so, wie denkst du darüber nach, wenn du über eine neue Applikation nachdenkst? Also dann können wir später vielleicht nochmal drauf eingehen, was mache ich denn eigentlich bei einer großen Bestandsapplikation?

SPEAKER_03 9:02

Genau, also es hängt natürlich von dem Setting ab, in dem ich mich gerade bewege. Also wenn ich Agenturen supporte, da würde ich immer einen ganz anderen Webstack wählen, als wenn ich Gruppen, also wenn ich Person, wenn ich Produktentwicklung unterstütze mit meiner Arbeit. Jetzt in den letzten Jahren habe ich viel Produktentwicklung gemacht. Und darum, das erlaubt mir, das auch überhaupt, einen eigenen Stack ins Spiel zu bringen, weil wenn ich Agenturarbeit machen würde, da muss immer alles schnell gehen, da muss viel von der Stange kommen. Da hat man gar keine Zeit dafür. Genau, aber bei der Produktentwicklung, da will man die Dinge richtig machen, da kann man auch die Zeit investieren. Und aktuell ist der Stack, also serverseitig wird mit klassischem PHP gerendert, auch wenn das uncool ist. PHP hat sich auch weiterentwickelt und mir ist im Grunde sowieso völlig egal. Genau, aber das war einfach gesetzt und dann muss man eben überlegen, also gehe ich den Weg, dass ich ein Headless Backend habe und dann mit einem Frontend aufsetze, das vielleicht so SPA-artig ist. Also wo ich einfach mehr Logik ins, ins, noch mehr Logik ins Frontend verschiebe, über die Logik, die ich für meinen UI sowieso brauche. Oder wähle ich eben ein Templating-System, was kompatibel ist mit diesem Backend und daran gerendert werden kann. Und bei den letzten Kunden, wo ich so Produktentwicklung gemacht habe, die sind sich sehr ähnlich gewesen. Darum ist der Stack bei denen im Grunde fast identisch, was auch ganz cool war, weil dann musste ich auch nicht bei Null anfangen bei dem nächsten Kunden. Zumindest gedanklich nicht. Und da ist die Templating-Engine Twig, weiß nicht, ob ihr die kennt. Nicht genutzt, aber vom Namen her ja. Genau, also die kommt so aus dem Symphony-Umfeld. Symphony ist ja so eines der großen PHP-Frameworks. Und dann gibt es ja noch Lavel. Und genau, aus deren Hause kommt eben die Twig-Template-Engine. Und das Schöne bei der ist, also die gibt es auch in einer JavaScript-Implementation. Und das macht es uns möglich, die Komponenten, die mit Twig-Templates arbeiten, eben wahlweise in PHP zu rendern oder im Frontend in SPA oder in Interactive Islands, also so wie Astro das macht. Oder eben auch in einem Static Side Generator wie 11T zum Beispiel. Genau, also das haben wir alles gemacht oder beziehungsweise alles davon ist auch im Einsatz. Genau, und was darüber hinausgeht, also ich versuche immer so viel, wie es geht, über CSS abzufackeln. Heutzutage ist CSS ja auch wirklich sehr potent und wird auch täglich stärker, ja, zieht immer mehr Arbeit ab von JavaScript und auch von HTML vielleicht. Und das halt einfach immer performanter zur Runtime als JavaScript laufen zu lassen. Einfach weil das halt nativ im Browser implementiert, entweder in C ⁇ oder Rust, während JavaScript eben just in time-compiltes, interpretiertes Scripting ist.

SPEAKER_01 12:36

Und hast du da vielleicht zum Verständnis so ein paar Beispiele, wo du in letzter Zeit vielleicht dann mehr. Oder was sind Dinge, wo du zu SS nutzt, wo vielleicht andere es nicht nutzen oder so, die, die sich jetzt vielleicht nicht so stark mit diesem Performance-Teil beschäftigen? Hast du da so ein paar?

SPEAKER_03 12:51

Also der so ein prominentes Beispiel ist Slider. Also früher hat man ja Flex-Slider und welche war der andere? Es gab zwei, die so Flick-Slider, glaube ich, oder irgendwie so. Also es gibt auf jeden Fall zwei so Libraries, mit denen man im Prinzip so wie so Bildergalerien oder Slider gebaut hat. Und das waren mitunter immer die größten JavaScript-Skripte, die ich sozusagen, oder auf Komponenten bezogen Skripte, die geschhippt wurden. Und das kann man alles mit CSS mittlerweile machen. Also es gibt ja dieses Scroll-Snapping, wo man eben dieses Einschnappen haben kann. Dann haben wir Smooth Scrolling. Dann ganz neu ist es ja diese CSS-Carousel-API, wo man sich sogar per CSS-Knöpfe links und rechts für Vor und zurück erzeugen lassen kann, aktuell nur in den Chromium-Browsern. Und diese Dot-Navigation, die es dann oftmals drunter gibt. Also das einzige Feld, was da noch nicht beackert ist, ist Endless Scrolling. Also, dass man sozusagen, wenn man am Ende des Scrollers ankommt, dass es dann einfach nahtlos wieder mit den ersten Elementen weitergeht. Also das ist zwar aktuell in der, also es wird aktuell so, da wird nach Ideen gesucht, aber es gibt es noch nicht.

SPEAKER_01 14:20

Das heißt, dann muss ich doch wieder die ganze Slider-Library reinholen, damit ich wieder am Anfang anfangen kann.

SPEAKER_03 14:26

Naja, ich ergänze das dann meistens mit eigenem JavaScript, das dann eben diese Dinge übernimmt. Also, aber ich flankiere das dann eben einfach mit deutlich weniger JavaScript, als das eben vormals nötig war. Und du hast halt auch Vorteile bei Responsiveness. Also das war ja auch immer so, wenn du das Browserfenster kleiner gemacht hast früher, dann musstest du quasi diesen Slider einmal sozusagen destroyen und dann musstest du den wieder neu initialisieren, basierend auf der Auflösung, die du gerade hast. Das hast du halt auch alles nicht.

SPEAKER_00 14:59

Wie ist denn das generell, wenn du so an der Speerspitze gerade von CSS bist, ist es ja oft so, dass ich mich dann in Kenner Use, also auf der Seite Kenner Use wiederfinde und dann diese Abwägung so schwer ist für mich, okay, kann ich das jetzt vertreten, dass irgendwie erst 80 Prozent der Browser das können oder nicht? Und wie geht man dann mit den Legacy-Produkten um? Also ist das, wie machst du diese Abwägung und was ist dann deine Lösung dafür, wenn du sagst, oh, das reicht mir aber nicht?

SPEAKER_03 15:30

Kann ich nachvollziehen. Ich bin, also auch wenn ich mit Reading Edge unterwegs bin, bin ich eigentlich immer sehr konservativ. Tatsächlich habe ich jetzt auch gerade den Fall gehabt, dass ein Kunde mit einem Chrome 56 angekommen ist. Also weil es auch Kunden gibt, die Smart-TVs nutzen. Und die haben halt einfach relativ veraltete Browser. Und dann sind natürlich so Sachen wie Grid, die es setup Chrome 57 gibt. Ist natürlich so knapp vorbei, sehr ärgerlich.

SPEAKER_01 16:05

Ein sehr modernes Feature aus, muss man sagen. Grid ist natürlich. Ja, genau.

SPEAKER_03 16:09

Das gibt es ja eigentlich seit 2017. Aber ja, der Fernseher, also auch wenn du heute einen Fernseher kaufst, bekommst du ja auch nicht den aktuellen Chrome oder Chromium, sondern vielleicht irgendwie einen der 40 Versionen hinterher hinkt. Genau, also ich bin da eigentlich sehr konservativ und es kommt immer so ein bisschen auf das Feature drauf an. Also was ich zum Beispiel nicht nutzen würde, auch absehbar noch gar nicht, ist CSS-Nesting, weil das hat halt überhaupt kein Fallback-Szenario, das irgendwie praktikabel ist. Also das kann der Browser entweder parsen oder gar nicht. Und dann, wenn er es nicht parsen kann, dann hat man gar nichts. Genau, dann könnte ich, also was kann man da machen? Da kann man im Grunde fast nichts machen. Also man könnte mit Post-CSS oder so, könnte man versuchen, eine Version dann davon zu machen oder Nesting von dem CSS und das dann shippen irgendwie über eine Feature Detection, aber das macht dann irgendwie das Rendering wieder langsam, das ist dann wieder das Problem mit der Performance. Sowas würde ich nicht benutzen. Aber bei dem Scroll-Snapping und Co., was ich da dann im Grunde verlieren würde, wenn ein alter Browser kommt, der das noch nicht kennt, der müsste aber dann auch schon ganz schön alt sein, dann hätte ich eben vielleicht kein Smooth Scrolling oder ich hätte kein Snapping. Der Scroller würde einfach, wenn ich ihn irgendwie scrolle, nirgendwo einschnappen, sondern einfach doof in der Mitte zwischen zwei Slides stehen bleiben und würde sich denken, so ja, habe ich schon mal schöner gesehen. Aber genau, es würde im Grunde trotzdem gehen.

SPEAKER_00 17:41

Mein Gedanke ist dann auch immer so, bei Leuten, die so einen alten Browser haben, da wird wahrscheinlich sowieso so vieles komisch aussehen, dass die es jetzt auch nicht sehr verwundet sind, wenn auch sowas mal passiert. Ich meine, am Ende ist, glaube ich, immer die Abwägung, ist es broken? Oder ist es auch, also ist es noch halbwegs nussbar und man weiß ungefähr, was es sein soll. Genau. Das ist auch so, ja.

SPEAKER_03 18:02

Und Browser Stack ist ja natürlich dein Freund dann, ne? Ja. Das kennt ihr ja wahrscheinlich auch.

SPEAKER_00 18:07

Ja, aber erzähl gerne mal ganz kurz drüber, weil das ist wahrscheinlich auch ein Tool, was du dann sehr oft nutzt, um eben genau das und vielleicht doch gerade Performance irgendwie dir anzuschauen.

SPEAKER_03 18:18

Ja, Performance nicht so, weil also Browser Stack ist ein Anbieter oder eine Plattform, eine Cloud-Plattform oder eine Software-Sa-Service-Plattform besser gesagt. Die haben alle möglichen Browser auf allen möglichen Betriebssystemen und man kann dann eben, man muss dafür zahlen, kostenlos ist es nicht, aber wenn man da zahlen des Mitglied ist, dann kann man eben hingehen und sagen, ich möchte jetzt gerne ein Windows 7 haben mit Chrome 56 zum Beispiel. Und dann wird auch tatsächlich, also dann wird das nicht emuliert, sondern wird tatsächlich eine Maschine, eine virtuelle Maschine hochgefahren und der Inhalt dieser Maschine zu einem gestreamt, als aber man merkt das jetzt nicht. Also so wie GeForce Now nur für Browser. Und man kann eben auch, also man kann iOS testen, man kann ältere iOS-Versionen testen, weil ich meine, wie kann man ältere iOS-Versionen testen? Ich weiß nicht, wie ihr das macht, aber ihr habt dann ja irgendwie, ihr braucht ja dann ein Gerät pro iOS-Version und dürft die ja nicht updaten. Weil wenn man einmal geupdatet hat, da gibt es ja keinen Weg zurück. Also ihr könnt nicht euch die alte Version nochmal drauf spielen. Ich glaube, ihr leistet euch das, aber für mich wäre es halt ein bisschen ein Overkill. Genau. Einfach damit man Bugreports von Kunden auch nachvollziehen kann, letztlich.

SPEAKER_00 19:40

Ah, das ist dein Haupt-Use Case davon. Also du machst es weniger mit der Spieler. Ich teste auch.

SPEAKER_03 19:46

Ja, ich benutze es weniger in der Entwicklung. Also ich habe manchmal so Kandidaten, wo ich natürlich denke, so, ja, ich glaube, da könnte es jetzt schlecht sein. Oder zum Beispiel, wenn man jetzt noch keine Lust hat, auf iOS 26 zu updaten, weil man Liquid Glass doof findet. Und auch die ganzen anderen Projekte. Wie kann man das denn doof finden? Ja, weiß ich auch nicht. Genau, es gibt ja noch so ein paar andere Lapsi, die da passiert sind. Also wenn man das sozusagen aussitzen will bis zur 27er Version, die wahrscheinlich demnächst vorgestellt wird, dann kann man zum Beispiel auch die 26er Versionen einfach auf Browser-Stack testen. Das habe ich gemacht. Also als die rauskamen, da wusste ich, da war mir ganz klar, dass da ganz viele Dinge ganz merkwürdig sind. Vor allem, wenn man irgendwelche Sachen als Sticky-Footer hat, weiß nicht, ob ihr sowas auch schon hattet, dann es gibt ja diese schwebende Adressleiste und der Browser, der denkt sich dann irgendeine Farbe aus, die darunter sein müsste. Und wenn man so ein Sticky-Ding unten floaten hat, dann nimmt er manchmal die Farbe davon. Genau, und ich hatte es vermutet und so war es dann auch. Und das konnte ich halt dann dank Browser-Stack testen.

SPEAKER_01 20:55

Wir finden ja selten im wirklich Browser statt. Wir finden zwar in einem Web-View statt, aber meistens im Rahmen einer nativen App, von daher müssen wir uns nicht mit der Browser-Leiste rumschlagen, außer in internen Prototypen, oder? Aber ich fand trotzdem diesen Punkt gerade interessant, weil ich ja meinte, wir leisten uns bestimmt ja iOS-Device auf alten Versionen zu haben. Ja, theoretisch leisten wir uns das. Theoretisch haben wir irgendwo welche Rumliegen, aber ich muss sagen, in der Realität passiert es schon selten, dass wir auf alten iOS-Versionen testen.

SPEAKER_00 21:20

Ja, es ist halt genauso, wie wir eben schon gesagt haben. Wir gucken uns halt an, wie viele Devices sind das und dann müssen wir halt abwägen. Lohnt es sich für uns, das darauf jetzt zu testen?

SPEAKER_01 21:30

Genau, und halt auch selbst auch bei Bug-Reports. Das ist halt nicht immer die Frage, was für Produkte man entwickelt. Also es ist am Ende so, es muss halt eine kritische Masse erreichen, theoretisch, dass wir uns mit Bugreports dann wirklich beschäftigen, wenn du halt Free-to-Play-Titel hast, so werden wir es nicht mit jedem einzelnen Bug beschäftigen. Wenn natürlich jemand was für sein Produkt bezahlt, gekauft hat, dann ist es ein bisschen anderer Qualitätsanspruch, den man dann an oder bei jeder User an dieses Produkt geben kann. So ist es natürlich bei uns immer eine Abwägung. Und da ist es schon so, dass wir manchmal großzügig abschneiden, was den Support angeht und andererseits auch auch großzügig abrunden, was die Anzahl an Reports angeht und wann wir uns damit beschäftigen. Obwohl gerade du ja vor kurzem auch ein altes, oder es war ein Android, glaube ich, extra gekauft habt, um das Performance-Test ist schon so, also gerade, wir haben natürlich immer, aber es ist halt nicht so, dass wir sagen, wir haben jegliche iOS-Versionen da, dass wir in dem Fall irgendwas machen können, sondern eher grundsätzlich zu sagen, lass uns Low-End-Devices da haben und wir testen halt parallel einfach immer auf Low-End-Devices, um einfach ein Gefühl für die Performance auf Low-End-Devices zu haben. Da haben wir auch letztens zum Beispiel gehabt, dass wir einfach geschaut haben, okay, wie sieht es mit irgendwie Crash oder A ⁇ A-Raten raus und haben uns mal ein paar Devices, wo die Rate im Verhältnis am höchsten ist, haben uns die mal bestellt und einfach lokal da liegen und gesagt, okay, dann wird es jetzt einfach meinen Main-Testing-Device und sage ich einfach, wenn ich da drauf nichts merke, dann wird es auf den anderen tendenziell vielleicht auch gut funktionieren. Also deswegen Browser Stack. Aber Browser-Stack ist auf jeden Fall eine super Ergänzung. Also es ist auch da, wenn wir teilweise irgendwelche Device haben, haben wir das auch schon mit Browser-Stack probiert nachzustellen.

SPEAKER_00 22:58

Aber lass uns gerne mal ein bisschen in die technische Tiefe gehen, weil das würde mich mal stark interessieren, du hast ja eben schon so gemeint, Performance testest du mit Browser-Stack eher weniger. Was ist denn dein Weg, Performance wirklich zu testen? Also erstmal vielleicht generelle Performance, also wenn du eine neue App erstellt hast und dann mal checken willst, okay, wie sieht denn so die Performance aus, aber auch, wie gehst du denn rein, wenn du merkst, oh, hier ist irgendwas nicht so, wie ich möchte, von der Geschwindigkeit, von der Performance, was auch immer. Was sind so deine Tools? Wie nutzt du die und wie fixst du damit dann auch deine Probleme?

SPEAKER_03 23:32

Ja. Genau, also Browser Stack einigt sich deswegen nicht, weil Browser Stack selbst auch schon so eine gewisse Langsamkeit durch sein Funktionsprinzip mit sich bringt. Und man hat zwar Dev-Tools, aber die sind halt einfach nicht, also die sind schon super, ist cool, dass man die hat, aber die sind halt nicht so gut wie die echten. Also ich kann jetzt kein Performance-Profiling oder so in den Dev-Tools da gut machen. Genau, das heißt, also zum einen gibt es, also für Ladezeit gibt es ja Tools wie unter anderem Webpage-Test, mit denen kann man das, kann man so Tests ganz gut machen. Sofern das Webprojekt eben von extern erreichbar ist. Webpage-Test ist letztlich sowas wie auch ein ferngesteuerter oder gescripteter Browser. Man kann sich dann aussuchen, welchen man testen möchte, ob Chrome oder Firefox. Man kann sagen, von wo aus der Test laufen soll. Soll der aus Frankfurt laufen? Soll der aus Übersee laufen? Und man kann dann auch die Geschwindigkeit der Anbindung wählen, die dann allerdings, glaube ich, emuliert ist, was immer noch natürlich nicht genau das gleiche ist wie ein echtes. Genau, also da gibt es dann, weiß ich nicht, Cables, also der Klassiker oder Fast 3G wäre jetzt so, da würde ich irgendwie so hingehen. Das ist so der in unseren breiten Graden zumindest so die langsamste Verbindung. Wenn man für den globalen Markt arbeitet, dann muss man vielleicht auch noch ein Slow 3G sich vielleicht angucken. Und genau, und das Device kann man sich auch noch aussuchen. Also ob das jetzt ein MotoG ist oder ob das ein Desktop-Browser sein soll. Genau. Über Webpage-Test kriegst du dann am Ende so eine Auswertung. Da werden natürlich die Lighthouse-Scores getestet, da kriegst du aber noch viele andere Metriken. Und du bekommst auch so einen Wasserfall-Chart, wo du genau sehen kannst, so wie wir es im Grunde auch aus dem Network-Panel des Browsers kennen, oder wir haben auch dieses Network, diese Network-Spur in dem Performance-Profiler, in den Dev-Tools, wenn man da Profilet. Aber WebPage-Test bereitet es einfach super auf, mit Details auch zu den einzelnen Requests, wo du dann auch sehen kannst, auf welchem Protokoll lief das. Und wenn es auf HTTP 2 oder höher lief, so auf welche Priorisierung hat dieser Request vom Browser bekommen, dann kannst du irgendwie nachvollziehen, also schickt der Server, beachtet der Server das oder ist dem Server das völlig egal. Das ist ja bei HTTP 2 auch so ein klassisches Problem, dass Server das leider nicht so implementieren, wie es sein müsste. Genau, und du kriegst eben ganz unten hast du auch so eine Leiste, wo du sehen kannst, wie hoch ist die Auslastung der CPU des Systems, also für das Parsen und das Ausführen, also Parsen von Alm und das Ausführen von JavaScript, respektive vielleicht auch das Layouting, das er da auch mit reinspielt. Und genau, dann, wenn, wenn halt diese CPU-Bar, wenn die irgendwie relativ gefüllt ist, sehr viel Aktivität drin ist, dann ist das schon so ein Indikator für, da läuft einfach zu viel auf dem Main Thread, da muss man irgendwie nochmal rangehen. Und dann bekommst du auch nochmal angezeigt, welches der Skripte, die du geladen hast im Waterfall dann quasi Aktivität auslöst. Genau. Das finde ich eigentlich ganz gut. Ansonsten den, also bei, wenn ich mit echten Geräten teste, dann versuche ich eben auch so Mid-Range-Geräte zu bekommen. Also, ich habe jetzt auch kein, nicht das neueste Smartphone. Ich habe hier ein Google Pixel 6. Also auch schon ein bisschen betagter. Genau, und dann kannst du da testen und eben auch per Remote-Debugging, also einfach per USB anschließen, kannst du dann Performance-Profiling machen und dann da tiefer einsteigen und gucken, wo gibt es Probleme. Und da gibt es ja dann, was so die Laufzeit-Performance angeht, gibt es ja diese Richtschnur, dass du versuchst, einen Task, wenn er ausführt, auf eine maximale Dauer von 50 Millisekunden zu begrenzen. Also wenn er länger dauert, dann fängt die Userin oder User an, irgendwie das zu bemerken, dass quasi das Interface blockiert ist und dass es eben nicht mehr auf Eingaben reagiert. Und da fangen dann, da fängt das Bauchgefühl an, zu sagen, so, das ist jetzt irgendwie ein Laggy hier alles. Genau, da gibt es dann wieder verschiedene Strategien, wie man diese 50 Millisekunden sozusagen, wie man in diesem Rahmen bleiben kann.

SPEAKER_00 28:27

Uh, was sind das so für Strategien?

SPEAKER_03 28:31

Also es gibt so verschiedene Strategien. Also entweder du verlagerst Tasks in komplett andere Threads, also weg vom Main-Shread. Das ist dann, das versuche ich auch viel zu machen, also dass ich zum Beispiel in dem aktuellen Text-Deck ist es so, dass ich in der Summe fünf Webworker habe, die noch hinten so rumschwirren und diese bestimmte Aufgaben übernehmen können. Zum Beispiel einer macht das Template-Rendering. Das heißt also, der kriegt die Daten, der hat die Templates, rendert die zusammen und schickt dann die fertig gerenderte HTML wieder nach vorne in den Main Thread rein. Dann gibt es einen Webworker, der mit dem anderen Webworker auch kommuniziert, aber auch mit dem Main Thread, der so Translation-Kram macht. Genau, was habe ich noch? Translation-Kram mit bezogen auf, also was in Form-System. Also Multi-Mehrsprachigkeit. Also wenn ich da sozusagen im Browser rendere, dann habe ich halt die ganzen Übersetzungen auch in dem drin und dann gibt er eben die passenden Übersetzungen für die aktuell gewählte Sprache zurück.

SPEAKER_01 29:35

Okay, Teil des Render-Webworkers, der sozusagen, also theoretisch ist es ja eine Sprache, die habe ich einmal eingestellt und danach wird jede Seite in dieser Default.

SPEAKER_03 29:45

Genau, also das ist deswegen, genau, stimmt, könnte man alles zusammen in einen reinstecken, aber die diesen Übersetzungsservice, also ich Sachen, die so leichtgewichtig sind, die schicke ich nicht an diesen Template-Renderer, weil der so ein bisschen, der arbeitet so ein bisschen wie ein Interactive Island. Also es ist quasi, der hat dann, da gibt es ein DOM-Diffing hinterher und so den ganzen Quatsch, den man so kennt, von denen von React, Angular und Co. Aber manchmal will ich so viel, manchmal ist das Overkill. Also wenn ich nur einen Button umbenennen will, weil irgendwie ein Produkt nicht da ist, dann will ich irgendwie out of stock draufschreiben und dafür habe ich dann, da schmeiße ich diese Maschinerie nicht an, sondern habe einfach ein kleines JavaScript im Main Thread, das das macht. Und das braucht dann eben aber auch den richtigen String, den es dann da reinsetzen muss und interviewt dann eben auch diesen Webworker dafür.

SPEAKER_00 30:41

Ist das, verstehst du richtig, dass das Logik und eine Infrastruktur ist mit diesen Webworkern, die du selber aufgesetzt hast oder ist das was, was Twig mitbringt?

SPEAKER_03 30:52

Twig ist einfach nur eine Syntax, also sozusagen einfach so eine Syntax, mit der man, also wie Handlebars zum Beispiel auch mit eben Kontrollschleifen, also Forloops und If-L-Statements und man kann Variablen dann nochmal in ein Template belegen und ausgeben, natürlich. Genau. Und hat dann hat dann Filter für Sorting oder für, wenn man Markdown rendern will, genau.

SPEAKER_01 31:19

Und kannst du vielleicht, ich glaube, ich würde jetzt mal sagen, das ist ja vom Ansatz her jetzt erstmal vielleicht da draußen nicht typisch, dass man sagt, okay, es gehört jetzt zum Standard-Stack, dass Leute diese Aufgaben in den Webworker verlegen. Kannst du uns da zum noch dazu erzählen, wann du entscheidest, was in so einem Webworker zu machen, warum du es entschieden hast? Und weil jetzt auch gerade bei diesen Translation, also mein erster Impuls, wenn ich es höre, denke ich irgendwie so, ist das so intensiv, dass ich einen Translation-Service in einen Webworker geben muss? Mein erster Instinkt wäre irgendwie so, das klingt übermäßig komplex und vielleicht auch unnötig. Und wie denkst du darüber nach? Warum hast du dich dafür entschieden? Und vielleicht auf unsere Zusammenarbeiten können sie das in Erwägung ziehen. Das wäre das, was der Outcome daraus hoffentlich ist.

SPEAKER_03 32:03

Genau, ich habe übrigens die Liste auf. Ich habe noch einen Filterworker, der macht so facetti Suchen. Also wenn du da irgendwas startest, dann regelt der das, dass der quasi das Backend anfragt und dann sozusagen das aufbereitet und das fertig nach vorne schickt. Dann genau für QR-Code-Scanning, da gibt es auch einen Worker, der das macht. Dann habe ich einen Speed-Test-Worker, der im Hintergrund quasi Speed-Tests durchführt. Und genau, dann habe ich noch einen, der so Exon-Colors aus Bildern extrahiert. Also dem kann man ein Bild entgegenwerfen. Und der sagt dann dunkelste quasi aus dem Farb des Farbskanners die Farbe, hältst du die und so könntest du einen Farbverlauf machen. Wie mache ich das? Also es gibt natürlich Dinge, die klingen schon schwer. Also der Renderer zum Beispiel, der klingt ja, da ist das irgendwie, ich glaube, das würde man jetzt nicht in Frage stellen. Aber im Grunde kannst du sagen, alles, was du aus dem Main Thread wegverbannen kannst, tu das einfach. Also, weil so schwer ist das nicht. Es gibt auch Libraries, die, die das leichter machen, so wie Comlink zum Beispiel. Das ist so eine kleine JavaScript-Library, die, die sozusagen so ein Syntactic Sugar auf dieses ganze Post-Message-System aufsetzt, dass das Ganze dann einfach netter zu bedienen ist. Und je mehr du Arbeit vom Main Thread weghalten kannst, desto besser. Und das ist natürlich besonders bei langsamen Geräten relevant. Also bei schnell bei iPhones ist es vielleicht nicht so wichtig. Aber je langsamer ein Gerät wird, desto constrainter ist es, desto begrenzter ist eben. Also die sind ja meistens so, dass die, die haben ja schon acht Prozessorkerne, diese kleinen Handys zum Beispiel, also die, die ihr euch da wahrscheinlich geholt habt. Die sind halt nur, jeder Kern ist halt einfach nur total lahm. Es gibt aber genug davon. Und deswegen, also so, je mehr man dem Main-Shread den Rücken freihalten kann, desto besser.

SPEAKER_00 34:11

Ich merke, da ist, glaube ich, eine Lücke bei mir. JavaScript ist ja eigentlich Single-Threaded, aber Webworker können auf einem anderen Thread laufen, ja. Also auf einem anderen Core. Genau.

SPEAKER_03 34:20

Ah, okay. Genau.

SPEAKER_00 34:21

Das war mega gut.

SPEAKER_03 34:22

Und du kannst quasi den Nachrichten schicken, wie du das irgendwie auch so über iFrame-Grenzen hinweg machen kannst. Oder so Message-Channel kannst du auch benutzen. Und dann kannst du auch Dinge, also du kannst bestimmte Dinge machen, zum Beispiel gibt es auch Offscreen-Canvas. Das ist quasi die Canvas, die aber in einem Webworker läuft. Da kann man eben dann so quasi Post-Processing drin machen von Pixeln oder Berechnungen auf Pixel-Basis und hat das nicht im Main-Shread. Genau. Und so Sachen wie Index.db, auf die hast du auch Zugriff aus dem Webworker raus. Was nicht geht, ist so Local, alle synchronen Interfaces und DOM geht nicht. Also auf den DOM kannst du nicht zugreifen. Da gibt es zwar so Tricks, da gibt es so einen, so eine Library, die heißt Partytown, die macht es möglich, aber mit so ganz üblen Verrenkungen. Ja, also das ist, ich hab das hab ich auch nicht ans Laufen gekriegt, weil es einfach krass unterdokumentiert ist, aber wie sie es machen, ist schon sehr klug.

SPEAKER_00 35:25

Die haben doch diese lustige Webseite, wo man die Cursor von anderen Leuten, anderen Besuchern der Webseite gerade sieht.

SPEAKER_03 35:30

Ist das nicht die? Ja, ist die das? Ich weiß es nicht. Das sind ja die Leute, die auch dieses Quick-Framework machen. Also das ist so dieser Dunskreis, ja.

SPEAKER_01 35:40

Ich glaube, ja, es ist auf jeden Fall, wir reden über das gleiche Party-Town, ja. Ich glaube auch, dass das war mit den.

SPEAKER_00 35:44

Aber haben die die Landingpage nicht mehr? Das war eine. Das Logo sieht für mich familiar aus, aber scheinbar ja, vielleicht haben sie es auch gekickt.

SPEAKER_01 35:55

Naja, wir werden sehen. Aber ich würde gerne mal nochmal so, wir sind jetzt schon in einige Dinge rein. Ich würde gerne nochmal auch für mich, aber zum Recap auch vielleicht nochmal für die Hörer nochmal probieren, so den Toolbelt, den wir von Chep jetzt so ein bisschen in die Hand bekommen, nochmal aufzuzeichnen. Also wir hatten ja vorhin irgendwie so ein bisschen die Kategorien aufgemacht, Ladezeiten und Runtime-Performance. So, wir haben jetzt irgendwie so ein bisschen gelernt, okay, was schaue ich mir erstmal an. Da hattest du, wie war nochmal die Name des Tools, das Web-Fat- oder wie das Web-Page-Test-Tool. Im Grunde ansonsten habe ich mal einen lokalen Device, wo ich auch irgendwie per Remote irgendwie drauf zugreifen kann, was sagen kann, ich teste das Ganze, beziehungsweise stelle dann Bugs eher über Browser-Stack nach, wenn es wirklich um alte Betriebssysteme geht, weg von Performance. Und wenn wir jetzt sagen, was können, also das ist sozusagen das rausfinden sozusagen, erstmal das Identifizieren und jetzt zu dem Toolbelt, was können wir denn tun, habe ich jetzt, im Grunde haben wir jetzt zwei Dinge genannt, wenn ich es richtig verstanden habe, die in Richtung Runtime-Performance sind. Also wir haben gesagt, was ich in CSS machen kann, mache ich in CSS und hole es raus aus JavaScript so. Das war das eine, was ich mir mitgenommen habe. Und das andere ist so, das, was nicht auf dem Main-Thread laufen muss, soll, in einen separaten Thread und dafür benutze ich Worker, dafür benutze ich die Worker grundsätzlich, die Worker-Infrastruktur, um das zu machen. Das heißt so, in meinem Toolbelt habe ich jetzt so möglichst viel CSS und davon weniger JavaScript und wenn schon JavaScript, dann auf einem Worker-Thread. Vielleicht können wir uns aber dieses Modell heißt Actor Model.

SPEAKER_03 37:22

Also das gibt es auch eben, dass man einfach eben sozusagen wie so Unterbedienstete hat, den man die Arbeit wegdelegiert, um quasi auf Main Thread möglichst frei sich bewegen zu können. Wir gehen gleich zur Ladezeit nochmal rüber. Ich wollte noch sagen, es gibt noch eine dritte Sache, die man für die Runtime-Performance machen kann. Das ist nämlich, wenn man Dinge animiert. Das kennt ihr wahrscheinlich auch, ihr werdet wahrscheinlich viele Animationen bei euch haben. Da gibt es einfach, also es gibt eigentlich ein ganz kleines Subset an CSS, was man nutzen kann, wenn man Animationen machen will, die performant sind. Also alles andere kann man machen und wenn man schnelles Gerät hat, ist es vielleicht auch schnell genug. Aber eigentlich ist es, im Grunde genommen ist es wahnsinnig imperformant. Und dahingehend kann man, das sieht man in seinem Profiler auch, also wenn sehr viel so CSS-Relayout, also wenn da so die Lila-Balken sehr groß werden oder die Grünen für Paint, dann animiert man auf die falsche Art und Weise und da muss man das eben sozusagen überdenken, wie man das macht. Und also es gibt eigentlich immer, also auf der Erlaubtliste ist eigentlich nur Opacity, dann Translation oder Transforms und Filter. Das sind die drei im Grunde. Also, und was man sich nicht mit denen zusammenbauen kann, wird halt inperformant und belegt halt den Main Thread zu einem gewissen Grad einfach mit Arbeit. Genau. Also das wären so, das wollte ich noch ergänzen, dass da kann man seine Runtime-Performance verbessern. Was so Ladearzeit angeht, da guckt man sich wirklich diesen Wasserfall an, weil der gibt Auskunft über Dinge wie wann wurde ein Server Connect durchgeführt. Wenn man bestimmte Ressourcen hat, die zwingend erforderlich sind, dann ist es ja sinnvoll, wenn man das schon vorab weiß, diese Server Connect zu diesen vielleicht weiteren Host, abgesehen vom Main-Host, frühzeitig zu machen. Da gibt es dann DNS-Pre-Connect-Anweisungen, die man, also man kann Link RHEL, nee, das ist nur Pre-Connect, DNS-Prefetch war es früher und jetzt heißt es Pre-Connect. Das kann man in seinen Head reinstecken und dann erstellt, dann stellt der Browser schon mal Verbindungen her zu diesen anderen Hosts. Oder man weiß sogar, welche Datei man brauchen wird später und die ist irgendwie relevant für eine schnelle Interaktion oder so, dass vielleicht das Haupt-JavaScript. Also wenn ihr das zum Beispiel über JavaScript-Modules ladet, dann ist es ja so ein asynchrones Ding und dann dauert das vielleicht, bis der Browser sich dran macht, die zu laden. Da kann man dann einen Link Rel Prefetch, äh genau, Prefetch in sein Head reinstecken und sagen, hey, Browser, die Ressource hier, die kannst du schon mal holen gehen, weil ich gebe dir hiermit die Garantie, ich werde es später brauchen, das mach das mal. Genau, und so kann man im Grunde den Wasserfall, der vielleicht erstmal nicht so aufgebaut ist, wo nicht die Dateien geladen werden in der Geschwindigkeit oder vielleicht auch in der Reihenfolge, die einem wichtig sind, nach und nach ummodellieren und dann neue Tests laufen lassen. Und dann sieht man eben, wie sich dieser Wasserfall verändert. Aha, hier, das wird vorher an zehnter Stelle geladen, jetzt wird es schon an dritter Stelle geladen, super. Und meine ganzen Connects zu den Servern, die finden nicht nacheinander mehr statt, sondern ich sehe, ah, cool, die sind jetzt alle gleichzeitig, also die werden vorbereitet und müssen nicht erst später, wenn ich dann zugreife, gemacht werden.

SPEAKER_00 41:16

Das sehe ich auch in dem Profiling von dem Performance-Tab in Chrome, richtig?

unknown 41:23

Ja.

SPEAKER_00 41:23

Oder in dem Network-Tab. Dann vielleicht, weil wie der Name von diesem Tab schon sagt, Performance Tab, ist das ja eigentlich so der Ort, den man zumindest in Chrome irgendwie nutzt, um sich diese Themen anzuschauen. Aber für mich ist das so, als ich das erste Mal auf diesen Tab gegangen bin und mal so ein Profiling gemacht habe, war ich danach so, wie soll ich hier irgendwie machen?

SPEAKER_03 41:43

Irgendwie die Mutter aller Profiles zu tun.

SPEAKER_00 41:46

Das ist unfassbar. Kannst du, also das ist ja eh schon eine schwierige Aufgabe, jemandem zu erklären, wie das Ding funktioniert. Traust du dich zu, das nur auf Tonspur mal, also so ein, zumindest so einen Ansatzpunkt zu geben? Wie kann man mal so eine erste Sache da herausfinden? Oder wie würdest du einem Anfänger zeigen, okay, wie benutzt du das?

SPEAKER_03 42:09

Es gibt zwei Methoden, die du da nutzen kannst. Das eine ist, dass du einfach ein Profiling startest auf der Seite, so wie sie gerade ist, und das eben, also das manuell startest und irgendwann sagst, so, das reicht mir jetzt, und was bei dem Profiling passiert, ist, dass einfach im Prinzip Telemetriedaten aus allen Ecken des Browsers zusammengesammelt werden, die in dieser Zeit irgendwie eine Rolle gespielt haben. Das sind, das können eben Network-Requests sein, das kann eben Rechenaktivität sein, runtergebrochen auf, war das jetzt HTML-Parsing, war das jetzt JavaScript-Parsing und Execution oder war das Layouting-Arbeit. Und das gleiche bekommst du auch für jeden Webworker, den du hast. Also wenn du mehrere Webworker hast, dann bekommst du da auch nochmal Spuren für. Also du kannst dann sehen, was passiert ist und kannst dann da reinzoomen, kannst zum Beispiel auch sehen, aha, da ist die Datei im Wasserfall gekommen. Danach kann ich sehen, dass eben erstmal JavaScript gepasst wurde. Macht Sinn, weil das war eine JavaScript-Datei, die geladen wurde. Und du kannst dann in diese Rechenaktivitäten von, in dem Fall JavaScript, HTML und CSS-Layout, dann geht das nicht ganz so gut. Aber bei JavaScript kannst du dann tiefer reingehen und kannst dir dann sogenannte Flame Charts anzeigen lassen. Das sind im Grunde so Call Stacks. Also was hat denn jetzt eigentlich zu dieser Aktivität geführt und welcher Callstack, welche Call Stack-Kette ist dadurch laufen worden? Und vielleicht auch welcher, welche Funktion hat irgendwie sehr viel Zeit verbraucht in meinen in der Zeit. Ja. Bei CSS, da kannst du zumindest, ich weiß nicht, ob man das, ich glaube, das musst du aktivieren, weil das dieses Profiling nochmal langsamer macht, da kannst du zum Beispiel noch tiefer reingehen, ob das quasi beim, ob das beim Recalculation viel Zeit gebraucht hat oder dann tatsächlich beim Painten und Layouten. Das Recalculating ist immer, wenn der Browser hingehen muss und HTML neu gegen die ganzen CSS-Selektoren matchen muss. Also das macht er zum Beispiel, wenn du eine CSS-Klasse auf dem Root-Element setzt, dann muss der den gesamten DOM-Baum wieder matchen gegen deinen CSS. Und das kann halt viel Zeit in Anspruch nehmen, je nach Selektor auch sogar richtig viel Zeit. Also die Hash-Selektoren sind da, sind da, die kann man schon so bauen, dass die sehr zeitintensiv sind. Weil der Browser einfach so eine gewisse Heuristik hat, dass er sagt, hey, wenn im Root eine Klasse geändert wird, dann könnte eigentlich ja bei jedem Element, wenn der Elternklasse jetzt eben diese andere ist, sich was getan haben. Also muss ich das machen. Oder du machst es an einer Stelle und alle quasi darauffolgenden Siblings werden neu evaluiert, weil du natürlich diesen Siblings-Selector in CSS hast, der dann eventuell zu einer Änderung führt. Genau, solche Dinge kriegst du dann eben da in diesem, wenn du bei CSS tiefer reingehst, angezeigt.

SPEAKER_01 45:31

Und vielleicht, jetzt haben wir gerade so ein bisschen verstanden, wie der Performance-Tab zu nutzen ist. Wir hatten ja vielleicht nochmal ein bisschen auf dieses, wie schaust du denn eigentlich auf Performance? Oder weil du hast ja so ein paar Dinge genannt, wie einerseits, okay, wenn man da reinschaut und irgendwie Einzelinteraktionen lenkt, diese 50 Millisekunden überschreitet, dann kann ich natürlich den Webpage-Check da an der Stelle nutzen, wenn es irgendwie um Ladezeiten geht. Aber ich frage mich, wie machst du denn, wenn wir von Runtime sprechen, wie machst du es zur Development Runtime oder im Laufe der Entwicklung, die Performance irgendwie im Blick zu haben? Also was ist so dein Tooling, was du durchgängig irgendwie nutzt oder vielleicht auch für, was würdest du gerne den Hörern irgendwie mitgeben? Wie sollten sie irgendwie darauf blicken und was sollten sie irgendwie kontinuierlich im Blick haben? Ich weiß nicht, war auch dieses, du hattest was von deinem Worker gesprochen, der Speed Check-Worker, hat der was mit Performance zu tun? Also war das was in die Richtung, was du diesen Worker-Lauf hast oder was war dieser Speed Check-Worker? Hatte der damit zu tun? Aber ich würde gerne zu verstehen, wie sieht denn, bist du aber jemand, der immer den Performance-Tab auf hat?

SPEAKER_03 46:32

Nee, ich habe den nicht immer auf. Also ich, also Performance ist generell schon was, was man immer mitdenken muss von Anfang an. Also du kannst, also es ist eines von diesen Dingen, so wie Accessibility oder was weiß ich, gibt es ja noch so ein paar andere Dinge. Die muss man von Anfang an mitdenken. Wenn man die nachträglich versucht reinzubauen, dann ist es immer schwierig. Also bis teilweise vielleicht auch gar nicht so einfach möglich. Ich kann auch gleich von einem Ding erzählen, was ich im Nachhinein wahrscheinlich anders gemacht hätte, das aber nicht so einfach mehr zu Retro-Fiten ist, was so jetzt Performance angeht. Aber ansonsten ist es eigentlich so, dass wenn so ein Projekt dann mal draußen ist, dann finde ich eigentlich am besten, so ein Real-User-Monitoring-Tool laufen zu haben. Also das ist sozusagen immer die Que für mich, auf Performance-Probleme Suche zu gehen. Und dieses Real-User-Monitoring-Tool, da gibt es ja diverseste Anbieter, was die machen, das ist einfach ein Skript, das läuft bei jedem User. Das könnte ich auch in meine Codebase einbauen. Aber die Frage ist halt, wo werden diese Daten zusammengesammelt und aufbereitet. Das ist ja eigentlich immer das Schwierige. Wir nutzen dafür zum Beispiel Sentry, aber es gibt auch Speed Curve oder Caliber und noch so ein paar andere. Oder von Akamai gibt es auch solche Tools. Die messen eigentlich kontinuierlich die Core Web-Vitals und gegebenenfalls noch ein paar andere Metriken und geben das zurück. Und ich kann dann in der Auswertung sehen, wenn meine Core Web-Vital-Werte in den Keller gehen. Core Web Vitals, was ist das? Das sind im Prinzip so performance bezogene Metriken, die vorwiegend Google erarbeitet hat und die eben diese Bereiche abdecken: Ladezeit, Runtime-Performance und auch Layout Stability. Es sind auch drei. Es gibt drei, die sozusagen eine wichtige Rolle spielen und dann gibt es noch viele andere, die da noch dazukommen. Aber so, da gibt es dann irgendwann eben dann die Benachrichtigung, hier ist irgendwas nicht mehr so gut. Guck mal nach und dann konzentriere ich mich wieder mehr auf das Thema Performance, bis es dann erstmal wieder auf Stand ist. Man kann in seiner CI-CD-Pipeline natürlich auch Tests laufen lassen. Also kann man Lighthouse-Tests laufen lassen. Man kann auch Tests laufen lassen, die generell sozusagen so Größenbudgets kontrollieren. Also dass man sagt, ich leiste mir bis zu 200k JavaScript, mehr möchte ich nicht haben. Bitte lass die Pipeline failen, wenn wir irgendwann an den Punkt kommen, wo wir mehr verbrauchen. Genau, damit einem das nicht so durchgeht, damit man nicht so eine schleichende Verschlechterung hat. Problem ist halt, das ist ja so ein Laborsetting. Also auch wenn wir auf unserem Mac jetzt das Lighthouse-Tool laufen lassen und wir gucken uns die Performance-Werte an, auf dem MacBook ist es mega, ist alles super, meine Seite ist schnell, geil, alles grün. Auf dem Windows-Rechner nebenan ist es vielleicht dann aber schon gar nicht mehr so. Und auf dem langsamen MotoG überhaupt nicht. Deswegen sind die auch überhaupt nicht vergleichbar. Also wenn ich sage, hey, ich habe bei Performance 98, dann sagst du, nee, das stimmt nicht, wir haben doch nur 80. Dann haben wir beide recht. Weil das eben nur bezogen ist auf unsere aktuelle Maschine. Also das wäre unter unsere Leitung auch. Also man kann, das wird zwar künstlich verlangsamt, also man kann seinen Durchsatz sozusagen auch schrotteln, aber das ist halt nicht das echte Ding. Also ich will nicht sagen, dass man es gar nicht nutzen sollte, aber man muss einfach wissen, dass das nicht das ist, was die Leute draußen sehen.

SPEAKER_00 50:49

Es ist auf jeden Fall immer noch gut als Vergleichsmetrik, ne? Also wenn man Änderungen schippt und merkt, oh, der Score ist irgendwie runtergegangen, dann kann man schon präventiv drauf gucken, so okay, was sollten wir da was machen?

SPEAKER_03 51:00

Das stimmt, also genau, also bezogen auf das gleiche Gerät sozusagen am Tag vorher, dann das kann man vergleichen. Das stimmt.

SPEAKER_01 51:08

Aber ansonsten würdest du sagen, Real User Monitoring, dann sowas wie Sentry, dass wir uns da aber wirklich eher uns den reellen Wert anschauen.

SPEAKER_03 51:15

Genau, also Century haben ja eh viele Leute sowieso am Start für einfach fürs Error-Tracking und dann hat man einfach dieses andere, diesen anderen Themenbereich Freihaus mit dabei.

SPEAKER_01 51:27

Ja, cool. Dann, wenn du magst, erzählen sie nochmal gerne, was du vorhin kurz geteasert hast, mit was du heute anders tun würdest, aber nicht mehr reversibel ist, wenn welche Pfeile nicht zugetappt.

SPEAKER_03 51:43

Da geht es um die generelle CSS-Architektur. Ich bin, also ich finde Tailwind okay und ich arbeite damit auch, aber für dieses Projekt mit vielen Komponenten habe ich mich für die BEM-Methodik entschieden. Die kenne ich gerne. Einfach auch das Block Element Modifier. Dafür steht die Abkürzung. Und es funktioniert so, dass du jeder Komponente einfach klassischen Namen gibst, idealerweise dein ganzes Projekt prefixed mit irgendwas, damit, falls du Komponenten von anderen Frameworks reinmischst, du keine Kollision hast. Es nicht beide Slider heißen zum Beispiel. Und alle Bestandteile dieser Komponente, also weiß ich nicht, von der Card darfst du dann ein Bild, dann hast du ja noch quasi die Caption und so, die kriegen dann CSS-Klassen zugewiesen, die eben auch wieder mit Card starten und dann Unterstrich, Unterstrich-Caption haben oder Unterstrich, Unterstrich-Image. Das ist einfach eine strikte Namenskonvention, die man da wählt. Aber klassisches CSS arbeitet ja wirklich immer so, und BAM ist da ja nicht anders, dass man an Elemente eine Klasse hängt und diese Klasse zeigt ins CSS und da sind dann ganz viele Anweisungen drin. Und über die Zeit baut man immer mehr Komponenten und hat immer mehr CSS, das dediziert für diese Komponenten ist, aber wo sozusagen Anweisungen da drin sich im Grunde ständig wiederholen und duplizieren. Und an dem Projekt hier bin ich jetzt schon eine ganze Weile dran und die Komponentenzahl ist halt unglaublich gewachsen und damit ist auch das CSS unglaublich gewachsen. Das wächst halt quasi eins zu eins mit mit der Komponentenmenge. Hätte ich Tailwind genommen von Anfang an, auch wenn das vielleicht fürs Debugging schwieriger ist, wäre das nicht passiert. Dann, also bei Tailwind ist es ja so, das verlagert ja sozusagen das Wachstum aus dem CSS raus ins HTML hinein. Das HTML wird ja dann einfach groß und clunky und das finden ja auch viele Leute doof. Der Unterschied ist aber, CSS muss immer als Ganzes heruntergeladen und gepasst werden, bevor der Browser den ersten Pinselstrich tut. Und er kann diesen Pinselstrich auch nicht tun, wenn er 20% des CSS hat. Weil es kann ja sein, dass da hinten was kommt, was eine höhere CSS-Spezifität hat, was das ja sozusagen wieder nachträglich invalidiert. Und im Gegensatz dazu ist HTML eines der wenigen streamenden Datenformate, die wir im Web haben, also neben JPEG-Bildern zum Beispiel. Das heißt also, es ist gar nicht so schlimm, wenn das HTML riesengroß wird. Also, das finden wir vielleicht ästhetisch blöd, aber es ist nicht schlimm, weil der Browser kann sofort anfangen, damit DOM aufzubauen. Das ist sozusagen bei Design so. Und da hätte ich sozusagen, also das kann ich jetzt nachträglich auch nicht mehr so einfach machen. Also vielleicht kann es, wenn ich mit KI-Ansatz vielleicht. Aber CSS prüfen auf Regressions ist ja eh auch nochmal so ein ganz schwieriges Thema, ob man da was kaputt macht. Genau, also hätte ich Tailwind genommen oder einen Utility-CSS-Ansatz, da gibt es ja auch noch andere außer Tailwind, dann wäre mein CSS einfach irgendwann an einem Punkt nicht mehr weiter gewachsen und würde jetzt nicht sozusagen als ein Web-Performance-Bremsklotz, in meiner Webseite im Head herumdümpeln.

SPEAKER_01 55:23

Aber das wäre jetzt noch genau meine Frage gewesen. Ist es dann am Ende ein, du hast gemerkt, dass es immer größer wird und das sozusagen per, also architekturell findest du es nicht schöner, ist es ein auffallender Performance-Impact bei der Seite, dass dann CSS so groß ist?

SPEAKER_03 55:37

Naja, das, also ich kann das schon, also es ist natürlich komprimiert und mit Brotli und Z-Standard und so kann man ja viel rausholen aus den Dingen, aber es ist schon auffällig, dass diese CSS-Datei relativ groß ist. Also, weiß ich nicht, ob ich das jetzt hier gerade mal sehen kann. Genau, also 737 KB ist schon groß. Das ist schon ein bisschen.

SPEAKER_01 56:06

Das heißt, jetzt bist du doch Tailwind-Fan.

SPEAKER_03 56:10

Ich war nie gegen Tailwind, aber genau, ich finde halt die BAM-Methodologie einfach gut, weil du kannst halt einfach in deinen DOM reingehen, inspecten und du siehst halt sofort, also welches CSS gehört zu welcher Komponente. Bei Tailwind hast du ja einfach so, ja, keine Ahnung, also wo sind da die Boundaries meiner Komponente und wo ist schon die nächste, wo hat die nächste angefangen? Also wahrscheinlich, wenn ich jetzt Tailwind nehmen würde, würde ich einfach Dummy-Klassen trotzdem in meinen HTML reinwerfen. Einfach, dass ich da auch sehen kann, wo sind die Boundaries meiner Komponenten und dass ich diese CSS-Klassen aber am Ende auch nutze. Also ich würde dann wirklich nur Tailwind nutzen. Genau, aber das wäre sowas, dass da würde ich vielleicht empfehlen, gerade wenn man so Projekte hat, die halt wachsen, Tailwind zu nutzen. Genau, also ich sage mal so, in Hardcore-CSS-Ler-Kreisen ist Tailwind sehr verschrien. Genau, also das finden da alle doof. Aber aus Performance-Sicht ist es ein ziemlich guter Ansatz. Und es ist auch ein gutes Framework, generell.

SPEAKER_01 57:19

Zeitmäßig sind wir auf jeden Fall jetzt schon langsam bei einer Stunde angelangt, deswegen würde ich mal so ein bisschen, also wir haben ja jetzt so probiert, parallel immer so ein bisschen das Toolbild aufzumalen, das du uns an die Hand gegeben hast. So, wenn wir jetzt die Frage eher nochmal ein bisschen offenstellen würden, hast du denn das Gefühl, so wir haben die grundlegenden Dinge, über die du so bei Performance nachdenkst, wenn du, wenn du Produkte entwickelst, angegangen? Oder würdest du sagen, es gibt noch einen Bereich, auf den müssen wir auf jeden Fall irgendwie eingehen und das möchte ich noch in das Web-Performance-Tool-Belt für unsere Hörer noch mit reinpacken?

SPEAKER_03 57:50

Naja, vielleicht, also was sich immer bewahrheit ist, je weniger JavaScript man benutzen kann, desto besser. Aus verschiedenen Gründen, weil JavaScript kostet halt immer dreifach. Also es musste übertragen werden, da muss gepasst und kompiliert werden und dann kann es ausgeführt werden. Also, oder sogar vierfach. Genau, das heißt also generell, wenn man jetzt so sagt, ich habe ein bestimmtes Kilobyte-Budget, würde JavaScript viel schwerer wiegen als, also ein Megabyte JavaScript ist tausendmal schlimmer als ein Megabyte Bilder. Man kann zwar bei Bildern viel rausholen, aber das, was eigentlich wirklich einen Impact, also einen Impact hat, ist JavaScript. Wenn man das schafft, das zu reduzieren, super. Ich finde diese Interactive Island-Konzepte gut, wie sie zum Beispiel Astro bietet, dass man eben sagt, ich liefere eigentlich meine Seiten statisch aus, wie auch immer ich die rendere, ob ich die mit PHP rendere oder mit Node oder die Vorrender mit einem statischen Seitengenerator. Und dann habe ich eben bestimmte Bereiche, die sind interaktiv, die müssen eben reaktiv sein. Und genau wie man das dann macht, also entweder macht es The Astro Way oder dann gibt es natürlich so andere Frameworks wie HTMX, die auch so einen Mittelweg gehen, also dass das Ganze dann leichtgewichtiger wird. Das wäre vielleicht noch so architekturell, was ich so den Hörerinnen und Hörern mitgeben wollen würde, versucht, JavaScript im Zaun zu halten und genau, versucht eben möglichst viel schon fertig vom Server zu schicken und on demand dann vielleicht irgendwie Dinge interaktiv zu gestalten.

SPEAKER_00 59:42

Das ist ja so ein Tipp sozusagen, wenn man auch auf ein neues Projekt schaut. Nicht zwangsweise, aber wir haben ja am Anfang auch eigentlich schon mal gesagt, wir könnten auch nochmal auf Legacy-Projekte schauen. Das haben wir gar nicht so sehr gemacht. Also was hast du denn ähnliche Tipps oder was würdest du jemandem sagen, der in React gefangen ist oder in einem View-Projekt und irgendwie gar nicht so viel Einfluss darauf hat, wie viel JavaScript da dann wirklich geschippt wird? Also man ist da ja oft begrenzt in den Dingen, wie zum Beispiel Dinge in Webworker auslagern. Wüsste ich jetzt gar nicht, ob das mit View so gut geht. Also vielleicht gibt es auch Libraries, aber hast du da Erfahrung mit und was würdest du da machen?

SPEAKER_03 1:00:21

Also ich glaube, da kannst du im Grunde nur versuchen, hinzumigrieren zu diesen Meta-Frameworks, zu einem der Meta-Frameworks, die dann aber auch, die erlauben, weniger Clients-Seite-Code zu schippen. Also dass du, aber das, das ist halt auch nicht eben schnell gemacht. Also das ist leider das Problem. Also wenn man sich, also ich weiß auch von einem Team von einer großen Zeitung, die eben auf, ich glaube, Angular gesetzt haben und die das im Client rendern und die Performance war halt echt nicht gut. Und die versuchen das natürlich dann, gerade bei Zeitungen, die halt total search-indexabhängig sind, also der Crawler muss da irgendwie ran, die haben dann versucht, das irgendwie nachträglich mit Server-Side-Rendering zu flankieren, für wenn der Google-Browser kommt, dann schickt bitte das. Aber das, also man versucht dann sozusagen das Ganze mit noch mehr komplexer Technik zu erschlagen. Und ich finde, irgendwann entgleitet einem das. Also das ist dann einfach, ja, da ist das Kind schon so ein bisschen im Brunnen gefallen. Also eine schnelle Lösung gibt es da nicht. Also das man kann nur dazulernen fürs nächste Mal und oder man muss einfach viel Zeit mitbringen und langsam aber sicher wieder in die andere Richtung das Ganze migrieren.

SPEAKER_01 1:01:44

Aber ich finde es interessant, dass du es jetzt von dem Legacy-Aspekt aufgezogen hast, Gareth, weil eigentlich wäre meine Frage wahrscheinlich in die ähnliche Richtung gegangen. Ich hätte nämlich von dir gerne nochmal so ein bisschen so ein Take zu den Web-Frameworks gehabt. So jetzt haben wir es gerade aus Legacy, wir haben es, ja dann war deine Antwort, ja lass mal wegmigrieren. Aber ich würde jetzt gerne mal mit dem, was du an Toolbelt irgendwie uns gegeben hast, auch nochmal gesagt hast, probiere JavaScript zu minimieren, probier vielleicht irgendwie dir ein Kilobyte-Budget an Java oder ein Lines of Code-Budget an JavaScript zu geben. Wie stehst du denn zu den großen Web-Frameworks, wenn ich jetzt sage, ich möchte eine Entscheidung treffen, ein neues Setup, so, ist es bei dir dann deswegen allein ein klares Nein so oder ist es ein, kommt darauf an, auf was kommt es an? Also wie denkst du über diese Frameworks nach und was wäre da deine Empfehlung, wenn man wirklich sagt, dieser Performance-Teil ist mir einfach sehr, sehr wichtig. So, ist es dann überhaupt eine Option, auf die Web-Frameworks zu gehen?

SPEAKER_03 1:02:34

Grundsätzlich schon, aber ich glaube, so ein Framework wie Next.js kommt ja überhaupt gar nicht. Also es gibt ja keinen Modus Operandi, aber ihr könnt mich korrigieren, wenn das mittlerweile anders ist, wo du ohne Client-Seite-JavaScript daherkommst. Also das ist da, also außer vielleicht bei Server-Rendered Components, wie heißen sie nochmal? Heißen noch Server-Rendered Components, oder? Da ist es auf jeden Fall so. Genau, also kann man sozusagen teile, aber da ist es andersrum. Das ist ja dann nicht dieses Interactive Island-Konzept, wo man eine statische Seite hat und dann gibt es quasi interaktive Inseln da drin, sondern bei denen ist es ja umgekehrt, alles ist interaktiv, bis man bis auf ein paar statische Inseln, die man drin hat. Also die Philosophie ist umgedreht. Das heißt also aus Web-Performance-Sicht, also die Next-Leute nutzen CDNs und machen ganz viele clevere Sachen. Also die versuchen sozusagen die Unzulänglichkeiten, die ihre Architektur hat, zu erschlagen, einfach mit Technik. Und das klappt auch, aber eigentlich arbeitet man sozusagen gegen Unzulänglichkeiten an und ich würde dann eher, ich glaube, bei Nuxt ist es zum Beispiel möglich, dass du schibst ohne JavaScript. Du kannst also eine Nuxt-Anwendung bauen in deiner Lieblingstemplating-Sprache, nämlich die von Vue, und kannst trotzdem eben eine leichtgewichtige Seite am Ende schippen. Also, weil man wählt ja eigentlich diese Frameworks meistens aus Developer Experience-Gründen, würde ich sagen. Also natürlich auch, so man kennt das und man nimmt natürlich immer den gleichen Hammer für alle Nägel. Verstehe ich auch. Genau, aber dass man da einfach guckt oder vielleicht sowas sich mal anguckt wie Quick. Das hatten wir ja vorhin schon mal erwähnt. Bei Quick ist es so, dass die eben auch nichts hydraten. Das ist ja das große Problem bei Next.js, wenn eben fertiges HTML geschickt wird und dann wird das Ganze nochmal sozusagen in einem Durchgang überrendert mit genau dem gleichen. Aber das ist ja diese Hydration. Und bei Quick ist es so, dass die so eine Art lazy Rehydration haben, dass im Zweifelfall vielleicht gar nichts hydrated wird, wenn man eine Seite nur liest, aber sobald man anfängt zu interagieren mit der Seite, dann wird diese Hydration nachträglich durchgeführt. Und das ist, da erschlägt man zwar auch ein Problem mit sehr viel schlauer Technologie, aber zumindest funktioniert es da. Ja.

SPEAKER_01 1:05:15

Also eigentlich, wenn man es runterdämpfen würde, auf achte auch bei der Auswahl deines Frameworks darauf, dass möglichst wenig Kleinzeit-JavaScript mitkommt. Ich meine, das ist ja auch was, was man sich an sich mal vielleicht einfach mitnehmen kann. Ich glaube auch, dass viele auch von uns zuhörern, ich würde auch sagen, wir am Ende diesen Part nicht sonderlich in einem bewussten Entscheidungsprozess irgendwie aufnehmen. Man muss natürlich auch dazu sagen, View ist bei uns der allgemeine Hammer, den wir halt oftmals nehmen, mit dem wir auch gute Erfahrungen haben und in die Kategorie kommt, wir erreichen eine ausreichende Performance damit so. Aber die, ich glaube schon, das einfach mal aktiver mitzunehmen, auch bei der Auswahl des Frameworks, da wirklich mal zu sehen, wo ist denn, wo ist denn das, wo viel kleinseitiges JavaScript mitkommt, ist, denke ich.

SPEAKER_00 1:05:54

Ich glaube, tendenziell könnte man wahrscheinlich noch ins Detail unterscheiden, was ist das denn für ein Use Case. Also. Also wie schon gesagt, bei einem Spiel sozusagen wäre das ja Quick überhaupt keine Option. Du willst ja was nichts da haben. Aber auch bei einer Web-App wäre Quick auch nicht sinnvoll. Ich glaube, Quick wurde ja explizit sogar für den die, wie nennt man das nochmal, die Shop-Seiten gebaut, weil da eben schon sehr viel Logik drinsteckt, aber man braucht selten alles davon oder meistens nur einen ganz kleinen Teil. Und ich glaube, da könnte man schon noch ins Detail gehen und sagen, okay, wie sieht es denn bei deinem Use Case aus? Aber grundsätzlich ist das wahrscheinlich ein guter Default zu sagen. Guck, also Davos gibt es teuer, überleg dir, ob du es brauchst. So, und bei unterschiedlichen Anwendungen ist es halt eine unterschiedliche Antwort. Und bei Spielen würde man wahrscheinlich eher noch sagen, ja komm, wir schippen das mal, damit es einfach dynamischer ist, in dem Fall, wo man es da braucht.

SPEAKER_01 1:06:50

Aber so habe ich ja auch das jetzt auch gar nicht wahrgenommen. Es ist ja nur eine weitere Achse, aber es ist ja immer, ich meine, bei Technologie ist es ja immer, dass es kommt darauf an und natürlich kommt es absolut auf deinen Use Case an. Und aber einfach diese, ich glaube halt schon, dass diese Achse mit wie viel JavaScript benötigen wir denn so, dass es weniger bewusst ist, als halt einfach nur, okay, so dass da, wie ich auch meinte, so Developer Experience erstmal oftmals einfach schlägt und man dann sich das vielleicht gar nicht so bewusst entscheidet. Und einfach sagt, okay, also ich glaube, dieser Trader wird nicht, wird nicht explizit, sondern ein bisschen implizit gemacht. Das fühlt sich gut an, das ist doch irgendwie Developer Experience sieht geil aus. Nehme ich so ungefähr.

SPEAKER_03 1:07:23

Ja, das hat man ja überall. Also man muss natürlich auch irgendwie ökonomisch vorgehen, das Wissen, das man hat, irgendwie weiter nutzen. Also da gibt es ja auch wieder viele andere Gründe. Also alles muss da in die Waagschale geworfen werden. Und es gibt Agenturen, die nehmen für alles WordPress, auch das ist nicht immer sinnvoll. Und genau, man hat halt einfach so seinen bevorzugten Text-Stack, aber es ist auf jeden Fall ja nicht verkehrt, da mal so sich ein paar Gedanken drum zu machen. Und dann kommt es halt wirklich darauf an, was für ein Produkt macht man und für welche Userbase macht man das. Also wenn ihr jetzt zum Beispiel Spiele für, vielleicht, wenn ihr irgendwann sagt, so, hey, der, keine Ahnung, der indische Markt, der ist so groß, wir wollen jetzt auch Spiele für den indischen Markt machen. Und die haben aber teilweise noch Feature Phones, so, dann müsst ihr einfach ganz anders rangehen. Dann könnt ihr auf keinen Fall, dann müsst ihr wirklich Bytes sparen. Aber wenn ihr für unsere, sagen wir mal, westliche Klientel baut, dann ist es natürlich schon entspannter generell. Ja.

SPEAKER_01 1:08:34

Alright. Dann, Chef, vielen, vielen Dank auf jeden Fall dafür schon mal. Ich denke mal, unsere Zuhörer mal einen guten Überblick dafür bekommen, haben jetzt so ein paar Sachen in ihrem Toolbild auf jeden Fall mehr. Und vielleicht bringt den einen oder anderen dazu bei einer Entscheidung für eine neue Technologie mal, dann den kleinenseitigen JavaScript-Code auch mit in Erwägung zu ziehen. Und ansonsten haben wir da, glaube ich, einigen Leuten ein bisschen was mit an die Hand gegeben. Das heißt, wir kommen jetzt zu einer unserer Lieblingskategorien, weil es nämlich die einzige im Deep Dive ist, die Picks of the Day. Die Picks of the Day. Wir sind zu dritt. Das heißt, es gibt mindestens mal drei Pick of the Days, wenn der Garal es geschafft hat, in der Zeit sich einen zu überlegen. Wir geben ihm dafür noch ein bisschen Zeit, weil ich weiß, dass der Chep auf jeden Fall was vorbereitet hat. Darfst du als Gast gerne anfangen? Was ist dein Pick of the Day?

SPEAKER_03 1:09:39

Also, es ist eigentlich ein Pick of the Day, der aus Sub-Pick of the Days besteht. Und zwar habe ich mich beschäftigt damit, wie ich hier bei mir mein eigenes LLM laufen lassen kann. Hab mir einen gebrauchten Mac Studio mit M1 Max geholt und hab da auch eine Weile für da unumgedoktert, immer mal wieder. Und jetzt habe ich das am Laufen. Das ist ziemlich cool. Ich habe LLM Studio drauf. Das ist sozusagen der Server für meine lokale LLMs. Da habe ich jetzt aktuell Gemma 4 drauf. Und dann habe ich das 26 Billionen Mixture of Expert Modell. Genau. Das ist relativ schnell, ziemlich geil. Aktuell auf 5-Bit quantisiert, falls du da in dem Game auch drin steckst.

SPEAKER_00 1:10:31

5-Bit war das das Maximum an deinem RAM wahrscheinlich ging, oder?

SPEAKER_03 1:10:36

Ja, weil ich da Gutes drüber gelesen hatte. 5-Bit ist halt dann nochmal irgendwie so ein bisschen cleverer als 4. Aber ich wollte jetzt nochmal ein 4-Bit quantisiertes mit diesem, mit, gibt es ja so eine Nvidia-Quantisierung, diese FP4, die wollte ich ausprobieren mit MLX. Mal gucken, was das bringt. Das ist, ob es noch ein bisschen schneller ist. Und nicht Döver. Genau, und dann habe ich noch Conf-UI da drauf. Da drin habe ich meine Image Generation Modelle. Das heißt, die beiden sind auch, also die. Das eine kann dem anderen sozusagen sagen, hey, ich brauche jetzt mal ein Bild. Und als Web-Oberfläche für die Nutzung, also von das Ding steht in der Rumpel-Kammer, da kann ich auch lieber hingehen, wenn ich eine Frage habe. Hab ich, also die, habe das halt natürlich auch Open AI-kompatible Schnittstellen, wo ich meine IDI dranhänge, aber wenn ich jetzt ein Chat-Interface haben möchte, dafür benutze ich dann Open Web UI, das ihr wahrscheinlich auch kennt. Genau, und das finde ich ziemlich cool und macht Spaß.

SPEAKER_01 1:11:39

Cool. Und wie ist so in der, also wie viel Prozent deiner AI-Use Cases machst du über diese Modell und wie viel gehst du an die cloud-basierten Modelle?

SPEAKER_03 1:11:49

Genau, also ich, was ich nicht mache, ist dieses Agentic Coding, weil ich aktuell zumindest noch der Meinung bin, dass ich gerne in der Lage sein will, das alles zu kontrollieren, was da rauskommt und ich nicht, wie unter so einer Lawine begraben werden möchte. Das heißt also, ich nutze das sozusagen eher als Sparingspartner für Themen. Genau, und ich migriere so langsam rüber. Also ich habe natürlich so bestimmte Kontexte, die in meinem gekauft bezahlten, in meiner bezahlten KI noch drin sind. Aber genau, also zunehmend migriere ich, also wenn ich neue Sachen habe, mache ich das dann immer da drüben und finde das eigentlich ganz gut. Ich habe jetzt einmal mir was übersetzen lassen, da hatte ich festgestellt, ah nee, da ist ChatGPT besser. Also so, das war jetzt nicht schlecht, aber es war auch irgendwie so ein bisschen hölzern und rumpelig und da, genau. Aber damit spiele ich rum und es ist schön.

SPEAKER_00 1:12:52

Hast du, was wäre denn ein Weg, wenn du sagst, du willst jetzt noch ein anderes Modell austesten und die Qualität soll gleich sein? Hast du da Evaluations oder machst du einen Gefühlstest? Also ein Promdo und Komponenten?

SPEAKER_03 1:13:04

Das wäre eher ein Gefühlstest, ja genau. Also Evaluations machen ja ganz viele andere Leute. Also da kann man sich ja schlau lesen. Da ist ja auch jetzt auch Gven 3.6 rausgekommen, das war auch ziemlich geiles. Genau, also das hört ja nie auf und da kann man sich eigentlich immer ganz gut irgendwo schon mal so einlesen. Und ansonsten finde ich, am besten ist es in der Praxis auszutesten. Also wie jetzt zum, also beim Coding war es okay, aber jetzt bei der Übersetzung dachte ich, nee, also das irgendwie ist jetzt irgendwie nicht falsch, aber es kommt auch nicht so rüber, wie wenn das Native übersetzt hätte.

SPEAKER_01 1:13:43

Interessant, dann schließe ich mich vielleicht an, weil es dazu passt und dir nochmal mehr Zeit gibt. Ich hab was. Okay, perfekt, dann sind wir an dem. Und zwar, es könnte jetzt ein Pick of the Day sein, der die Kategorie, weil man nämlich auch im Vorgespräch schon geschärzt, früher hat er Dennis so Sachen gemacht wie Fahrradfahren als Pick of the Day. Mein Pick of the Day könnte jetzt in diese Kategorie fallen, bitte?

SPEAKER_00 1:14:02

Gartenbüro bauen.

SPEAKER_01 1:14:02

Ein Gartenbüro bauen. Nur weil ich das mache, ist das kein Pick of the Day und dann pete ich nicht jedem. Nee, es geht in Richtung LLM und zwar so ein bisschen dieser Paradigmenshift, so wie man mit einem LLM interagiert. Ich hatte schon in einem der vergangenen mal Whisper Flow als Tool genannt, um grundsätzlich Sprache als Input für jedwede Dinge zu haben, aber hauptsächlich, um mit LLMs zu interagieren. Und ich merke gerade bei uns in der Firma, dass schon, wir es, glaube ich, unterschiedlich nutzen, wie viel wir Sprachinput nutzen. Und mein Pick of the Day wäre erstmal, schreibt nichts mehr in euer LLM, sondern sprecht ab jetzt einfach alles rein und schreibt auf gar keinen Fall mehr.

SPEAKER_00 1:14:38

Aber machst du das auch im Office im Großhaben?

SPEAKER_01 1:14:40

Und genau das ist der Punkt. Und ich werde damit jetzt anfangen. Ich habe mich bisher in irgendwie dann vielleicht in einem Einzelbüro eingeschlossen und ich werde jetzt anfangen, damit das auch auf dem Floor zu machen mit meinem LLM zu reden.

SPEAKER_00 1:14:53

Was ich super spannend finde, Whisper Flow, ne, sagt ja schon Whisper. Und was die tatsächlich in ihrem Büro haben, es gibt ein geiles Video von ihrem Arbeitsalltag. Die haben alle so Mikros mit so einem langen, so einem Kabel sozusagen und dann haben die das so vermund und flüstern da halt rein. Und das soll unfassbar gut funktionieren. Das ist ihre Lösung im Großraumbüro, das zum Beispiel. Scheiße für die Stimme ist meine Frau aus Logopäden. Flüstern ist nicht geil für die Stimme.

SPEAKER_01 1:15:18

Okay, interessant. Aber ich meine, der andere Punkt wäre, alle setzen Noise Canceling auf. Ja, okay, klar, also ich finde wirklich, ich meine, aber das ist ja der eine, es gibt ja mehrere. Du bist jetzt schon in dem Extrem, der nur fragt, machst du es im Büro ja oder nein? Aber es gibt ja schon viele, die vorher schon sagen, oh, echt sprechen, nehmen, ich muss mir überlegen, ich muss das strukturieren, ich kann da jetzt nicht einfach nur reinbrabbeln. Die Antwort ist doch, du kannst und mach das mehr. Das ist wirklich, gibt nochmal einen extremen Produktivitätsboost. Und auch selbst dieser Part mit, man gibt einfach an das Kontext. Also klar, ich kann jetzt sagen, ich muss das strukturiert geben und dann bin ich da mehr on point, aber eigentlich ist der Stand, wo wir jetzt eher sind, so, du musst nicht so on point sein. Und wenn du sprichst, dann erzählst du mehr darüber und wichtige Details, die du vielleicht schreibend einfach auslassen würdest. So und es funktioniert wirklich extrem gut auch so. Also zum Beispiel, ich habe mittlerweile so ein Use Case, dass ich eigentlich jegliche Dokumentation für unser Produkt komplett nur noch LLM-basiert überhaupt schreibe, das Ganze nur mit Sprachinput mache und selbst so Dinge sage wie wir haben irgendwie Meetings und haben da nochmal über das Feature drüber diskutiert, dann nutze ich die Summaries, die mittlerweile auch die, auch die Google-Summaries von so einem Google Meets mittlerweile auf einem viel besseren Niveau, dass ich das wiederum als Input nehme und sage, okay, check jetzt nochmal, was macht meine aktuelle Doku, was haben wir für andere Dinge besprochen, guckt nochmal, ob wir an der Doku was anpassen müssen. Und dieses Reinsprechen hat für mich meinen Arbeitsflow auf jeden Fall nochmal stark verändert und würde auf jeden Fall deswegen als mein Pick of the Day nennen, so redet mit eurem Computer. Hört auf zu schreiben. Guter Input. Die Frage, ist das jetzt wie Fahrradfahren?

SPEAKER_00 1:16:46

Es ist ein Metapick, würde ich sagen. Es ist jetzt kein Link. Ich kann einen Link zu Whisperflow nochmal das sagen. Whisperflow hast du ja schon. Okay, aber es hat dein Thema passt auch dazu, oder? Mein Thema passt eigentlich auch dazu, aber irgendwie, es ist auch ein Thema und ich finde es schade. Irgendwie denke ich mir gerade so, ich habe nochmal hart versucht nachzudenken, ob ich nicht einen Performance-Pick habe. Außer dem Performance-Sub bei Chrome. Einfach einen Affiliate-Link zu meinem neuen iPhone auf der Webseite. Noch einmal, aber mir fällt irgendwie nichts ein. Also nichts, was richtig kommt. Wir haben ja viele aber nicht AI.

SPEAKER_01 1:17:24

Wir haben jetzt eine Stunde 15 nicht über AI geredet. So, dann komm. Wir sind unter uns. Also doch AI, oder was? Nee, mach doch deinen AI-Pick. Also besser, als dass du jetzt noch irgendwas hier.

SPEAKER_00 1:17:34

Also ich sag mal, ein Pick wäre sonst thrallt gewesen. Einfach auch um mal Shoutouts an Grischer rauszuhauen. Das ist ein Mitarbeiter bei uns schöpf für dich, der das wahrscheinlich nicht weiß, der auch, also diese Library mitentwickelt hat. Und das ist die 3JS-Library in Svelte. Und Svelte ist ja, sag ich mal, vielleicht siehst du das ähnlich von den Frameworks, die es gibt, am ehesten das, was noch Performance-nativ ist, sozusagen. Also sie achten da zumindest sehr viel drauf. Und Thrailt ist sozusagen 3D für Svelte. Und da das ja immer mehr Thema ist so und immer mehr Animationen auch momentan in 3D sind, glaube ich, ist das eine ganz coole Schnittstelle, wenn man was im Web baut und es aber vielleicht auch sehr animationslastig ist, dann ist Thraelt bestimmt eine gute Anlaufstelle, genau. Und du guckst gerade schon.

SPEAKER_01 1:18:30

Genau, da können wir direkt packen. Die schon uns mit Deep Dive Nummer 163 war auch über Thraalt mit Grischer. Von daher. Ja, komm, ich nehme den jetzt einfach.

SPEAKER_00 1:18:36

Das passt mir ein bisschen mehr.

SPEAKER_03 1:18:39

Svelte kommt ja auch aus der Datenvisualisierung. Also es wurde ja für die New York Times mal entwickelt, um dann sozusagen interaktive Grafiken zu zeigen. Und da ist es ja wirklich richtig stark drin.

SPEAKER_00 1:18:51

Ja, richtig. Dann hebe ich mir den einfach den anderen für einfach nichts mehr auf. Da musst du auch nichts mehr suchen.

SPEAKER_01 1:18:57

Ja, perfekt. Dann, wenn du dich bis dahin daran erinnern kannst, schreibst du lieber jetzt auf. Ansonsten gilt es noch zu sagen, schreib vielen, vielen Dank, dass du die Zeit genommen hast. Das hat sehr viel Spaß gemacht. Gerne. Schön, dass du da warst. Hat sehr viel Spaß gemacht, ja. Fand ich auch. Danke für die Einladung. Sehr gerne. Und wir euch immer vielen Dank fürs Zuhören. Wie immer gerne Feedback an podcast.programmier.bar oder auch gerne über unsere Website und Discord? Discord natürlich auch und alle möglichen anderen Kanäle, die ihr auf unserer Website findet.

SPEAKER_03 1:19:26

Da muss ich mal reinspringen.

SPEAKER_01 1:19:27

E-Mail immer sehr, sehr gerne. Ich freue mich immer sehr, hast du letztens gesehen, an der letzten Feedback-E-Mail gab es einen, was ihr hört, auch mit Hashtag Garelt MockRockt. Ja, das ist ein Highlight. Ist das, was du ins Spiel gebracht hast?

SPEAKER_00 1:19:38

Ich weiß es nicht. Hab ich dann befragt. Also hat er sich das selbst ausgedacht? Also Dave und ich haben uns auch gefragt, ob wir das in der News-Folge gesagt haben, aber ich glaube nicht.

SPEAKER_01 1:19:47

Also vielleicht können wir das ab jetzt irgendwie mal so ein bisschen einführen. Ich muss sagen, Garet Mock rockt als Hashtag, finde ich, sehr, sehr gut. Und da haben einen Shoutout an Dennis Lugowski, der hat die E-Mail geschrieben. Vielen Dank dafür. You made my day.

SPEAKER_00 1:20:02

Vielleicht sogar mein Week, vielleicht sogar mehr. Also mal gucken, was noch kommt, aber ich habe mich sehr gefreut.

SPEAKER_01 1:20:07

Hab jetzt gerne jede E-Mail mit Hashtag Garet Mock rockt aufhört und auch jeden Post, den ihr irgendwo anders in Social Media macht.

SPEAKER_00 1:20:12

Ja, oder ich finde, wir können das schon auf alle unsere Podcasts übertragen, oder? Vielleicht machen wir auch ein T-Shirt. Fabi Fink rockt. Das ist ein Zungenbrecher.

SPEAKER_01 1:20:21

Ja, das ist ja auch insofern fein, dass ich ja auch knapp an dem Namen Fabi Fink vorbeigeschlittert habe.

SPEAKER_00 1:20:27

Ja, ich glaube, das ist jetzt, steckt in mir drin.

SPEAKER_03 1:20:31

Ein gefährlicher Zungenbrecher, ja.

SPEAKER_01 1:20:33

Ja, aber man muss das, du weißt nicht, aber mein Opa hieß früher wirklich, als sie nach Deutschland kamen, haben sie sich umbenannt in Fink, weil sie gemerkt haben, ah ja, Fit mit auch noch CK ist vielleicht nicht der beste Name in Deutschland.

SPEAKER_03 1:20:43

Ja, ja, okay, ja. Das ist ein kleiner Funfact.

SPEAKER_00 1:20:46

Für die, die noch zum Ende genommen.

SPEAKER_01 1:20:48

Also sie haben schon dreimal Tschüss gesagt, also nochmal Tschüss wie immer Feedback, ne? Und so weiter. Hashtag Gareth Mogrockt. Danke euch. Shep, vielen Dank. Macht's gut. Ciao.