Internet Slow on Certain Websites

Rule Out Your Local Connection First

Run a speed test on the same device that is experiencing the problem, while the slow site is open in another tab. If your speed test shows normal results but the site is still slow, your local connection is not the bottleneck. If the speed test is also slow, fix the general connection before investigating the specific site.

Next, open the same slow site on a second device on the same network, then on your phone using mobile data instead of Wi-Fi. This three-step comparison tells you whether the problem is device-specific, network-specific, or genuinely with the site itself.

What the Pattern Means

DNS Resolution Testing for a Specific Site

DNS can be a direct cause of per-site slowness in two ways: slow lookup time adds latency to every page load, and a bad resolver can route you to a geographically distant or underloaded CDN node. You can test both with the dig command:

dig example.com @8.8.8.8
dig example.com @1.1.1.1
dig example.com @YOUR_ISP_DNS

Compare the query time reported at the bottom of each output. If your ISP's DNS takes noticeably longer to respond, or if it returns a different IP address that maps to a farther CDN node, switching to a public resolver like 8.8.8.8 or 1.1.1.1 can improve load times for that site specifically.

Traceroute and MTR to Find the Slow Hop

When a site is consistently slow from your home network but fast over mobile data, use traceroute or MTR to find where latency increases. On macOS and Linux, run mtr example.com. On Windows, run tracert example.com. Each line shows a router hop and its round-trip time. A sudden jump in latency at a specific hop — especially one owned by your ISP or a transit provider rather than the destination — points to a congested interconnect or a bad peering route between your ISP and the site's network.

ISP peering problems are one of the most common causes of site-specific slowness. Your ISP has direct connections (peering) to some networks and pays for transit to reach others. A congested or poorly maintained interconnect between your ISP and a particular CDN can make one site feel broken while everything else is fast. This is not something you can fix on your end, but you can report it to your ISP with the traceroute data as evidence.

Checking Which CDN Node You Are Hitting

Many large sites use Cloudflare, Fastly, Akamai, or AWS CloudFront as their CDN. You can see which point of presence (POP) is serving your requests by inspecting response headers:

curl -I https://example.com

Look for headers like cf-ray (Cloudflare, includes airport code of the POP), x-served-by (Fastly), or x-amz-cf-pop (CloudFront). If you are being routed to a distant POP — for example, a European POP when you are in North America — changing your DNS resolver may route you to a closer one, since CDNs use DNS-based load balancing to assign users to the nearest node.

Fix 1: Test Via Mobile Data to Isolate the ISP Path

If a site loads normally on your phone's mobile data but slowly on home Wi-Fi, the problem is somewhere between your home ISP and the site's servers. Mobile data uses a completely different ISP path, so the comparison cleanly separates your local network from the specific ISP routing issue.

Similarly, if the site is fast through a VPN but slow without one, your ISP's direct path to that site or CDN is the problem — the VPN routes your traffic through a different network with different peering to reach the destination.

Fix 2: Change DNS and Flush Cache

Switch your DNS resolver to 1.1.1.1 or 8.8.8.8, then flush your local DNS cache. On Windows: ipconfig /flushdns. On macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. Then reload the slow site in a fresh browser window. DNS changes help most when the slowness is in initial page load time (the DNS lookup phase) or when changing resolvers routes you to a closer CDN node.

Fix 3: Check for ISP Routing Problems and Report

If traceroute shows high latency at an ISP-owned hop, contact your ISP's technical support with the traceroute output and the specific site that is slow. ISPs can identify congested peering links and, in some cases, reroute traffic or upgrade capacity. Many ISPs also publish looking glass tools — web interfaces that let you run traceroutes from inside the ISP's network to the destination, which can help confirm whether the problem is on their end.

Fix 4: Try Another Browser or Private Window

If only one site is slow in one browser but fast in another, the issue is browser state: a broken cookie, corrupted service worker, extension rule, or cached bad script. Private windows temporarily bypass most of those variables and are the quickest confirmation test.

Frequently Asked Questions

Why are only some websites slow?

Different websites use different servers, CDNs, DNS paths, and ISP peering routes. A congested interconnect between your ISP and one particular CDN can make that site slow while everything else is fast, even though your speed test looks fine.

Can changing DNS fix slow websites?

Sometimes. DNS affects which CDN node you are routed to, and a slow resolver adds latency to every initial page load. It helps most when the slowness is in the time-to-first-byte or when you are being routed to a distant content server.

How do I know if the website itself is the problem?

Test the same site from your home network, mobile data, and a VPN. If it is slow from all three paths, the site or its CDN is almost certainly the issue. Check the site's public status page or social channels before spending time on local troubleshooting.