Why Network Hops Matter More Than Raw Bandwidth for Application Performance

Your vendor just upgraded you to a 10Gbps uplink and your application still feels sluggish. Users are complaining. The monitoring dashboard shows plenty of headroom on bandwidth. So what's actually wrong?

Probably hops. Specifically, too many of them between your users and your infrastructure.

This is one of the most consistent misunderstandings I see in infrastructure conversations — the assumption that bandwidth is the primary lever for application performance. It's not. For most real-world workloads, latency is what determines whether an application feels fast or broken, and latency is almost entirely a function of physical distance and the number of routing hops between two endpoints.

Bandwidth Is a Pipe. Latency Is Physics.

Think about it this way: bandwidth tells you how much data can move through a connection at once. Latency tells you how long it takes for a single packet to make the round trip. For bulk file transfers, bandwidth matters enormously. For interactive applications — web apps, APIs, database queries, anything with request/response cycles — latency is what the user actually feels.

Here's the math that makes this concrete. A modern web page might require 50-100 separate HTTP requests to fully load. If your server is sitting in an AWS us-west-2 region in Oregon and your user is in Boise, you're looking at 20-40ms of round-trip latency per request. Multiply that across 80 requests and you've added 1.6 to 3.2 seconds of pure network wait time before you've even considered server processing time or render time. That's not a bandwidth problem. That's a geography problem.

Move that same workload to infrastructure in Boise and that round-trip drops to under 5ms. Same 80 requests. Same application code. Now you're adding 400ms of network time instead of over 3 seconds. Users notice that difference immediately.

What Actually Happens at Each Hop

Every time a packet traverses a router, it incurs processing delay. It's small — often under a millisecond at any single hop — but it adds up, and it compounds with physical propagation delay across fiber. The speed of light in fiber is roughly 200,000 km/s, which sounds fast until you realize that a round trip from Boise to an Oregon data center and back covers real distance through real cable paths that don't run in straight lines.

Run a traceroute from a Boise machine to us-west-2 and count the hops. You'll typically see 12-18 hops, with the packet bouncing through regional aggregation points before it even reaches AWS's edge. Each of those hops adds jitter and potential queuing delay. On a congested path — and internet backbone paths get congested, especially during business hours — that queuing delay can spike unpredictably.

# Run this from a Boise-based machine and watch where the latency jumps
traceroute -n 8.8.8.8

# Compare with a traceroute to a local Idaho endpoint
traceroute -n <local-idaho-ip>

The latency jump usually happens at the handoff from local ISP infrastructure to the regional backbone. That's where you pay the geography tax.

The Workloads Where This Bites Hardest

Not every workload is equally sensitive to hop count and latency. Static asset serving through a CDN? Latency matters less because the CDN puts content close to users. But here's a list of workloads where latency is genuinely the dominant performance factor:

Database-backed web applications. Every page load triggers multiple database queries. If your application server is in Oregon and your database is too, you've got app-to-DB latency on top of user-to-app latency. If your users are in Boise, you're stacking two geography problems.

Real-time APIs. Payment processing integrations, healthcare record lookups, anything with a synchronous external API call in the critical path. These calls block the response. Shaving 30ms off each one is meaningful.

VoIP and video conferencing infrastructure. These are the most latency-sensitive workloads that exist. Jitter above 30ms starts degrading call quality noticeably. Jitter above 50ms and you're in "this call is terrible" territory.

Remote desktop and virtual desktop infrastructure (VDI). Every mouse click, every keystroke traverses the network. Sub-10ms latency is the difference between a VDI session that feels local and one that feels like you're working through molasses.

EHR and clinical applications. Healthcare organizations in the Treasure Valley running Epic, Cerner, or similar systems are particularly exposed here. Clinicians interact with these systems constantly throughout a shift. Aggregate that latency across hundreds of interactions per day per user and you're talking about real productivity loss — not to mention the compliance implications of patient data routing through out-of-state infrastructure.

BGP Routing Isn't Magic — It's Policy

One thing that surprises people who haven't run their own network: the route a packet takes across the internet isn't determined by what's physically fastest. It's determined by BGP routing policy, and BGP is fundamentally about business relationships between networks, not about optimizing your application's performance.

We've run our own ASN with BGP peering at the Seattle Internet Exchange. I've spent real time staring at routing tables and watching traffic take paths that made no geographic sense because of how peering agreements were structured. Traffic from Boise to a server in Portland sometimes routes through Denver. Not because Denver is on the way, but because that's where the peering relationship dictated the handoff.

When your infrastructure is local — actually local, not "Pacific Northwest" local — you short-circuit a lot of that BGP complexity. Traffic from a Boise user to a Boise data center stays on local and regional fiber with fewer handoffs between carrier networks. Fewer handoffs means fewer opportunities for suboptimal routing decisions and fewer points where congestion can add unpredictable latency.

This is one of the reasons proximity to your users matters more than raw connectivity specs. A 10Gbps port in a remote data center with 35ms latency to your users will underperform a 1Gbps port 5ms away for most interactive workloads.

Measuring This Yourself

Don't take my word for it. Measure it. Here's a straightforward way to quantify the latency difference for your specific workload.

If you're running a web application, use curl to measure time-to-first-byte from a Boise-based machine against your current infrastructure:

# Measure time to first byte from your current setup
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://your-app.example.com

# Run this multiple times across different times of day
# Watch for variance — that's jitter showing up
for i in {1..10}; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://your-app.example.com
  sleep 5
done

The variance matters as much as the average. A server that averages 40ms but spikes to 200ms during peak hours is a server that produces user complaints. Consistent low latency is better than occasionally fast latency with high jitter.

For database workloads, instrument your application to log query execution time separately from total request time. If your total request time is 800ms but your query execution time is 80ms, you've got 720ms of overhead to account for — and a significant chunk of that is probably network time, not application logic.

The Practical Case for Infrastructure Closer to Home

A healthcare SaaS company running clinical workflow software for Treasure Valley practices moved their workload from us-west-2 to our Weiser data center — 85 miles from Boise. Their average API response time dropped from 180ms to 47ms. Their EHR integration queries, which had been a constant source of support tickets about "slowness," went from averaging 220ms to under 60ms. Same application code. Same database schema. Different geography.

Their bill also dropped from roughly $38K/month to $24K/month, mostly from eliminating egress charges that had been silently accumulating, but that's a separate conversation.

The latency improvement wasn't magic. It was physics. Fewer miles of fiber, fewer routing hops, less time waiting for packets to come back. The application code didn't change because it didn't need to — the bottleneck was never in the code.

If you're running workloads that serve users in Boise or anywhere in the Treasure Valley, and your infrastructure is sitting in an Oregon hyperscaler region, you're paying a latency tax on every single user interaction. You're also paying an egress tax every time data leaves that region, but again — different conversation.

The first step is measuring what you're actually experiencing. Run the traceroutes. Instrument your TTFB. Look at your p95 and p99 latency, not just your average. Once you have those numbers, the case for moving closer to your users tends to make itself.

---

If what you're seeing in those measurements looks like a geography problem — and it usually does — talk to us about what your workload actually needs. We can run a latency comparison against your current setup with real numbers from our network, and show you exactly what the hop count looks like between our Weiser data center and your Boise users.