Cache performance
UNPKG is fast because most requests are answered from cache at the edge. This guide explains what gets cached, for how long, and how to write URLs that hit it.
Permanent URLs are the fast path
npm never lets a published version be overwritten, so an exact-version file URL is permanent. UNPKG caches those responses at the edge for a year. URLs without a fully resolved version, such as unpkg.com/preact@10, must resolve first and redirect, so they are never the direct cache hit. For the best chance of a cache hit, use the full package version and file path in production URLs, like unpkg.com/preact@10.5.0/dist/preact.min.js.
That speed is a trade-off, not a free win: a fully pinned URL never changes, so bug fixes and patches only arrive when you update it. Looser specifiers flow updates to you automatically, at the cost of a redirect on the way in and accepting whatever the next release brings. A middle path is a patch-level specifier (such as preact@10.26), which takes bug fixes within a release line while major and minor changes stay deliberate. Which side you choose is a judgment call, and the security side of it is exactly the risk UNPKG Shield exists to carry, by watching new releases and stopping the bad ones at the edge whichever way you pin.
Verified, self-healing entries
Before a file enters any cache layer it is length- and digest-verified against the origin's response. An entry that fails verification later is evicted and refetched rather than served. If a version has to be withdrawn, operators can evict that exact package@version from every layer without disturbing any other version. The network page explains the machinery.