Take the 2-minute tour ×

My website takes awfully long time after entering the domain name and before the content starts showing up.
I assume this is something to do with the dns resolution or the networks.
How do I go about troubleshooting this problem? Where do I start and what tools do I need? I know I’ll need nslookup and traceroute. What else will I need?

share|improve this question

5 Answers 5

Indeed, what makes you think it is DNS related?
You should answer yourself the following questions:
- What is the hardware performance? Do you have hardware bottlenecks (ie poor hdd performance)?
- Is your apache configuration optimal? See Max clients, requests per child, keep alive.
- Is the php/etc. code optimised?

Benchmark your apache configuration using ab.
Watch hardware utilisation (cpu, hdd).
If it is the case, go with load balancers (HAproxy) and use multiple web servers.

share|improve this answer

Please tell us the domain name, then we can test how fast the authoritative DNS is. There are two factors here:

  1. geographical location of the DNS server, which affects network latency
  2. server response time

Most authoritative servers should be able to give back an answer in a few milliseconds, so in many cases the network latency will be more important than the DNS server capacity.

If the DNS server itself is well connected then it'll be down to not only how fast the web server is, but also on the page layout.

Some layout methods (particular tables, ISTR) cause difficulties for browsers because they prevent the browser from rendering the page until most of the content has been downloaded.

@Moriarty's suggesting of the Firebug extension is a good one for looking at the DNS and HTTP requests, but I don't think it'll address the potential problem of poor page layout.

share|improve this answer

Before digging into networks and packet sniffing and all that, make sure it is not browser specific, install a fresh copy of Chrome and see how it does. Then make sure it's not machine specific, try it on other machines on the same network. Then make sure it's not network specific, try it from a wi-fi cafe, or a friend's house.

If it's still slow, Prof Moriarty and Willam have some great places to dig deeper. Is it a large page with a long TABLE? Plug-in's? IFRAMES? Lots of javascript?

share|improve this answer

First, get a high-level view of what is happening when the page loads with the help of the Firebug extension for Forefox. I will show you the exact amount of time each component of the web page takes to load. This will give you the first clue for what exactly you have to investigate.

If it is indeed a DNS problem, one of the most powerful tools to debugging DNS is dig. With the +trace option, it will show you all the intermediary steps needed to look up a domain, with lookup times for each step.

If it is a problem with establishing a TCP connection to the web site, you can first try to just ping it. If the round-trip time is large, you may want to try tcptraceroute on port 80 which uses TCP packets instead of UDP (or ICMP) like the default traceroute to see where packets get delayed. Using TCP would reproduce more faithfully the treatment your packets get on intermediary networks, some providers may throttle UDP traffic (and completely filter ICMP -- or actually give it high priority, and then you don't see that TCP is slower).

If DNS resolution time is short, and RTT to the server too, it may have capacity problems...

share|improve this answer

You need to look at the timing of different network packets back and forth between your computer, DNS server, and web host(s). If using a proxy server you need to check that traffic.

A really good tool for this is Wireshark.

Compare the time between DNS lookup, response, web server (HTTP) request, and web server response. A typical web page will have many individual parts, each of which is a request from your computer and response by the server. Check the same page from another computer/network to see differences. Remember to clear your DNS and browser caches before testing.

share|improve this answer

Your Answer


