“Hey, is the network slow today, or is it just me?” ── This article is for the person who gets asked that question at the office. See if any of these sound familiar.
- Every Monday at 9 a.m., everything company-wide turns to molasses
- One particular team or corner of the office always has problems
- The moment you connect to the VPN, not just internal systems but ordinary web browsing slows to a crawl
- The speed test numbers look fine, yet everything feels unmistakably slow
Let’s get one thing out of the way first: “slow” does not necessarily mean “the pipe is too thin.” Network slowness has a cast of usual suspects, each defined by which layer is clogged ── and each shows a different set of symptoms. The world is full of slowness that no bandwidth upgrade will ever fix.
This is not a configuration manual. It’s a map of where to look. Assuming a typical small-to-midsize office network, we’ll cover:
- How to break “slow” into three distinct problems (§1)
- DNS ── the stall before anything even starts (§2)
- Switches and broadcasts ── when one machine’s muttering reaches everyone (§3)
- VPNs ── when everyone’s traffic gets pulled through one tunnel (§4)
- DHCP, NAT, and port numbers ── when the address ledgers run out (§5)
- A practitioner’s 5-step triage routine (§6)
For each suspect, we’ll take the shortest path to why it makes things slow. No deep configuration knowledge required ── the cause-and-effect is the only thing you need to walk away with.
This article continues our “how your PC really works” series (IP addresses, DNS, and firewalls). Having covered a single PC, we now widen the lens to an entire organization’s network for the first time.
1. Breaking “slow” into three problems ── bandwidth, latency, and loss
1-1. Three kinds of slow, three different diseases
“Slow” is really three different things wearing the same coat. This three-way split runs through the entire article.
The three kinds of "slow"
① Bandwidth (road width) How much data fits through at once
└ When clogged: downloads crawl, everyone is slow at peak hours
② Latency (round trip) How long until data reaches the other side and returns
└ When clogged: every click is followed by a beat of waiting
③ Loss (dropped data) Waiting for lost data to be re-sent
└ When clogged: video calls stutter, things are randomly very slow
- Bandwidth (road width): how much data flows per second ── the number of lanes. Too little causes congestion, but when the road is empty there’s no problem at all. That’s why bandwidth shortage wears the face of “only slow at busy times”
- Latency: the round-trip time for data to reach the other side and come back. It’s unrelated to road width ── it’s set by distance and the number of stops along the way. That’s why latency wears the face of “whatever I do, the first beat is heavy”
- Loss (packet loss): some of the data you sent vanishes en route. The network quietly re-sends what was lost, but that re-sending wait wears the face of “usually fine, but occasionally everything lurches” and “video and audio break up”
1-2. Working backwards from symptoms
| What it feels like | First suspect | Section |
|---|---|---|
| Slow between clicking and the page starting to appear | Latency or name resolution | §2 DNS |
| One team or area is slow across the board | Layer 2 (switches, broadcasts) | §3 |
| Everything slows down on the VPN | A detoured route | §4 VPN |
| Slow at specific times ── first thing, lunch break | Bandwidth or exhaustion | §5 |
| Only video calls break up | Loss, Wi-Fi quality | §1 / §6 |
ping (a command that measures round-trip time) and a speed test measure different things. ping measures ② latency; a speed test mostly measures ① bandwidth. That’s why “the speed test is fast but everything feels slow” is a perfectly consistent state of the world.
2. The stall before anything starts ── DNS
2-1. What always happens before a page opens
Before your browser can fetch a page, it must perform name resolution (the lookup that converts a domain name into an IP address ── the actual street address). We mapped out how this works in our DNS article, but for an office network only one fact matters:
Until name resolution finishes, not a single byte of the real conversation begins.
So when DNS clogs, no amount of bandwidth helps ── the “first beat after every click” gets heavy, guaranteed. It’s not ① bandwidth, not ③ loss; it’s slowness before the communication even starts.
2-2. Why office DNS clogs
In a typical office, each PC sends its lookups to an internal DNS server (often a forwarder ── a relay clerk ── running on some shared piece of office equipment), which passes them along to external DNS. If that relay clerk is underpowered or overloaded, every employee’s “first beat” gets heavy at the same time.
The failure mode is even nastier. DNS lookups have multi-second timeouts, and when the first DNS server goes silent, the client waits those seconds out before asking the second server. “It freezes for a few seconds before opening ── but once open, it’s fast.” That symptom is the classic signature of waiting on DNS.
Someone says “the network is slow,” you run a speed test, and the numbers come back healthy. A speed test only resolves a name once, so DNS slowness barely registers in it. If the symptom is “only the start is slow,” the thing to measure is name resolution ── not bandwidth.
3. One machine’s muttering reaches everyone ── switches and broadcasts
3-1. The switch in one breath ── a smart distributor
The switch (the box that bundles multiple devices into a LAN) sitting under desks and in wiring closets is not a dumb splitter. It learns which device lives behind which port and delivers data only to the port where the destination actually is. That’s why, on a normal day, your neighbor’s giant download doesn’t trample your traffic.
And since switches are often confused with routers: “a switch handles traffic within one network; a router connects one network to another” ── that one line is all you need here.
3-2. But broadcasts reach everyone, always
The switch’s cleverness has one exception: the broadcast (a shout addressed to everyone on the network ── “is the owner of this address here?”). Because the destination is “everyone,” the switch must flood it out every port, no matter what it has learned.
Normal traffic: flows only to the destination port
PC-A ──→ [switch] ──→ PC-B
×──→ PC-C (not sent)
×──→ PC-D (not sent)
Broadcast: floods every port, always
PC-A ──→ [switch] ──→ PC-B
├──→ PC-C
└──→ PC-D … to everyone on the network
Broadcasts are a necessary part of normal network operation. The problem is volume. In a huge flat network ── a whole floor wired into one network with no internal boundaries ── hundreds of machines’ “is so-and-so here?” calls reach everyone, continuously. Picture a classroom where everyone is forced to listen to everyone else’s muttering. Each machine is only whispering, but hundreds of whispers add up to real noise.
3-3. The broadcast storm ── the classic total-collapse culprit
More dangerous still is the broadcast storm. When switches get accidentally cabled into a loop, everyone-addressed traffic circles the loop and multiplies until it saturates the network. “Suddenly, company-wide, everything is slow to the point of barely connecting” ── this worst-case symptom has a classic culprit, and this is it.
The cause is usually not failing hardware but the rogue desk switch under somebody’s desk. A well-meaning person connects two open jacks with a spare cable, or plugs a personal switch into the wall twice ── and a loop is born.
3-4. Mini-explainer: what is a subnet mask?
Time to collect a term. The subnet mask is the value that marks where the boundary sits in an IP address ── how much of it names the network, and how much names the individual machine. It expresses exactly the same thing as the /24 notation (CIDR) from our IP address article, just written differently (255.255.255.0).
In this chapter’s context, here’s what it means: a subnet is the range a broadcast can reach. Splitting a network into subnets means “dividing the classroom into smaller rooms so the muttering carries less far.” This is precisely why subnetting is the textbook remedy for the noisy flat-network problem.
4. Everyone’s traffic in one tunnel ── VPN
4-1. Mini-explainer: what is a VPN?
A VPN (Virtual Private Network) builds an encrypted tunnel between your PC at home (or on the road) and the company network, making your machine behave as if it were plugged into an Ethernet jack at the office. Its reason for existing is twofold: nobody along the path (your home ISP, public Wi-Fi) can peek inside, and you can reach internal-only systems from outside.
4-2. The full-tunnel detour ── why “home is slower than the office”
What matters for slowness is that tunnels come in two operating modes.
Full tunnel: all traffic goes via the office
Home PC ━━ VPN ━━→ Office ──→ Internet ──→ video site
(encrypted) (consumes the office line both ways)
Split tunnel: only office-bound traffic uses the tunnel
Home PC ━━ VPN ━━→ Office (internal systems only)
└─────────→ Internet ──→ video site (direct)
- Full tunnel: everything ── office-bound and internet-bound alike ── is hauled to the office first, then sent out. Easy to manage from a security standpoint, but even plain web browsing takes the physically longer route “home → office → site → office → home” (② latency goes up). Worse, every remote worker’s web browsing merges onto the company’s single internet line, so at busy times ① bandwidth clogs too
- Split tunnel: only traffic for internal systems enters the tunnel; everything else goes direct from home. The detour and the merge disappear ── in exchange, the company has less visibility into the traffic. A trade-off
“When I connect to the VPN, even normal web browsing slows down, not just internal systems” ── that symptom is almost certainly the full-tunnel detour plus the merge.
4-3. Encryption ── the fixed surcharge
One more thing: a VPN charges a fixed handling fee called encryption and encapsulation (sealing your data inside an encrypted envelope for transport). The envelope takes up room that payload could have used, and sealing and unsealing take processing time. Normally you won’t notice ── but when a crowd of remote workers converges on an aging VPN appliance, the appliance’s own processing capacity becomes the bottleneck. “The Monday-morning sluggishness turned out to be a traffic jam at the VPN box” is a very common ending to this story.
5. When the address ledgers run out ── DHCP, NAT, and port numbers
The suspects so far were all “some point along the route is clogged.” The last family is different: ledgers filling up ── slowness that happens while every piece of equipment is working exactly as designed.
5-1. Mini-explainer: what is DHCP?
DHCP is the mechanism that automatically lends an IP address to any device joining the network. The only reason your PC can communicate the moment it joins the Wi-Fi is that a DHCP server behind the scenes says “here’s your address.” The stock of lendable addresses (the address pool) has a ceiling, and every loan has a term (the lease period).
Its relationship to slowness is simple. As personal phones, conference-room gear, and IoT devices keep piling on, the pool runs dry ── and newly arriving devices can’t get an address at all. The symptom: machines can’t join the network, or take bizarrely long to join. There’s a seat for them, but no address to hand out.
5-2. Mini-explainer: what is NAT? What is a port number?
NAT is the mechanism that lets the office’s whole crowd of private IP addresses share one (or a few) public IPs, translating between the two worlds. It has appeared twice in this series already ── as “the home address vs. the public-facing address” in the IP address article, and as “Wall 1” in the firewall article. Here, let’s zoom in on the single point that matters for slowness.
That point rests on port numbers (the numbered “service windows,” 0–65535, that subdivide a single IP address). A NAT device tracks “which internal machine’s which conversation is using which outward-facing port” in a ledger of IP + port pairs (the NAT table, or session table).
5-3. What happens when the ledger fills up
The NAT device's ledger (conceptual) Internal conversation Outward-facing window 192.168.1.23 : 51344 → 203.0.113.5 : 40001 192.168.1.47 : 50122 → 203.0.113.5 : 40002 192.168.1.88 : 49873 → 203.0.113.5 : 40003 ... ... (Finite. When it fills up ↓ ) New conversation ──────→ no entry possible: can't open / old rows evicted, connections drop
Modern work means a single PC holds dozens to hundreds of simultaneous conversations (one browser tab of a cloud app accounts for several). The ledger swells just from headcount × cloud usage ── and when it’s full, you get “only new connections fail,” “long-lived connections suddenly drop,” and “general flakiness”: slowness that looks nothing like a failure. If trouble started right after the company grew or rolled out a batch of SaaS tools, this exhaustion family deserves a hard look.
6. The practitioner’s triage routine ── where to look first
Finally, let’s fold the whole map into a 5-step inspection routine. Stay within your company’s rules and your own authority ── probing other people’s machines or other companies’ servers is strictly off-limits.
- 1Establish the scopeJust you? One team? The whole company? The scope is your suspect list (just you → your own gear or Wi-Fi; one team → §3; company-wide → §2, §4, §5).
- 2ping for latency and lossAgainst both an internal device and an external host. Round-trip time (②) and drops (③) become numbers here.
- 3Check whether only name resolution is slowIf nslookup takes seconds to answer ── or only the first try fails ── §2 is the prime suspect.
- 4Compare routesFaster with the VPN off? Fixed by going wired? Whatever route you removed (§4, Wi-Fi) is your culprit.
- 5Correlate with time of dayReproducible first thing in the morning or at lunch → bandwidth or exhaustion (§5). “Slow at all hours” → route or configuration.
Steps 2 and 3 each need exactly one line.
ping -c 10 192.168.1.1 # to the internal gateway: watch round-trip time and loss%nslookup example.com # how fast (and whether) name resolution itself succeedsNumbers taken during an outage mean little on their own. The value is in the difference from normal. Save the output of these same commands on a good day ── that’s the single highest-ROI piece of “monitoring” a practitioner can set up.
Summary ── the essence in 4 lines
- Split “slow” into bandwidth (road width), latency (round trip), and loss (dropped data), and symptoms start pointing back at the guilty layer
- “Only the first beat is slow” → DNS. “One area is totally dead” → broadcasts (a loop). “Everything slows on the VPN” → the full-tunnel detour. Symptoms and suspects pair up reliably
- DHCP pools and NAT ledgers fill up. With zero failures anywhere, a network gets slower just from headcount and cloud usage growing
- Triage runs scope → ping → name resolution → route → time of day. Notes from a healthy day are the strongest preparation there is
The address system itself lives in What Is an IP Address?, name resolution in What Is DNS?, and defense against inbound traffic in What Happens Without a Firewall?. Together with this article, the full picture of “the office network” connects into one map.
FAQ
Q1. Will adding Wi-Fi access points speed things up?
A. Only when the cause is weak or congested Wi-Fi. On this article’s map, wireless affects ① bandwidth and ③ loss. If the symptom is “the first beat is slow” (§2) or “only slow on the VPN” (§4), no number of access points will change anything. Identify the layer with the §6 triage before spending the money.
Q2. Why does everything feel slow when the speed test is fast?
A. A speed test mostly measures ① bandwidth ── and against the nearest, best-positioned server at that. ② Latency, ③ loss, DNS wait time, and VPN detours barely register in its numbers. Day-to-day work is dominated by “small messages making dozens of round trips,” so latency and name resolution shape how the network feels far more than bandwidth does.
Q3. Should the VPN be on all the time?
A. Company policy comes first. Structurally speaking, an always-on full tunnel means “all traffic detours through the office, always” ── a permanent slowness surcharge (§4). On the other hand, the security and management benefits are real, so this is a genuine speed-versus-control trade-off. If the pain is significant, the constructive move is asking the network team whether split tunneling is on the table.
Q4. Does any of this happen on a home network?
A. A scaled-down version, yes. Your home router keeps a NAT ledger too (§5), and with a few dozen devices it can run out. Same for the DHCP pool. The broadcast problem of §3, on the other hand, almost never surfaces with a household’s device count. If “only video calls break up, even at home,” the shortest path is suspecting ③ loss ── that is, Wi-Fi quality.
Q5. What’s the first piece of monitoring worth setting up?
A. Before any serious monitoring tool: do what the §6 Tip says and save the output of ping and nslookup from a healthy day. It costs nothing and buys you the single most valuable thing during an outage ── the difference from normal. As a next step, even a trivial setup that pings the gateway on a schedule and logs the results is plenty to establish time-of-day correlation (§5, the bandwidth family).
Leave a Reply