Free CDN Tiers Compared: Cloudflare Wins, With Caveats

Cloudflare wins.

For a conventional website that needs global caching, managed TLS, DNS, and basic DDoS protection without a metered delivery allowance, Cloudflare has the strongest zero-dollar package and the fewest billing traps.

The Cloudflare Free plan↗ puts its reverse proxy in front of an existing web server. That distinction matters: Cloudflare caches eligible files, but it does not replace the origin, database, object store, or application runtime.

Its practical advantages are blunt:

• No small monthly bandwidth bucket to nurse.
• Universal SSL certificates for proxied hostnames.
• Global cache and Anycast DNS in one account.
• Basic bot and DDoS defenses before traffic reaches the origin.
• Page Rules have largely given way to more focused Cache Rules, Redirect Rules, and Configuration Rules.

There are catches. Cloudflare decides which content is cacheable by default, HTML commonly reaches the origin unless a Cache Rule changes that behavior, and advanced Web Application Firewall controls sit above the Free plan. Large files, video delivery, image transformation, programmable edge code, and detailed logs also have separate limits or products.

Pick Cloudflare for a public site. It is the winner when the origin already exists and the job is to absorb ordinary web traffic without turning every gigabyte into a billing event.

AWS integration changes the verdict.

CloudFront is the better choice when files already live in a private Amazon S3 bucket, requests need signed URLs or signed cookies, or the delivery configuration belongs beside IAM, AWS Certificate Manager, and infrastructure code.

AWS publishes a recurring allowance on its CloudFront pricing page↗, including data transfer and HTTP or HTTPS requests, but usage beyond those allowances is metered. The account also needs a payment method, so “free” means the invoice stayed within thresholds, not that billing is impossible.

CloudFront wins these specific cases:

• A private S3 origin must remain inaccessible from the public internet.
• IAM policies and CloudFormation or Terraform already govern the stack.
• Signed access protects downloads or subscriber media.
• Lambda@Edge or CloudFront Functions must alter requests.
• AWS cost allocation tags and consolidated billing are required.

The hidden cost is operational as much as financial. Cache invalidations, request classes, origin fetches, log storage, Lambda execution, and S3 operations can each occupy a different line on the bill, while a cache miss may incur both origin and CDN charges.

That complexity is justified for an AWS application. I would not choose it for a small WordPress site merely to save the first few dollars.

No, they serve projects.

cdnjs and jsDelivr are excellent public asset networks for eligible open-source packages, but neither is a general reverse proxy where a business can point its domain and cache arbitrary HTML, customer uploads, or private application responses.

The distinction is routinely missed because both services place JavaScript, CSS, font, and source-map files on fast global infrastructure. cdnjs describes itself↗ as a free and open-source CDN service, while jsDelivr distributes files from npm, GitHub, WordPress, and other supported sources.

Use these services when:

• A browser needs a popular, versioned library.
• An open-source project needs public package distribution.
• The URL can remain public and immutable.
• There is no private origin or personalized response.

Do not treat a community library CDN as free hosting. Package removal, version pinning, browser privacy policy, Content Security Policy, and third-party availability all affect a production website, and loading a popular script from a shared URL no longer guarantees a useful cross-site browser cache.

This is where the loser wins. For an open-source Java or JavaScript library that simply needs stable public files, jsDelivr or cdnjs is more appropriate than placing an entire reverse-proxy service in front of a repository.

Count cache misses first.

A zero-dollar edge tier becomes expensive when uncached requests pull bytes from a metered origin, dynamic traffic invokes paid compute, or a traffic spike crosses an allowance before anyone notices the billing alert.

Check these costs before changing DNS:

• Origin egress: every miss can produce a storage-provider transfer charge.
• Request fees: object storage may bill GET, HEAD, and listing operations separately.
• Invalidations: frequent purges reduce cache efficiency and may become chargeable.
• Functions: edge code is often metered by invocation and execution time.
• Logs: raw request logs create storage, query, and retention costs.
• Security: managed WAF rules, bot controls, rate limiting, and account support commonly require payment.
• Images and video: transformation, resizing, streaming, and large-file delivery are frequently separate products.
• Migration: changing cache keys or TLS behavior can break cookies, query strings, redirects, and authenticated pages.

Measure the cache-hit ratio by bytes, not just request count. A website can report thousands of cached icons while a handful of missed 500 MB files dominate origin traffic, which makes the impressive-looking request ratio financially useless.

Upgrade when paid controls remove a demonstrated constraint: required WAF rules, predictable support, longer logs, contractual uptime, higher edge-compute limits, or a lower effective rate at sustained volume. The Fastly pricing model↗ is aimed at measured delivery and programmable edge services, which can suit teams needing precise cache behavior but is harder to mistake for an unlimited giveaway.

Set budget alarms too. The correct plan is the one whose worst plausible month is affordable, not the one whose normal month happens to read zero.