Seite 7 - Web Performance

Wachsender Speicherverbrauch, träge Interaktionen und Browser-Tabs, die nach Stunden abstürzen: JavaScript-Anwendungen mit langlebigen Seiten leiden häufig unter Memory Leaks, die sich erst mit der Zeit bemerkbar machen. Dieser Artikel zeigt die häufigsten Leak-Quellen, den praktischen Umgang mit Heap Snapshots in den Chrome DevTools und einen Schritt für Schritt Debugging-Workflow, mit dem sich Lecks zuverlässig lokalisieren und beheben lassen.

Wenn Requests plotzlich haengen, obwohl die CPU-Auslastung niedrig bleibt, steckt oft Lock Contention dahinter. Mit performance_schema in MySQL und pg_locks in PostgreSQL laesst sich Lock Contention systematisch diagnostizieren, statt bei jedem Vorfall aufs Neue zu raten, welche Session welche andere blockiert.

Mehrere Web Worker, die sich denselben SharedArrayBuffer teilen, brauchen eine Art, aufeinander zu warten, ohne staendig in einer Schleife zu pollen. Atomics.wait() bietet genau das, blockiert dabei aber den kompletten Thread und ist deshalb im Main Thread verboten. Atomics.waitAsync() loest dasselbe Problem non-blockierend und funktioniert dadurch auch dort, wo Blockieren keine Option ist.

Naive Entity-Iteration über Millionen Datensätze führt zuverlässig in ein Memory-Limit, weil der UnitOfWork jede geladene Entity im Speicher hält. EntityManager::clear(), toIterable() und Bulk-DQL-Updates lösen dieses Problem, jeweils mit eigenen Kompromissen.

Die Alpine.js Bundle Größe wirkt auf den ersten Blick unbedeutend klein, doch sobald Plugins, die CSP Build Variante und mehrere Komponenten Bibliotheken zusammenkommen, entscheidet die genaue Zusammensetzung über spürbare Unterschiede bei Ladezeit und Time to Interactive. Wer die Kilobyte Werte und die CSP Tradeoffs kennt, trifft bewusste statt zufällige Entscheidungen beim Bundle Aufbau.

Die meisten Webanwendungen lesen deutlich häufiger aus der Datenbank, als sie schreiben, wodurch der Primary-Server oft zum Flaschenhals wird, obwohl Schreibzugriffe nur einen kleinen Teil der Last ausmachen. Read-Replicas verteilen Lesezugriffe auf zusätzliche Server-Kopien und entlasten so den Primary spürbar.

Die Edge Runtime verspricht minimale Kaltstartzeiten und globale Verteilung, verzichtet dafür aber auf zentrale Node-APIs. Die Node Runtime bietet volle Kompatibilität, kostet aber Latenz bei global verteilten Nutzern. Wer pro Route bewusst entscheidet, holt aus beiden Modellen das Beste heraus.

Ein Dashboard, das gleichzeitig Nutzerdaten, Bestellhistorie und Produktempfehlungen lädt, feuert ohne Batching drei separate HTTP-Requests mit jeweils eigenem TLS-Handshake und eigener Latenz ab. GraphQL Batching bündelt solche unabhängigen Operationen in einem einzigen HTTP-Request und reduziert damit die Anzahl der Roundtrips, ohne das Schema oder die Resolver-Logik zu verändern.

Static Site Generation, Incremental Static Regeneration und Prerendering-Services versprechen schnelle, cachefreundliche Shop-Seiten, bringen aber eine eigene Build-Pipeline mit Artifact-Stores, Rebuild-Fenstern und separater Cache-Invalidierung mit. Dieser Artikel zeigt technisch genau, wo Magento mit Hyvä, Varnish Full Page Cache und ESI-gestützten dynamischen Inseln dieselben Vorteile schon ohne diese zusätzliche Komplexität liefert, und wann ein Hybrid-Ansatz trotzdem gerechtfertigt ist.

Jahrelang war eine Transition von oder zu einem auto-Wert in CSS schlicht nicht möglich, weil der Browser keinen numerischen Zwischenwert für auto berechnen konnte. Mit calc-size() und der Eigenschaft interpolate-size ändert sich das grundlegend: Der Browser darf jetzt selbst einen numerischen Anfangs- oder Endwert für auto ermitteln und dazwischen sauber animieren, ganz ohne JavaScript-Messungen oder feste Pixelwerte.