How to Debug a Slow Website: Read the Waterfall Chart in the Right Order

Your site is slow, and the internet's advice is to install a caching plugin and compress your images. That advice will cost you a weekend of guesswork. Open your browser's Network panel instead — the waterfall chart already knows exactly which request is eating your time. You just have to read it in the right order.

Debugging performance is a diagnosis problem, not a fix problem. Most slow sites have one culprit, not twelve. The fixes people try first — cache plugins, image compression, a new host — are applied before anyone knows whether the bottleneck is the server or the browser. This is the order that finds the culprit in about five minutes.

1. Start with a number, not a feeling

"It feels slow on my phone" is not a diagnosis. Your phone, your connection, and your cached resources make you the worst possible test subject. Run the page through Lighthouse (it's built into DevTools — Ctrl+Shift+I, then the Lighthouse tab) or PageSpeed Insights, and write down the actual numbers.

Then check what your real users see. Google's Chrome User Experience Report (CrUX) publishes real-user Core Web Vitals data for pages with enough traffic, and it's the field data Google actually uses as a ranking factor. PageSpeed Insights shows both lab and field numbers side by side. If the two disagree, trust the field — your users don't browse on your laptop with your cache.

The thresholds that matter: Largest Contentful Paint is "poor" past 4 seconds. Interaction to Next Paint — how long your slowest click, tap, or keypress takes to show a result — is good at 200ms or less and poor past 500ms, per DebugBear's scoring guide. And the stakes are real: the BBC found it lost an additional 10% of users for every extra second of load, while Rakuten 24's performance work raised revenue per visitor by 53.37% (both via web.dev).

Now you have the number you're trying to move. Open DevTools.

2. Read the waterfall: the first bar splits every diagnosis in two

Go to the Network tab, check Disable cache — this makes you a first-time visitor instead of someone with a warm browser cache — and reload. Click the Time column to sort the slowest requests to the top.

Now look at the first request: the HTML document itself. Select it and open the Timing tab. The number that matters is "Waiting" — Time to First Byte (TTFB), the time between the request going out and the first byte coming back. That number is entirely the server's time. Nothing in the browser had any say in it.

This one read splits your diagnosis in two:

• TTFB dominates the load time — the first bar is where the seconds live. The problem is server-side.
• TTFB is short and everything after it is long — the server answered fast, then the browser spent the rest of the time downloading and processing. The problem is front-end.

That's the trick most debugging guides skip. They hand you twenty possible causes; this tells you which half of the stack to ignore before you spend a single minute on fixes.

3. If the first bar is slow, it's the server

A slow TTFB means something between your server and your database is working too hard, or something is needlessly in the way. The mechanical checks, in order:

• Compare cached vs. uncached. Load the page logged out (or in an incognito window) and logged in. If logged-out is fast and logged-in is slow, your page cache works fine and the uncached path is the problem — usually a slow query on the personalized path.
• Check the distance. If TTFB is high for everyone and there's no cache between the server and the user, the server may just be far away. This is the CDN-shaped problem.
• Look at the application. DevTools can't see inside your server, but your slow-query log and application profiler can. The single most common server-side cause on CMS-backed sites is a pile of database queries on every page load — something you confirm in a profiler, not by guessing.

The discipline here is what not to do: don't compress images or minify JavaScript while TTFB is the problem. None of that touches the first bar. You'd be polishing the browser while the server wheezes.

4. If everything after the first bar is slow, it's the front end

Now the waterfall is your crime scene. Work the suspects in this order.

Render-blocking resources. CSS in your <head> pauses rendering until it's downloaded and processed. JavaScript in the <head> is worse — it's parser-blocking by default, halting the HTML parser entirely, because the browser can't know whether the script will rewrite the page until it runs (Google's web.dev explains the distinction in its critical-path module). Run Lighthouse's "Eliminate render-blocking resources" audit — it only flags resources that actually delay rendering, so you won't chase false positives — or open the same URL in WebPageTest, which marks render-blocking resources with an orange circle in the waterfall.

Fat files. Type larger-than:500 in the Network filter box to surface everything over 500KB. Uncompressed images and bundled JavaScript are the classics. Sort by Size and ask whether each large file earns its bytes on first load. Note what web.dev's course quietly points out: images and fonts don't even block the initial render, so they're pure weight — weight you can defer.

Third-party scripts. Analytics, chat widgets, ad tags, social embeds — each one is someone else's code on your critical path. Here's the fastest test in the toolbox: right-click the suspect request, choose Block request URL, and hard-reload. If the page suddenly flies, you've found your culprit. Then lazy-load it, defer it, or ask whether you need it at all. This one experiment has settled more performance arguments than any amount of theorizing.

One more DevTools trick while you're here: enable Capture screenshots in the Network panel settings and reload. You'll get filmstrip frames showing exactly what the user saw while each bar was loading — which ties the numbers to the actual experience. A page that shows content at 2 seconds and finishes at 8 feels very different from one that's blank until 7.

The "but Lighthouse is green" objection

Lab tests are best-case: a fast connection, a powerful machine, a cold start. Your users are on mid-range phones, congested networks, and warm caches that hide some problems while exposing others. That's why the CrUX field data matters — it aggregates what real users experienced over the last month, and it's the number Google judges you by.

If you have real-user monitoring (RUM) — even a basic analytics snippet — you get something lab tests can't give you: which specific users are suffering. A slow page for everyone is a code problem; a slow page only on low-end Android devices is a weight problem. The fix depends on the answer.

The checklist

1. Get two numbers: Lighthouse (lab) and CrUX via PageSpeed Insights (field). Trust the field when they disagree.
2. Network tab, Disable cache on, reload, sort by Time.
3. Read the first request's Waiting time (TTFB). Slow → server. Fast → front end.
4. Front end: render-blocking audit, then larger-than: filter, then Block-request-URL tests on third parties.
5. Fix exactly one thing. Re-run the waterfall. That's your before-and-after.

Your site isn't slow everywhere. It's slow in one place, and the waterfall chart was pointing at it the whole time.

References

• Why does speed matter? — web.dev (Google)
• Understand the critical path — web.dev (Google)
• Network features reference — Chrome DevTools
• Measure and Optimize Google Core Web Vitals — DebugBear