Browser DevTools Vocabulary

The time from the browser sending an HTTP request until it receives the first byte of the response — a key server performance indicator that includes DNS lookup, TCP connection, TLS handshake, and server processing time.

"Our checkout page had a TTFB of 2.3s — profiling showed the server was doing a synchronous database call. Caching the product catalog reduced TTFB to 180ms."

A visualisation in the browser Performance panel where the x-axis shows time and the y-axis shows the call stack — functions appear as horizontal bars, and the height indicates nesting depth. Wider bars mean longer execution.

"The flame chart showed a 400ms wide bar for our custom serialiser function, indicating it was blocking the main thread on every render. Refactoring to async processing eliminated the jank."

Any JavaScript task that blocks the browser's main thread for more than 50ms — degrading responsiveness and increasing INP (Interaction to Next Paint). Visible as red-highlighted bars in the Performance panel.

"The Performance panel flagged a 340ms long task caused by our route-change event handler synchronously computing report statistics. Moving to a Web Worker dropped the task below 50ms."

In a heap snapshot, the total memory that would be freed if the object and all objects it exclusively references were garbage collected — the true cost of holding a reference.

"The cache object had a shallow size of 48 bytes but a retained size of 42MB — it was holding references to thousands of old DOM nodes. Clearing the cache freed the expected memory."

Time spent waiting before a network request can begin — caused by the browser's connection limit (6 per origin), waiting for an existing connection to be available, or proxy negotiation.

"The waterfall showed 12 of our API requests spent 800ms stalled — caused by HTTP/1.1's 6-connection limit. Switching to HTTP/2 multiplexing eliminated the stall time entirely."

A Chrome DevTools panel that shows which bytes of loaded JavaScript and CSS were actually executed or applied during a page session — identifying unused code opportunities for tree-shaking.

"The Coverage panel showed 68% of our main bundle was unused on the landing page. Code-splitting and lazy-loading the dashboard routes reduced the landing page JS by 187KB."

A Core Web Vitals metric measuring how much page content unexpectedly moves during loading — calculated as the sum of all individual layout shift scores. Good CLS is below 0.1.

"Our hero image caused a CLS of 0.34 — it loaded after the text, pushing the CTA button 200px down. Adding explicit width and height attributes eliminated the layout shift."

The source that caused a network request — a script file and line number, an HTML element, or a browser-internal action. Used to trace which part of code is making unexpected requests.

"The Initiator column showed our analytics library was responsible for 47 requests to third-party domains — something the team hadn't noticed. Switching to a self-hosted alternative removed the requests."

A DevTools overlay that highlights in green which areas of the page are being repainted on each frame — used to identify excessive or unexpected repaints that degrade scroll performance.

"Paint flashing revealed the entire background layer was repainting on every scroll event because our parallax CSS used top instead of transform. Switching to will-change: transform isolated the compositing layer."

A condition where memory that is no longer needed is not released, causing the heap to grow continuously over time. Detectable in DevTools by comparing heap snapshots taken at intervals.

"Three heap snapshots taken 30 seconds apart showed the heap growing from 24MB to 89MB with no user interaction — a detached DOM subtree held by a closure in our infinite scroll event listener."