How to Choose a CDN for Download Sites: Large-File Speed Tests Need More Than Time to First Byte

Two CDNs are tested at the same time: one has a time to first byte of only 80 ms, while the other needs 300 ms. Looking at this data alone, the first one seems to win easily.

But when you actually download a 2 GB file, the result may be completely the opposite.

If the first CDN has a sustained download speed of only 2MB/s, it would theoretically take about 17 minutes; the second CDN, despite waiting more than 200 ms longer, can sustain 20MB/s, completing the whole file in about two minutes.

For web pages, a few hundred milliseconds of TTFB difference may be noticeable; for software installers, game patches, system images, and asset archives, the transfer capability over the following minutes is what truly determines user experience.

This is the most common pitfall when download sites choose a CDN:Testing large files with web page testing methods, looking only at ping, latency, or TTFB, without actually downloading the file for a period of time.

A CDN node responding quickly does not mean it can keep transferring quickly; starting fast for a few seconds does not mean it will not slow down when the download reaches 80%. Download sites need to evaluate a complete delivery chain, not a single number at the very beginning of a request.

How download sites and ordinary content sites differ in their CDN requirements

For ordinary news sites, e-commerce sites, and corporate websites, most resources may be only tens of KB to a few MB. These pages care more about DNS, connection, TLS, TTFB, and the load order of above-the-fold resources.

Download sites face a different situation:

• A single file may range from tens of MB to several GB;

• A single user may occupy a connection and bandwidth for a long time;

• Users may pause, resume, or restart downloads;

• Download tools may open multiple connections at the same time;

• Traffic spikes occur when popular files are released;

• Unpopular files may be frequently evicted from cache and fetched from origin;

• Failed downloads waste traffic that has already been transferred;

• Some users are on mobile networks or cross-border links;

• When files are hotlinked by external websites, traffic bills can rise rapidly.

Therefore, a CDN suitable for static web resources is not necessarily suitable for large file downloads. Many nodes, low ping, and impressive TTFB only demonstrate part of its capabilities; they do not directly indicate large file delivery performance.

When choosing a CDN, download sites need to answer at least four questions:

1. Can users reliably connect to the node;

2. Can the node sustain sufficient download speed;

3. Can the download resume from where it was interrupted;

4. Can both popular and unpopular files be cached reasonably, rather than constantly going back to origin.

Why large file speed tests cannot rely only on TTFB

TTFB is the time from when the client sends a request to when it receives the first response byte. It can reflect DNS, connection, TLS, CDN processing, caching, and origin fetch stages, but it only covers the period before and at the very beginning of a download.

Assume the test results for a 500 MB file are as follows:

For a 500 MB file, although CDN A returns the first byte earliest, users have to wait longer for the download to complete.

This does not mean TTFB has no value. Excessively high TTFB may indicate a cache miss, unreasonable node scheduling, excessive origin fetch distance, or slow origin response. The problem is thatTTFB must be considered together with sustained throughput, completion time, and failure rate.

If you are only testing an image, an HTML page, or a small file of a few hundred KB, TTFB may account for a large share of total time; if you are testing files of several GB, sustained download speed usually becomes the main factor.

For the difference between these two concepts, seePing Is Fast but the Website Is Slow? Don't Mistake Latency for Loading SpeedandWhat Causes High TTFB? Should You Check the CDN or the Origin First?.

Do not confuse Mbps and MB/s in download speeds

CDN consoles, speed test tools, and download software may use different units.

• Mbpsmeans megabits per second;

• MB/smeans megabytes per second;

• 1 byte equals 8 bits;

• Theoretically, 100Mbps is approximately equal to 12.5MB/s.

Therefore, a user having a 100Mbps broadband connection does not mean the download tool will show 100MB/s. After accounting for protocol overhead, line fluctuations, device performance, and other traffic, actual speed is usually even lower than the theoretical value.

When comparing CDNs, units must be consistent. If one result shows “80Mbps” and another shows “12MB/s,” you cannot directly compare the numbers.

You can use the following conversion:

MB/s = Mbps ÷ 8
Mbps = MB/s × 8

For example:

80Mbps ≈ 10MB/s
20MB/s ≈ 160Mbps

Articles, test reports, and internal review forms should ideally note units at the same time, to avoid confusing “megabit bandwidth” with “how many megabytes are downloaded per second.”

Which metrics matter most when download sites choose a CDN

1. Download success rate

No matter how fast the speed is, it is meaningless if connections are frequently interrupted.

Success rate should take priority over peak speed. During testing, record:

• DNS resolution failures;

• TCP or TLS connection failures;

• HTTP 4xx and 5xx status codes;

• Downloads dropping mid-way;

• Client timeouts;

• Range request failures;

• File size or checksum mismatches;

• Whether retries can recover.

Do not record only “eventual success.” A user who retries three times before completing a download and one who succeeds on the first try do not have the same experience.

2. Time to first byte

TTFB can help determine whether a download can start quickly, and it can also reveal cache MISS and origin fetch issues.

But for large files, TTFB is suitable for answering “how soon the download starts,” not “how long it takes to complete.”

3. Sustained download speed

Sustained speed is the core of large file testing. At minimum, record:

• Average speed in the first 10 seconds;

• Average speed over the entire test;

• Lowest speed during the test;

• Speed in the latter half of the download;

• Time required to complete the specified file;

• P50 and P95 across multiple tests.

Some CDNs start downloads at very high speeds and then drop noticeably after a few dozen seconds; other nodes start a bit slower but maintain stable throughput for a long time. A speed test lasting only three to five seconds may miss this difference.

4. Speed fluctuations

The same average speed does not mean the same experience.

In one case, speed stays around 10MB/s; in another, it fluctuates repeatedly between 1MB/s and 25MB/s. The averages may be close, but the latter is more likely to cause the estimated remaining time to jump, download timeouts, and users to think the task is stuck.

Therefore, you also need to observe the speed curve and dispersion, rather than keeping only an average.

5. Performance across regions and carriers

Fast downloads on China Telecom in Beijing do not prove that China Mobile in Guangzhou, China Unicom in Chengdu, or overseas users will also be fast.

Download sites should arrange tests based on the real user distribution:

• Mainland China users: split by China Telecom, China Unicom, China Mobile, and major regions;

• Overseas users: test by country, city, and major local networks;

• Cross-border downloads: focus on cross-border links and peak hours;

• Many mobile users: add 4G, 5G, and home broadband environments;

• Campus, enterprise, or special network users: supplement tests with real environments.

You can first useCdnChart website speed testto observe DNS resolution, connection, TTFB, and availability in different regions, then use actual file download tests to supplement sustained throughput data.

Note that regular website speed tests usually do not download several GB of files completely for a single task. They are suitable for discovering node, connection, and first-byte issues, but they cannot replace long-duration large file transfer tests.

6. Stability during peak hours

The biggest fear for download sites is fast test speeds, followed by a sudden drop when users download in large numbers.

Tests should at least cover:

• Weekday daytime;

• Local evening peak hours;

• Weekends;

• Before and after new version releases;

• When game updates, system upgrades, or events begin;

• When a single node experiences high concurrency.

A peak speed from a single early-morning test only proves that the CDN performed that way at that time; it does not prove it can consistently deliver the same throughput over the long term.

How to choose test files so you don't get a false result

Test files should come from real business scenarios, not a small file specially created for benchmarking that is especially easy to cache.

You can prepare three tiers:

The exact sizes need not be mechanically fixed at 10MB, 100MB, or 1GB. Software download sites should choose based on the actual size of installers, while game asset sites should simulate patch packages, full clients, and asset files.

If most files in your business are between 300MB and 800MB, but you test only with a 5MB file, the results will hardly represent real users.

Test files should also meet the following conditions:

• Content is fixed and not frequently overwritten under the same URL;

• File size is clear;

• A checksum such as SHA-256 can be calculated;

• Response headers match those of official download files;

• CDN cache rules match those of official files;

• Does not carry random query parameters that change every time;

• Contains no sensitive information;

• File integrity can be verified after the test.

To avoid runaway test traffic, you can limit test frequency and the number of nodes; there is no need for every probe to download a multi-GB file every minute.

Cold cache and warm cache must be tested separately

When the same file is accessed for the first time, the CDN node may not have it cached and needs to fetch it from the origin; on the second access, the file may already be stored on the node.

These two cases answer different questions:

• Cold cache test: observe the origin fetch path, origin bandwidth, first user experience, and cache fill capability;

• Warm cache test: observe the edge node's ability to continuously transfer files to users.

If you compare one CDN's warm cache results with another CDN's first origin fetch results, the conclusion has no reference value.

You can request the same URL repeatedly and check the cache status:

curl -sS -D - -o /dev/null \
  'https://download.example.com/files/client-v3.2.zip'

Focus on:

Cache-Control
Age
ETag
Last-Modified
Content-Length
Accept-Ranges
Via
X-Cache
CF-Cache-Status

Different CDNs use different cache status headers, so you should refer to the provider's documentation.HITusually indicates a response from cache,MISSusually indicates a miss at the current cache layer, but multi-tier caching, origin shields, and hierarchical caching can make the actual path more complex.

For cache status, seeHow to Read CDN Cache Hits: Understanding HIT, MISS, and Age.

Large file caching cannot be judged only by “supports caching”

A CDN provider saying it “supports large file caching” does not mean all your installers can be stored long-term on every edge node.

When choosing, continue to confirm:

• The maximum cacheable size per file;

• Whether file size limits are the same across plans;

• Whether Range segments are cached separately or fetched from origin;

• How soon unpopular files may be evicted;

• Whether hierarchical or regional caching is supported;

• Whether cache preheating is available;

• Whether preheating covers all nodes or only some regions;

• Whether cache purge is billed by URL, directory, or tag;

• Whether a file MISS results in a full origin fetch;

• Whether origin requests can be collapsed when multiple users request a cold file simultaneously;

• Whether large file caching incurs extra fees.

These rules change quickly and may vary by plan, so the CDN provider's current official documentation, contract, and actual test results should ultimately prevail.

Why unpopular files are especially likely to expose problems

Popular files are accessed frequently and are usually more likely to stay in cache. Unpopular files may be accessed only once every few days or even weeks, making them more likely to be evicted from nodes.

When a user downloads an unpopular file, the node needs to fetch it from origin again. If the origin egress is only 100Mbps and multiple requests arrive at once, no number of CDN nodes can magically increase origin bandwidth.

Therefore, tests should not select only the most popular installers. You should also select:

• Popular files that were just released and have high traffic;

• Ordinary files with steady daily downloads;

• Unpopular files that have not been accessed for a long time;

• Large files close to the per-file size limit.

Why Range requests are important for download sites

Range requests allow the client to fetch only part of a file. After a download is paused, the client can resume from the position already completed instead of downloading the entire file again.

MDN'sHTTP Range request documentationstates that services supporting partial requests usually returnAccept-Ranges: bytes; a successful range request usually returns206 Partial Content, and viaContent-Rangeindicates which portion of the file is returned.

First check the response headers:

curl -sSI \
  'https://download.example.com/files/client-v3.2.zip'

If you see:

Accept-Ranges: bytes
Content-Length: 1073741824
ETag: "example-version-id"

This indicates the server claims to support byte-range requests. However, the most reliable method is still to actually issue a Range GET:

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1048575' \
  'https://download.example.com/files/client-v3.2.zip'

Under normal circumstances, the response looks like:

HTTP/2 206
Content-Range: bytes 0-1048575/1073741824
Content-Length: 1048576

This means the client requested and received only the first 1MB of the file.

If the server returns200 OKand sends the entire file, it may mean the Range request was ignored; if it returns416 Requested Range Not Satisfiable, the requested range may exceed the file length or be incorrectly formatted.

Amazon CloudFront'sofficial Range GET documentationalso explains that edge nodes can process and cache partial byte ranges for large files; if the origin does not support Range, the actual behavior may become fetching the complete object from the origin. Therefore, you should not verify only the client-to-CDN segment; you must also confirm how Range is handled when the CDN fetches from origin.

Resuming downloads cannot be judged only by response headers; you must actually interrupt once

HavingAccept-Rangesdoes not mean the entire resume process is necessarily working.

An actual test should include:

1. Start downloading a large file;

2. Actively interrupt after downloading part of it;

3. Keep the partial local file;

4. Initiate resume again;

5. Check whether it returns206;

6. Confirm it does not restart from zero;

7. Verify the file hash after the download completes.

You can test it with curl like this:

curl -L \
  -o client-v3.2.zip.part \
  'https://download.example.com/files/client-v3.2.zip'

After interruption, continue:

curl -L -C - \
  -o client-v3.2.zip.part \
  'https://download.example.com/files/client-v3.2.zip'

After completion, calculate the checksum:

sha256sum client-v3.2.zip.part

If the file content is replaced during download but the URL does not change, the resumed file may be a mix of old and new content. Download sites should use versioned URLs and rely onETag,Last-Modified,If-Rangeor client-side verification mechanisms to reduce this risk.

For example, do not always use:

/download/client-latest.zip

A more suitable actual download URL is:

/download/client-3.2.0-build-184.zip

client-latest.zipIt can be used to redirect to a specific version, but the actual large file URL should ideally keep its content immutable.

How to use curl to test real large file download speed

The following command downloads the complete file but does not save the content to disk:

curl -L -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{response_code}\nsize=%{size_download}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\navg_speed=%{speed_download}\n' \
  'https://download.example.com/files/test-500mb.bin'

The output may look like:

remote_ip=203.0.113.20
http_code=200
size=524288000
dns=0.018
connect=0.052
tls=0.091
ttfb=0.146
total=42.831
avg_speed=12240164

speed_downloadBy default, it is expressed in bytes per second. The above12240164is roughly equivalent to 11.7MB/s.

curl's--write-outofficial documentationlists the request variables that can be output. Test reports should not retain only the final speed; they should also record the response IP, status code, file size, TTFB, and total time.

Why you cannot run the test only once

The first attempt may hit a cold cache, while the second may hit the node cache; one attempt may connect to an idle node, while the next may be scheduled to another IP.

It is recommended to repeat tests in the same region, on the same carrier, and during the same time period, and record:

• The node IP resolved and connected to each time;

• Cache status;

• Average download speed;

• Total time;

• Whether interruptions occurred;

• P50 and P95;

• The actual performance of the slowest run.

If the website itself has the problem of being “sometimes fast and sometimes slow,” seeWhen a Website Is Sometimes Fast and Sometimes Slow: How Should You Test CDN Speed?.

A fast single connection does not mean multiple users downloading simultaneously will also be fast

Large file downloads have two different types of concurrency:

• One user opens multiple connections through a download tool;

• Multiple users simultaneously download different or the same files from the same node.

Both cases should be tested, but they must not be mixed together.

Single-connection test

A single connection is closer to direct browser downloads and ordinary client behavior, and allows you to observe the sustained throughput and stability of one connection.

Multi-connection test

Download tools may split a file into multiple Ranges and open several connections at once. Multiple connections can sometimes improve speed, but they may simply bypass per-connection rate limits and do not represent the CDN's overall capacity.

If a candidate CDN reaches normal speed only with 16 or 32 connections enabled, while a single browser connection is very slow, you need to confirm what client real users actually use.

Multi-user concurrency test

When multiple users download simultaneously, observe:

• Whether total throughput grows reasonably with concurrency;

• Whether per-user speed drops sharply;

• Whether 429, 503, or connection resets occur;

• Whether the node rate-limits by single IP, single connection, or single URL;

• Whether popular files are always returned from cache;

• Whether origin fetch traffic increases abnormally.

Concurrency tests can easily generate large amounts of traffic and costs, so they should be conducted within authorized test domains, files, and capacity limits; do not launch stress tests against third-party download sites.

Slow download speeds are not necessarily a CDN node problem

A large file download path typically is:

用户 → 本地网络 → 运营商 → CDN边缘节点 → 上层缓存 → 源站或对象存储

Any segment can become a bottleneck.

Slow with warm cache

If the file is confirmed to beHIT, but downloads are still slow, focus on checking:

• Network quality from the user to the node;

• Node egress and current load;

• Per-connection rate limiting;

• Regional or carrier scheduling;

• Download tool concurrency strategy;

• User local bandwidth and disk write speed.

Slow with cold cache

If onlyMISSis slow, and normal after a hit, focus on checking:

• The origin fetch path from the CDN to the origin;

• Origin egress bandwidth;

• Object storage read performance;

• Whether the origin supports Range;

• Whether concurrent requests for the same cold file trigger repeated origin fetches;

• Whether hierarchical caching and origin request collapsing are effective.

Slow in all regions

If multiple regions and carriers are slow and their speed caps are very close, suspect:

• Rate limiting at the origin or object storage;

• Bandwidth limits in the CDN plan;

• Rate limiting by single file, single connection, or single IP;

• Slow authentication service response;

• Limitations in the download program itself;

• Disk or CPU bottlenecks on the test device.

Slow only in some regions

This is more likely related to node coverage, carrier interconnection, scheduling, or the local network. You need to compare region, carrier, node IP, and time period together, rather than looking only at nationwide averages.

Do signed URLs and hotlink protection affect cache hit rates?

Download sites often use signed URLs:

/file/client.zip?expires=1789800000&token=abc123

If each user'stokenis different, and the CDN includes all query parameters in the cache key, the same file may generate many cache copies, and the cache hit rate will drop significantly.

But simply ignoring all parameters may also create authentication bypass risks.

A more reasonable approach is:

• Complete signature verification at the edge;

• After verification passes, let identical files reuse the same cache object as much as possible;

• Clarify which parameters affect file content;

• Only parameters that affect content enter the cache key;

• Limit signature validity periods and the range of files allowed to be accessed;

• Maintain strict authentication for sensitive, paid, or private files;

• Do not prioritize “improving hit rate” over access control.

The specific implementation depends on the CDN provider's edge authentication, cache key, and signing capabilities, and must be verified in a test environment; rules from other platforms cannot be copied directly.

When choosing a CDN for download sites, also calculate these costs clearly

For large file businesses, traffic costs are usually much higher than request costs, but you cannot compare only the per-GB unit price.

The full cost may include:

• CDN egress traffic in different countries and regions;

• Origin or object storage egress traffic;

• Origin fetch traffic;

• HTTPS request fees;

• Number of Range requests;

• Cache purge and preheating;

• Log storage and delivery;

• Edge authentication or edge computing;

• Tiered pricing after exceeding the plan;

• Burst bandwidth during popular version releases;

• Invalid traffic from hotlinking, crawlers, and malicious downloads.

For example, one CDN may have a lower unit price, but frequent large file cache evictions may generate substantial object storage egress fees; another CDN may have a slightly higher unit price but maintain better cache hit rates and origin fetch control, resulting in a lower total cost.

During testing, you should check CDN traffic, origin traffic, and object storage bills at the same time, not just user-side speed.

How to build a CDN comparison table for download sites

You can create a unified scoring table for candidate CDNs:

Different download sites can adjust the weights.

Software download sites can give more weight to resume, file integrity, and cross-region stability; game patch sites can give more weight to large file throughput, peak capacity, and preheating; private resource download platforms should give more weight to signed URLs, authentication, and log auditing.

Do not simply average all metrics. For download sites, failure rate and sustained speed are usually more important than homepage load speed.

A test process closer to real business scenarios

Before formally selecting a CDN, you can proceed in the following order:

Create file samples

Select small files, medium files, typical large files, popular files, and unpopular files from real business scenarios, and record their sizes, versions, and hashes.

Unify candidate CDN configurations

Try to have all candidate CDNs use the same origin, cache times, test domain logic, and access permissions. Avoid enabling hierarchical caching for one while another still uses default settings.

First verify the basic path

Check DNS, HTTPS certificates, HTTP status codes, cache status, and node IPs to confirm that the file actually passes through the candidate CDN.

Test HIT and MISS separately

Record first origin fetch and cache hit separately; do not mix them in calculations or compare different cache conditions with each other.

Actually download for a long enough time

The test should be long enough to observe sustained throughput and mid-download fluctuations. If a real file takes ten minutes to download, you cannot test only the first five seconds.

Verify Range and resume

Actually interrupt and resume the download, and confirm206, file offset, and final checksum are correct.

Cover real user regions

Choose regions, carriers, and time periods based on access logs, orders, client reports, and business plans, rather than evenly distributing test points.

Add controlled concurrency

Test single connections first, then multi-connection download tools, and finally conduct multi-user concurrency tests within authorized capacity.

Observe the origin and costs

While user-side performance improves, you must also check whether origin egress increases, cache hit rate decreases, or origin requests become abnormal.

Roll out gradually with small traffic

First let some users or some files use the new CDN, observe completion rate, average speed, P95, interruption rate, complaints, and costs, and then decide whether to expand.

Frequently asked questions

Should download sites choose the CDN with the most nodes?

Not necessarily. The number of nodes only indicates coverage scale; it does not directly mean your users can connect to suitable nodes, nor does it prove those nodes have sufficient large file throughput. Base your decision on real user regions, carriers, and file download results.

What download speed for large files is considered normal?

There is no universal standard. It is affected by user bandwidth, CDN nodes, network paths, the origin, single-connection policies, and file popularity. A more meaningful approach is to set targets based on real user networks, such as download speed in core regions, P95 completion time, and success rate, rather than pursuing a fixed number divorced from the environment.

Can testing a 100MB file represent a 1GB file?

Not necessarily. A 100MB file can reveal obvious connection and throughput problems, but it may not be enough to expose long-duration rate limiting, slowdowns in the latter half, or connection interruptions. If your business regularly distributes files larger than 1GB, you should at least fully test some representative large files.

The CDN shows HIT, so why is the download still slow?

HITIt only means the file came from a cache layer; it does not mean the path from the user to the node is necessarily good, nor that there is no congestion or rate limiting at the node egress. You should also consider the response IP, region, carrier, sustained download speed, and time period.

Does Range support necessarily mean resume will work?

Not necessarily. You also need to confirm that the CDN, origin, and client work together properly, that the file is not overwritten with the same name during resume, and that the correct206andContent-Range. It is best to actually interrupt once, then complete the resume and file verification.

Can a single large file be delivered by multiple CDNs?

Yes. Download sites can use multiple CDNs by region, carrier, file type, or traffic ratio, and can configure active-standby failover. However, multi-CDN increases the complexity of cache consistency, signature authentication, log aggregation, and fault diagnosis. For related issues, seeCan a Website Use Multiple CDNs? How to Read Results from Multiple Providers.

Can CdnChart directly test a full large file download?

CdnChart is better suited for first observing node scheduling, connectivity, TTFB, availability, and basic download performance across different regions and carriers. For files of hundreds of MB or several GB, you should also use curl, real download clients, and controlled long-duration tests to supplement sustained throughput, Range, resume, and completion rate data.

When download sites screen CDNs, it helps to remember one practical rule:The first byte determines when users see the download start; sustained throughput determines when they actually get the file.

If a speed test report contains only ping and TTFB, but no file size, download duration, average speed, speed fluctuations, cache status, or Range results, it is not sufficient to support large file CDN selection.