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.
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.
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 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.
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 ;)
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.
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.
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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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?
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 ?
"I would like my visitors not to be spied upon by a huge CDN, which I only have to use due to DOS and my own wastefulness wrt bandwidth bc holy moly computers are fast nowadays"
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.
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.
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.
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.
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.
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 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.
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.
81 comments
[ 3.9 ms ] story [ 134 ms ] threadIf you read [The First Round Review](http://firstround.com/review), you've seen it in action.
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.
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.
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.
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.
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.
It can't, which is why it's ridiculous to say "there's no excuse not to use a CDN".
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.
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.
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.
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.
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.
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 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.
I imagine data mining for CDNs is very lucrative given they interface customer AND business.
Well, you can often pay much less for bandwidth than alternate solutions.
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/
> 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?
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 ?
Then you're effectively rolling your own CDN. Definitely an option for some cases, but overly complex and costly for most.
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.
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.
> 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.
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 :)
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
[1] http://www.jamiebriant.com
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.