Deep Dive 206 –

Web Performance mit Christian Schaefer

28.04.2026

// Podcast
// Deep Dive 206

Shownotes

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:

Download

/transkript/programmierbar/deep-dive-206-web-performance-mit-christian-schaefer

Fabi: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Mein Name ist Fabian Fink und mit mir im Studio ist der
Garrelt: Garel Smog.
Fabi: Hi, Garel. Wir wollen heute über Webperformance sprechen Oh Gott. Und dafür haben wir uns einen ganz besonderen Gast eingeladen, den lieben Christian Schäfer, auch genannt, der Shapp oder einfach nur Shapp. Wir freuen uns sehr, dass Du da bist. Hi.
Christian: Ja, hallo ihr Zweien. Danke für die Einladung. Schön, dass ich da sein darf.
Fabi: Wir freuen uns ebenfalls. Du schreibst ja auf deiner eigenen Webseite so, dass Du generell son bisschen nicht so sehr an die oder nicht so viel mit den Standard js Frameworks nutzt, sondern sehr bärbones irgendwie unterwegs bist, eher so auf traditionelle Server setzt und irgendwie Bleating Edge CSS bist und auch sagst, so, Du bist auf jeden Fall, was Loading und Run Times Performance 1 Seite angeht, auf jeden Fall son bisschen dein Steckenpferd ist. Und werd ich jetzt nicht, kann gut sein, dass man dich hier nicht zum ersten Mal deine Stimme hört, sondern Du bist ja auch allseits bekannt über den Working Podcast, einen Co Host vom Working drauf Podcast, den wir auch schon mehrmals hier referenziert haben in unserem Podcast. Ansonsten auch bereit unterwegs, bist bei der Frontiers Konferenz, organisierst aber auch das Webworker Meet-up NRW und auch bei anderen Konferenzen mit unterwegs. Heißt, Du treibst dich viel rum und das Thema Webperformance ist auf jeden Fall, wenn ich das jetzt hier so richtig wiedergebe, son bisschen auch mit deinem Steckenpferd. Deswegen freuen wir uns natürlich heute mit dir, da son bisschen drüber zu reden und vielleicht, ich mein, Webperformance ist erst mal 'n superweiter Begriff so, ne. Und also ich glaube, ich vielleicht für unsere Zuhörer wär's super, wenn Du mal probieren könntest für dich so den Begriff oder was Du unter Webperformance verstehst. Wenn Du wenn jetzt jemand sagt, hier okay, wir müssen die Webperformance optimieren, an welche Bereiche denkst Du da?
Christian: Genau, also Webperformance ist eigentlich, also ich hab mich neulich mal gefragt, warum ich überhaupt son Webperformance Nerd bin und gleichzeitig aber auch zum Beispiel 'n CSS Nerd. Also irgendwie passt das ja überhaupt gar nicht zusammen. Das eine, da geht's ja ums Styling, das andere ist ja schon sehr technisch. Beides zahlt aber auf die User Experience ein. So, da das ist irgendwie der gemeinsame Nenner. Also es also 'n Interface muss gut aussehen, charmant sein, gut funktionieren und eben auch schnell sein. Genau, und dafür sind, da sind so verschiedene Bestandteile, die die da in die Web Performance reinlaufen, wo auch immer dann die Ursache für eine gute oder eine schlechte Webperformance liegt, ist ist gar nicht, ist erst mal 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 Performance, weil ich kann natürlich auch eine Webseite haben, die sehr schnell lädt, aber die die danach wahnsinnig ressourcenintensiv ist und und ruckelt. Ihr kennt das eben ihr kennt das ausm Spielbereich.
Garrelt: Ja. Da
Christian: werdet ihr wahrscheinlich viel mit der Performance euch beschäftigen, vielleicht weniger mit der Ladezeit. Also die nimmt man dann vielleicht für son Spiel ja auch in Kauf. Genau, und dann gibt's noch son son dritten Aspekt, der ist vielleicht einfach die also Layoutstabilität. Das heißt also, wenn ich wenn ich was habe und ich beweg mich über diese Oberfläche, über dieses UI drüber, egal ob's jetzt 'n Spiel ist oder eine Webseite, bei Spielen nervt's ja total, wenn man jetzt irgendwie son 3D Spiel hat, man geht durch eine Landschaft und Bäume und so poppen halt superspät erst ins Bild. Also sieht irgendwie kacke aus und nervt. Und bei Webseiten gibt's das eben auch. Also das ist dann zum Beispiel, dass 'n Ladendes Bild spät kommt, der Browser 'n Relayout durchführt oder Werbung reinkommt und Layout shifts passieren. Das wär so dieser dritte Aspekt, der der vielleicht son bisschen immer untern Tisch fällt, aber der irgendwie auch wichtig ist und auch sozusagen unter diesen Webperformanceschirm gepackt werden kann.
Fabi: 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 unsere Zuhörer noch 'n bisschen besser kennenlernen. Woher woher kommt denn dieses dieser Performance Nerdum so? Also wie wie wie kommt es, dass Du dich irgendwie gerne damit beschäftigst? Gab's da irgend einen gab's da 'n Auslöser oder eine schlechte Seite, die nicht gut geladen hat?
Christian: Ja, nee, nee, die gab's nicht. Aber ich glaube, ich bin einfach irgendwann über Steve Sauders Werke gestolpert. Das ist ja so der Grand Signue 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, wo wo die damals schon im Grunde ja, Interface Bausteine gezeigt haben, wie sie die entwickelt haben und was da warum die so am besten funktionieren. Und die hatten eben auch dieses Yahoo Exceptional Performance Team, wo Steve Sauders eben der der Leiter war und wo noch 'n paar andere Leute dabei waren. Und genau, das war ja noch die Zeit der der Blogs, da gab's ja, Podcasts gab's, glaub 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 geblockt und auch 'n Buch geschrieben oder sogar 2 Performance Websites, glaub 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 hab mich dann irgendwie immer weiter in Richtung Frontend bewegt. Und dessen Kernaussage war eigentlich, dass 80 Prozent der der Webperformance Botlenicks im Frontend entstehen und nur 20 im Backend. Das heißt also, wenn ich meine Datenbank tune und 'n 'n super eingestelltes PHP hab mit Caching und Zip und Zapp. Aber mein Frontend ist eben einfach nicht sauber aufgebaut, dann ist man 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 wenn eine Seite langsam ist.
Garrelt: Würdest Du denn sagen, das hält sich bis heute so dieses 80 20 Verhältnis? Weil ich mein, es wird ja versucht, viel mehr ins Backend zu shiften, ne. Service Adrendering mal als ein Beispiel. Würdest Du sagen, das hat das auch 'n bisschen geändert? Oder ist es eigentlich dasselbe Thema, weil selbst Server Side Rendering eigentlich Frontend Arbeit ist in dem Sinne?
Christian: Also ich glaube, daran hat sich im Grunde nichts geändert. Also es ist natürlich hat sich wieder entspannt, aber die Zeit, also als dieses Buch rauskam, da hat man auch gerendert. Also wir haben ja immer diese diese, also die nennt man ja Schweinezyklen, ne. Also sagen wir mal so, alle 10 Jahre landet man wieder da, wo man vor 10 Jahren war. Immer auf der Suche nach dem Also auf der anderen Seite ist das Gras ja immer grüner, ne. Und so merkt man ja immer, was man mit in seinen aktuellen Situationen für Probleme hat und versucht, sich daraus wegzuentwickeln hin zu 'nem besseren Konzept. Und das passiert eben über 10 Jahre so lange, bis man im Grunde wieder da ankommt. Also Alter Wein in neuen Schläuchen und natürlich haben das hat das dann andere Begrifflichkeiten, aber von den Grundkonzepten hat's 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 wie das gelaufen ist, werden wir uns, jetzt bewegen wir uns erst mal wieder zum Server zurück und dann werden wir uns wieder irgendwie zum Client bewegen. So ist es wahrscheinlich. So so muss das sein.
Garrelt: Aha. Okay.
Fabi: Und vielleicht kannst Du uns ja mal son bisschen, vielleicht können wir mal ausgehen davon so, wenn Du jetzt, Du bist ja selbstständiger Frontend Developer und vielleicht mal 'n bisschen darüber erzählen, was so dein Standardwebstag ist, daraus vielleicht mal son bisschen ausgehen zu gehen, wo Du wo Du vielleicht aktuell irgendwie Botle leck siehst, wenn Du's so, wenn Du's von der von der Pike auf sozusagen designst dein Frontend so. An welchem Punkt, vielleicht kann man's, also was ist dein Stack und an welchem Punkt mach ich mir eigentlich Gedanken die Performance so? Also ist das was, wofür ich die richtige, also von von vornherein die richtige Entscheidung treffen muss oder ist das was, ich mein, ich könnt dir auch genauso gut sagen, wo sein, ich sind einige dadrauf, die sagen, ey Leute, mittlerweile mit denen Devices, auch grade 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, na ja, komm, lass es doch mal. Also so, wie wie wie denkst Du darüber nach, wenn Du über eine neue Applikation nachdenkst, so? Also dann können wir später können wir vielleicht noch mal drauf eingehen, was mach ich denn eigentlich bei 'ner großen Bestandsapplikation?
Christian: Genau. Also es hängt natürlich von dem Setting ab, in dem ich mich grade bewege, ne. Also wenn ich Agenturen supporte, da würde ich immer 'n ganz anderen Webstack wählen, als wenn ich Gruppen, also wenn ich wenn ich Produktentwicklung unterstütze mit meiner Arbeit. Mhm. Jetzt in den letzten Jahren habe ich viel Produktentwicklung gemacht, da und darum, das erlaubt mir das auch überhaupt, 'n 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 das war einfach gesetzt. Und dann muss man eben überlegen, also gehe ich den Weg, dass ich 'n Headless Backend habe und dann mit 'nem Frontend aufsetze, das vielleicht so SPSPA artig ist. Also wo ich einfach mehr Logik ins ins noch mehr Logik ins Frontend verschiebe über die Logik, die ich über die ich für meinen UI sowieso brauche. Oder wähle ich eben 'n Templateing System, was kompatibel ist mit diesem Backend und darin geändert werden kann. Und bei den letzten Kunden, wo ich zur 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 musst ich auch nicht bei 0 anfangen bei dem nächsten Kunden. Zumindest gedanklich nicht. Und da ist die Twig, weiß nicht, ob ihr die kennt.
Fabi: Nicht genutzt, aber vom Namen her.
Christian: Genauso, die kommt so aus dem Symphony Umfeld. Symphony ist ja so 1 der großen PHP Frameworks. Und dann gibt's ja noch. Und genau, auf die aus der Kernhause kommt eben die. Und das Schöne bei der ist, also die gibt's auch in 'ner JavaScript Implementation. Mhm. Und das macht's uns möglich, die Komponenten, die mit Twig Templates arbeiten, eben wahlweise in PHP zu rendern oder im Frontend in 'ner in SPA oder in Interactive Islands, also wie Astro das macht. Mhm. Oder eben auch in 'nem Static Side Generator wie 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 versuch immer so viel wie's geht über CSS abzufackeln. Heute 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 als JavaScript laufen zu lassen. Einfach, weil das halt nach tiefem Browser implementiert, entweder in c plus plus oder während JavaScript eben just in time, interpretiertes Scripting ist.
Fabi: Und hast Du da vielleicht für zum Verständnis son paar Beispiel, wo wo Du in letzter Zeit vielleicht dann mehr hin Oder was sind Dinge, wo Du zuerst essen würdest, wo vielleicht andere es es nicht nutzen oder so, die, die sich jetzt vielleicht nicht so stark mit diesem Performanceteilen beschäftigen? Hast Du da son paar?
Christian: Also der son prominentes Beispiel ist Slider. Also früher hat man ja Flex Slider und welche war der andere? Es gab 2, die so Flick Slider, glaub ich, irgendwie so. Also es gibt auf jeden Fall 2 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 die geshept wurden. Und das kann man alles mit mit CSS mittlerweile machen. Also es gibt ja dieses Scroll Snaping, wo man eben dieses Einschnappen haben kann. Dann haben wir Smooth Scrolling. Dann ganz neu ist es ja die diese CSS Carussell 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 Navigation, die's dann oftmals drunter gibt. Also das einzige Feld, was da noch nicht beackert ist, ist, also dass man sozusagen, wenn man am Ende des Scrollers ankommt,
Fabi: dass
Christian: es dann einfach nahtlos wieder mit den Erste Elementen weitergeht. Also das ist zwar aktuell in der, also es wird aktuell so, da wird nach Ideen gesucht, aber es gibt's noch nicht.
Fabi: Das heißt, dann muss ich doch wieder die ganze rein reinholen, damit ich damit ich wieder am Anfang dann anschauen kann.
Christian: Na ja, ich ergänz das dann meistens mit eigenem JavaScript, das dann eben diese diese Dinge übernimmt. Also aber ich flankier das dann eben einfach mit deutlich weniger JavaScript, als als das eben vormals nötig war. Und Du hast halt auch Vorteile bei Responsivness. Also das war ja auch immer so, wenn wenn Du das Browserfenster kleiner gemacht hast früher, dann musstest Du quasi diesen Slider einmal sozusagen und dann musstest Du den wieder neu initialisieren basierend auf der Auflösung, die Du grade hast. Das hast Du halt auch alles nicht.
Garrelt: Wie ist 'n 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 Produktenummer? 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?
Christian: Mhm. Kann ich nachvollziehen. Ich bin, also auch wenn ich mit Beating Edge unterwegs bin, bin ich eigentlich immer sehr konservativ. Tatsächlich hab ich jetzt auch grade den Fall gehabt, dass 'n Kunde mit 'nem Chrome 56 angekommen ist.
Fabi: Mhm.
Christian: Also weil es auch Kunden gibt, die Smart TVs nutzen. Mhm. Und die haben halt einfach relativ veraltete Browser. Und dann sind natürlich so Sachen wie Grid, die es erst ab Chrome 57 gibt.
Garrelt: Ist wirklich
Christian: so knapp vorbei, sehr ärgerlich.
Garrelt: Sehr ehrlich. Das
Fabi: ist 'n sehr modernes Sponsor, muss man sagen, also Grid
Christian: ist natürlich ein wenig weniger. Ja, gibt's ja eigentlich seit 2017. Aber ja, der Fernseher Also auch wenn Du heute 'n Fernseher kaufst, bekommst Du ja auch nicht den aktuellen Chrom oder Chromium, sondern vielleicht irgendwie einen der 40 Versionen hinterherhinkt.
Garrelt: Mhm.
Christian: Genau, also ich bin bin eigentlich sehr konservativ und es kommt immer son 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's nicht parsen kann, dann ist hat man gar nix. 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 ist macht dann irgendwie das Rendering wieder langsam. Ist dann wieder das Problem mit der Performance. So was würd ich nicht benutzen. Aber bei den bei dem Scrollsnapping und Co, was ich da dann im Grunde verlieren würde, wenn 'n alter Browser kommt, der das noch nicht kennt, der müsste aber dann auch schon ganz schön alt sein, dann dann hätte ich eben vielleicht kein Smoothscrolling oder ich hätte kein Snaping. Der Scroller würde einfach, wenn ich ihn irgendwie scrolle, nirgendwo einschnappen, sondern einfach doof in der Mitte zwischen 2 Slides stehenbleiben und dann würde sich denken so, ja, hab ich schon mal schöner gesehen. Okay. Aber genau, es würde es würde im Grunde trotzdem gehen, genau.
Garrelt: Mein Gedanke ist dann auch immer so, bei Leuten, die son alten Browser haben, da wird wahrscheinlich sowieso so vieles komisch aussehen, dass die's jetzt auch nicht sehr verwundert sind, wenn auch so was mal passiert. Ich mein, am Ende ist, glaub ich, immer die Abwägung, ist es broken oder ist es auch, also ist es noch halbwegs nutzbar und man weiß ungefähr, was es sein soll.
Christian: Genau.
Garrelt: Das ist auch, ja. Ja.
Christian: Und Browser Stack ist ja natürlich dein Freund dann,
Garrelt: Ja. So.
Christian: Das kennt ihr ja wahrscheinlich auch.
Garrelt: Ja, aber erzähl gerne mal ganz kurz drüber, weil das wahrscheinlich auch 'n Tool, was Du dann sehr oft nutzt, eben genau das und vielleicht doch grade Performance irgendwie an dir anzuschauen.
Christian: Ja, Performance nicht so, weil also Browser Stack ist 'n Anbieter oder eine Plattform, eine Cloud Plattform oder 'n Software-a-Service-Plattform besser gesagt, die 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 Zahlendesmitglied ist, dann kann man eben hingehen und sagen, ich möchte jetzt gerne ein Windows 7 haben mit Chrome 56 zum Beispiel. Mhm. 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 wie Geforce Now nur für Browser. Mhm. Und man kann eben auch, also man kann iOS testen, man kann ältere iOS Versionen testen, weil ich mein, 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 ihr ja nicht updaten. Weil wenn man einmal geupdatet hat, da gibt's ja keinen Weg zurück. Also ihr könnt nicht die euch die alte Version noch mal drauf spielen. Genau, ich glaube, ihr leistet euch das, aber für mich wär's halt 'n bisschen Overkill. Genau, einfach damit man Bug Reports von Kunden auch nachvollziehen kann letztlich.
Garrelt: Ah, das ist dein Haupt Use Case davon. Also Du machst es weniger in der Entwicklung.
Christian: Die Tests auch.
Garrelt: Okay.
Christian: Ja, ich benutz es weniger in der Entwicklung. Also ich hab 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 Class doof findet
Fabi: Mhm. Und auch
Christian: die ganzen anderen
Fabi: Wie kann man das denn doof finden?
Christian: Ja, weiß ich auch nicht. Genau, es gibt ja noch son paar andere, die da die da passiert sind. Also wenn man das sozusagen aussitzen will bis zur Siebenzwanzigerversion, die ja wahrscheinlich demnächst vorgestellt wird, dann kann man zum Beispiel auch die Sechsundzwanzigerversion einfach auf Browser Stack testen. Ja. Das hab ich gemacht. Also als die rauskam, da wusst ich, da war mir ganz klar, dass dass da ganz viele Dinge ganz merkwürdig sind. Vor allem, wenn man irgendwelche so Sachen im als hat, weiß nicht, ob ihr so was auch schon hattet, dann es gibt ja diese schwebende Adressleistung. Der Browser, der denkt sich dann irgend eine Farbe aus, die da drunter sein müsste. Und wenn man son Sticky Ding unten floaten hat, dann nimmt der manchmal die Farbe davon. Genau und das, so ich ich hatte es vermutet und so war's dann auch. Und das konnt ich halt dann dank Browser Stack testen.
Fabi: Mhm. Mhm. Na, sieh mal, da ist ja, wir finden ja selten im im wirklich Browser statt. Wir finden's ja in einem statt, aber meistens in im Rahmen 1 nativen App. Von daher müssen wir uns nicht mit der Browserleiste rumschlagen, außer 'n internen Prototypen, oder? Ja, aber ich fand trotzdem diesen Punkt grade interessant, weil ich hab ja meinte so, wir leisten uns bestimmt ja iOS Devys auf alten Versionen zu haben. Ja, theoretisch leisten wir uns das, theoretisch haben wir irgendwelche rumliegen. Aber ich muss sagen, in der Realität passiert's schon selten, dass wir auf alten iOS Versionen testen, ne.
Garrelt: Also. 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?
Fabi: Genau und halt auch, selbst auch bei Bug Reports, ne. Das ist halt nicht immer die Frage, was für Produkte man entwickelt so. Also es ist am Ende so, es muss ja eine kritische Masse erreichen theoretisch, dass wir uns mit Bug Reports dann wirklich beschäftigen, wenn Du halt Free to play Titel hast, so werden wir uns nicht mit jedem einzelnen Bug beschäftigen. Wenn natürlich jemand was für sein Produkt bezahlt gekauft hat, dann ist es 'n bisschen ein dritter Qualitätsanspruch, den man dann an oder bei jeder User an dieses Produkt geben kann. So, das ist 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 großzügig abrunden, was die Anzahl an Reports angeht und wann wir uns damit beschäftigen, ne. Also das
Garrelt: Obwohl grade Du ja vor Kurzem auch 'n altes oder es war an Android, glaub ich, extra gekauft
Fabi: habt, Genau, Performance testen. Performance testen ist schon so. Also auf grade, wir haben natürlich immer, aber ist halt nichts zu sagen, wir haben jegliche iOS Version da, dass wir in dem Fall irgendwas machen können, sondern eher grundsätzlich zu sagen, lass uns lowend Devices da haben. Und wir testen halt parallel einfach immer auf lowend Device zum einfachen Gefühl für die Performance, auf lowend Device zu haben. Da haben wir auch letztens zum Beispiel gehabt, dass wir einfach geschaut haben, okay, wie sieht's mit irgendwie Crash- oder Raten raus? Wir haben uns mal 'n paar Devices, wo die Rate im Verhältnis am höchsten ist, haben uns die mal bestellt und einfach lokal daliegen und gesagt, okay, dann wird es jetzt einfach mein testing Device. Und sag ich einfach, wenn ich da drauf nichts merke, dann wird's auf den anderen tendenziell vielleicht auch gut funktionieren. Also deswegen Browserstack, aber Browserstack ist auf jeden Fall eine super Ergänzung. Also man ist auch da, wenn wir teilweise irgendwelche Device haben. Ja. Drum haben wir das auch schon mit BrowserStack probiert, nachzustellen.
Garrelt: Aber lass uns gern mal 'n bisschen in die technische Tiefe gehen, weil das würd mich mal stark interessieren, Du hast ja eben schon so gemeint, performance testet Du mit BrowserStack eher weniger. Was ist denn dein Weg, Performance wirklich zu testen? Also erst mal 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 ja, wie fix Du damit dann auch deine Probleme?
Christian: Ja. Genau, also Browser Stack eintinkt sich deswegen nicht, weil weil Browser Stack selbst auch schon sone gewisse Langsamkeit durch sein Funktionsprinzip mit sich bringt. Und man hat zwar Dev Tools, aber die sind halt einfach nicht, also die sind, ist schon super, cool, dass man die hat. Aber die sind halt nicht so gut wie die 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. Mhm. Genau, das heißt, also zum einen gibt's, also für Ladezeit gibt's ja Tools wie unter einem Webpage Test, mit denen kann man das, kann man so Tests ganz gut machen. Mhm. Sofern die das Webprojekt eben von extern erreichbar ist. Webpage Test ist letztlich so was wie 'n auch 'n ferngeschalter oder gescripeter 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 er aus Frankfurt laufen? Soll der aus Übersee laufen? Und man kann dann auch die Geschwindigkeit der Anbindung wählen, die dann die dann allerdings, glaub ich, emuliert ist, was immer noch natürlich nicht genau das Gleiche ist wie 'n echtes. Genau, also da gibt's dann, weiß ich nicht, Cables sind so der Klassiker oder Fast 3 g wär jetzt so, da würd ich irgendwie so hingehen. Das ist so der, in unseren Breitengraden zumindest so die die langsamste Verbindung. Mhm. Wenn man für den globalen Markt arbeitet, dann muss man vielleicht auch noch slow, slow, shree g sich sich vielleicht angucken. Und genau, und das Device kann man sich auch noch aussuchen. Also ob das jetzt 'n ist
Fabi: oder
Christian: ob das 'n Desktop Browser sein soll. Mhm. Genau. Über Webpage Test kriegst Du da am Ende son eine Auswertung. Da werden natürlich die Lighthousescores getestet. Da kriegst Du aber noch viele viele andere Metriken. Und Du bekommst auch einen son Wasserfallchart, wo Du genau sehen kannst, so wie wir's im Grunde auch aus dem Network Panel des Browsers kennen oder wir haben auch dieses Network, diese Network ja, Spur in dem Performance Profiler, in den Dev Tools, Mhm. Wenn man da profilet. Aber Webpage Test bratet es einfach super auf mit Details auch zu den einzelnen Requests, wo Du dann auch sehen kannst, ja, auf welchem Protokoll lief das? Und wenn es auf HTTP 2 oder höher lief, so auf welche Priorisierung hat 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 son klassisches Problem, dass Server das leider nicht so implementieren, wie's wie's sein müsste. Genau, und Du kriegst eben ganz unten hast Du auch sone Leiste, wo Du sehen kannst, wie hoch ist die Auslastung der der CPU des Systems, also für das Parsen und das Ausführen. Also Parsen von allem und das Ausführen von JavaScript respektive vielleicht auch das Layouting, dass er da auch mit reinspielt. Mhm. Und genau, dann wenn wenn halt diese CPU Bar, wenn die irgendwie relativ gefüllt ist, sehr, sehr viel Aktivität drin ist, dann ist das schon son Indikator für, da läuft einfach zu viel auf dem auf dem Mainstreet, da da muss man irgendwie noch mal rangehen. Und dann bekommst Du auch noch mal angezeigt, welches der Skripte, die Du geladen hast, im Wasserfall dann quasi Aktivität auslöst.
Fabi: Mhm.
Christian: Genau. Das find ich eigentlich ganz gut. Ansonsten den, also bei, wenn ich mit echten Geräten teste, dann versuch ich eben auch so Midrange Geräte zu bekommen. Also genau, ich hab jetzt auch kein, nicht das neueste Smartphone. Ich hab hier 'n Google Pixel 6. Mhm. Also auch schon 'n bisschen betagter. Genau, und dann dann kannst Du da testen und und eben auch per Remote Debugging, also einfach per USB anschließen, kannst Du dann Performance Profiling machen und dann da tiefer tiefer einsteigen und gucken, wo gibt's Probleme? Und da gibt's ja dann, was so die Laufzeitperformance angeht, gibt's ja diese Richtschnur, dass Du versuchst, 'n Task, wenn er ausführt, auf eine maximale Dauer von 50 Millisekunden zu begrenzen. Also wenn er dann wenn er länger dauert, dann fängt die Userin oder User an, irgendwie das zu bemerken, dass dass quasi das Interface blockiert ist und dass es eben nicht mehr auf Eingaben reagiert. Und und das finden, da da fangen dann, da fängt das Bauchgefühl an zu sagen, so, das ist jetzt irgendwie 'n Legggy hier alles. Genau, da gibt's dann wieder verschiedene Strategien, wie man diese 50 Millisekunden sozusagen, wie man in diesem Rahmen bleiben kann.
Garrelt: Oh, was sind das so für Strategien?
Christian: Also es gibt so verschiedene Strategien. Also entweder Du verlagerst Tasks in komplett andere Threads, also weg vom Main Thread. Das ist dann, das versuch ich auch viel zu machen. Also dass ich zum Beispiel in dem aktuellen Textdeck ist es so, dass ich in der Summe 5 Webworker hab, die die noch hinten so rumschwirren und diese bestimmte Aufgaben übernehmen können. Zum Beispiel 1, der macht das Template Rendering. Das heißt also, der kriegt die Daten, der hat die Templates, rendert die zusammen und schickt dann die fertige fertig reneter HTML wieder nach vorne in den Main Thread rein. Mhm. Dann gibt's einen Webworker, der mit dem anderen Webworker auch kommuniziert, aber auch mit dem Main Thread, der so Translation Kram macht.
Fabi: Mhm.
Christian: Genau, was hab ich noch?
Fabi: Translation Kram mit bezogen auf, also was in Form
Christian: Also Multimehrsprachigkeit. Also wenn ich da sozusagen im Browser rändere, dann dann hab ich halt die ganzen Übersetzungs, Übersetzungen auch in dem drin. Und dann gibt er eben die passenden Übersetzungen für die aktuell gewählte Sprache zurück.
Fabi: Genau. Find ich Teil des des Render Webworkers, der sozusagen, weil theoretisch ist es ja eine Sprache, die hab ich einmal eingestellt und danach wird jede Seite in dieser Default
Christian: Genau, also das ist deswegen, genau, stimmt, könnte man alles zusammen in in einen reinstecken, aber die diesen Übersetzungsservice, also ich Sachen, die so leichtgewichtig sind, die schick ich nicht an diesen Template Renderer, weil der son bisschen, der arbeitet son bisschen wie 'n. Also das ist quasi, der hat dann, da gibt's dann hinterher und so das den ganzen Quatsch, den man so kennt von den von React, Angela und Co. Aber manchmal will ich so viel, manchmal ist das Overkill. Also wenn ich nur 'n Button umbenennen will, weil irgendwie 'n Produkt nicht da ist, dann dann will ich irgendwie auftaufschreiben und dafür hab ich dann, da schmeiß ich diese Maschinerie nicht an, sondern hab einfach 'n kleines JavaScript im Main Thread, das das macht. Und das braucht dann eben aber auch den richtigen String, den's dann da reinsetzen muss und interviewt dann eben auch diesen Webworker dafür.
Garrelt: Ist das, verstehst Du das richtig, dass das Logik und eine Infrastruktur ist mit diesen Webworkern, die Du selber aufgesetzt hast? Oder ist das was, was TWik mitbringt?
Christian: Genau. TWik ist einfach nur eine eine eine Syntax, also sozusagen einfach so eine Syntax, mit der man, also wie Handelbars zum Beispiel auch Ja. Mit eben Kontrollschleifen, also und und und und man kann Variablen dann noch mal in der Template belegen und ausgeben
Fabi: natürlich. Mhm. Genau, und
Christian: hat dann hat dann Filter fürs Swoting oder für, wenn man Markdown rändern will. Genau.
Fabi: Mhm. Und kannst Du vielleicht, ich glaub, ich würde jetzt mal sagen, das ist ja vom Ansatz her jetzt erst mal vielleicht da draußen nicht typisch und man sagt, okay, es gehört zum Standard Stack, dass Leute diese Aufgaben in den Webworker verlegen. Kannst Du uns da zum bisschen noch dazu erzählen einfach, wann Du entscheidest, was in son Webworker zu machen, warum Du's entschieden hast und weil jetzt auch grade bei diesen Translations, so mein Also mein erster Impuls, wenn ich's höre, denke ich irgendwie so, ist das so intensiv, dass ich 'n Translation Service in 'n Webworker geben muss? So mein erster Instinkt war irgendwie so, das klingt übermäßig komplex und vielleicht auch unnötig Und also wie wie denkst Du darüber nach? So wann warum hast Du dich dafür entschieden? Und vielleicht auf unserer Zuhörer, wann können Sie das in Erwägung ziehen? Das wär das, was was der Outcome daraus hoffentlich ist.
Christian: Genau, ich hab übrigens die Liste auf. Ich hab noch 'n son Filterworker, der macht so facettierte Suchen. Also wenn Du Mhm. Da irgendwas startest, dann dann regelt der das, dass der quasi die das Backend anfragt und dann sozusagen das aufbereitet und das fertig nach vorne schickt. Mhm. Dann genau für QR Code Scanning, da gibt's auch 'n Worker, der das macht.
Fabi: Mhm.
Christian: Dann hab ich 'n Speed Test Worker, der im Hintergrund quasi Speedtests durchführt. Und genau, dann hab ich noch einen, der so aus Bildern extrahiert. Also dem kann man 'n Bild entgegenwerfen.
Garrelt: Mhm.
Christian: Und der sagt dann, dunkelste quasi aus dem Farb, auf das Farbskalastiefarbe hältst Du die und so könntest Du 'n Farbverlauf machen. Mhm. Wie mach ich das? Also es gibt natürlich Dinge, die die klingen schon schwer, ne. Also der der Render zum Beispiel, der der klingt ja, da ist es irgendwie, ich glaube, das würde man jetzt nicht infrage stellen. Aber im Grunde kannst Du sagen, alles, was was Du ausm Mainstretch wegverbannen kannst, tu das einfach. Also weil so schwer ist das nicht. Es gibt auch, die die das leichter machen, so wie Complink zum Beispiel. Das ist son son kleine Javascip Library, die sozusagen son auf dieses ganze Post Message System aufsetzt, dass es das Ganze dann einfach netter zu bedienen ist. Und je mehr Du Arbeit vom Mainstream kannst, desto besser.
Fabi: Mhm.
Christian: Und das ist natürlich besonders bei langsamen Geräten relevant. Also bei schnell bei iPhones ist es vielleicht nicht so wichtig. Aber je langsam 'n Gerät wird, desto ist es, desto begrenzter ist eben Also die sind ja meistens so, dass die, die haben ja schon 8 Prozessorkerne, diese kleinen Handys zum Beispiel. Also die, die ihr euch da wahrscheinlich geholt habt, die sind halt nur, all jeder Kern ist halt einfach nur total lahm. Es gibt aber genug davon. Und deswegen, also so, je mehr man dem Mainstread den Rücken freihalten kann, desto besser.
Garrelt: Ja. Ist also, boah, ich glaub, ich merke, da ist, glaub ich, eine Lücke bei mir. Javaskip ist ja eigentlich Single, aber Webblöcke können auf 'nem anderen laufen, ja. Also auf 'nem anderen Chor.
Christian: Genau. Ah, okay. Ja,
Garrelt: genau. Das war mir geil.
Christian: Und Du kannst quasi den Nachrichten schicken, wie Du das irgendwie auch so über Grenzen wegmachen kannst oder so Message Channel kannst Du auch benutzen. Ja. Ja. Und dann kannst Du auch Dinge, also Du kannst bestimmte Dinge machen. Zum Beispiel gibt's auch off offscreen Canvas. Das ist quasi die Canvas, die aber in 'nem Webworker läuft. Ja. Da kann man eben dann so quasi Post processing dran machen von von Pixeln oder Berechnungen auf Pixelbasis und und hat das nicht im Main Thread. Ja. Genau. Und so Sachen wie Index DB, auf die hast Du auch Zugriff aus dem Web Work heraus. Was nicht geht, ist so Locals, alle synchronen Interfaces und Dom geht nicht. Also aufn Dom kannst Du nicht zugreifen. Da gibt's zwar so Tricks. Da gibt's so einen son 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 unter dokumentiert ist. Aber wie sie's machen, ist schon sehr klug, ja.
Garrelt: Die haben doch diese lustige Webseite, wo man die Cursor von anderen Leuten, anderen Besuchern der Webseite grad sieht. Ist das nicht
Christian: die? Ja, ist die das? Ich weiß es nicht. Das sind ja die Leute, die auch dieses Framework machen. Also das ist so Genau. Dieser Dunstkreis. Ja.
Fabi: Party. Ich glaub, ja, es ist auf jeden Fall, wir reden über das gleiche Partytownia. Ich glaube auch, dass das das war mit den.
Garrelt: Aber haben die die Landingpage nicht mehr?
Fabi: Das war eine
Garrelt: Das also sieht, das Logo sieht für mich familiär aus, aber scheinbar, ja, vielleicht haben sie's auch gekickt. Na ja.
Fabi: Wir werden sehen. Aber ich würd gern mal noch mal so, wir sind jetzt schon in einige Dinge rein. Ich würd noch mal auch für für mich, aber zum Recaper vielleicht noch mal für die Hörer noch mal probieren, so den Toolbild, den wir von Shapherd son bisschen an die Hand bekommen, noch mal aufzuzeichnen. Also wir hatten ja vorhin irgendwie son bisschen die Kategorien aufgemacht, Ladezeiten und Performance so. Wir haben uns irgendwie son bisschen gelernt, okay, was schaue ich mir erst mal an? Da hattest Du, wie war noch mal die Name des Tools, dass das Web, Fed oder
Christian: Webpage Test.
Fabi: Webpage Test Tool. Im Grunde genommen ansonsten hab ich meine lokalen Device, wo ich auch irgendwie per remote irgendwie drauf zugreifen kann, einfach sagen kann, ich teste das Ganze beziehungsweise stell dann Bugs eher über Browserstag nach, wenn's wirklich alte Betriebssysteme geht, weg von Performance. Und wenn wir jetzt sagen, was können, also das sozusagen das das Rausfinden sozusagen, erst mal das Identifizieren. Und jetzt zu dem Toolbild, was können wir denn tun? Hab ich jetzt, im Grunde genommen genommen haben wir jetzt 2 Dinge genannt, wenn ich's richtig verstanden hab, die in Richtung Performance sind. Also wir haben gesagt, was ich in CSS machen kann, mach ich in CSS und hol's raus aus JavaScript so. Das war der das eine, was ich mir mitgenommen hab. Ja. Und das andere ist so, das, was nicht aufm Main Thread laufen muss, soll in einen separaten Thread und dafür benutz ich Worker, dafür benutz ich die Worker grundsätzlich die Worker Infrastruktur, das zu machen. Das heißt so, in meinem Toolbild hab ich jetzt so möglichst viel CSS und davon weniger JavaScript. Und wenn schon JavaScript, dann auf 'nem dann auf 'nem Worker Thread.
Christian: Vielleicht können wir uns ja mal das, ja. Dieses Modell heißt, also das das gibt's auch eben, dass man einfach eben sozusagen wie so Unterbedienstete hat, den man, den man die Arbeit wegdelegiert, quasi auf Mainshrat möglichst frei sich bewegen zu können. Wir gehen gleich zur Ladezeit noch mal rüber. Ich wollte noch sagen, es gibt noch eine dritte Sache, die man für die machen kann. Das ist nämlich, wenn man Dinge animiert, das kennt ihr wahrscheinlich auch. Ihr werdet wahrscheinlich viele Animationen bei euch haben. Ja. Da gibt's einfach, also es gibt eigentlich 'n 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 inperformant. Und da hingehen kann man, das sieht man in seinen in seinem Profiler auch, also wenn sehr viel so CSS Relayout, also wenn da so die die Lilabalken sehr groß werden oder die Grünen für, 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 Erlaubnis ist eigentlich nur. Dann Translation oder Transforms und Filter. Das sind die die 3 im Grunde, also. Und was man sich nicht mit denen zusammenbauen kann, wird halt inperformant und belegt halt den zu 'nem gewissen Grad einfach mit Arbeit. Genau. Also es wären so, das wollt ich noch ergänzen, dass da kann man seine Performance verbessern. Was Solada Zeit angeht, da guckt man sich wirklich diesen diesen Wasserfall an, weil der gibt Auskunft über Dinge wie, wann wurde 'n Server Connect durchgeführt? Wenn man bestimmte Ressourcen hat, die die zwingend erforderlich sind, dann ist es ja sinnvoll, wenn man das schon vorab weiß, diese Server Connects zu diesen vielleicht weiteren Host, abgesehen vom Main Host frühzeitig zu machen. Da gibt's dann DNS Preconnect Anweisungen, die man, also man kann Link, ne, das nur nur Preconnect DNS, DNS prefatcht war's früher und jetzt heißt das Preconnect. Mhm.
Fabi: Das
Christian: kann man in seinen seinen 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 schnelle Interaktion oder so, das vielleicht Hauptjavascript. Also wenn ihr das zum Beispiel über Javascript moduls ladet, dann dann ist das ja son asynchrones Ding und dann dauert das vielleicht, bis der Browser sich dran macht, die zu laden. Da kann man dann 'n Link rel prefatch, ja genau prefatch in den in seinen reinstecken und sagen, hey Browser, die Ressource hier, die kannst Du schon mal holen gehen, weil ich geborene dir hiermit Garantie, ich werd das später brauchen. Das macht das mal. Genau. Und und so kann man im Grunde sein den Wasserfall, der der vielleicht erst mal nicht so aufgebaut ist, wo die nicht die Dateien geladen werden in der Geschwindigkeit oder vielleicht auch in der Reihenfolge, in 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 wurd vorher an zehnter Stelle geladen, jetzt wird's schon an dritter Stelle geladen, super. Und meine ganzen Connects zu den Servern, die finden nicht nacheinander mehr statt, sondern ich seh, ah cool, die sind jetzt alle gleichzeitig. Also die die werden vorbereitet und müssen nicht erst später, wenn ich dann zugreife, gemacht werden.
Garrelt: Das sehe ich auch in dem Profiling von dem Performance Tab in Chrome, richtig? Ja. 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 für Chrome irgendwie nutzt, sich diese Themen anzuschauen. Aber für mich ist das so, als ich das erste Mal auf diesen Tab gegangen bin und mal son Profil gemacht hab, war ich danach so Ja. Wie soll ich ihr
Christian: Ja, das ist die Mutter aller
Garrelt: aller. Das ist eher unfassbar. Kannst Du, also das ist ja schon eine schwierige Aufgabe, jemanden zu erklären, wie das Ding funktioniert. Traust Du dich zu, dass nur auf Tonspur mal, also son zumindest son Ansatzpunkt zu geben, wie kann man mal so eine erste Sache da herausfinden oder wie würdest Du 'nem 'nem Anfänger zeigen, okay, wie benutzt Du das?
Christian: Es gibt 2 Methoden, die Du da nutzen kannst. Das eine ist, dass Du einfach 'n Profiling startest auf der Seite, so wie sie grade 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. Mhm. Das sind, das können eben Network sein, das können kann eben Rechenaktivität sein, runtergebrochen auf, war das jetzt HTML Passing? War das jetzt Java Script Passing 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 noch mal Spuren für. Also Du kannst dann sehen, was 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 erst mal JavaScript gepast wurde. Macht Sinn, weil das war eine JavaScript Datei, die geladen wurde. Mhm. Und Du kannst dann in diese die Rechenaktivitäten von, in dem Fall JavaScript, HTML und CSS Layoutern geht das nicht ganz so gut. Aber bei Javascript kannst Du dann tiefer reingehen und kannst dir dann sogenannte Flamecharts anzeigen lassen. Das sind im Grunde so Callstacks. Also was hat denn jetzt eigentlich zu dieser Aktivität geführt und welcher Callstack, welche Callstack Kette ist da durchlaufen worden? Mhm. Und vielleicht auch welcher welche Funktion hat irgendwie sehr viel Zeit verbraucht in in mein, in der Zeit und ja. Bei CSS, da kannst Du zumindest, ich weiß nicht, wann das Ich glaube, das musst Du aktivieren, weil das dieses Profiling noch mal langsamer macht. Da kannst Du zum Beispiel noch tiefer reingehen, ob das quasi beim, ob das beim viel Zeit gebraucht hat oder dann tatsächlich beim painten und Layouten. Mhm.
Fabi: Das
Christian: Recalkulation ist immer, wenn der Browser hingehen muss und HTML neu gegen die ganzen CSS Selektoren menschen muss. Mhm. Also das macht er zum Beispiel, wenn wenn Du eine CSS Klasse auf dem 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 has Selektoren sind da sind da, die kann man schon so bauen, dass die sehr zeitintensiv sind, weil der Browser einfach sone gewisse Heuristik hat, dass er sagt, hey, wenn wenn im Boot eine Klasse geändert wird, dann könnte eigentlich ja bei jedem Element, wenn der der Elternklasse jetzt eben diese andere ist, sich was getan haben. Also muss ich das machen. Oder Du machst das an 1 Stelle und alle quasi darauf folgenden Siplings werden neu evaluiert, weil Du natürlich diesen Siplings Selektor in CSS hast, der dann eventuell zu 'ner Änderung führt. Mhm. Genau, solche Dinge kriegst Du dann eben da in diesem, wenn Du über CSS tiefer reingehst, angezeigt.
Fabi: Mhm. Und vielleicht, jetzt haben wir grad son bisschen verstanden, wie der Performance Tab zum Nutzen ist. Wir hatten ja vielleicht noch mal 'n bisschen auf dieses, wie schaust Du denn eigentlich auf Performance oder ja, Du hast ja son paar Dinge genannt, wie einerseits, okay, wenn man da reinschaut und irgendwie Einzelinteraktionen lenkt diese 50 Millisekunden überschreitet, dann kann ich natürlich den Webpagecheck da an der Stelle nutzen, wenn's irgendwie Ladezeiten geht. Aber ich frag mich, wie machst Du denn, wenn wir von Run Time sprechen, wie machst Du's zur Development Run Time oder zum in der 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 was würdest Du gerne den Hörern irgendwie mitgeben? Wie sollten wie sollten sie irgendwie darauf blicken und was sollten sie irgendwie kontinuierlich im Blick haben so? Ich weiß nicht, war auch dieses, Du hattest was von deinem Worker gesprochen, der Speedcheck Worker. Hat der was mit Performance zu Also war das was in die Richtung, was Du diesen Worker erlaubt hast oder war's so dieses Speedcheck Worker? Hat er damit zu tun? Aber ich würd gern so verstehen, wie wie sieht dein, bist Du, aber wie man ja immer den Performance Tab aufhat?
Christian: Nee, ich hab 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 1 von diesen Dingen, so wie Accessibility oder was weiß ich, gibt gibt's da noch son paar andere Dinge, die muss man von Anfang an mitdenken. Wenn man die nachträglich versucht reinzubauen, dann ist immer schwierig. Also bist teilweise vielleicht auch gar nicht so einfach möglich. Ich kann auch gleich von von einem einem Ding erzählen, was ich im Nachhinein wahrscheinlich anders gemacht hätte, das aber nicht so einfach mehr zu zu retrofitten ist, was so jetzt Performance angeht. Aber ansonsten ist es eigentlich so, dass wenn wenn son Projekt dann mal draußen ist, dann find ich eigentlich am besten son
Fabi: Tool laufen zu haben. Also das
Christian: ist sozusagen immer die zu haben. Also das ist sozusagen immer die für mich, auf Performancesblemesuche zu gehen. Und dieses Tool, da gibt's ja diverseste Anbieter. Was die machen, das ist einfach 'n Skript, das läuft bei jedem User. Das könnt könnt ich auch in meine Code Base einbauen. Aber die Frage ist halt, wo werden diese Daten zusammen gesammelt und auf aufbereitet? Das ist ja eigentlich immer das Schwierige. Wir nutzen dafür zum Beispiel Centry, aber es gibt auch oder und noch son son paar andere. Oder oder von Akamai gibt's auch solche Tools, die messen eigentlich kontinuierlich die Core Web Vitals und gegebenenfalls noch 'n paar andere Metriken und 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 performancebezogene Metriken, die vorwiegend Google erarbeitet hat und die eben diese Bereiche abdecken, Ladezeit, Performance und auch Layoutstability. Sind auch sind auch 3. Es gibt 3, die sozusagen eine wichtige Rolle spielen und dann gibt's noch viele andere, die dann noch dazukommen. Aber so das das da gibt's dann irgendwann eben dann die Benachrichtigung, hier ist irgendwas nicht mehr so gut. Guck mal nach und dann dann konzentrier ich mich wieder mehr auf das Thema Performance, bis bis es dann erst mal wieder auf Stand ist. Man kann in seinem in seiner CICD 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ößtenbudgets kontrollieren, also dass man sagt, ich leiste mir bis zu 200 k JavaScript, mehr möchte ich nicht haben. Bitte lasst die Pipeline fehlen, wenn wir irgendwann an den Punkt kommen, wo wir mehr verbrauchen. Genau, damit damit einem das nicht so so durchgeht, damit man nicht son son schleichende Verschlechterung hat. Problem ist halt, das sind das ist ja son Laborsetting. Also auch wenn wir auf unserem Mac jetzt den das Lighthouse Tool laufen lassen und wir gucken uns die Performancewerte an, auf auf dem MacBook ist es mega, ist alles super. Meine Seite ist schnell, geil, alles grün. Auf dem Windows Rechner nebenan ist das vielleicht dann aber schon gar nicht mehr so. Und auf dem langsamen Moto-G überhaupt nicht. Deswegen sind die auch überhaupt nicht vergleichbar. Also wenn wenn ich sage, hey, ich hab bei Performance 98, dann sagst Du, nee, das stimmt nicht, wir haben doch nur 80.
Garrelt: Mhm.
Christian: Dann haben wir beide recht.
Fabi: Mhm.
Christian: Weil das eben nur bezogen ist auf unsere aktuelle Maschine. Also es wäre und unsere Leitung auch. Also man kann, das wird zwar künstlich verlangsamt, also man kann seinen seinen Durchsatz sozusagen auch schrottteln, aber das ist halt nicht das echte Ding. Also ich will nicht sagen, dass man's gar nicht nutzen sollte, aber man muss einfach wissen, dass das nicht die nicht das ist, was die Leute draußen sehen.
Garrelt: Es ist auf jeden Fall immer noch gut als Vergleichsmetrik, ne. Also wenn man Änderungen schipped und merkt, oh, der Score ist irgendwie noch durchgegangen, dann kann man schon präventiv drauf gucken, so, okay, was ist also, soll ich mir da was machen?
Christian: Das stimmt. Also genau, also bezogen auf das gleiche Gerät sozusagen am Tag vorher, ne, dann das kann man vergleichen. Das stimmt. Ja.
Fabi: Ja. Aber sonst würdest Du sagen, User Monitoring und so was wie, das wird da das wird da einfach wirklich eher uns den reellen Wert anschauen.
Christian: Genau. Also haben ja viele Leute sowieso am Start für einfach fürs Erro Tracking und dann hat man einfach dieses andere, das diesen anderen Themenbereich, Freihaus mit dabei. Mhm.
Fabi: Ja, cool. Dann, wenn Du magst, da sind sie noch mal gerne, was Du vorhin kurz geteasert hast mit, was Du heute anders tun würdest, aber nicht mehr reversibel ist, wenn welche fallen hast Du getappt?
Christian: Das da geht's dann da geht's die die generelle CSS Architektur. Mhm. Ich bin, also ich find Tailment okay und ich arbeite damit auch. Aber für dieses für dieses Projekt mit vielen Komponenten hab ich mich für die BEM Methodik entschieden.
Fabi: Mhm. Kenn ich gerne einfach auch.
Garrelt: BEM, ja.
Christian: Dafür steht die Abkürzung. Und das das funktioniert so, dass Du jeder Komponente einfach klassischen Namen gibst, idealerweise dein ganzes Projekt präfix mit irgendwas, damit, falls Du Komponenten von anderen Frameworks reinmisch, Du keine Kollisionen hast, das nicht beide Slider heißen zum Beispiel. Und alle Bestandteile dieser Komponente, also weiß nicht, von der Card darfst Du dann 'n Bild, dann hast Du ja noch quasi die Caption und so, die kriegen dann CSS Klassen zugewiesen, die eben auch wieder mit starten und dann Unterstrich Unterstrich Caption haben oder Unterstrich Unterstrich Image. Das ist einfach 'n striktes, eine strikte Namenskonvention, die man da wählt. Aber klassisches CSS arbeitet ja wirklich immer so und BAM ist da eigentlich nicht anders, dass man an Elemente eine Klasse hängt und diese diese Klasse zeigt in CSS und da sind dann ganz viele Anweisungen drin. Und über die Zeit baut man immer mehr Komponenten und hat immer mehr CSS, das die das hier für diese Komponenten ist, aber wo sozusagen Anweisungen dadrin sich im Grunde ständig wiederholen und duplizieren. Wow. Und an dem Projekt hier bin ich jetzt schon eine ganze Weile dran und das das ist, die Komponentenzahl ist halt unglaublich gewachsen und damit ist auch die das CSS unglaublich gewachsen. Das wächst halt quasi 1 zu 1 mit mit der Komponentenmenge. Mhm. Hätte ich Talewind genommen von Anfang an, auch wenn das vielleicht fürs Debugging schwieriger ist, wär das nicht passiert. Dann also ne, bei Talewind ist es ja so, das verlagert ja sozusagen die das Wachstum aus dem CSS raus ins HTML hinein. Das HTML wird ja dann einfach groß und klunky und das finde ich auch viele Leute doof. Der Unterschied ist aber, CSS muss immer als Ganzes heruntergeladen und werden, bevor der Browser den ersten Pinselstrich tut. Und der kann diesen Pinselstrich auch nicht tun, wenn wenn er 20 Prozent 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.
Garrelt: Ja.
Christian: Und im Gegensatz dazu ist HTML 1 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 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 auch noch mal son ganz schwieriges Thema, ob man da was kaputtmacht. Genau, also hätte ich Talewind genommen oder 'n Utility CSS Ansatz, gibt's ja auch noch andere außer Talewind, dann wär mein CSS einfach irgendwann an 'nem Punkt nicht mehr weiter gewachsen und würde jetzt nicht sozusagen als ein Webperformance Bremsklotz in in meinem in meiner Webseite im Head herumdümpeln.
Fabi: So. Aber das wär 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, auffallender Performance Impact bei der Seite, dass dann CSS so groß Na
Christian: ja, das, also ich ich kann das schon, also es ist natürlich komprimiert und mit Brotli und was ist das hier, z-Standard und so kann man ja viel rausholen aus den Dingen. Aber es ist schon auffällig, dass die CSS Datei relativ groß ist. Also weiß ich nicht, ob ich das jetzt hier grad mal sehen kann. Genau, also 737 k b ist schon groß.
Garrelt: Das ist schon 'n bisschen Mit CSS, ja. Ja. Mhm. Genau.
Fabi: Das heißt, jetzt bist Du doch Tailwind Fan.
Christian: Ich war nie gegen Tailwind, aber genau, ich finde halt die BEM Meteorologie einfach gut, weil Du kannst halt einfach in das, in deinen Dom reingehen, inspekten 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 wo sind da die meiner Komponente und wo ist schon die nächste, wo hat die nächste angefangen? Also wahrscheinlich, wenn ich wenn ich jetzt Tailwind nehmen würde, würd ich einfach Dummy Klassen trotzdem in mein HTML reinwerfen. Einfach, dass ich da auch sehen kann, wo sind die meiner Komponenten, ohne dass ich diese CSS Klassen aber am Ende auch nutze. Also ich würde dann wirklich Notainment nutzen. Genau, aber das wär so was, da würde ich vielleicht empfehlen, grade wenn man so Projekte hat, die die halt wachsen, Tailwind zu nutzen. Genau, also ich sag mal so, in Hardcore CSSler Kreisen ist Tailwind sehr verschrien. Genau, also das finden da alle doof. Aber aus Performance Sicht ist es 'n ziemlich guter Ansatz. Und es ist auch 'n gutes Framework generell.
Fabi: Zeitmäßig sind wir auf jeden Fall jetzt schon langsam bei 'ner bei 'ner Stunde angelangt, deswegen würd ich mal son bisschen, wir haben ja jetzt so probiert parallel immer son bisschen das das Toolbild aufmalen, das Du uns an die Hand gegeben hast so. Wenn wir jetzt die Frage eher noch mal 'n bisschen offen auch dir gegenüber stellen 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öcht ich noch in das in das Webperformance Toolwelt für unsere Hörer noch mit reinpacken?
Christian: Na ja, vielleicht, also was sich immer bewahrheitet ist, je weniger JavaScript man benutzen kann, desto besser aus verschiedenen Gründen, weil JavaScript kostet halt immer dreifach. Also es muss übertragen werden, da muss gepast und werden und dann kann's ausgeführt werden. Also oder sogar vierfach. Genau, das heißt also generell, wenn man jetzt so sagt, ich hab 'n bestimmtes Kilobyte Budget, würde JavaScript viel schwerer wiegen als Also einiger bei JavaScript ist tausendmal schlimmer als einen Megabyte Bilder. Man kann zwar bei Bildern viel rausholen, aber das, was eigentlich wirklich 'n also 'n Impact hat, ist, JavaScript, wenn man das schafft, das zu reduzieren, super. Ich finde diese Konzepte gut, wie sie zum Beispiel Astro bietet, dass man eben sagt, ich liefer eigentlich meine Seiten statisch aus, wie auch immer ich die Ränder, ob ich die mit PHP Render oder mit Node oder die Vorrender mitm statischen Seitengenerator. Und dann hab ich eben bestimmte Bereiche, die sind interaktiv, die müssen eben reaktiv sein. Und genau, wie man das dann macht, also entweder macht es wie Astroway oder dann gibt's natürlich so andere Frameworks wie HMX, die die auf son Mittelweg gehen, also dass das Ganze dann leichtgewichtiger wird. Das wär vielleicht noch so Architekturell, was ich was ich so den Hörerinnen und Hörern mitgeben wollen würde, versucht, JavaScript im Sound zu halten und genau versucht eben, möglichst viel schon fertig vom Server zu zu schicken und dann vielleicht irgendwie Dinge interaktiv zu gestalten.
Garrelt: Das ist ja son Tipp sozusagen, wenn man auch auf 'n neues Projekt schaut. Nicht zwangsweise, aber Mhm.
Fabi: Wir haben
Garrelt: ja am Anfang auch eigentlich schon mal gesagt, wir könnten auch noch mal auf Legacy Projekte schauen. Das haben wir gar nicht so sehr gemacht. Also was hast Du denn ähnliche Tipps oder was würdest Du irgendwann sagen, der in gefangen ist? Oder in 'nem Viewprojekt und irgendwie gar nicht so viel Einfluss darauf hat, wie viel JavaScript da dann wirklich geschipped wird? Also man ist da ja oft begrenzt in den Dingen, wie zum Beispiel Dinge in Webworker auslagern. Wüsst ich jetzt gar nicht, ob das mit View so gut geht. Also vielleicht gibt's auch, aber hast Du da Erfahrungen mit und was würdest Du da machen?
Christian: Also ich glaube, da kannst Du im Grunde nur versuchen, hin zu migrieren zu diesen Meta Frameworks, zu einem der Meta Frameworks,
Garrelt: Mhm.
Christian: Die dann aber auch die erlauben, weniger Kleinzeitcode zu shippen. Also dass Du Aber das das ist halt auch nicht eben schnell gemacht, ne. Also das ist leider das Problem. Also wenn man sich, also ich weiß auch von 'nem Team von 'ner von 'ner großen Zeitung, die eben auf, ich glaube, Angular gesetzt haben
Fabi: Mhm.
Christian: Und die das im Kleinen trändern. Und die war halt echt nicht gut. Und die versuchen das natürlich dann, grade bei Zeitungen, die halt total abhängig sind, also der Crawler muss da irgendwie ran, die haben dann versucht, das irgendwie nachträglich mit Serverset Rendering zu zu flankieren. Mhm. Für wenn der Google Browser kommt, dann schick 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 son bisschen im Brunnen gefallen. Also eine schnelle Lösung gibt's da 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.
Fabi: Aber ich find interessant, dass Du's jetzt von dem Legacy Aspekt aufgezogen hast, gerade. Weil eigentlich wär meine Frage wahrscheinlich in die ähnliche Richtung gegangen. Ich hätte nämlich von dir gern noch mal son bisschen son Take zu den Web Frameworks gehabt. So jetzt haben wir's gerade aus Legacy, wir haben's, ja dann war deine Antwort, ja das mal wegmigrieren. Aber ich würde jetzt gern mal mit dem, was Du an Toolbild irgendwie uns gegeben hast und noch mal gesagt hast, probiert, Javascript zu minimieren, probier vielleicht irgendwie dir einen Kilobyte Budget an Javas oder 'n 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, neues Set-up so? Ist es bei dir dann deswegen allein ein klares Nein so oder ist es ein, Frameworks nach und was was was wär da deine Empfehlung, wenn man wirklich sagt, irgendwie dieser Performanceteil ist mir einfach sehr, sehr wichtig so. Ist das dann überhaupt eine Option, auf die Web Frameworks zu gehen?
Christian: Grundsätzlich schon, aber ich glaube, so son Framework wie NextJS kommt ja überhaupt gar nicht. Also es es gibt ja kein Modusoperandi, aber ihr könnt mich korrigieren, wenn wenn das mittlerweile anders ist, wo Du ohne Kleinzeit JavaScript daherkommst. Also das ist da, also außer vielleicht bei Server Server Renad Components, wie heißen sie noch mal? Heißt noch Server Renad Components, oder? Da ist es auf jeden Fall so. Genau, also kann man kann man sozusagen Teile, aber da da ist es andersrum. Das ist ja dann nicht dieses Interactive Island Konzept, wo man eine statische Seite hat und dann gibt's quasi interaktive Inseln da drin, sondern bei denen ist es ja umgekehrt, alles ist interaktiv, bis man bis auf 'n paar statische Inseln, die man drin hat. Also die die Philosophie ist umgedreht. Mhm. Das heißt also aus Webperformancesicht, also die Next Leute nutzen CDNs und machen ganz viele clevere Sachen. Also die die versuchen sozusagen, die Unzulänglichkeiten, die ihre Architektur hat, zu erschlagen, einfach mit Technik. Und das klappt auch, aber eigentlich eigentlich arbeitet man sozusagen gegen Unzulänglichkeiten an und ich würde dann eher Ich glaube, bei ist es zum Beispiel möglich, dass Du ohne JavaScript Du kannst da so eine Anwendung bauen in deiner Lieblingstemplating Sprache, nämlich. Mhm. Und kannst trotzdem eben eine leichtgewichtige Seite am Ende schippen. Also weil man wählt ja eigentlich diese Frameworks meistens aus Development Experience Gründen, würd ich sagen. Mhm. Also natürlich auch so, man kennt das und man nimmt natürlich immer den den gleichen Hammer für alle Nägel, versteh ich auch.
Fabi: Mhm.
Christian: Genau, aber dass man da einfach guckt oder vielleicht so was sich mal anguckt wie QUIC, Das hatten wir ja vorhin schon mal erwähnt. Mhm. Bei QUIC ist es so, dass die eben auch nix hydraten. Das ist ja das große Problem bei bei denen bei NextJS, wenn eben fertiges HTML geschickt wird und dann wird das Ganze noch mal sozusagen in einen Durchgang überrendert, mit Hydration. Und bei QUIC ist es so, dass die son Art haben, dass im Zweifelsfall vielleicht gar nichts wird, wenn man eine Seite nur liest, aber sobald man anfängt zu interagieren mit der Seite, dann wird diese Histation nachträglich durchgeführt. Und das ist, da steckt man zwar auch 'n Problem mit sehr viel schlauer Technologie, aber zumindest funktioniert's da.
Fabi: Ja. Also eigentlich, wenn man's runterdampfen würde auf, achte auch bei der Auswahl deines Frameworks darauf, dass möglichst wenig Kleinzeit JavaScript mitkommt. Und ich mein, ist ja auch was, was man sich an sich mal vielleicht einfach mitnehmen kann. Ich glaube auch, dass viele auch von uns hören, ich würd auch sagen, wir am Ende diesen Part nicht sonderlich in in 'nem bewussten Entscheidungsprozess irgendwie aufnehmen. Man muss natürlich auch dazu sagen, ne, 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 Autor des Frameworks ja wirklich mal zu sehen, wo ist denn wo ist denn das, wo viel kleinseitiges JavaScript mitkommt ist, denk ich.
Garrelt: Ich glaube, tendenziell könnte man wahrscheinlich noch ins Detail unterscheiden, was ist das denn fürn Use Case? Also wie schon gesagt, bei 'ner bei 'nem Spiel sozusagen wär das ja wär wär ja QUIC überhaupt keine Option so. Du hättest ja uns wissen, ja. Aber auch bei 'ner Web App wäre QUIC auch nicht sinnvoll. Ich glaub, QUIC wurde explizit sogar für den die, wie nennt man das noch mal, die so Shopseiten gebaut, weil da eben schon sehr viel Logik drinsteckt. Aber man braucht selten alles davon oder meistens nur 'n ganz kleinen Teil. Und ich glaube, da könnte man schon noch ins Detail gehen und sagen, okay, wie sieht's denn bei deinem aus? Aber grundsätzlich ist das wahrscheinlich 'n guter Default zu sagen. Guck, also Java gibt es teuer, überleg dir, ob Du's 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 wir schütten das mal, damit's einfach dynamischer ist in dem Fall, wo man's da braucht.
Fabi: Aber so hab ich ja auch jetzt das jetzt auch gar nicht wahrgenommen. Ist ja nur eine weitere Achse, aber ist ja immer, ich mein, bei Technologie ist ja immer das, es es kommt darauf an und natürlich kommt es absolut auf dein Use Case an und aber einfach diese, ich glaub 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,
Garrelt: die Asheb
Fabi: ja auch meinte so Developer Experience erst mal, oftmals es einfach schlägt und man dann sich das vielleicht gar nicht so bewusst entscheidet, so. Und einfach sagt, okay, also ich glaub, ich glaub, dieser Trader wird nicht wirklich explizit, sondern 'n bisschen implizit gemacht. Das fühlt sich gut an, das ist doch irgendwie Developer Experience sieht geil aus, nehme ich, so. Ja, ja,
Christian: ja, das sagt man ja überall, ne. Also man muss natürlich auch irgendwie ökonomisch vorgehen, das Wissen, was man hat, irgendwie weiter nutzen. Also da gibt's ja auch auch wieder viele andere Gründe, ne. Also alles muss da in die Waagschale geworfen werden und es gibt Agenturen, die nehmen für alles WordPress. Auch auch das ist nicht immer sinnvoll. Mhm. Und genau, man hat halt einfach so seinen bevorzugten Textdeck. Klar. Aber ist auf jeden Fall ja nicht verkehrt damals, sich 'n paar Gedanken drum zu machen. Und dann kommt's halt wirklich drauf an, was für 'n 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 dann könnt ihr auf keinen Fall, dann müsst ihr wirklich Bytes sparen, so. Ja. Aber wenn ihr für für unsere, sagen wir mal, westliche Klientel baut, dann ist ist es natürlich schon entspannter generell.
Garrelt: Ja.
Fabi: Dann Chef, vielen, vielen Dank auf jeden Fall dafür schon mal, ich denk mal, unsere Zuhörer haben einen guten Überblick dafür bekommen, haben jetzt son paar Sachen in ihrem Toolbild auf jeden Fall mehr. Und vielleicht bringt sie den ein oder anderen dazu bei 'ner Entscheidung für eine neue Technologie mal dann den kleinseitigen JavaScript Code auch mit in Erwägung zu ziehen. Und ansonsten haben wir da, glaub ich, einigen Leuten ein bisschen was mit an die Hand gegeben. Das heißt, wir kommen jetzt zu 1 unserer Lieblingskategorien, weil es nämlich die Einzige im Deep Dive die. Die. Wir sind zu dritt. Das heißt, es gibt mindestens mal 3, wenn der Garra das geschafft hat, in der Zeit einen zu überlegen. Wir geben ihm dafür noch 'n bisschen Zeit, weil
Garrelt: ich
Fabi: weiß, dass der Shapp auf jeden Fall was vorbereitet hat. Darfst Du als Gast gerne anfangen? Was ist dein?
Christian: Also es ist eigentlich 'n, der aus Sub besteht. Und zwar hab ich mich beschäftigt damit, wie ich hier bei mir mein eigenes LLM laufen lassen kann, hab mir einen gebrauchten Mac Studio mit m 1 Max geholt.
Fabi: Gut.
Christian: Und hab da auch eine Weile für dran rumgedoktert immer mal wieder. Und jetzt hab ich das am Laufen, das ist ziemlich cool. Ich hab LLM Studio drauf, das ist sozusagen der Server für meine für lokale LLMs. Da hab ich jetzt aktuell Gemma 4 drauf. Mhm. Welches? Und dann hab ich das 26 Billionen Expert Modell. Mhm. Genau. Das ist relativ schnell ziemlich geil. Auf aktuell auf 5 Bit quantisiert, falls Du da in dem Game auch drinsteckst.
Garrelt: Ja, ja, ja. Ja, genau. 5 Bit fand das Maximum an deinem RAM wahrscheinlich ging, oder? Weil ich mein
Christian: Ja, weil ich da Gutes drüber gelesen hatte, 5 Bit ist halt dann noch mal irgendwie son bisschen cleverer als 4. Ja. Aber ich wollte jetzt noch mal ein 4 Bit quantisiertes mit diesem mit, gibt's da sone NVIDIA Quantisierung, diese f p 4, die wollt ich ausprobieren mit MLX. Mal gucken, was das bringt.
Fabi: Das
Christian: ist, ob's noch 'n bisschen schneller ist und nicht Döver. Genau. Und dann hab ich noch Comfi UI dadrauf. Da drin hab ich meine Imagegeneration Modelle.
Garrelt: Mhm. Das
Christian: heißt so, die beiden sind auch, also die das eine kann dem anderen sozusagen sagen, hey, ich brauch jetzt mal 'n Bild.
Fabi: Mhm.
Christian: Und als Weboberfläche für die Nutzung, also von, das Ding steht in der Rumpelkammer, da kann ich nicht immer hingehen, wenn ich eine Frage hab. Mhm. Hab ich, also die, das hat natürlich auch Open AI kompatible Schnittstellen, wo ich meine IDI dranhänge. Aber wenn ich jetzt 'n Chat Interface haben möchte, dafür benutz ich dann Open Web UI, das ihr wahrscheinlich auch kennt.
Garrelt: Mhm. Mhm. Genau.
Christian: Und das find ich ziemlich cool und macht Spaß.
Fabi: Cool. Und wie ist so in der, also wie viel Prozent deiner AI Use Cases machst Du über diese dieses Modell und wie viel gehst Du an die cloud basierten Modelle?
Christian: 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 was da rauskommt und ich nicht wie unter soner Lawine begraben werden möchte.
Garrelt: Mhm.
Christian: Das heißt also, ich nutz das sozusagen eher als Sparringspartner für für Themen. Genau, und ich migriere so langsam rüber. Also ich hab natürlich so bestimmte Kontexte, die in mein in meinem gekauft bezahlten, in meiner bezahlten KI noch drin sind. Aber genau, also zunehmend migr ich, also wenn ich neue Sachen hab, mach ich das dann immer da drüben und find das eigentlich ganz gut. Ich hab jetzt einmal mir was übersetzen lassen, da hatt ich festgestellt, ah nee, da ist ChatGPT besser. Mhm. Also so, das war jetzt nicht schlecht, aber es war auch irgendwie son bisschen hölzern und rumpelig und da, genau. Aber damit spiel ich rum und das ist schön.
Garrelt: Hast Du, Du, was wäre denn 'n Weg, wenn Du sagst, Du willst jetzt noch 'n anderes Modell austesten und die Qualitätsvergleich sein? Hast Du da Evaluations oder ist das, machst Du 'n Gefühlstest, also 'n Promnyon?
Christian: Das wär eher 'n Gefühlstest, ja, genau. Also machen ja ganz viele andere Leute. Also da kann man sich ja schlau lesen. Da ist ja, jetzt ist auch Gwen 3 Punkt 6 rausgekommen, das
Garrelt: wohl auch
Christian: ziemlich geil ist. Ja. Genau, also da das hört ja nie auf und da kann man sich eigentlich immer ganz gut irgendwo schon mal so einlesen. Und ansonsten find ich am besten ist, ist es in der Praxis auszutesten. Also wie jetzt zum, also beim Coding war's okay, aber jetzt bei der Übersetzung dacht 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, so. Mhm. Ja.
Fabi: Interessant, dann schließe ich mich vielleicht an, weil's dazu passt und dir noch mal mehr Zeit gibt.
Garrelt: Ich hab was. Was passt noch dazu?
Fabi: Okay, perfekt. Dann sind wir in dem. Und zwar, es könnte jetzt ein Pick of the day sein, der die Kategorie war, man mich auch im Vorgespräch schon gescherzt. Früher hat der Dennis so Sachen gemacht wie Fahrradfahren als Pick of the day. Mein Pick of the day könnt ihr jetzt in diese Kategorie fallen? Bitte.
Garrelt: 'N Büro bauen.
Fabi: 'N Gartenbüro bauen. Nur weil ich das mache, ist das kein Pick of the day und empfehle ich nicht jedem. Nee, es geht in Richtung LLM und zwar son bisschen dieser Paradigmen, so wie man mit dem LLM interagiert. Ich hatte schon in einem der vergangenen mal Whisperflow als Tool genannt, grundsätzlich Sprache als Input für jedwede jedwede Dinge zu haben, aber hauptsächlich, mit LLMs zu interagieren. Mhm. Und ich merk grade bei uns in der Firma, dass schon wir sie und wir es, glaub ich, unterschiedlich nutzen, wie viel wir Sprachinput nutzen. Und mein Pick of the day wäre erst mal, schreibt nichts mehr an euer LLM, sondern sprecht ab jetzt einfach alles rein und schreibt auf gar keinen Fall mehr.
Garrelt: Und aber machst Du das auch im Office, zum großen
Fabi: Das und genau das ist der Punkt und ich und ich werde damit jetzt anfangen. Ich hab mich bisher in in irgendwie dann vielleicht in 'nem Einzelbüro eingeschlossen. Ja. Ich werde jetzt anfangen damit, das auch auf dem Floor zu machen mit meinem LLM zu reden.
Garrelt: Was ich super spannend finde, Whisperflow, ne, sagt der schon Whisper.
Fabi: Ja. Und
Garrelt: was die tatsächlich in ihrem Büro haben, es gibt 'n geiles Video von ihrem Arbeitsalltag. Die haben alle so Mikros mit so 'nem langen, ne, son Kabel sozusagen und dann haben die das so verbunden und flüstern da halt rein. Und das soll unfassbar gut funktionieren und das ist ihre Lösung im Großraumbüro, das zu müssen.
Fabi: Scheißen für die Stimme ist. Meine Frau ist Logopädin, Flüstern ist nicht geil. Okay, interessant. Aber ich meine, aber der andere der andere Punkt wär, also setzen Noise Cancelling auf, so.
Garrelt: Ja, okay, ich sag schon
Fabi: mal was davon.
Garrelt: Ja, okay.
Fabi: Aber also ich find wirklich, ich mein, aber das ist ja der eine, es gibt ja mehrere, ne. Du bist jetzt schon in 'nem Extrem, der nur fragt, machst Du's 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 da strukturieren. Ich kann da jetzt nicht einfach nur reinbrabbeln. Ja. Die Antwort ist, doch, Du kannst und mach das mehr und das ist wirklich, gibt noch mal 'n extremen Produktivitätsbus. Und auch selbst dieser Apartment, man gibt einfach anders 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 das funktioniert wirklich extrem gut auch so. Also zum Beispiel, ich hab mittlerweile son Use Case, dass ich eigentlich jegliche Dokumentation für unser Produkt komplett nur noch basiert überhaupt schreibe, das Ganze nur Sprachinput mache und selbst so Dinge sage wie, wir haben irgendwie Meetings und haben dann noch mal übers Feature drüber diskutiert, dann nutz ich die, die mittlerweile auch die, auch die Google Summarys von so Google Meets mittlerweile auf 'nem viel besseren Niveau, dass ich das wiederum als Input nehm und sag, okay, check jetzt mal, was macht meine aktuelle Doku? Was haben wir für andere Dinge besprochen? Guckt noch mal, ob wir an der Doku was anpassen müssen? Mhm. Und dieses Reinsprechen hat für mich meinen Arbeitsfloor auf jeden Fall noch mal stark verändert und würde auf jeden Fall Deswegen als mein nennen so, redet mit eurem Computer. Hört auf zu schreiben.
Christian: Guter Input.
Fabi: Die Frage, ist das jetzt wie Fahrradfahren?
Garrelt: Es es ist 'n Metapick, würd ich sagen, ne? Es ist jetzt kein Link. Du kann, mein Ich kann
Fabi: 'n Link, ich kann Link zu Whisperfloor, wo Du sagst.
Garrelt: Gibt's Whisperfloor hast Du schon mal. Ja, ist unfair.
Fabi: Okay, aber so, mein Thema passt auch dazu, oder?
Garrelt: Mein Thema passt eigentlich auch dazu, aber irgendwie, es ist auch eine RI Thema und ich find das schade. Irgendwie denk ich mir grad so, ich hab noch mal hart versucht nachzudenken, ob ich nicht 'n Performance Pick hab. Außer den Performance noch bei Chrome, aber weißt
Fabi: Du aus iPhone kaufen? Ja, einfach eine
Garrelt: aber mir fällt irgendwie nix ein, also nichts, was richtig Komm, hau raus.
Fabi: Ja, mach, wir sind, wir haben jetzt viel über nicht, wir haben jetzt eine Stunde 15 über ihr Ei geredet.
Christian: So, dann komm. Ja. Wir
Garrelt: sind unter uns. Ja. Also
Fabi: doch oder was? Ey, mach doch dann eine Eye Pic. Also besser als Du
Garrelt: willst noch irgendwas hier. Also ich sag mal, ein einen Pic wär sonst gewesen. Einfach auch, mal Shoutouts an Grisha rauszuhauen. Das ist 'n Mitarbeiter bei uns Chef für dich, der das wahrscheinlich nicht weiß, der auch, also diese mitentwickelt hat. Und das ist die 3JS library in Svedald. Und Svedald ist ja, sag ich mal, vielleicht siehst Du das ähnlich von den Frame. Es gibt am ehesten das, was noch performance nativ ist sozusagen. Also sie achten da zumindest sehr viel und threllt das sozusagen ja, 3D fürs Welt. Und da das ja immer mehr Thema ist so und immer mehr Animationen auch momentan in 3D sind, glaub ich, ist das eine ganz coole Schnittstelle, Wenn man was im Web baut und es aber vielleicht auch sehr animationslastig ist, dann ist bestimmt eine gute Anlaufstelle. Genau. Und Du guckst grad schon.
Fabi: Genau, da können wir direkt packen, wenn ich schon uns mit Deep Dive Nummer 163 war über Threlt, mit Grisha, von daher.
Garrelt: Ja, komm, ich nehm den jetzt einfach. Das, es passt son bisschen mehr. Dann nehm ich den
Christian: ist gut. Svelt kommt ja auch aus der Datenvisualisierung. Also
Fabi: Ja, stimmt.
Christian: Ja, es wurd ja für die New York Times immer entwickelt, dann sozusagen interaktive Grafiken zeigen. Und da ist es ja wirklich richtig stark drin, ne. Ja. Richtig. Ja.
Garrelt: Dann heb ich mir den einfach den anderen für einfach nix mehr auf. Da musst Du auch nix mehr nicht mehr suchen.
Fabi: Ja, perfekt. Dann, wenn Du's für dich bis dahin dran erinnern kannst, schreib's dir lieber jetzt auf. Ansonsten gibt's noch zu sagen, schreib vielen, vielen Dank, dass Du dir die Zeit genommen hast. Das hat sehr viel Spaß gemacht.
Christian: Gerne.
Fabi: Schön, dass Du da warst.
Garrelt: Hat sehr viel Spaß gemacht, ja.
Christian: Fand ich auch. Danke für die Einladung.
Fabi: Sehr gerne. Und wir euch immer vielen Dank fürs Zuhören. Wie immer gerne Feedback an Podcast at Programmier Punkt 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, aber Ja,
Christian: da muss ich mal reinspringen.
Fabi: Ich E-Mail immer sehr, sehr gerne. Ich freu mich immer sehr. Hast Du letztens gesehen, an der letzten 4
Garrelt: Feedback E-Mail gab's einen, was
Fabi: sie hörte auch mit Hashtag, Garelt Mog rockt.
Garrelt: Ja, das ist das was Highlight.
Christian: Hast Du
Fabi: das, ist das was Du ins Spiel gebracht hast? Ich weiß es nicht. Hab mich das hab mich dann gepackt. Also hat er sich das selbst ausgedacht, oder?
Garrelt: Ich, also Dave und ich haben uns auch gefragt, ob wir das in der in der in der News Folge gesagt haben, aber ich glaube nicht.
Fabi: Also vielleicht können wir das ab jetzt irgendwie mal son bisschen bisschen einführen. Ich muss sagen, Garet Mock rockt als als Hashtag find ich sehr, sehr
Garrelt: gut und da
Fabi: ein Shoutout an Dennis Lugowski, der hat die E-Mail geschrieben. Vielen Dank dafür.
Garrelt: Vielleicht sogar mein Week. Vielleicht sogar mehr. Also mal gucken, was noch kommt. Aber ich hab mich sehr gefreut.
Fabi: Hab jetzt gerne jede E-Mail mit Hashtag aufhören und auch jeden Post, den ihr irgendwo anders in Social Media macht.
Garrelt: Ja oder ich finde, wir können das schon auf alle unsere Podcasts übertragen, oder? Vielleicht machen wir auch 'n T-Shirt, hab ich hab ich. Das das ist 'n Zungenbrecher.
Fabi: Ja, das ist ja auch insofern fein, dass ich ja auch knapp an dem Namen Fabi vorbeigeschlittert bin.
Garrelt: Ja, ich glaub, das ist jetzt, steckt in mir drin jetzt, dass Du mal
Christian: so gefährlicher Zungenbrecher, ja.
Fabi: Ja, aber mein, also muss das, Herr Chef, Du weißt ja, aber mein Opa hieß früher wirklich, als sie nach Deutschland kamen, haben sie sich umbenannt entfinkt, weil sie gemerkt haben, ah ja, mit auch noch c k ist vielleicht nicht der beste Name in Deutschland.
Christian: Ja. Ja, okay, ja.
Garrelt: Ist das 'n geiler Funfact für die, die noch ist, jetzt zum Ende. Ja, genau.
Fabi: Also sie haben schon dreimal tschüss gesagt, also noch mal tschüss wie immer Feedback, ne und so weiter. Hashtag Garat Mogrockt. Danke euch. Jeff, vielen Dank. Macht's gut. Tschau. Tschau. Tschüs.

Web Performance mit Christian Schaefer

Shownotes

Picks of the Day

Threlte – performantes 3D in Svelte

Wispr Flow

Speaker Info

Christian Schaefer