Why Is My Website Slow? A Developer's Guide to Testing the Network First

Your website feels slow. Your first move is probably to open the code editor. That is the wrong first move.

Most slow-website problems start outside your application. DNS servers lag. Routes take a strange path across the internet. A CDN node sits farther away than it should. None of that shows up when you profile your database queries.

This guide walks through how to test your network before you touch a single line of code. You will learn what to check, what good numbers look like, and what a bad result actually tells you.

Your Code Is Usually Not the First Problem

Here's a story that plays out often. A team notices their checkout page takes six seconds to load. They spend a week rewriting queries and shrinking images. The page is still slow.

Then someone runs a basic DNS check. Turns out their domain provider has been resolving slowly for every visitor, every single day. The code was never the issue.

Browsers and users don't care whether a delay comes from your server or from the network between you and them. They just see a page that won't load. That's why network testing has to happen before application debugging, not after.

The good news: most network tests take under a minute and need no special tools beyond your terminal.

Start With DNS

Every visit to your site begins with a DNS lookup. The browser has to turn your domain name into an IP address before it can connect to anything.

If that lookup is slow, everything downstream is delayed too, no matter how fast your server responds afterward.

Run a lookup with dig yourdomain.com or nslookup yourdomain.com and check the response time. Compare it against a few different resolvers, such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1. If your own DNS provider is noticeably slower than either of those, you've found a real lead.

A few things worth checking here:

• TTL values that are set too high, which delays how fast changes take effect
• Records that differ depending on which resolver you ask
• DNSSEC that's misconfigured, which some resolvers will silently reject

If you recently changed DNS records and things still look inconsistent, that's usually a propagation delay rather than a broken config. Give it time before assuming something is wrong.

Check the Round Trip With Ping

Ping tells you how long it takes for a packet to reach your server and come back. It's a rough number, but it's a useful starting point.

Rough guide for what the numbers mean:

The catch: pinging from your own laptop only tells you about your own location. If your server is in Frankfurt and you're testing from Frankfurt, of course it looks fast. Test from a few different regions, or use a service that runs the check from multiple locations for you.

Trace the Path

Ping tells you a delay exists. Traceroute tells you where.

Running traceroute yourdomain.com (or tracert on Windows) shows every router your data passes through on the way to your server. Somewhere in that list, you might spot a hop that adds a huge jump in response time. That's usually where your bottleneck lives.

A detail that surprises a lot of developers: the shortest line on a map is rarely the actual path your data takes. Internet routing depends on agreements between network providers, not geography. A server sitting physically close to your users can still perform badly if the traffic gets routed the long way around.

Look for Packet Loss

Packet loss means some of the data sent between the client and server never arrives, so it has to be resent. Even a small amount causes real problems.

A loss rate of just 1–2% can make video calls stutter, cause API requests to time out, and make pages load partway before stalling.

This is one of the trickier issues to catch because it's inconsistent by nature. One visitor has a smooth experience, and the next one gets stuck for no obvious reason. Tools like mtr combine ping and traceroute in a way that's especially good at catching loss on unstable connections.

Common causes include network congestion, a misconfigured firewall, a bad router somewhere along the path, or interference on a wireless connection.

Time to First Byte Matters More Than People Think

Time to First Byte, or TTFB, measures how long your server takes to send back the first bit of data after receiving a request. It's separate from how fast a page finishes rendering.

Rough targets:

• Under 200ms: strong
• 200–500ms: acceptable
• Over 800ms: needs attention

A high TTFB usually points to something happening on the server side: slow database queries, an overloaded backend, or a CDN that isn't caching the way you expect.

Plenty of teams stare at total page load time and miss TTFB entirely, even though it often points straight at the actual cause.

Confirm the CDN Is Actually Helping

A CDN's job is to serve content from a location close to the visitor instead of routing every request back to your origin server. But having a CDN doesn't guarantee it's doing its job well.

Watch for:

• Cache rules that are too strict, forcing repeated origin fetches
• A low cache hit ratio
• Edge locations that don't cover the regions your users are actually in

If most of your traffic comes from Southeast Asia but your CDN's nearest edge node is in the US, you're not getting much benefit. Run tests from a few different regions and compare load times with the CDN active versus bypassed. The gap tells you how much work it's really doing.

Don't Skip the TLS Handshake

HTTPS adds a negotiation step before any content loads: the TLS handshake. Modern implementations are fast, but a poorly configured certificate can slow this down noticeably.

Things worth checking:

• Certificate chains that are unnecessarily long
• Expired or soon-to-expire certificates
• Outdated cipher suites that force a slower negotiation

Browsers hide most of this complexity, which is exactly why it gets overlooked. A slow handshake can tack on a few hundred milliseconds before the page even starts rendering, and most developers never think to check it.

Watch the Request Waterfall

Open your browser's developer tools and load your page while watching the network tab. This waterfall view shows every request your page makes and how long each one takes.

This is where third-party scripts usually get exposed. Analytics tags, chat widgets, ad scripts, and social media embeds all add their own network requests. One slow third-party service can hold up your entire page, even if your own server responded instantly.

Look for requests that block rendering, unnecessary redirect chains, and resources loading one after another instead of in parallel.

Separate Latency From Bandwidth

These two get confused constantly, but they measure different things. Latency is how long a single request takes to respond. Bandwidth is how much data can move at once.

A connection can have great latency and still choke on bandwidth if it's handling large downloads, video streams, or heavy media. If your site leans on big assets, a bandwidth test is worth running separately from a latency check.

Test From Somewhere Other Than Your Office

It's easy to test a site only from your own desk and assume the results apply everywhere. They don't.

A page that loads in two seconds from your office might take seven seconds for a visitor halfway across the world, thanks to distance, routing, and CDN gaps that never show up in local testing.

If you're serious about performance, set up monitoring from a handful of different regions, not just one.

Check Your Server's IP Reputation

This one gets skipped until it causes a visible problem. A server's IP address carries a reputation based on its history, and a bad one can trigger extra scrutiny from firewalls, spam filters, and security tools, none of which has anything to do with your code.

It's worth checking your IP's reputation and routing details periodically, especially if you're on shared hosting where a neighbor's bad behavior could affect you.

A Quick Order of Operations

When a site is running slow and you don't know why, work through checks in roughly this order:

1. DNS lookup — rule out resolution delays first
2. Ping and traceroute — confirm the route and rough latency
3. Packet loss check — catch anything intermittent
4. TTFB — figure out if the server itself is slow to respond
5. CDN and TLS checks — rule out configuration issues
6. Waterfall analysis — look for what's actually loading on the page

Working through them in this order means you rule out the cheap, fast checks before spending real time on deeper application debugging.

The Real Lesson

Slow websites get blamed on code far more often than the code deserves. Network issues hide well because they're invisible from inside your application, and they show up differently for every visitor depending on where they're connecting from.

Run the checks above before you start optimizing anything. In a lot of cases, you'll find the real problem in minutes, not days.