"Why is this page slow to load?" is a question you answer by reading data, not by guessing. This lesson covers the waterfall chart, the numbers you can pull in code, the exact thresholds Google checks, and the fixes, resource hints and image techniques, that turn a diagnosis into a real improvement.

Reading a waterfall

Picture a relay race where each runner has to wait for the one before them to finish, even on legs that could have run side by side. DevTools' Network tab draws exactly that: every request as a horizontal bar, split into phases, Queued → Stalled → DNS Lookup → Initial Connection → SSL → Request Sent → Waiting (TTFB) → Content Download.

Three patterns to look for, in order of how often they're the real problem.

A long Stalled bar across many requests at once usually means the browser is holding requests back because it already has too many open connections to the same server. HTTP/2 mostly fixes this by letting many requests share one connection, check the Protocol column to confirm.

A long TTFB, time to first byte, on the very first document request points at the server: a cold start, a slow backend, or missing caching. This is not a frontend problem, and nothing on the page can render until this finishes.

A "staircase," where request B doesn't start until request A finishes even though nothing forced that, usually means one thing was only discovered after reading another: the HTML finds the CSS, the CSS finds a font, the JS then goes and fetches data. Every step like this costs one full round trip.

Remember: a long TTFB is a server problem. A "staircase" shape is a discovery-order problem. Different symptoms, different fixes.

Measuring it in code with the Performance API

The Performance API gives you the exact same numbers the waterfall draws, but as data you can read in code and send to your own monitoring.

The three Core Web Vitals get watched with a PerformanceObserver:

Each of the three measures a different thing. LCP (Largest Contentful Paint) is how fast the page feels like it loaded. INP (Interaction to Next Paint) is how quickly the page responds when you click or type. CLS (Cumulative Layout Shift) is how much content jumps around while loading. They matter to your job for a concrete reason: Google uses all three as a search-ranking signal, and they're the closest thing we have to a number for "did this feel good to use."

Remember: LCP is load speed, INP is responsiveness, CLS is visual stability. Three different questions, three different fixes.

The exact thresholds, and why two tools can disagree

Field data comes from real visitors' actual devices and networks (via CrUX, PageSpeed Insights, Search Console), and it's what Google actually uses for ranking. Lab data comes from a tool like Lighthouse or WebPageTest, running against one simulated device and network. Lab data is useful for diagnosing a problem, but it's not the real thing, it can't capture how a real mid-range phone on patchy 4G actually experiences your page. That's exactly how a page passes Lighthouse cleanly and still fails its real Core Web Vitals in the field.

Remember: lab data diagnoses. Field data is what actually gets scored.

How real apps actually ship this data

Calling PerformanceObserver yourself is what these metrics run on underneath, but production monitoring code uses Google's web-vitals npm package instead of reimplementing each metric's rules by hand, because those rules have real edge cases: LCP's "biggest element so far" can change as content keeps loading in, and CLS groups nearby shifts together into windows.

Why check sendBeacon first, not fetch? CLS and LCP often only finalize the instant a user navigates away. A normal fetch() call fired during that moment can get killed mid-flight the second the tab closes, silently losing the data. navigator.sendBeacon(url, data) exists specifically for this: the browser promises to send it even if the page is already gone. It's fire-and-forget, always a POST, and capped around 64KB, plenty for a small metrics message. fetch(..., { keepalive: true }) is the backup for browsers without sendBeacon.

Fixing a slow INP in React usually means reaching for patterns you already know: React.memo/useMemo/useCallback to stop unnecessary re-renders, startTransition to let React deprioritize an expensive update so typing and clicking still feel instant, and list virtualization (a later lesson) to avoid mounting hundreds of DOM nodes at once. For one genuinely long, unavoidable synchronous task, parsing a huge payload, sorting a massive array, scheduler.yield() hands control back to the browser between chunks so it can still respond to a click mid-task.

Remember: sendBeacon for data fired on unload, fetch for everything else where you need to read the response.

preload versus prefetch

Both tell the browser about a resource before it would normally find it on its own, but they carry different urgency.

preload competes with this page's own critical resources for bandwidth, which is exactly how candidates accidentally slow a page down by preloading too much of it. prefetch is low-priority and safe to use more freely, though it's wasted bandwidth the moment the guess about the "next page" turns out wrong.

Remember: preload says "I need this now." Prefetch says "I might need this soon, whenever there's time to spare."

Images: still the biggest payload on most pages

loading="lazy" skips downloading offscreen images until they're close to the viewport, natively, with no JavaScript needed. Setting width/height (or aspect-ratio in CSS) lets the browser reserve the right amount of space before the image even loads, which directly fixes the layout-shift bug CLS measures. AVIF and WebP run 25 to 50 percent smaller than JPEG or PNG at the same visual quality. srcset/sizes stop a 2000px image from being sent to a 400px-wide phone screen.

Remember: setting width and height on an image is a CLS fix, not just a layout nicety, it lets the browser reserve the image's space before it's even downloaded.