- Dankeschön - präsentieren zu dürfen - Zeit, in Präsenz - Titel - Performance-Unterschiede in Endprodukten

1. Thema einführen + Tiefe 2. Fragestellung für heute 3. Strategien zur Beantwortung + erklärende Worte zu Design 4. wichtige Ergebnisse: graphisch + Zahlen für Interpretation 5. 5 Minuten Lessons Learned für weitere Arbeiten <PAUSE>

- gefundene Definition - moderne Webseiten - other factors -> JS - statisch und dynamisch - Komplexität - Vorhersehbarkeit der Performance - Diagram - dynamische: +Nutzer, +Netzwerk, +Services (Backend, DB, APIs) - viele Faktoren - Probleme -> langsamster Pfad

- Für Entwickler schwieriger - Pfad rechts aufwendig - Pfad links fast unmöglich - Hoffnung: Foren für gewähltes Framework - -> Frage nach bestem Framework

Oder anders formuliert: <VORLESEN> - 3 Aspekte herausstellen

1. Framework 1. Entwicklungs-Framework 2. nicht einfach & gut konfigurierbar, sondern as is

2. für den Nutzer merklichen Einfluss 1. unterschiedlich 2. technisch vs wahrgenommen 3. Zeiten unter 30ms ignorieren

3. Render-Geschwindigkeit 1. viel Facetten -> Tendenzen 2. Beispiel: schnelle erste Änderung, späte letzte Änderung <PAUSE>

- Versuch der Antwort -> 6 Dimensionen eingegrenzt 1. Frameworks 2. Anwendung: Bündelung, wiederverwendbare Ressourcen 3. Network Delay -> Hosting-Umgebung 4. Metriken beschreiben Untersuchungs-Gegenstand 5. Werkzeuge: Overhead -> -Performance 6. Browser

FRAMEWORKS: - CSR und SSR vorlesen - Big 3 - Liebling Astro - Wahl: - vergangene Nutzung - Bereitschaft zu Nutzung - Neigung unter Entwicklern mit Erfahrung im Framework - Bewusst CSR UND SSR

- Vergleich bedarf gleicher Umstände - sonst max. 2 Frameworks - Nachbildung der App Instagram - 4 Seiten - Delayed vs statisch - Create: Spezialfall -> Dynamisch - Komponenten: Wrapper und Funktionen - Möglichkeit für un-konfigurierte Performanceoptimierung

HOSTING: 1. Anbieter 1. Realistische Netzwerkverzögerung + Serverauslastung 2. SSR-Funktionen 3. kostenlos -> kleine Projekte 4. Github + Github Actions 5. Verbreitet 6. Mit Netzwerkanfragen untersucht 2. Localhost 1. ohne Netzwerkverzögerung 2. Preview oder serve 3. Baseline für Browser-Prozesse

METRIKEN: - 3 Kategorien - PLT - klassische PLT - requeststart bis DomContentLoaded - CLT - Prozesse im Browser ohne... - Netzwerk - Serveraktivitäten (SSR) - Baseline für Browserprozesse - Component Update Time - Reaktion auf Eingaben - Nutzereingaben - Websocket Nachrichten - nach PLT und CLT

- Kategorien zuweisen (nur PLT) 1. TBW: Netzwerk-Bytes 2. TTFB: requestStart bis erstes Antwortbyte 3. DomContentLoaded: requestStart bis DOM geladen 4. LVC: letzte sichtbare Änderung im Viewport 5. LCP: Renderzeit des größten Element im Viewport -> empfundene Ladezeit

1. TTI: requestStart bis DOM "interactive" 2. TBT: von Nutzereingaben abgehalten (Code / Parsing) 3. LoadEventEnd: requestStart bis OnLoad des DOM 4. OFVC und OLVC: requestStart bis visuelle Änderung im Viewport 5. DOM Mutations 1. nicht bekannt 2. im HTML Root-Element pro Framework 3. Laden und User Input

1. erste Station Lighthouse 1. Sammlung an Metriken 2. CLI: Automatisierung 3. techn. mögl.: andere Browser 4. Google Produkt -> Headless Google Chrome 2. Playwright 1. prim. Content & Interaktionen 2. Custom Skripte im Browserfenster 3. Black Box mögl. -> Unabhängig von Entwicklung 4. Browserwahl

- Lighthouse: - Aggregat - Playwright: - Window-Kontext - Custom

BROWSERS: - Lighthouse nur Google Chrome - Playwright Wahl nach Verbreitung <VORLESEN> <PAUSE>

- Erkenntnisse vorwegnehmen -> richtige Augen 1. PLT und CLT unschlüssig für Frage 1. Stärken und Schwächen 2. undeutliche Bestlösung (CSR vs SSR) 2. CUT 1. Tendenzen in Spannweite & Zeiten vom DOM Mutations 1. Browser 2. Frameworks

- lokal besser (nicht überraschend) - Ausreißer: - Create & Profile: Astro - Feed: Angular, Next.js, Nuxt

- große Diff. unter Framework - gut: Next.js, Astro, Svelte - schlecht - Feed: Angular, Vue.js - generell, Nuxt

- lokal schlechter (!!!) - gut: Astro - schlecht: Nuxt - Abhängig v. Host & Seite: React und Svelte

- lokal gut - gut: React und Vue.js - schlecht: Astro - statisch besser

- Ausreißer: Astro & Svelte in Firefox

- unerfindlicher Grund: requestStart spät in Firefox - Lösung: balanced loadEventEnd <Formel>

Alte Messwerte

Angeglichenen Werte - einziger Unterscheid: Firefox - Rest: - schlecht: - Angular - Chromium, Mobile Chrome, Microsoft Edge, Google Chrome - Astro - Desktop Safari, Mobile Safari

1. starke Ausreißer von Nuxt auf der Feed 2. Profile: Chained Async Funktionen.

- Outlier, aber lokal deutlich besser - in OLVC nicht sichtbar - interessant: Unterschied

- OFCV und OLVC beinhalten Netzwerkzeiten - dazwischen Render-Geschwindigkeit im Browser Gleichung

OLVC

OVCD - hat nicht viel gebracht - OFVC relativ kurz - Idee kann verbessert werden

- Laden & Updaten der Seite - CLT und CUT

1. Injection 2. Intervall 3. loadtimes 4. MutationObserver 5. DOM Mutation (id, xpath, Zeit -> Window-Kontext)

1. Seiten Laden 1. 10 Sekunden warten 2. Auswerten 2. User Interaction 1. gleicher Prozess 2. Reset 3. Interaktion 4. Warten

Ergebnis: 1. schlechter: Next.js, Svelte 2. Unterschiede in Browsern 3. Aufzeichnungen fehlen 1. Frameworks fehlen 2. Grenze bei 100 ms

- 2 Aufzeichnungsgrenzen (Init & Ende) - 100 ms Intervall für Erkennung Root Element - 10 Sekunden bis Ende - Fehlend: - direkt nach Ladebeginn - länger als 10 Sekunden

- 4 User Actions: Formular -> Vorschau - Caption - Dropdown - URL - Caption + Dropdown

1. gut: Nuxt (max. 200 unabhängig vom Browser) 2. langsam: Next.js (Firefox, Mobile Safari, Desktop Safari) 3. schnell: 1. Chromium, Mobile Chrome, Google Chrome, ME 2. Render-Engine Blink <PAUSE>

- Min., Max., Durchschnitt - rot: schlechteste Werte - langsamste Browser - gut: Nuxt (Ausnahmen) - schlecht: Next.js (Ausnahmen)

- ähnlich - mittlere Plätze umkämpft / Framework ungefähr gleich

- schnellste Browser: ME, Google Chrome - grün: schnellste Werte - Astro war schon schlechtester Minimalwert

- Durchschnitt -> Ranking - Rein: - 1: Nuxt - 2: Angular - 3: Vue.js, React - 5: Astro, Svelte - 7: Nex.js - Weighted nach Nutzungsquote - 1: Nuxt - 2: Angular, Vue.js - 4: React, Astro - 6: Svelte - 7: Next.js

Rankings: <VORLESEN>

- Zusammenfassung - kritische Worte zu - Ergebnissen - Herangehensweise - Test-Ansätze zu DOM Mutations

- Ergebnisse nicht ausreichen zu Antwort in PLT und CLT - CUT: Tendenzen zu Performance-Unterschied - Frameworks: Ø 69 - 107 ms - Browsers: Ø 62 - 164 ms - größerer Unterschied erhofft und erwartet

- Lücken in meiner Forschung - Lighthouse schwankt um 30% - Verteilung interessanter - Mehr Datenpunkte - Seiten & -arten - Komponenten & -funktionen - Hosting Möglichkeiten - Test Runs & zu Tageszeiten für Network Delay

- Verbesserungsmöglichkeiten 1. fehlende Aufzeichnungen 1. Black-Box vergessen -> White-Box 2. Events am Anfang und Ende von Änderungen 1. Initialisierung signalisieren 2. Ende von State-Change signalisieren 2. Navigation zwischen Seiten <PAUSE>

- Vorbereitete Antworten - gerne unvorbereitete Antworten geben

- Hosting irrelevant - schlecht: Astro, Next.js

- lokal schlechter - schlecht: Angular und Next.js