The homepage keeps spinning, then loads quickly after a refresh; the text appears, but images take much longer to show; the site works normally from the office, yet customers on mobile networks wait a long time. All of these can be described as a “slow website,” but the underlying problem may be in very different parts of the request path.

When a website is slow to load, start by checking DNS resolution and connection setup, then look at time to first byte, followed by images, scripts, APIs, and browser rendering. Once you know where the delay is concentrated, you can determine whether the right target is the network path, origin server, cache, or frontend code.

CDN07 recommends recording one complete page load before changing configuration. Even when a CDN is already in place, troubleshoot the request according to the path it actually takes.

Where is the website slow? Start with the symptoms to narrow the scope

Don’t just record that “the homepage took 5 seconds.” The same total load time can be caused by very different problems.

This table is intended to help identify where to start investigating; it does not replace a diagnosis. A blank page can occur before the HTML is returned, or after resource downloads have completed.

Before troubleshooting, record the exact URL, time of occurrence, region, carrier, device, and login state. Repeat the test several times under the same conditions and keep the failed and slower results rather than selecting only the fastest run.

If only a product page is slow while the homepage and static files are normal, the investigation should be different from a case where every page is slow. Start by identifying the affected request so the rest of the troubleshooting has a clear direction.

How to record DNS, connection, and time-to-first-byte latency

Browser developer tools can break a request into multiple stages. These concepts should be distinguished first:

These stages are not simply additive components of the total page load time. Images, scripts, and APIs can be requested in parallel, and some connections can be reused; when content becomes visible depends on critical resources and their dependencies.

In Chrome, you can record these timings as follows:

1. Open Developer Tools and go to the Network panel.
2. Make sure No throttling is selected to avoid accidentally retaining a simulated slow-network profile.
3. To inspect the redirect chain, enable Preserve log and then refresh the page.
4. Find the main document with the type Document/Doc, then open Timing.
5. Record DNS, connection, Waiting (TTFB), and Content Download, then check the other requests that affect the initial viewport.

To compare the effect of the browser cache, you can enable Disable cache and run another test. This does not clear the CDN cache, nor does it mean that all DNS and connection state has been reset. If the site uses a Service Worker, also check whether the response was supplied by that browser-side program. Chrome Network timing and request stages

What to check when DNS resolution is slow

Slow DNS resolution means the client may already be spending time before it has even started connecting. First determine whether the delay affects the main site domain or another domain used for resources such as images, fonts, or analytics.

Then verify the records in your domain management console: whether the site was recently migrated, whether the CNAME points to the current service endpoint, and whether the A and AAAA records still match the deployment design. A records map to IPv4 addresses, while AAAA records map to IPv6 addresses, so both should be checked separately.

On Windows, macOS, or Linux systems with nslookup installed, you can query the records for the example domain:

nslookup -type=A example.com
nslookup -type=AAAA example.com

Replace example.com with your own domain. These queries do not modify DNS configuration; they only show the results returned by the DNS service used by the command, which may differ from what a browser using secure DNS sees. For parameter details, see BIND nslookup documentation.

In the results, distinguish the address of the DNS server itself from the result of the domain lookup. An A or AAAA record only shows that an address was returned by that query; it does not by itself prove that the website is correctly connected to a CDN. A timeout or NXDOMAIN response also requires checking the domain spelling, DNS service, and authoritative records.

Different regions returning different IP addresses is not necessarily abnormal; CDN traffic steering can produce different results. Conversely, seeing the same IP address does not prove that every user is taking the same network path.

If only one network repeatedly experiences slow DNS resolution, preserve the query results from that environment and compare them with other networks. If multiple networks show the same problem, inspect the authoritative DNS service and the record chain. Do not remove a provider-required CNAME simply to “save one DNS lookup.”

If the browser does not show a separate DNS timing value, that may be due to caching or connection reuse. It does not mean the first visit incurred no DNS lookup cost.

Why slow connection setup does not necessarily mean the server is poorly configured

After DNS resolution completes, the client still needs to establish a connection. A typical new HTTP/1.1 or HTTP/2 HTTPS connection involves TCP setup and a TLS handshake; HTTP/3 uses QUIC, so the same TCP timing breakdown cannot be applied directly.

When the connection stage is unusually long, record the remote address, protocol, user network, and time of occurrence, then check for retries, packet loss, congestion, connection limits, or TLS configuration issues.

There are three distinctions that are easy to overlook.

A connection from the browser to the CDN edge is not the same as a connection from the CDN to the origin. The origin server is the backend system that actually stores content or runs the application. After a CDN is deployed, browser records typically show only the path to the edge node; the connection on the other side, including the origin fetch, requires server-side evidence.

Ping measures a different type of interaction. It does not cover the HTTPS handshake, application queuing, database queries, resource downloads, or script execution, so a low Ping time does not guarantee that the page will load quickly.

Redirects also consume time. An HTTP-to-HTTPS redirect, followed by a redirect from the bare domain to www and then to a language-specific page, can generate several responses before the final HTML is returned. Check whether each redirect is necessary and make internal links point directly to the correct destination.

When performance degrades noticeably for certain carriers or during peak hours, compare the same URL during similar time windows instead of comparing daytime broadband results with evening mobile-network results. For cross-region workloads, you can also use Optimization approaches for overseas website access by users in Mainland China to plan additional tests across different networks.

How to distinguish network issues from origin issues when TTFB is high

TTFB refers to time to first byte, an indicator of how long it takes before the response starts arriving. However, different tools may use different timing start points.

Page-navigation TTFB can include DNS resolution, connection setup, and other stages before the first byte; Chrome Network’s Waiting (TTFB) measures the wait after the request is sent and also includes network round trips. Before comparing the two values, confirm that they use the same measurement definition. TTFB definition from web.dev

Therefore, seeing a TTFB of 1 second does not mean the server spent 1 second executing application code. For requests passing through a CDN, this interval may also include edge processing, an origin fetch, and intermediate proxies.

Compare public static files with dynamic requests

During the same time window, compare the application page with a small public static file.

If the static file is fast but a particular API repeatedly takes much longer, prioritize checking that API’s application processing, database queries, external service calls, and queueing. However, the two requests may use different caching or backend paths, so logs are still needed to confirm the cause.

If multiple types of requests are slow, inspect the shared network path, proxy layer, and origin resources they have in common. Do not test only the homepage and assume the entire system has the same problem.

After deploying a CDN, verify whether the request is actually being served from cache

A CDN can store cacheable responses at distribution nodes. When a cache hit occurs, some requests do not need to contact the origin again; on a cache miss or when validation is required, the request may continue to the origin. For the basic mechanics, see How CDN caching and content distribution work.

Check the path, cache rules, response headers, and logs for slow requests. Cache-status fields differ across products, so use the relevant provider documentation for their exact meaning; the absence of a familiar response header does not by itself prove that caching is not taking place.

Public resources and personal data must be handled separately. Login sessions, shopping carts, and account information should not be placed under site-wide shared caching simply to reduce TTFB. Cache rules must respect the boundaries of authentication and response content. HTTP caching and shared caching guidance

Use a request ID to correlate browser and server-side records

Where possible, use a request ID to correlate edge, web server, and application logs. When no shared ID exists, at least align the timestamp, request path, and status code.

If the browser waits for a long time while application processing is short, there are still components outside the application logs that need investigation. If the application itself records a long processing time, continue with database queries, external API calls, or compute-heavy tasks.

If the origin is under unusually high load, also check whether application requests are bypassing the expected CDN entry point. If a site is already behind a CDN but still has other direct-access paths, see How to troubleshoot origin IP exposure and access protection for additional guidance. Do not assume an attack solely because resource utilization has increased.

Why images and the page can still feel slow even when HTML returns quickly

Fast HTML delivery only means that the main document request performed well. The initial viewport may still be waiting for images, CSS, JavaScript, or application APIs.

When checking critical resources, start with two timestamps: when the request started and how long it took after it started.

If a hero image starts downloading very late, the problem may be resource discovery or dependency ordering. For example, if JavaScript has to run before the image is inserted into the page, reducing the image size can improve the download time but will not eliminate the earlier wait.

If the primary above-the-fold content is a large image, check whether the browser can discover it early enough. Do not automatically apply lazy-loading intended for below-the-fold images. LCP (Largest Contentful Paint) can help show when the main content in the viewport becomes visible, but it does not mean every feature on the page is ready. Guide to optimizing critical resources and LCP

If a resource begins downloading promptly but takes a long time to finish, check the following:

• Whether the image resolution and format are appropriate for the actual display size;
• Whether text resources use an appropriate compression method;
• Whether a large number of files are being loaded even though they are not yet needed for the initial viewport;
• Whether the resource domain uses the expected CDN and caching configuration.

If the page remains sluggish after resources finish downloading, move to the Performance panel and inspect scripts and rendering. When JavaScript occupies the browser’s main thread for a long time, users may still be unable to see content promptly or interact with the page even if file transfers are faster.

Also inspect third-party fonts, analytics, and customer-support scripts separately. Putting the main site behind a CDN does not automatically optimize these independent domains.

Use curl to verify where the same request is actually spending time

The browser is useful for understanding full-page dependencies, while curl is useful for validating a specific URL. The following command works in a typical Linux or macOS shell and tests a standard GET request:

curl -sS -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  -w 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nready=%{time_pretransfer}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://www.example.com/'

Replace the URL with your own page. -o /dev/null discards the downloaded content; -sS hides the progress meter while preserving error messages; the two timeout parameters limit the waiting time for the connection phase and the entire operation. On Windows, use the appropriate curl.exe, output target, and Shell line-continuation syntax rather than copying this multiline command unchanged.

The timing values are reported in seconds. Names such as dns, connect, and tls are readable labels corresponding to the curl fields inside the braces. Most of these are cumulative times measured from the start of the operation, so they should not be added together. Official curl timing field documentation

The following is a teaching example, not a measurement from a CDN07 customer:

Assuming there are no interim responses such as 103, for a typical new, direct, non-redirected HTTP/1.1 or HTTP/2 HTTPS request, the adjacent timestamps can help with interpretation: TCP connection setup takes about 0.08 seconds, the TLS handshake about 0.13 seconds, the interval from transfer readiness to the first byte about 1.20 seconds, and the time after the first byte about 0.08 seconds.

These figures suggest that the next step should be to inspect the network, proxy, origin fetch, and application processing after the request is sent. The 1.20-second interval is still not the server’s execution time by itself.

The status code must also be considered. A 200 response does not guarantee that the returned content is the expected page; 301 or 302 means the redirect chain should be checked, and this command does not automatically follow redirects; for 403, 502, or 504 responses, address the relevant access or upstream problem first. In failure or timeout cases, do not treat incomplete timing data as a normal sample.

curl does not continue downloading images embedded in the page, nor does it execute JavaScript. A fast curl result therefore does not prove that the full page is fast.

How to verify that an optimization actually worked instead of simply testing under different conditions

After changing configuration, retest using the same URL, login state, and similar network conditions. Clearly note whether the browser cache is enabled, and continue checking both the response status and content.

Focus on the stages that were previously slow: Did DNS resolution become faster? Did first-byte waiting improve? Do critical images begin loading earlier? Do not look only at the total load time, because an improvement may come from the browser cache or temporary network variation.

For websites with significant regional differences, test across the networks used by your main users. For mobile-specific problems, reproduce the issue on an actual phone. Desktop browser throttling is useful for controlling variables, but it cannot fully represent a specific carrier’s real path or the performance of a physical mobile device.

When handing the issue to technical support, provide the URL, time of occurrence, region and carrier, browser and device information, a Timing screenshot, and the request ID. After exporting a HAR file or logs, still review and remove sensitive information such as tokens and personal data rather than relying solely on the tool’s default redaction.

Frequently Asked Questions

Why is the website slow the first time but fast the second time?

This can be related to browser caching, CDN caching, DNS caching, connection reuse, or application warm-up. Compare whether the two requests were actually sent, where the responses came from, and which timing stages became shorter. You cannot conclude that the CDN is configured correctly simply because a repeat visit is faster.

Does a TTFB above 1 second mean the server is underpowered?

Not necessarily. First confirm the timing definition, then look at the network, proxy, origin fetch, and application logs. If application processing is short, upgrading the server may not improve the main bottleneck; if slow queries or queueing are significant, the backend processing should be addressed instead.

Is it normal for a website to be slow even when Ping is low?

Yes, because they measure different things. Continue checking the HTTPS request, first-byte timing, resource sizes, and script execution. A low Ping time does not rule out problems in any of these stages.

The site is still slow after deploying a CDN. Should we switch providers?

First confirm that the slow request is actually passing through the CDN, that the content is suitable for caching, that origin fetches are not unusually slow, and that frontend tasks are not blocking the page. It is worth comparing providers only when the issue consistently concentrates on the relevant distribution node or network path and you have evidence from controlled comparisons.

How can I determine why the website is slow only in certain regions?

Compare different networks during similar time windows using the same URL, and record DNS results, remote addresses, status codes, and timing for each stage. Also confirm whether the request used IPv4 or IPv6. A single test from another region is not enough to establish a long-term cause, and regional differences alone do not prove that traffic is being blocked.

Will clearing the cache keep the website faster?

No. Clearing the browser cache may cause the next visit to download files again, while clearing the CDN cache can increase origin traffic. Only clear or invalidate the necessary scope when you have reason to suspect abnormal cache content or state, and then verify the result.

Where should I start when optimizing website performance?

Keep these four points in mind during troubleshooting:

• Identify the specific request and the stage consuming the most time before deciding what to change.
• Slow first-byte delivery must be evaluated together with network and server-side evidence; it should not be attributed directly to the server.
• Even after HTML returns quickly, check critical resources and browser rendering.
• Validate the effect of a CDN under the same conditions rather than relying on a single speed test.

As a next step, open the Network panel and keep a Timing record for one slow request, then use curl to validate the same URL. If the issue is concentrated in origin processing, continue with the application logs; if it is concentrated in content delivery or cross-region access, you can review CDN07's DDoS-protected CDN service deployment options and evaluate the configuration and optimization path based on the actual request flow.