Why I Keep Fonts, CSS, and JavaScript With My Site

A public CDN URL looks convenient:

<script src="https://cdn.example.com/library.min.js"></script>

It also makes the page depend on another domain, deployment, privacy policy, and connection. For small libraries, CSS, and fonts, I usually prefer serving the file with the site.

External delivery adds work and trust

Before downloading the asset, the browser may need DNS, connection, and TLS setup for the CDN. HTTP caching can help later, but modern browser cache partitioning means the old promise that every visitor already has the popular CDN file is much less dependable.

Local assets also make the deployed version clear in Git. An unpinned URL can change underneath the site:

https://cdn.example.com/library.js
https://cdn.example.com/library/latest.js

If a CDN is appropriate, pin the version:

https://cdn.example.com/library/3.2.1/library.min.js

For third-party scripts, Subresource Integrity can verify expected content. MDN has a useful Subresource Integrity guide.

Fonts make the trade-off obvious

A remote stylesheet from:

https://fonts.example.com/...

may lead to several more font requests. Self-hosting known font files keeps the dependency on the same origin and makes subsets, caching, and versions easier to control. Licensing still determines whether self-hosting is allowed.

A CDN can still be the right infrastructure

Large downloads, geographically distributed media, or a service designed around dynamic transformation may benefit from a specialised CDN. Your own hosting platform may already deliver static assets through a CDN, so “local” does not necessarily mean one physical server.

The distinction I care about is ownership of the dependency. If a critical stylesheet or tiny library can ship with the site, I would rather version and deploy it there. Use an external CDN when it provides a measured benefit, not because an old performance checklist promised a shared cache hit.

← Back to all articles