Your problem could be a DNS problem.
When you type
http://www.google.com
into a browser, the information is not in a format which is useful.
To reach Google, the browser "needs a number", that number being
the IP address.
To get the number, your computer consults a DNS server. Your ISP
can have many DNS servers, or you can manually modify the computer
to use a "big name" DNS service. Google actually offers such a thing
for free.
Now, to debug DNS problems, you can again go to the command prompt
(just like you were doing with tracert).
Open a command prompt window, and in there type
nslookup
www.google.com
That does basically the same operation your (slow) browser is doing.
Now, watch the dynamics of the response.
If the answer and command prompt character come back immediately,
that means something answered the DNS query quickly.
But, say the thing stalled for five seconds, and then the answer
came back.
Typically, an ISP uses two DNS servers. They're redundant. When your
computer signs into the ISP, and connects up, the ISP sends down
the addresses of the two DNS servers.
Now, when you run the "nslookup" command, the computer will
consult the first DNS server. If the attempt fails (the DNS server
is dead, and the attempt times out), then your computer will consult
the second available DNS address. If that too times out, then
nslookup will report a problem, and no numeric translation
of the
www.google.com address will be provided. In the browser,
such a failure would be reported as a connection problem.
On some computer OSes, the DNS servers are consulted round robin.
If a dead DNS server is detected, the OS will consult the second
DNS server the next time, and the time after that. There will be
no slowdown. If the second DNS server goes away, such an OS switches
back to the first DNS server and tries that. Basically, the OS
"parks" on the working DNS server. Windows doesn't do that.
On Windows, Windows will keep trying the first DNS server, even though
it is dead. This might add a five second delay to each browser transaction,
which would cause quite a pronounced slowdown. Rather than being a
"bandwidth degradation", the effect is much worse, and it's actually
a "time domain" effect, where things kinda stop for a period of seconds,
until the timeout triggers an attempt to use the second DNS address.
So now you're ready to "study your DNS".
nslookup
www.yahoo.com
and say it comes back fast. Translations can be cached, and even if
DNS is entirely dead, perhaps the computer still "knows the number for Yahoo".
nslookup
www.someobscurewebsite.com
Now, we try a web site we don't normally use, to see if a "fresh"
DNS translation happens in a short interval or not. The web site
you choose, should be a real one, and not a fake. An example of a
site you might not use is
www.sun.com for example (Sun Microsystems),
and that one I think it has a single IP address as the translation output..
(Sun was bought by Oracle.)
If you now reboot the computer, you may find attempts to reach
yahoo.com with the web browser, are now just as slow as other
sites. If you reboot, I would expect the DNS cache to get
flushed on the computer. Other networking devices can have
DNS caches, and still have the info when needed.
So it's not always a "raw bandwidth" problem. Sometimes it is a
problem with IP address translation.
To a limited extent, you can also study the dynamics with
software such as Wireshark (packet sniffer and logger). But
in this case, the nslookup thing is a bit simpler to operate.
Wireshark has a *lot* of options, and takes a bit of getting
used to.
Paul