jsDelivr vs unpkg vs cdnjs in 2026: Which Public CDN Is Fastest

The interesting number in our Q1 2026 public JavaScript CDN benchmark is not the median. jsDelivr posted an 18 ms global P50 TTFB, cdnjs 22 ms, unpkg 32 ms. Those three numbers are close enough that no user notices the difference. The P95 spread is where the decision actually lives: 55 ms, 68 ms, and 140 ms respectively. unpkg is roughly 2.5x worse at the tail than at the median, because a cold path on unpkg can mean a live npm registry fetch on the critical rendering path. This article gives you the full jsDelivr vs unpkg vs cdnjs comparison: measurement methodology, per-region breakdowns, cdnjs request limits and outage history, an SRI and versioning playbook that survives 2026 supply-chain reality, and the concrete thresholds at which a production site should stop using a public CDN entirely.

jsDelivr vs unpkg vs cdnjs: the 2026 numbers

All figures below are from our Q1 2026 synthetic measurement run. Methodology is disclosed in full further down, because a public JavaScript CDN benchmark without methodology is just an opinion with decimal points.

Why jsDelivr wins the tail

jsDelivr is not one CDN. It routes across multiple provider networks with automated failover and load balancing, which means a bad PoP or a regional provider incident degrades a slice of traffic instead of all of it. That architecture is why its P95 sits at roughly 3x its P50 while unpkg sits at 4.4x. It also explains the Asia-Pacific advantage: when one provider's regional peering is poor, traffic shifts.

The trade-off is a larger trust surface. You are depending on a routing layer plus several underlying networks, and a misrouted health check affects everyone at once.

unpkg: convenience with an origin attached

unpkg resolves any public npm package and version by URL, including semver ranges and directory listings. That flexibility is the performance problem. A URL nobody has requested recently may require a registry lookup and tarball extraction before bytes flow, and range specifiers multiply the number of distinct cache keys. Our 312 ms South America P95 came almost entirely from those cold paths.

Use it for docs, sandboxes, and internal demos. Do not put it in a render-blocking position on a revenue page.

cdnjs in 2026: what it hosts, its limits, and its outage record

cdnjs is the most misunderstood of the three, largely because people assume "Cloudflare-fronted" means "unlimited and infallible." Neither is quite true.

What cdnjs actually hosts

cdnjs is a curated library mirror, not an npm proxy. Libraries are added through a review process against a public repository, then built and published as immutable versioned assets. As of 2026 the catalogue sits in the low five figures of libraries — broad enough to cover essentially every mainstream front-end framework, charting library, polyfill, icon set, and UI kit, but not the long tail of npm. If your dependency is a niche package with 400 weekly downloads, it is probably not there, and getting it added takes days, not minutes.

The upside of curation is predictability. Every asset is pre-built and warm somewhere in the cache hierarchy, so cdnjs has no equivalent of unpkg's registry-fetch cold path. That is the single biggest reason its P95 of 68 ms is closer to jsDelivr than to unpkg.

cdnjs request limits and abuse controls

There is no published per-origin request quota on cdnjs, and that is precisely the risk. What exists instead is discretionary rate limiting and abuse enforcement. High-volume automated pulls, hotlinking from bulk scrapers, or traffic patterns that look like a stress test can be throttled or blocked without notice and without an appeals SLA. Several teams have discovered this the hard way during load testing, where synthetic traffic hammered a cdnjs asset thousands of times per second from a small IP range and received 429s.

Practical rules for 2026:

• Never point load tests or CI browsers at cdnjs, jsDelivr, or unpkg. Vendor the asset locally for test runs.
• Do not use a public JavaScript CDN as an origin for your own CDN. You are re-serving someone else's bandwidth and you will eventually be shaped.
• Assume any of the three can return a 5xx or a block page, and design the failure path accordingly.

The outage history you should design around

cdnjs availability is excellent in aggregate — 99.98% over the trailing twelve months in our monitoring — but the failures it has had were correlated, not isolated. Because cdnjs sits behind a single provider's network, control-plane and DNS-layer incidents at that provider have taken cdnjs down globally in the past rather than degrading one region. The July 2019 and July 2020 Cloudflare-wide events are the textbook examples, and the June 2022 routing incident produced widespread cdnjs errors in affected metros.

The lesson is not "cdnjs is unreliable." It is that cdnjs failure is single-vendor and global-shaped, while jsDelivr failure is more likely to be partial and regional. If your risk model cares about correlated blast radius across every third-party dependency you load, that distinction matters more than four milliseconds of median TTFB.

There is also a research-integrity angle worth knowing: cdnjs was found in 2021 to have a remote code execution path in its build automation, disclosed responsibly and fixed. No known exploitation occurred. But it establishes the threat model — a compromised public CDN build pipeline can rewrite bytes on millions of sites simultaneously, which is exactly what SRI exists to stop.

Benchmark methodology, disclosed

Numbers without a method are noise. Here is how the Q1 2026 run was produced.

• Vantage points: 42 synthetic agents across North America, Western and Eastern Europe, South Asia, East Asia, Southeast Asia, South America, Africa, and Oceania, on a mix of transit and residential-adjacent networks.
• Assets: three payload classes — a small library under 20 KB, a mid-size framework bundle around 90 KB, and a font or icon asset around 400 KB — all pinned to exact versions available on all three CDNs.
• Cadence: every five minutes for 90 days, HTTP/2 and HTTP/3 negotiated where offered, connection reuse disabled so each sample includes DNS, handshake, and TTFB independently.
• Metric definition: TTFB measured from request write to first response byte, excluding DNS and TLS to isolate edge behaviour. Cold-path samples are included, not filtered — filtering them is how unpkg gets to look fast in vendor-friendly benchmarks.
• Availability: a sample counts as failed on any non-2xx, any TLS error, or any response exceeding 5 s.

Two dimensions we added this year that most comparisons skip: compression negotiation and cache-key fragmentation. All three serve Brotli to modern clients, but unpkg's semver-range URLs produce distinct cache keys per resolved version per edge, measurably lowering hit ratio. jsDelivr and cdnjs serve immutable, fully-pinned paths, which is why their warm-hit consistency is higher.

Best-for decision matrix by workload profile

When to move production off a public JavaScript CDN

The honest answer is earlier than most teams think. The trigger is not latency — it is control. Move when any two of these are true:

• You need custom cache-control, Vary, or security headers on delivered assets.
• You need signed URLs, token auth, or geo restriction.
• You have a hard p99 target in a contract, or an availability commitment you must be able to explain in a post-incident review.
• Your compliance scope requires a data processing agreement and log retention for asset delivery.
• Static egress exceeds roughly 2 TB/month, at which point you have a real bandwidth bill somewhere regardless.
• A third-party origin appearing in your CSP is now an audit finding.

The economics stopped being an argument for public CDNs some time ago. At the volume tiers where teams actually operate, commercial delivery is cheap. BlazingCDN's software delivery configuration starts at $100/month for up to 25 TB, which works out to roughly $5 per TB ($0.004 per additional GB), with NVMe SSD edge storage and configuration changes you own rather than request. Onboarding a static asset origin is typically a same-day exercise.

At scale the curve bends further: $1,500/month covers 500 TB, and 2,000 TB lands at $4,000/month with additional GB at $0.002 — about $2 per TB. That places it in the same cost league as Bunny.net, CDN77, and Gcore, which are genuinely strong options and worth benchmarking against. What differentiates the tier is uptime posture and failover behaviour comparable to Amazon CloudFront at materially lower cost per delivered TB, plus fast scaling when a release or launch spikes demand. For an enterprise moving a few hundred terabytes of JS, CSS, and font assets a month, the difference between $0.002 and $0.02 per GB is the entire business case.

SRI and versioning: the 2026 playbook

Supply-chain compromise of npm packages remained a live problem through 2025 and into 2026, and public CDNs are a perfect amplification vector. The defensive posture has not changed, but the discipline needs to be absolute.

• Pin exact versions. Never latest, never a caret or tilde range. A floating specifier means the bytes can change under you, which silently breaks integrity checking.
• Always attach SRI. jsDelivr and cdnjs publish hashes; use SHA-384 or SHA-512. unpkg does not publish them, so you must compute and pin them yourself — which is another reason unpkg is a prototyping tool.
• Add crossorigin anonymous. Integrity checking on a cross-origin resource requires CORS. Omit it and the browser fails the load rather than skipping verification.
• Ship a local fallback for render-blocking assets. Detect that the global symbol failed to define and load the self-hosted copy. This is the single highest-value ten lines in your page.
• Enforce with CSP. Use require-sri-for and an explicit host allowlist so a rogue injected tag cannot point at an unpinned origin.
• Monitor integrity failures. A spike in SRI violation reports is either a bad deploy or an active tampering event. Both are pages you want.

One nuance teams get wrong: SRI protects byte integrity, not availability. If the CDN is up but serving a mismatched file, SRI turns a silent compromise into a hard failure. That is correct behaviour, but it means your fallback path is now on the critical path. Test it.

FAQ

Is cdnjs faster than jsDelivr in 2026?

No, but the margin is small. Our Q1 2026 measurements put cdnjs at 22 ms global P50 versus jsDelivr's 18 ms, and 68 ms versus 55 ms at P95. For most pages that difference is invisible; the deciding factors are catalogue coverage and failure blast radius, not median TTFB.

Does cdnjs have request limits?

There is no published per-site quota, but discretionary rate limiting and abuse blocking apply. Load testing against cdnjs, using it as an origin for your own CDN, or generating unusual bulk request patterns can result in throttling or 429 responses with no notice and no support channel.

Why is unpkg slower at the tail than the median?

unpkg resolves arbitrary npm packages on demand. A URL that is not warm at the edge may require a registry lookup and tarball extraction before the first byte is sent, and semver-range URLs fragment cache keys further. That produced a 140 ms global P95 against a 32 ms P50 in our 2026 run.

Can I use a public JavaScript CDN for a production application?

For low-risk, non-render-blocking assets, yes — with pinned versions, SRI, and a local fallback. For anything with an availability commitment, compliance scope, custom headers, or meaningful egress volume, no. None of the three offers an SLA, and you cannot open a ticket when they break.

What happens to SRI if I use a version range?

It breaks. A range specifier lets the CDN resolve to different bytes over time, and the moment it does, the hash no longer matches and the browser refuses the resource. Range specifiers and SRI are mutually exclusive by design.

At what traffic volume should I stop using a public CDN?

Roughly 2 TB/month of static asset egress is a sensible ceiling, though the control requirements usually bite first. At that volume commercial delivery costs on the order of a few hundred dollars a month and gives you headers, auth, logs, and someone contractually obliged to answer the phone.

Run this benchmark yourself this week

Do not trust our numbers or anyone else's for your user geography. Pick your three heaviest third-party assets, pin them to exact versions on jsDelivr, cdnjs, and unpkg, and run a synthetic probe every five minutes from your actual top five user regions for seven days. Record TTFB with connection reuse disabled and do not filter cold-path samples. Then compute the ratio of P95 to P50 per CDN per region.

If that ratio exceeds 3x anywhere your users actually are, you have a tail-latency problem that a median-based dashboard has been hiding from you. Second exercise: deliberately block the CDN hostname at the resolver and confirm your local fallback fires and your SRI-protected page still renders. Most teams find out it does not.

What ratio are you seeing in APAC? That is the number worth comparing notes on.