A team proposes self-hosting a third-party vendor's JavaScript from your own domain instead of loading it from the vendor's CDN. What does that buy you in performance terms, and what do you take on?
answer
- removes one origin handshake
- you choose the cache lifetime
- pin and verify a reviewed copy
- shared-CDN caching argument is dead
- you now own updating it forever
basics
~20 sSelf-hosting removes an extra origin handshake, lets you set your own cache lifetime and priority, and lets you pin a reviewed version. In exchange you own updating it, some vendors break or forbid it, and the script often still calls home anyway.
solid answer
~60 sThe gains are real but bounded. You drop a DNS lookup, TCP connection and TLS handshake because the file comes over a connection already open to your origin; you control the caching headers, which matters because many vendor scripts ship with deliberately short lifetimes and get refetched constantly; you can compress, prioritise and place it as you would your own assets; and you can pin a specific reviewed copy with integrity checks rather than accepting whatever the vendor serves today. The costs are ownership. You now run a job that fetches, verifies and republishes updates, and you carry the risk when you fall behind on a security or compatibility fix. Many vendor scripts fetch further resources from the vendor at runtime, so you have only removed the first hop. Some vendors forbid rehosting in their terms, and some scripts detect or depend on their own origin. Note the old argument that a shared public CDN copy is already cached from other sites no longer holds, because modern browsers partition the HTTP cache by top-level site.
go deeper
Know the basic tradeoff: serving the file yourself removes a connection to another host and lets you control caching, but you become responsible for keeping it current.
Explain the mechanics behind each gain: handshake avoidance, cache lifetime and fingerprinting, integrity pinning, and why a loader that calls home limits the benefit.
Show that you would measure the split between connection, download, execution and runtime fetches before committing, and that you would design the update-and-verify pipeline rather than pinning and forgetting.
Own the durability question: who maintains this in two years, what the stale-copy risk is, and whether the engineering time beats simply deferring, facading or dropping the vendor.
## What self-hosting actually changes Self-hosting means taking the vendor's file, putting it behind your own domain, and serving it as if it were your own asset. It is a common suggestion when a vendor script is on the critical path, and it is right often enough to be worth understanding precisely, and wrong often enough to be worth interrogating. ## The gains **One less origin.** A request to the vendor's host needs its own DNS resolution, TCP connection and TLS handshake before any bytes flow. Served from your origin, the request rides a connection that is already open and warm. On a high-latency mobile connection that saving is measured in hundreds of milliseconds and it is paid on first view, exactly when it hurts most. **Cache control.** Vendors frequently serve their scripts with short cache lifetimes so they can push changes quickly. That is good for them and expensive for you: repeat visitors refetch a file that rarely changed. When you host it, you choose the lifetime, and a fingerprinted filename lets you cache it for a long time safely. **Delivery control.** It becomes an asset like your own: your compression settings, your CDN, your priority decisions, your ability to place it where it belongs in the loading order rather than wherever the snippet was pasted. **Integrity and review.** A vendor-hosted script is whatever the vendor is serving at this instant, and cannot meaningfully be pinned. A copy you host is a specific artefact you can review, pin, and protect with subresource integrity and a tight Content Security Policy, so an unexpected change is a deliberate act rather than a silent one. **Availability and reachability.** Your page no longer depends on a third-party host being fast, or reachable at all, for that asset. Domain-based blockers that would have prevented the vendor host from loading also do not apply, which may be desirable or may be exactly the thing you should not be defeating: if users are blocking a tracker, routing around their choice is an ethical decision, not a technical one. **The obsolete argument.** Somebody will claim the vendor's public CDN is better because the user already has the file cached from another site. That reasoning is dead: modern browsers partition the HTTP cache by top-level site specifically to close that cross-site tracking channel, so a copy fetched on another site does not serve yours. ## The costs **You own updates forever.** Somebody must fetch new versions, check them, and republish, and somebody must notice when the vendor ships a fix you need. This is a small automation and a permanent maintenance obligation, and the failure mode is quiet: a pinned copy that silently drifts years out of date while everyone assumes it is current. **Long caching turns mistakes into long mistakes.** The same aggressive cache lifetime that made self-hosting attractive means a bad or compromised copy stays in users' caches. Fingerprint the filename so you can replace it, rather than relying on being able to purge. **You may only remove the first hop.** Plenty of vendor scripts immediately request configuration, further modules or beacons from the vendor's own origins. In that case you have removed one handshake and kept everything else, and the measured gain can be close to nothing. Check what the script actually does at runtime before promising a number. **Vendor terms and vendor behaviour.** Some vendors' terms prohibit rehosting; some scripts are built to be loaded from their own origin, self-update, or refuse to run from an unexpected host. Ad and consent-management scripts in particular tend to be off-limits. Find out before building the pipeline. **Security stays yours either way, and grows a little.** A vendor `<script src>` already runs in your origin's JavaScript context with full access to your DOM and same-origin storage, so self-hosting does not hand it new powers. What changes is that you are now serving the artefact, so if you ship a bad copy it carries your cache headers and your reputation, and the vendor's ability to hotfix disappears. ## How to decide Treat it as a measurement, not an ideology. Establish what the vendor costs today, split into connection setup versus download versus execution versus its own runtime fetches. If connection setup and repeat-visit refetching are the bulk of it and the script is largely self-contained, self-hosting is a solid win and worth the pipeline. If the script is a thin loader that pulls the rest from the vendor anyway, self-hosting buys one handshake and a maintenance job, and your effort belongs elsewhere: deferring it, facading it, moving it server-side, or removing the vendor.
- Someone argues to keep the vendor's CDN because visitors will already have the file cached from other sites. Is that still true?No. Browsers now partition the HTTP cache by top-level site, so a copy fetched while the user was on another site is not reused on yours. The argument was reasonable years ago and was closed deliberately, because a shared cache leaked cross-site information.
- You self-host a vendor script and cache it for a year. What has to be true for that to be safe?The URL must be content-addressed or versioned, so publishing a new copy means a new URL rather than waiting for caches to expire. You also need a job that checks for vendor updates and a way to notice breakage, since a long lifetime makes a bad copy long-lived on users' devices.
- When does self-hosting deliver almost no measurable benefit?When the file is a thin loader that immediately fetches its real payload and configuration from the vendor's origins. You have removed one connection setup and kept every other request, plus taken on a maintenance pipeline. Measure the script's runtime requests before committing to the work.
saying these in an interview costs you the question
- Claiming the shared public CDN copy is already cached
- Assuming self-hosting changes what the script can access
- Pinning a copy with no update or review process
- Ignoring vendor terms that forbid rehosting
- Promising a win without checking the script's runtime fetches