For Static Sites, There’s No Excuse Not to Use a CDN | Hacker News Reader

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

forestry.io

123 pointsdwalkr75 comments

Is this an ad for Netlify ? It's cited 10 times in the post.

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.

There is also very little benefit to putting pages on a CDN.

CDNs are beneficial for images and static asset files because pages often have dozens of those so the small speed up of going through a CDN is multiplied many times over.

The difference yielded by moving a single file (the primary page) to CDN is unlikely to make any measurable benefit overall unless you specifically run a site with a very geographically distributed user base.

Even for sites with a NA/European user base you can host in either US or Europe and it makes no difference. The latency is not significant compared to other performance issues.

Block 3rd party scripts by default and its amazing how many pages will simply not load at all. CDNs will eventually exert their power if this practice keeps growing.

I imagine data mining for CDNs is very lucrative given they interface customer AND business.

Since you use the phrase "by default" when you say they block 3rd party scripts, I'm assuming you are aware that the weakness can be overcome by simply turning-off that feature from withing the CDN Provider's Web Interface. At least I know Cloudflare allows that.

  they block 3rd party scripts

"They" who? I am blocking 3rd party scripts with uBlock..

And HTTP/2 further reduces the benefit of a CDN for small assets (vs. no CDN), since requests are asynchronous and multiplexed, giving you better performance.

> There is also very little benefit to putting pages on a CDN.

Well, you can often pay much less for bandwidth than alternate solutions.

Agreed. While they're not fully static, our websites are used in tens of thousands of schools nationwide. A CDN (no matter the provider) was getting blocked by some district somewhere for some reason or another (dedicated IP or not). This created all sorts of failover overhead for us. In the end, we bagged the CDN (for the main services, at least).

While I certainly agree that there are lots of reasons not to use a CDN, Netlify is pretty cool and useful for certain purposes. I've started using them for a 'static' blog via Hugo and someone (not me) figured out a clever way of having comments powered by Webmentions which relies on Netlify's API to trigger rebuilds (it's nice because it results in the ability to have a Javascript-free site without paying money for some comment-service or having to have my own server to host comments on; it can be done just with a free Gitlab/Github account).

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.

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.

I definitely agree. The point I wanted to make here is that setting up replication for a static site is trivial due to their static/stateless nature (you can just use a CDN.) These same qualities make distributing a static site over IPFS easy to do too.

Yeah, +1 to this. I'd use a CDN if it wasn't all owned by one company. I run a static site on IPFS, and just have two nodes located in NYC & San Francisco that my local gateway is always connected to.

It does a pretty good job for USA visitors (which is where the majority of my traffic comes from). But it'd be ideal for IPFS to use geo-dns, along with FileCoin implemented so that I can pay for nodes in other countries to have my content pinned.

Also, my site uses Service Workers to cache all of the content + TurboLinks, which drastically speeds up every subsequent page transition. I'm not sure if that's doable if you're using an external CDN like Cloudflare for all of your resources.

Has the team done much since they raised $250 million? I've only seen one or two releases since, and the commit graph looks very slow. It's been a while since I checked, though, I might be out of the loop.

There's been a lot of activity with the JS implementation of IPFS, but I'd agree that the core IPFS development has been lackluster lately.

Do you have a blog on setting this up per chance? I'm interested in reading more about IPFS (haven't looked at it since I first heard about months and months ago). Their website seems a bit light on the details bar a link to a whitepaper I haven't dared to look at yet ;)

Here is one: https://medium.com/@merunasgrincalaitis/how-to-host-your-ipf...

Or have a CDN (e.g Cloudflare) support IPFS and get the best of both worlds.

A fundamental issue with CDNs is that you have to trust them. Even for public content, who accesses what is valuable private information. I can imagine IPFS making this worse, when anyone who wants to observe what is accessed by whom need only mirror it.

If the SV/Startup set ever move past this ridiculous "outsource all the things" idea, now is as good a time as any to enable realistic self-owned CDN's using a lot of low-resource nodes across a variety of providers around the globe/your service area.

CDN's also ruin HTTPS security.

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 "static" resources from the dynamic stuff on different domains, serving them with different certs.

As a web user, some CDN's like cloudflare offer 'HTTPS', 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.

You do realise they are talking about static sites with no user private data?

TLS provides other security properties than just confidentiality (not to mention that confidentiality can be useful even if the files are public and static), and inteionally MITMing your site will break those properties as well.

What if the static site is hosting some information banned in a specific country ? Simply accessing it might put a person at risk. I'm being very general here as you can find examples for practically anywhere.

TLS should be everywhere, whether private data or not. Any intermediary can be adulterating the payload otherwise, and we know that some carriers, routers, adware, etc, do.

I keep forgetting that MITM attacks can work both ways. I need to keep it in the list on "why you should use HTTPS"

What public data you access is in itself private data. Even if you don't care about your personal privacy, I think we should all care about the chilling effects of people not being afforded privacy to look at public information.

That people can browse Wikipedia, and their ISP / government is prevented from knowing whether the article being read is about knitting or a political issue is a good thing.

Ok good point.

This is true, but how could a CDN possibly cache a response without access to it? Unfortunately it seems to be a necessity.

> This is true, but how could a CDN possibly cache a response without access to it?

It can't, which is why it's ridiculous to say "there's no excuse not to use a CDN".

Cloudflare offers the option to use plain HTTP to your backend. You can use TLS between Cloudflare and the origin server if you want to. I think it's a stretch to say having that option is immoral. I can understand the concern however and it would be nice if there was at least a mechanism for making users aware of this.

They give you the option of "Full (strict)" SSL. Or as I call it, "actual SSL".

Snark aside, it at very least dilutes the brand of SSL to give the pretense that they're giving it to you with the default option, and give you the pretense of giving you something extra on top of it with the "full (strict)" option.

Full is still encrypted, just not checked to match the domain.

For example, until recently many people used it to add a custom domain to sites hosted on github pages, but the connection from CF to GH was still encrypted.

> or you have to do a lot of careful dividing up the "static" resources from the dynamic

Static / dynamic is orthogonal to private / non-private. It's important to consider that what public or static information a user requests may be private for them.

Consider for instance, if I go to WebMD's page on e.g. Lupus. If the static, public image on the page were pulled in from a CDN, the fact I visited that page is now leaked to a third party, for which they could infer whatever they wanted to. Or maybe sell that on, so drug companies can hit me up with targeted ads.

> Or maybe sell that on, so drug companies can hit me up with targeted ads.

If you're using an ad blocker, wouldn't this be irrelevant? The drug company would be wasting money buying data that will be worthless.

> If you're using an ad blocker, wouldn't this be irrelevant?

No; using an ad blocker won't prevent this kind of data collection. Ad blockers prevent you seeing ads, and some can block certain page elements associated with data collection (e.g. social media buttons), but this type of data collection is indistinguishable from the content itself.

While there are still other users who don't block ads, the incentive to collect such data for targeted advertising exists, and I think it's unlikely you will be specifically excluded from the dataset on this basis. I think it's also worth bearing in mind that it's in the interest of a data vendor to inflate expectations of the relevance of the data they sell.

My site is not using an CDN and faster than forestry.io.

Mostly due to the fact that its 2 statically resources than can be loaded in around 0.3 seconds.

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.

Optimizing for ping time is premature optimization when website obesity is the elephant in the room.

They nail this in the article, but draw the wrong conclusion:

> Communicating with the more distant server caused a 500% increase in round-trip latency. 250 milliseconds may sound like a short amount of time, but this time penalty applies to every request the user makes to that server: CSS, JavaScript, images, etc. Even small amounts of latency can negatively impact your site. If there were an easy way to eliminate this latency, wouldn’t you want to do it?

(150 assets | 8MB (lol)) may sound like a small amount of data, but bandwidth delay product and sequential asset requests can result in time penalties which are multiplied with latency to significantly increase page load time.

You can optimize your TLS handshake (you're using TLS, right?) to fit in fewer TCP fragments (don't include the whole chain), use OCSP stapling so the client doesn't need to make a separate request to your certificate authority before starting to load your site.

You can remove the penalty of sequential asset fetches using HTTP/2 to push / prefetch assets. This should almost completely eliminate "asset delay product" parts of your load time from having too many assets that aren't queued as part of the initial request.

You can cheat bandwidth delay product by using Google's BBR TCP congestion control on your servers, which provides much higher bandwidth in the face of packet loss (packet loss which will probably be more likely for clients with higher ping). You might not really notice this, but someone loading your site from Australia over janky undersea cables will thank you later.

At this point, if you look at the flame graph of your site loading, you may have realized that the steaming garbage heap of JavaScript and fonts is still taking several seconds to literally transfer over the network and parse. You should now meditate on what part of "static site" requires so much dynamic client code, and try to trim your site down to something that could at least fit on an effing floppy disk.

Maybe after you've looked at all of these, maybe, if you have globally distributed users and site load time is still a major issue for you, maybe then evaluate what putting a CDN in the middle would do for your load time. But loading your site from a CDN will never make up for the 5 second render time caused by your endless bloated chain of abstractions.

0.3 seconds seems really long for that - are you storing the files on disk or in memory?

I mean I really agree with you and think more people should do exactly what you're doing, but comon, let's bikeshed this at least a little :)

Both - on disk, but the kernel caches it in memory. Not everyone is blessed with an fast internet connection.

Unless you don'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.

"Subscribe to our newsletter to get the posts directly in your inbox."

No! Of course not!

I don't understand why every damn site add those annoying popup. I would love to know his many subscriptions sites receive from those popup.

Mobile Firefox plus uBlock origin set to block all 3rd party scripts and no 'subscribe' popup appeared for me.

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) ?

You open one connection and then the rest flows. For static sites it might be enough.

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 ?

> ... with DNS anycast can’t you resolve this with putting your website on local providers ?

Then you're effectively rolling your own CDN. Definitely an option for some cases, but overly complex and costly for most.

I have a very good excuse for NOT hosting my site on "a CDN": 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.

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.

More details: http://blog.zorinaq.com/release-of-hablog-and-new-design/

Thanks, love the post! Your DNS method is fine for basic redundancy, but what about actual load balancing, for when 1 of the 3 servers gets hit hard?

You can do the same redundancy with CDNs. Most big sites use a multi-CDN solution, and balance traffic based on price and performance, with the added benefit of automatic failover if a CDN has issues.

I've never seen any multi-CDN setup that fully avoids central points of failures. For example Cloudflare requires making Cloudflare nameservers the authoritative servers for your domain name. Therefore if they have an outage (and if the records aren't cached at the client level,) then your website is going to be inaccessible.

Really? I can't imagine you HAVE to set your NS to Cloudflare, there has to be alternatives. I work for a CDN, the idea of requiring a customer to set us as their NS is crazy to me.

You post doesn't seem to really be advocating not using a CDN, but running your own CDN. Many people don't have the time / budget / inclination to do this themselves.

Very interesting. I've read your article and saw you're relying on DNS pinning, a concept that I didn't know about. What happens if the first GET request from a browser resolves to an IP that happens to be down? Will it retry the other A record's IP?

I read your blog post and some of the comments, and I don't see how you can justify this claim:

> As a result my site has had 100% uptime since its deployment years ago

Assuming your individual hosts did go down occasionally, how do you know how many of your visitors waited 2 or 3 minutes for the browser to try the alternative IP?

If you have no service level requirements, you definitionally have 100% uptime.

Every site that needs a CDN probably already has one, because it's a quick win. For every site that doesn't need one (small user base, small asset size, etc) it'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.

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's happen to be in the same datacenter as the origin servers, as I can use the private interfaces for my strongswan traffic.

If I want to poorly mimic the geographic DNS behavior of CDN's, I can use split views in DNS to very roughly send people to a closer caching proxy. It isn't perfect, but then neither are CDN's.

To take this a step further, I can use multiple domains with TLS SNI from different registrars to provide some take-down resistance.

The advantage to this model is that one CDN or VPS provider does not have control over my content.

The drawback is that I have to manage these nodes myself. Nowadays that isn't too bad, because each VPS allows for making API calls to spin up VM's with pre-built images. Ansible also allows for adding new nodes dynamically. There are community playbooks for most VPS providers.

I don't think I'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.

For content-driven websites, static sites are great regardless of editorial complexity. We (https://www.marquee.studio) build editorial tools that connect to our headless CMS (https://www.proof.pub) and compile static websites to be distributed on a CDN. Sites load quickly, and it's a much safer to have your CMS decoupled from the eventual editorial product.

If you read [The First Round Review](http://firstround.com/review), you've seen it in action.

By static sites they mean more than just a bundle of markup, but a website created using a Static Site Generator (Jekyll, Hugo, etc.) and because of GitHub Pages it's become popular to make it that simply pushing to a git repo with the markup for one of these tools will trigger a task to pull the repo, compile the markup, and serve up the result.

GitHub pages is free and highly scalable, but unless you're a paying user GitHub has some limits. So for things like very popular projects you could simply move your stuff to a server+nginx or s3+cloudfront. However, these cost money so it's hard for many to justify doing that when GitHub Pages is free. In comes Netlify which provides the "better" GitHub Pages experience with the ability to use whatever you want that can be installed using go, python, ruby, or node and the resulting markup is distributed via a CDN all for free.

With such a nice deployment story the question becomes: why not just put every website like this? Mainly because it's all based on using Git to edit markdown files which usually non-technical people have issues with. Netlify offers NetlifyCMS as a solution to this and Forestry offers a more robust version of this with a more powerful and clean editor.

CDNs are great in general.

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.

I have a CloudFront add-on for Heroku that, in some cases, can double performance without any application changes.

https://www.mixable.net/blog/making-heroku-fast/ https://elements.heroku.com/addons/edge

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't count how many times a customer asked "should I refresh?" 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.

You can purge content from most CDNs through an api.

Absolutely true but try telling that to your designers using Cloudfront.

Page authors: for content sites, there'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]

[1] http://www.jamiebriant.com

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't even need to care.

A full RSS feed is a really good candidate for putting on a cdn though. It doesn’t change often and is really big.

Yes, but in the current landscape you can punt it off to Feedbin, Feedly and other services like that since they are those who will to the bulk of the serving.

And if you have people in China that use your site some of the CDN's are blocked and can'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's all the "other" 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.

May I ask why?

Reply on news.ycombinator.com