Images load quickly, but the login button keeps spinning. Product listings appear, yet searches and checkout requests take several seconds. For a site hosted on a U.S. server and serving users in Mainland China, this difference can persist even after adding a CDN.

A DDoS-protected CDN can improve access to dynamic APIs if the service supports appropriate dynamic request forwarding and origin connectivity, and if network delays account for part of the slow response. Even when responses cannot be cached, dynamic APIs may benefit from better network paths and connection reuse. Slow database queries, application queues, and third-party APIs still need backend work.

The result depends on more than which edge location the user reaches. The path from that location to the U.S. origin matters too.

If every dynamic request reaches the origin, where does acceleration come from?

When a static asset is in cache, the CDN can serve it directly. Dynamic requests such as login, order lookup, and form submission usually require application processing; the result of one user's request cannot simply be served to the next user.

But an uncached response can still be delivered faster.

With a direct connection to a U.S. origin, the user's network carries the cross-border connection and each request round trip. With a CDN, the browser connects to an edge location, which forwards the request to the U.S. origin. If that second leg takes a better route and avoids repeated connection setup, the overall wait may shrink.

That is why testing a DDoS-protected CDN with only a home page or an image is insufficient. A cache hit shows that static delivery works; it says little about login and order APIs.

When a U.S. server feels slow, find where the time goes first

A dynamic request may involve DNS lookup, connection setup, request transmission, edge processing, the trip to the origin, application processing, and response download. These stages are not always strictly sequential, but separating them helps identify what to optimize.

If evenings are markedly slower, examine the cross-border path

If origin processing time stays similar but requests that work during the day experience waits, jitter, and timeouts in the evening, investigate congestion and packet loss.

Results can differ by region and among China Telecom, China Unicom, and China Mobile. A fast test from another country to the U.S. origin does not represent the experience of users in Mainland China. A good result in one city does not represent every user either.

In this situation, test a DDoS-protected CDN to see whether its entry network and origin route improve results. Adding CPU to the server alone is unlikely to address a network-path problem.

If every region is slow, the application may be the bottleneck

Suppose a request takes two seconds, and backend instrumentation shows that its critical processing path takes 1.6 seconds. Network changes cannot remove all of the remaining 400 milliseconds, and switching CDNs will not make the 1.6 seconds of application work disappear.

This is a hypothetical example, not a measured result. It illustrates a useful limit:the more time the backend consumes, the smaller the overall gain usually available from network optimization alone.

Check slow SQL queries, database lock waits, thread pools, external payment or SMS services, and whether the application calls several remote services in sequence. Low server CPU usage does not rule out these waits.

A slow page action may involve several sequential requests

For example, the frontend checks login status, then fetches user details, then uses those details to request application data. Each step waits for the previous one, adding repeated cross-border delays.

A CDN may improve the network portion of each request. Removing unnecessary sequential calls, combining endpoints where appropriate, and running independent requests in parallel can matter just as much. The presence of a CDN does not eliminate the need to inspect frontend and backend call patterns.

If you are unsure where to start, use the step-by-step guide to diagnosing website latency to trace “the page is slow” to a particular request and stage of waiting.

How can a DDoS-protected CDN help uncached dynamic APIs?

Choose a more stable route to the origin

The public Internet route from a user's carrier to a U.S. data center may not be suitable at every hour. Depending on its network capabilities, a dynamic acceleration service can select an alternative intermediate path and reduce the effects of congestion or inefficient routing.

Cloudflare's smart routing documentation describes one product implementation that selects traffic paths using current network conditions. It shows that routing is a potential optimization, but it does not mean every plan labeled “DDoS-protected CDN” uses the same mechanism.

For a U.S. origin, assess connectivity from the edge location to the specific data center. An edge location in Hong Kong may be close to Mainland China, but its location alone is not enough.

Reuse origin connections to avoid repeated handshakes

New connections generally require additional network round trips. On a long cross-border path, repeated TCP and TLS setup can become significant.

If the CDN can reuse established origin connections under suitable conditions, later requests may avoid part of that overhead. Amazon CloudFront's custom origin connection documentation notes that persistent connections save later requests the time needed to establish a new TCP connection and complete a TLS handshake.

These gains depend on both origin and proxy settings. An origin that frequently closes connections, mismatched timeouts, or a saturated connection pool can limit the benefit. Connection reuse policies also differ by product.

Connection reuse only reduces setup costs. Every request that must be processed in the U.S. still has to send the necessary data there and return the result.

Reduce unnecessary origin load during an attack

Dynamic APIs can be slowed by poor connectivity or by abusive requests. Sustained traffic to login, search, and expensive query endpoints can lengthen origin queues, forcing legitimate users to wait too.

Combined with suitable application protection, a DDoS-protected CDN can reduce some abusive traffic before it reaches the origin, giving legitimate requests a better chance of being processed promptly. This reduces the impact of an attack; it does not guarantee a fixed percentage improvement for every legitimate request.

For individual endpoints, use API abuse prevention and access controls to design appropriate rules. Browser pages, mobile APIs, and payment callbacks need different handling; a browser challenge cannot be applied uniformly to all three.

Why can routing through Hong Kong make a U.S. API faster—or slower?

Sending a user in Mainland China to Hong Kong before connecting to a U.S. origin is not inherently faster. The two network legs and proxy processing must perform better overall than a direct origin connection.

If the path to the edge is stable and the edge has a good route to the U.S. data center, the intermediary may reduce congestion and jitter. But if the edge is quick to reach while its route to the U.S. origin suffers packet loss, the request will stall on the second leg. Another proxy hop can also add processing and queue time.

Assess three separate questions:

• Is the route from your users' main regions to the edge location stable?
• Is the route from that edge location to the specific U.S. data center stable?
• Do the proxy or origin develop queues under normal and peak load?

A low ping to an edge location in Hong Kong says nothing by itself about the remaining origin trip and application processing. Do not substitute edge ping latency for end-to-end API response time.

CDN07 allows configuration of edge locations, bandwidth, and security policies to suit the workload. For a U.S. origin, include both user regions and the U.S. data center when evaluating a DDoS-protected CDN setup , and choose settings based on real dynamic API results.

How to test: Compare direct and CDN requests to the same endpoint

Choose a representative read-only endpoint, such as a public product category query. A health check that only returns “OK” confirms basic connectivity; it does not represent database queries or authenticated APIs.

Explicitly bypass the CDN cache for the test endpoint, and confirm in origin or application logs that each request reached the origin. A random query parameter alone does not prove that caching was bypassed.

Measure request stages through the CDN first

The following command runs in a Linux or macOS terminal with curl installed. Replace the example domain and path with your own read-only endpoint:

curl --noproxy '*' --http1.1 -sS \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'code=%{http_code}\nremote=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://api.example.com/api/catalog

This example uses HTTP/1.1 to show the stages of a single request over a new HTTPS connection. Test real browser traffic separately with the protocol it actually uses. --noproxy '*' prevents an environment proxy from affecting the comparison. Run the test where direct outbound connections are permitted.

curl's official documentation defines these timings in seconds. Most are cumulative from the start of the request, so do not add them all together.

Here, ttfb - tls is not “origin processing time.” Client-side timings alone cannot separate CDN origin fetch time from application processing.

Also check code and the response body. A quick 403, CAPTCHA page, or login redirect does not mean the API has been accelerated. If the connection fails or times out, a zero for an incomplete stage does not mean it was fast.

Compare direct origin requests in an authorized test environment

If your origin permits requests from the test location, keep the same URL and use --resolve to specify the origin IP address:

curl --noproxy '*' --http1.1 -sS \
  --connect-timeout 10 --max-time 30 \
  --resolve 'api.example.com:443:192.0.2.20' \
  -o /dev/null \
  -w 'code=%{http_code}\nremote=%{remote_ip}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://api.example.com/api/catalog

192.0.2.20 is a documentation example. Replace it with your origin IP address. The command retains the URL hostname for the Host header, SNI, and certificate validation; this example requires the origin to serve HTTPS for that hostname.

Because the IP address is specified, this direct test skips the usual DNS lookup. It is better suited to comparing connection and request paths; do not treat the difference in total time as an exact measure of the benefit production users will see.

Do not expose the entire origin to the public Internet for this test or disable certificate validation to hide hostname or trust-chain errors. If the origin only accepts CDN requests, use an authorized test endpoint or ask the technical team to help with the comparison.

Correlate client and origin measurements

Record at least the test time, region, carrier, request path, status code, and corresponding request ID. Origin logs or application performance monitoring should show queue time, application processing, and dependency calls for the same request.

Developers can also use the Server-Timing response header to expose backend timing in a controlled test. For example:

Server-Timing: app;dur=120, db;dur=35

These are illustrative values; dur is measured in milliseconds. The application defines each metric and its scope. If db is included in app, do not add the two. The header does not measure backend work automatically; the application or monitoring system must generate it, and it should not expose sensitive internal details publicly.

Include different regions, carriers, and evening peak periods in the comparison. Test both new connections and repeated requests; repeatedly starting separate curl processes does not reproduce connection reuse in a browser.

Where do dynamic API configurations commonly go wrong?

Caching every GET endpoint as public content

GET is a request method, not a sign that a response is safe to share among users. Profile, balance, and order queries can return private data even when they use GET.

For responses that must not be stored, the origin can return:

Cache-Control: private, no-store

Under RFC 9111's caching rules , private without field names prevents shared caches from storing a response, while no-store instructs caches not to store the corresponding request or response. no-cache requires validation before reuse; it does not prohibit storage.

Check the CDN configuration as well so forced caching rules do not conflict with the intended behavior, and verify that one account cannot receive another account's private result.

Dropping authentication or required parameters to improve cache hits

Dynamic requests must retain the Cookies, Authorization header, query parameters, and request body required by the application. Removing a product ID, language, tenant, or signature parameter can return the wrong data or break authentication.

The cache key and the parameters forwarded to the origin are different things. Excluding a parameter from the cache key does not mean the origin no longer needs it. After integration, verify real application requests, not just whether the domain loads.

Automatically retrying order submissions after an API timeout

A network timeout does not prove that the server did nothing. The order may have been created even though its response did not arrive in time.

RFC 9110's guidance on idempotency and retries distinguishes operations that can be repeated safely from non-idempotent ones. Payments, orders, and inventory changes need application-level idempotency keys, status checks, and duplicate submission handling. Increasing proxy retries cannot solve this.

Assuming long-lived connections work because ordinary APIs work

Test WebSocket, SSE, and streaming endpoints separately. Establishing a connection is only the first step. Check idle timeouts, reconnection, sustained delivery, and whether proxy buffering delays incremental output until the end.

CDN07's product page lists WebSocket support, but confirm connection duration, timeouts, and streaming behavior for your application during integration. Verify capabilities such as SSE separately; WebSocket support alone does not establish them.

When should you keep tuning the CDN or change the U.S. origin?

Evaluate response time, success rate, and application correctness together. P95 and P99 can reveal slower requests, but they require enough samples. A few manual tests cannot establish long-term performance.

If most users are consistently in Mainland China and the application depends on many sequential, strongly consistent reads and writes across the border, you may also need to change where the application and database run. Moving some read-only services to a more suitable location could reduce round trips, but data synchronization, access controls, and consistency must be designed together. A CDN cannot replace that architectural work.

When choosing a provider, use the guide to routes and protection for dynamic applications to move the evaluation beyond “Does the site load?” to “Can users reliably complete critical tasks?”

Frequently asked questions

If dynamic APIs are not cached, does a CDN just add another hop?

Not necessarily. A suitable origin route and connection reuse may reduce wait time, but the CDN can add overhead if it does not improve the path or request handling. Compare results for the same endpoint.

Will a U.S. West Coast server always be faster for users in Mainland China?

Geography alone cannot answer that. Carrier interconnection, routing, congestion, and origin configuration at the specific data center also matter. Test the actual server from your users' main networks.

Can an edge location in Hong Kong bring a U.S. API response down to tens of milliseconds?

There is no such guarantee. If the request must be processed in the U.S., cross-border transit and application processing still take time. Latency from a user to the Hong Kong edge is not the full API response time.

Ping is lower. Why is login still slow?

Ping does not cover the full HTTPS, proxy, database, and application flow. Login may also involve a CAPTCHA, fraud checks, or an external identity provider. Measure the actual login request and its dependencies.

The API got slower after enabling DDoS protection. Should we turn it off?

First check for challenges, rate limiting, origin timeouts, or incorrect rules. Adjust the affected endpoints rather than disabling protection for the entire site. As performance recovers, verify that abusive traffic is not again reaching the origin.

When should we consider moving the server?

If the backend is optimized and suitable routes have been tested, but critical actions still suffer from cross-border round trips—or long-term costs and stability fall short—compare migration and regional deployment options. Base the decision on where users are and what the application depends on.

For a U.S.-hosted application serving users in Mainland China, improving dynamic APIs means reducing avoidable network waits while keeping origin processing time under control. A faster home page is only the start. The real measure is how login, search, checkout, and persistent connections perform.

To plan a test, share the U.S. data center location, primary user regions, representative endpoints, and peak hours through CDN07 technical consultation . Start with a few application paths, then compare success rates, response times, and backend load to find a suitable combination of routes and protection.