Search results "performance"

Your code runs perfectly on ten items and stutters on ten thousand - even though not a single line changed. Big-O doesn't tell you "how fast," only "how the cost grows as the amount of data grows." How to spot the shape of that growth in everyday frontend code - and how to turn a loop inside a loop into something that doesn't slow down on large data.

The same server response can sit in several caches at once - app memory, the Service Worker, the HTTP cache, the CDN - and the whole page is held by bfcache on top of that. Each has a different owner and something different clears it, so "clear cache" hits one of them, sometimes none. What's left is the question every such debugging session starts with: which layer is holding the stale copy, and what invalidates it.

Turn off the internet, refresh the page - and it still works. Behind that is the Service Worker: a separate script that steps between the page and the network and intercepts every request for a file before it reaches the server. It decides whether to answer from the network, from its own cache (Cache API), or on its own terms - and from that one decision come all the caching strategies, offline mode, and the classic 'after a deploy the user sees the old version' trap.

Take a single style.css file and follow its day on a live site: first the browser downloads it, then it serves it from memory without asking the server, then it asks the server whether its copy is still current and usually gets just a confirmation instead of the whole file, and after you deploy a new version it downloads it again. That one story is all of HTTP caching - Cache-Control, ETag, 304, and stale-while-revalidate.

Every DOM element goes through five stages before you see it, regardless of the framework. Some styles trigger only the last stage; others trigger all five. That's the difference in animation cost - from a single composite step to a full reflow.