For Static Sites, There’s No Excuse Not to Use a CDN

Is this an ad for Netlify ? It&#x27;s cited 10 times in the post.<p>There are plenty of reasons not to use a CDN, not the least being that you might not want to give a third-party access to your traffic. Even static information might be sensitive, accessing some forbidden data can put people at risk. The central position CDN are increasingly taking on the Internet make then worryingly nice targets for snooping by surveillance bodies.

CDNs make a lot of sense for improving load times and for the overall efficiency of network utilization, but I worry that the current ones (Cloudflare et al.) contribute too much to the recentralization of the Internet.<p>What we need is for gateway.ipfs.io to use geo-dns such that it can serve this purpose, and IPFS gateways can be run all over the world by regional ISPs, universities, and even individuals.

CDN&#x27;s also ruin HTTPS security.<p>As a domain owner, you have to give your HTTPS private keys, and all your users private data (authentication cookies, passwords, etc.) to your CDN, or you have to do a lot of careful dividing up the &quot;static&quot; resources from the dynamic stuff on different domains, serving them with different certs.<p>As a web user, some CDN&#x27;s like cloudflare offer &#x27;HTTPS&#x27;, but with plain HTTP as the backhaul to the origin server. That tricks the user into thinking their connection is secure, which is, IMO, immoral.

My site is not using an CDN and faster than forestry.io.<p>Mostly due to the fact that its 2 statically resources than can be loaded in around 0.3 seconds.<p>Foresty.io can load the HTML and the CSS in the same amount of time, but then another 8 megabytes of JavaScript and imagery follows.<p>Optimizing for ping time is premature optimization when website obesity is the elephant in the room.

Unless you don&#x27;t want to give up at least partial control of your domain and content to an intermediary.

I see plenty of possible excuses, starting with the easiest one to come up with being not wanting any intermediaries so the TLS connection is truly end-to-end.

&quot;Subscribe to our newsletter to get the posts directly in your inbox.&quot;<p>No! Of course not!<p>I don&#x27;t understand why every damn site add those annoying popup. I would love to know his many subscriptions sites receive from those popup.

Laziness, premature optimization, better to get your idea out there instead of obsessing over tools. I can think of several.

Isn’t http2 resolving the latency problem (after the first connection of course) ?<p>You open one connection and then the rest flows. For static sites it might be enough.<p>Of course, in case of worldwide audience it might be a problem, but with DNS anycast can’t you resolve this with putting your website on local providers ?

I have a very good excuse for NOT hosting my site on &quot;a CDN&quot;: one CDN is a central point of failure. Instead I host it on 3 geographically redundant dumb servers from 3 different hosting providers (and all my DNS records resolve to 3 IPs.) As a result my site has had 100% uptime since its deployment years ago, despite many individual outages at these hosters. There has also been multiple occurrences where an entire swath of the web was down because of outage at $CDN, while my site was chugging along just fine.<p>I think the most likely outage I might encounter would be due to operator error, eg. accidentally pushing a bad web server config to my 3 servers.<p>More details: <a href="http:&#x2F;&#x2F;blog.zorinaq.com&#x2F;release-of-hablog-and-new-design&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.zorinaq.com&#x2F;release-of-hablog-and-new-design&#x2F;</a>

Every site that needs a CDN probably already has one, because it&#x27;s a quick win. For every site that doesn&#x27;t need one (small user base, small asset size, etc) it&#x27;s likely not worth the added complexity.

There is a middle ground, which I have done for hobby sites that sometimes get popular by mistake.<p>I set up dozens of caching reverse proxies, distributed on a few VPS providers. Each VM then uses strongswan to route to my primary origin servers. In some cases, there is no extra bandwidth cost, if the caching VM&#x27;s happen to be in the same datacenter as the origin servers, as I can use the private interfaces for my strongswan traffic.<p>If I want to poorly mimic the geographic DNS behavior of CDN&#x27;s, I can use split views in DNS to very roughly send people to a closer caching proxy. It isn&#x27;t perfect, but then neither are CDN&#x27;s.<p>To take this a step further, I can use multiple domains with TLS SNI from different registrars to provide some take-down resistance.<p>The advantage to this model is that one CDN or VPS provider does not have control over my content.<p>The drawback is that I have to manage these nodes myself. Nowadays that isn&#x27;t too bad, because each VPS allows for making API calls to spin up VM&#x27;s with pre-built images. Ansible also allows for adding new nodes dynamically. There are community playbooks for most VPS providers.

I don&#x27;t think I&#x27;m up to date with the Web enough to understand the selling point of this article. Is it not that most use cases of static sites are not at all concerned with latency or bandwidth, but rather simplicity and presentation? My perspective is limited in scope, mostly to personal projects, so some additional insight will be much appreciated.

CDNs are great in general.<p>I find myself putting CloudFront in front of pretty much everything to unlock speed, security and now even functionality like auth thanks to Lambda@Edge.<p>I have a CloudFront add-on for Heroku that, in some cases, can double performance without any application changes.<p><a href="https:&#x2F;&#x2F;www.mixable.net&#x2F;blog&#x2F;making-heroku-fast&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.mixable.net&#x2F;blog&#x2F;making-heroku-fast&#x2F;</a> <a href="https:&#x2F;&#x2F;elements.heroku.com&#x2F;addons&#x2F;edge" rel="nofollow">https:&#x2F;&#x2F;elements.heroku.com&#x2F;addons&#x2F;edge</a>

The only part I had an issue with in terms of a CDN was expiring content fast enough when making changes as it seemed to be a headache worrying about that as I can&#x27;t count how many times a customer asked &quot;should I refresh?&quot; but I guess then it should be a dynamic site if changes are frequent enough. Using Netlify seemed to handle this problem of expiration for me and I do believe they are using AWS and are handling the details or caching and expiring headers etc. so I would recommend using a service that removes worrying about that part.

Page authors: for content sites, there&#x27;s no excuse to auto-focus on the search bar, it breaks keyboard navigation (and given the content, you can expect that a large portion of your audience uses it).

I used Amazon Cloudfront for this tiny blog describing how to set up a tiny blog using Cloudfront. [1]<p>[1] <a href="http:&#x2F;&#x2F;www.jamiebriant.com" rel="nofollow">http:&#x2F;&#x2F;www.jamiebriant.com</a>

I like to do statistics of user agents and ip localization. If the files are hosted on a cdn the http logs are not easily available. For me this is the biggest reason for self hosting.

For static sites of a huge size and with lots of visitors maybe. But hey, if you publish a full RSS feeds then you don&#x27;t even need to care.

And if you have people in China that use your site some of the CDN&#x27;s are blocked and can&#x27;t be reached from behind the GFoC.

CDNs are great, but can we stop upvoting abusive headlines?

The total size of the HTML on that page (including stuff that loads JS and tracking images) is 30KB. It&#x27;s all the &quot;other&quot; stuff that makes the site feel slow IMHO... perhaps for marketing purposes they want to track everything; but for actually transferring information, a CDN would not help them given how quickly a few hundred KB can be served.

Any site that cares about SEO should definitely use one.