4 ms·

Latency of a new request as mentioned in one of those articles is the main reason why I self host everything. Since HTTPS needs an extra round trip to startup,

Latency of a new request as mentioned in one of those articles is the main reason why I self host everything. Since HTTPS needs an extra round trip to startup, it's now even more important to not CDN your libraries. The average bandwidth of a user is only going to go up, and their connection latency will remain the same. If you are making a SaaS product that business want, using CDNs also make it hard to offer a enterprise on-site version as they want the software to have no external dependencies.

cortesoft 10y ago
This might make sense, if all of your users are located near your web servers and you can comfortably handle the load of all the requests hitting your web servers. If the user making the request is in Australia, for example, and your web server is in the US, the user is going to be able to complete many round trip requests to the local CDN pop in Australia in the time it takes to make a single request to your server in the US. Latency is one of the main reasons TO use a CDN. A CDN's entire business model depends on making sure they have reliable and low latency connections to end users. They peer with multiple providers in multiple regions, to make sure links aren't congested and requests are routed efficiently. Unless you are going to run datacenters all around the world, you aren't going to beat a CDN in latency.
- detaro 10y ago
  Or you use a CDN in front of your site, caching the content under your domain. But certainly something to be aware of.
- extrapickles 10y ago
  If the only thing you have on the CDN is libraries, it's faster to have your site host them even if it's on the other side of the world. When HTTP2 file push is widely supported, it becomes even more in favor of hosting locally, as you can start sending your libraries right after you are done sending the initial page without waiting for the browser to request them. If you are using a CDN for images/video, then yes, you would have savings from using a CDN since your users will have to nail up a connection to your CDN anyways. Then again a fair number of the users for the site I'm currently working on have high latency connections (800ms+), so it might be distorting my view somewhat.

cortesoft 10y ago

This might make sense, if all of your users are located near your web servers and you can comfortably handle the load of all the requests hitting your web servers. If the user making the request is in Australia, for example, and your web server is in the US, the user is going to be able to complete many round trip requests to the local CDN pop in Australia in the time it takes to make a single request to your server in the US. Latency is one of the main reasons TO use a CDN. A CDN's entire business model depends on making sure they have reliable and low latency connections to end users. They peer with multiple providers in multiple regions, to make sure links aren't congested and requests are routed efficiently. Unless you are going to run datacenters all around the world, you aren't going to beat a CDN in latency.

detaro 10y ago
Or you use a CDN in front of your site, caching the content under your domain. But certainly something to be aware of.
extrapickles 10y ago
If the only thing you have on the CDN is libraries, it's faster to have your site host them even if it's on the other side of the world. When HTTP2 file push is widely supported, it becomes even more in favor of hosting locally, as you can start sending your libraries right after you are done sending the initial page without waiting for the browser to request them. If you are using a CDN for images/video, then yes, you would have savings from using a CDN since your users will have to nail up a connection to your CDN anyways. Then again a fair number of the users for the site I'm currently working on have high latency connections (800ms+), so it might be distorting my view somewhat.