Page 13 - Web Performance

A tab in the background keeps running unchanged in most applications, polling intervals fire, animations run, videos play unheard. The Page Visibility API provides a reliable signal through document.hidden and the visibilitychange event, letting you throttle exactly this background work and noticeably save CPU, battery and network, without the user ever noticing.

Memory leaks in JavaScript rarely happen by accident, they happen because of strong references that keep objects pinned to the heap even though the code no longer needs them. WeakRef and FinalizationRegistry are the official JavaScript APIs for cooperating with the garbage collector and releasing resources cleanly, without undermining the foundation of automatic memory management.

Classic Tailwind CSS produced stylesheets of 3 MB and more during development. The JIT compiler solves this problem at its root: it scans template files in real time, generates only the classes that are actually needed on demand, and makes arbitrary values like [clamp(1rem,5vw,3rem)] work without any configuration.

Vite revolutionizes the dev server with native ESM, Webpack remains the heavyweight for complex enterprise setups, and Rollup produces the cleanest library bundles. Pick the wrong bundler and you lose development speed, build performance, or bundle quality: this comparison shows which tool is the right choice for which scenario in 2026.

Memory leaks in JavaScript applications are invisible, until the browser crashes or the page noticeably slows down after a few minutes. Heap snapshots, allocation timelines and the retainer graph in Chrome DevTools make invisible memory leaks visible, locatable and fixable.

map(), filter(), take(), drop() and reduce() now exist directly on iterators, with lazy evaluation instead of full materialization into an array.

Largest Contentful Paint is widely regarded as the most important of the three Core Web Vitals for perceived load speed, yet in practice it often gets approached wrong, with teams generically trying to make the entire page faster. The first necessary step is identifying the actual LCP element on a page, which is often not the element you would intuitively expect. The second step is breaking the LCP time down into its four phases, TTFB, Load Delay, Load Time, and Render Delay, and optimizing each phase specifically and individually, instead of chasing a diffuse improvement of the total time.

On multi-core servers, network card interrupts without deliberate IRQ affinity often all land on the same CPU core, while the remaining cores stay uninvolved. Under high packet rates, that one core becomes a bottleneck long before the server's overall CPU utilization is anywhere near exhausted.

Read/write splitting routes writes to a single primary server and reads to several replicas in order to scale the database layer horizontally. In PHP that concretely means a connection routing layer that picks the right connection depending on the query type, and a deliberate way of handling replication lag so users do not suddenly see stale data right after a write.

Multiple web workers sharing the same SharedArrayBuffer need a way to wait on each other without constantly polling in a loop. Atomics.wait() provides exactly that, but blocks the entire thread and is therefore forbidden on the main thread. Atomics.waitAsync() solves the same problem non-blockingly, working even where blocking simply isn't an option.