When a page feels slow, it’s rarely “the internet” in general—it’s usually a few specific requests taking too long, blocking rendering, or downloading way more than they should. Firefox’s Network Monitor is one of the fastest ways to see that clearly.
Here’s how to read it without getting lost in tabs and jargon.
What the Network Monitor is actually showing (in plain terms)
The Network Monitor is a timeline and ledger of everything the page asks for: HTML, CSS, JavaScript, images, fonts, API calls, ads, analytics, and more.
Each row is one request. The columns tell you what it was, how big it was, how long it took, and what happened along the way.
- Name: the file or endpoint (often the most useful starting clue).
- Status: HTTP code (200, 304, 404, 500, etc.).
- Type: document, script, stylesheet, image, font, XHR/fetch.
- Transferred / Size: what actually downloaded vs the resource’s uncompressed size.
- Time: total duration for that request.
Think of it like a receipt: what you “bought,” what it cost, and where the time went.
Open it the quick way (and capture the right moment)
In Firefox, open DevTools and go to Network. Then reload the page so the panel captures a clean run.
- Open DevTools (menu or shortcut), then click Network.
- Check Disable cache if you want to see a first-visit experience (more realistic for new users).
- Reload the page with the Network tab open.
If you’re chasing a “sometimes slow” issue, do two runs: one with cache enabled (returning visitor) and one with cache disabled (new visitor).
How to spot the biggest problems in 60 seconds
Start simple: sort and scan.
- Sort by Time: find the slowest individual requests (often APIs, third-party scripts, or large images).
- Sort by Transferred: find what’s costing the most bandwidth (usually images, video, or uncompressed bundles).
- Filter by Type: isolate JS, CSS, Img, Font, or XHR/fetch.
- Look for clusters: many requests to the same domain can point to a third-party dependency or a misconfigured asset pipeline.
One slow request can be annoying. A slow request that blocks everything else is usually the real culprit.
Blocking vs slow: what “waterfall” patterns usually mean
The waterfall view (when you click a request) helps you tell the difference between “server was slow” and “the browser was waiting on something.”
Common patterns to recognize:
- Long wait before download starts: often server response time (TTFB), backend slowness, or a slow third-party.
- Lots of queued/blocked time: the browser couldn’t start yet (connection limits, priorities, or other resources taking precedence).
- Big download segment: the file is large or connection is slow (images, bundles, fonts).
If your CSS or critical JS is slow early in the waterfall, the page can “feel stuck” even if everything eventually loads.
Red flags worth investigating (a practical checklist)
These are the things that most often turn into real fixes.
- Many 301/302 redirects: extra round-trips; can also hide mixed URL versions (http/https, www/non-www).
- Repeated 404s: broken assets still cost time; also clutter logs and make debugging harder.
- Lots of 304s but still slow: caching might be revalidating too often, or the bottleneck is elsewhere.
- Huge images served for small slots: oversized hero images, unoptimized PNGs, missing responsive image sizes.
- Third-party scripts early: tag managers, ads, chat widgets, A/B testing can delay first render.
- Fonts loading late: can cause flashes (FOIT/FOUT) and layout shifts if not handled well.
A good rule: fix the biggest, earliest, and most repeated costs first.
Quick “what to do next” based on what you find
Once you’ve found the suspicious requests, you usually need just one next step per category.
- Slow HTML / high TTFB: check server timing, database calls, caching layer, and CDN configuration.
- Large JS bundles: split bundles, remove unused dependencies, enable compression (Brotli/Gzip), verify HTTP caching.
- Heavy images: resize to actual display needs, switch to modern formats (AVIF/WebP), add responsive variants.
- Third-party slowdowns: delay non-critical tags, reduce vendors, or load after interaction where appropriate.
- Caching not working: verify Cache-Control headers, immutable assets, and avoid changing URLs without fingerprinting.
If you’re sharing findings with someone else, include: the slow request URL, its domain, its time, and whether it’s first-party or third-party.
Takeaway: treat the Network panel like a shortlist generator
The Network Monitor isn’t just for developers—it’s a practical way to turn “this page feels slow” into a short list of fixable items. Sort by time, sort by size, identify what’s early in the load, and you’ll usually find the top 1–3 requests that matter most.