8 ms·

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

123 points by dwalkr 8y ago

seba_dos1 8y ago
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.
yakcyll 8y ago
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.
- alexcabrera 8y ago
  For content-driven websites, static sites are great regardless of editorial complexity. We (https://www.marquee.studio https://www.marquee.studio) build editorial tools that connect to our headless CMS (https://www.proof.pub 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 http://firstround.com/review), you've seen it in action.
- 0xCMP 8y ago
  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.
ireflect 8y ago
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.
- jgrahamc 8y ago
  Or have a CDN (e.g Cloudflare) support IPFS and get the best of both worlds.
- dwalkr 8y ago
  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.
- prophesi 8y ago
  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.
  - StavrosK 8y ago
    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.
alanfranzoni 8y ago
Unless you don't want to give up at least partial control of your domain and content to an intermediary.
tw1010 8y ago
Laziness, premature optimization, better to get your idea out there instead of obsessing over tools. I can think of several.
rf1331 8y ago
Any site that cares about SEO should definitely use one.
- enz 8y ago
  May I ask why?
londons_explore 8y ago
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.
- timc3 8y ago
  You do realise they are talking about static sites with no user private data?
  - cyphar 8y ago
    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.
  - ajnin 8y ago
    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.
  - endorphone 8y ago
    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.
    - jedimastert 8y ago
      I keep forgetting that MITM attacks can work both ways. I need to keep it in the list on "why you should use HTTPS"
  - 8y ago
ajnin 8y ago
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.
- saas_co_de 8y ago
  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.
  - staplers 8y ago
    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.
    - kingsleyokei 8y ago
      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.
      - deleted 8y ago
        [deleted]
sebringj 8y ago
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.
- cortesoft 8y ago
  You can purge content from most CDNs through an api.
  - sebringj 8y ago
    Absolutely true but try telling that to your designers using Cloudfront.
mrb 8y ago
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/ http://blog.zorinaq.com/release-of-hablog-and-new-design/
- gnode 8y ago
  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.
- ifbizo 8y ago
  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?
- cortesoft 8y ago
  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.
  - mrb 8y ago
    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.
JeanMarcS 8y ago
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 ?
- organsnyder 8y ago
  > ... 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.
someonewhocar3s 8y ago
"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"
patrickg_zill 8y ago
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.
yoz-y 8y ago
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.
- zrail 8y ago
  A full RSS feed is a really good candidate for putting on a cdn though. It doesn’t change often and is really big.
  - yoz-y 8y ago
    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.
dorfsmay 8y ago
"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.
- pwg 8y ago
  Mobile Firefox plus uBlock origin set to block all 3rd party scripts and no 'subscribe' popup appeared for me.
727374 8y ago
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.
blueflow 8y ago
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.
- lunixbochs 8y ago
  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.
russh 8y ago
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.
nzoschke 8y ago
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://www.mixable.net/blog/making-heroku-fast/ https://elements.heroku.com/addons/edge https://elements.heroku.com/addons/edge
andreareina 8y ago
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).
enriquto 8y ago
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.
lowbloodsugar 8y ago
I used Amazon Cloudfront for this tiny blog describing how to set up a tiny blog using Cloudfront. [1] [1] http://www.jamiebriant.com http://www.jamiebriant.com
starchy 8y ago
CDNs are great, but can we stop upvoting abusive headlines?
LinuxBender 8y ago
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.
originalsimba 8y ago
That headline is the worst, dumbest advice I've read about CDNs to date.

123 points by dwalkr 8y ago

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.

yakcyll 8y ago

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.

alexcabrera 8y ago
For content-driven websites, static sites are great regardless of editorial complexity. We (https://www.marquee.studio https://www.marquee.studio) build editorial tools that connect to our headless CMS (https://www.proof.pub 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 http://firstround.com/review), you've seen it in action.
0xCMP 8y ago
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.

ireflect 8y ago

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.

jgrahamc 8y ago
Or have a CDN (e.g Cloudflare) support IPFS and get the best of both worlds.
dwalkr 8y ago
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.
prophesi 8y ago
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.
- StavrosK 8y ago
  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.

alanfranzoni 8y ago

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

tw1010 8y ago

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

rf1331 8y ago

Any site that cares about SEO should definitely use one.

enz 8y ago
May I ask why?

londons_explore 8y ago

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.

timc3 8y ago
You do realise they are talking about static sites with no user private data?
- cyphar 8y ago
  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.
- ajnin 8y ago
  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.
- endorphone 8y ago
  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.
  - jedimastert 8y ago
    I keep forgetting that MITM attacks can work both ways. I need to keep it in the list on "why you should use HTTPS"
- 8y ago

ajnin 8y ago

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.

saas_co_de 8y ago
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.
- staplers 8y ago
  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.
  - kingsleyokei 8y ago
    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.
    - deleted 8y ago
      [deleted]

sebringj 8y ago

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.

cortesoft 8y ago
You can purge content from most CDNs through an api.
- sebringj 8y ago
  Absolutely true but try telling that to your designers using Cloudfront.

mrb 8y ago

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/ http://blog.zorinaq.com/release-of-hablog-and-new-design/

gnode 8y ago
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.
ifbizo 8y ago
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?
cortesoft 8y ago
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.
- mrb 8y ago
  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.

JeanMarcS 8y ago

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 ?

organsnyder 8y ago
> ... 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.

someonewhocar3s 8y ago

"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"

patrickg_zill 8y ago

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.

yoz-y 8y ago

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.

zrail 8y ago
A full RSS feed is a really good candidate for putting on a cdn though. It doesn’t change often and is really big.
- yoz-y 8y ago
  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.

dorfsmay 8y ago

"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.

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

727374 8y ago

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.

blueflow 8y ago

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.

lunixbochs 8y ago
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.

russh 8y ago

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.

nzoschke 8y ago

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://www.mixable.net/blog/making-heroku-fast/ https://elements.heroku.com/addons/edge https://elements.heroku.com/addons/edge

andreareina 8y ago

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

enriquto 8y ago

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.

lowbloodsugar 8y ago

I used Amazon Cloudfront for this tiny blog describing how to set up a tiny blog using Cloudfront. [1] [1] http://www.jamiebriant.com http://www.jamiebriant.com

starchy 8y ago

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

LinuxBender 8y ago

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.

originalsimba 8y ago

That headline is the worst, dumbest advice I've read about CDNs to date.