Some Websites Load Slowly but Others Are Fast? What to Check First

If only a few websites are slow, start with those pages—not a reset of your whole network.

Changing DNS, deleting every cookie, and restarting the router in one sitting may change the symptom. It also makes it harder to know which change mattered. When unrelated sites still work, a more useful first question is: does the affected page fail to open, or does one part of it fail to finish?

Use one troublesome page to separate those cases, compare it under a few consistent conditions, and collect enough detail for a targeted next step. You do not need to diagnose the website’s infrastructure yourself.

Quick answer

Some websites can be slow while others are fast because a visit involves that particular site’s responses, its additional resources, your browser’s state, and the network paths used to reach them. A working page elsewhere does not prove that every part of your connection is healthy.

Start here:

1. Open a different page on the same site and an unrelated site.
2. Record what is missing: the entire page, images, video, sign-in, or responsive controls.
3. Compare the affected page in another browser, keeping the content and sign-in state as similar as practical.
4. If the problem repeats, check the service’s official status information and, where appropriate, compare another device or network.

Browser support guidance uses similar scope checks to distinguish site-specific problems from broader browser or connection failures. These comparisons narrow an investigation; they do not identify a culprit on their own.[1]

1. Separate “the website is slow” into an observable symptom

Choose one affected page. Do not start with a list of settings to change.

Write down what happens:

• The page stays blank: note whether it eventually displays content or ends with an error.
• Text appears but an image or video does not: record the missing component, rather than calling the whole connection slow.
• The page looks complete but sign-in or a button fails: note the action and any message shown. Avoid repeatedly submitting a purchase, payment, or other consequential form.
• The page is usable but its loading indicator keeps running: distinguish the unfinished background activity from the task you actually need to complete.

A website can embed content from other sites. Chrome’s documentation gives images, ads, and text as examples; those embedded services may also have their own cookie requirements.[2] The name in the address bar therefore does not describe every request that helps build the page.

Illustrative example, not a test result: a shop’s product description appears, but its image area remains blank. That observation justifies investigating the image request. It does not establish that the shop’s main server, your ISP, or an extension caused the delay.

If every website is slow, use the broader slow website loading guide instead. This article is for a problem that stays concentrated on particular pages or services.

2. Compare pages before comparing settings

Open another ordinary page on the affected site. Then open an unrelated site you normally use. Record the results without rapidly refreshing either one.

These are useful distinctions:

Swipe or scroll horizontally to read all three columns.

Do not turn the table into a verdict. Two devices can have different accounts, permissions, browser settings, and local connections. Two networks can use different routes and destination servers. A comparison is useful because it changes the questions worth asking—not because it removes all uncertainty.

Check the service’s own status information

Look for a status page or support notice linked from the service’s official website. Match the reported component and time to your symptom. A video service’s billing incident, for example, may have nothing to do with playback.

An incident that matches your experience is a reason to avoid disruptive local changes while the operator investigates. A green status page is not proof that your particular region, account, or page is unaffected. Save the time and the notice, if relevant, for your support report.

3. If only part of the page is missing, inspect that part

You can stop at the visible symptom and report it. For a more specific clue on a desktop browser, Chrome’s Developer tools → Network panel shows the requests made while a page loads.[3]

Use this optional workflow on an ordinary, non-sensitive page:

1. Open the page, then open Developer tools → Network. Make sure recording is active and select No throttling.
2. Clear the existing request list if needed, then reload once. Do not submit a payment or repeat another consequential action just to generate a log.
3. Find the main page request, usually identified as a document. If text arrived but images did not, inspect the image requests instead; for a missing embedded player, look for the related requests rather than assuming the document is slow.
4. Right-click the request-table headings to add Domain if useful. Note the hostname associated with a repeated failure, not the full private address or its query parameters.
5. Select the relevant request and open Timing. Record whether it is pending, fails with a message, or spends time in a particular phase.

Chrome documents request columns, domain filters, and the Timing view. It also provides Preserve log when you need to retain requests across a navigation.[3] Labels can change between versions.

A red request is not automatically the cause of a broken page. Ask whether the failure matches the missing feature and repeats when that feature fails. An unrelated advertising request can fail while the content you need works normally.

Likewise, a request marked Stalled does not prove your ISP stalled it. For the difference between DNS, connection setup, response waiting, and content download, use the request-timing walkthrough.

Keep cache settings consistent across comparisons. A refresh may reuse resources or connections; a faster second visit does not isolate the cause. Chrome’s Disable cache control affects the browser resource cache while DevTools is open, not every cache involved in reaching the service.[3]

4. Read an error as a clue—not a speed measurement

If a request returns an error, preserve its exact code or wording. HTTP status codes describe the response to a particular request; they are not internet-speed scores.[4]

• 403: access was refused. Investigate the service’s access or account requirements rather than assuming insufficient bandwidth.
• 404: the requested resource was not found. Confirm the page or resource address through the site’s normal navigation.
• 429: the service reports too many requests. Stop rapid refreshes and follow the service’s retry guidance.
• 502 or 504: a gateway received an invalid upstream response or did not receive one in time.
• 503: the service is not ready to handle the request, which can occur during maintenance or overload.

These meanings come from the documented status definitions.[4] They do not tell you which organization owns every component involved, or prove that a visible error explains the entire page’s behavior.

A browser may also show a blocked request or a CORS error rather than an ordinary HTTP status. Record it for the site’s support team. Do not install an extension that disables browser security or try to bypass cross-origin protections to make the page work.

For certificate or security-warning pages, stop and use the browser’s official guidance or a trusted administrator. Do not click through the warning as a troubleshooting shortcut.[1]

5. Choose one targeted browser check

If another browser works with comparable content, inspect differences in the original browser before changing your whole network.

On your personal device, if it is not managed by work or school, review optional extensions that modify that site. Test one relevant extension at a time and restore it if the comparison does not help. Keep workplace-required software and security protections in place. Mozilla identifies extensions, stored data, and browser settings as possible contributors to site breakage; that is a list of possibilities, not a diagnosis of your device.[5]

If the pattern points to one site’s stored state, consider deleting only that site’s data after saving work and checking that you can sign back in. Chrome offers site-specific deletion in Settings → Privacy and security → Third-party cookies → See all site data and permissions; search for the site and select its delete control. Menu wording may vary. Deleting cookies can sign you out and remove preferences, and you cannot restore deleted data by turning a setting back on.[2]

Do not globally enable cookies, disable filtering, or remove security software because an embedded feature fails. If the site requests a permission or cookie exception, understand the privacy trade-off and follow its official support instructions. On managed devices, ask the administrator.

If the main difference is normal versus private browsing, use the dedicated Incognito comparison guide. Private mode changes more than one condition, so “it works there” is a starting point, not proof of corrupt cookies.

6. Use another network only when it answers a specific question

If several devices have the same site-specific problem on home internet, a comparison through another trusted connection may be useful.

For a public page on your phone, compare Wi-Fi with mobile data, explicitly turning Wi-Fi off for the mobile-data visit. Keep the same URL and comparable content. Avoid large downloads, account changes, and any attempt to bypass an organization’s required VPN or access policy. Mobile-data charges may apply.

Then return to the original connection and repeat. If the difference persists, record it. The result can justify investigating resolver behavior, filtering, destination selection, or reachability; it cannot identify one of those as the cause by itself. The Wi-Fi versus mobile-data guide covers the comparison in more detail.

A fast speed test elsewhere does not settle this question. VelocityVerify’s methodology explains that its measurements depend on the route to its own endpoint as well as the device, local network, and conditions at the time.[6] That is useful connection context, not a measurement of every resource used by the affected website.

Your next step: write a support report someone can investigate

Choose one affected page and complete this note with your actual observations:

Affected public page or service:
Date, local time, and time zone:
Device, browser/version, and connection:
What fails: whole page, image, video, sign-in, or interaction:
Another page on the same site:
Unrelated site:
Another browser/device result, if checked:
Another network result, if checked:
Exact error or relevant request hostname, if visible:
Single change tested and whether restoring it restored the symptom:

Send it to the team best placed to investigate the pattern. For a service-specific error, missing feature, or failure across different connections, start with the website’s official support. For a problem that repeatedly occurs across devices on one home connection but not another, your ISP or network administrator may also need the comparison. A managed-device or policy-related problem belongs with your administrator. None of these handoff choices establishes fault.

Review screenshots before sharing. Chrome’s sanitized HAR export omits certain sensitive headers, including cookies and authorization headers, but a network log may still expose sensitive addresses or content.[3] Do not post an unreviewed HAR publicly. Use an official, trusted support channel and share only what is necessary.

You now have something more useful than “the internet is slow”: a specific failure, a repeatable comparison, and a clear question for the next person to investigate.

Sources

This is a researched troubleshooting guide, not an original website-speed benchmark. No user-device test results are claimed.

1. Mozilla: Websites don’t load—troubleshoot and fix error messages
2. Chrome Help: Delete, allow, and manage cookies
3. Chrome DevTools: Network features reference
4. MDN: HTTP response status codes
5. Mozilla: Websites look wrong or appear differently
6. VelocityVerify: Testing methodology

About the Author: Younes Kirat

Younes publishes and maintains VelocityVerify, focusing on broadband diagnostics, latency reduction, and consumer networking explainers. Read more about his work on his author profile.