Providing Local JS and CSS Resources for CDN Fallbacks

Question

Given that

• CDNs are a Good Thing because they can serve resources closer to the client, the client can cache them, and you can reduce load on your own server.
• In recent browsers, loading resources from third-party servers does not decrease security thanks to Subresource Integrity (SRI).
• CDNs may be down or blocked in some countries, and are not available when developing offline¹.

I think it is compelling to use CDNs, but also to be prepared for them to be unavailable. This blog post gives a nice introduction to different approaches for providing fallbacks. If you look at the Basic example, you can see that it already contains quite a bit of boilerplate code to provide fallbacks for just jQuery and Bootstrap, while the favored solution suggests using Fallback.js, which seems to be largely unmaintained for the past year. Similarly, the most relevant SO question for the topic is only about providing a fallback for jQuery.

However, in most real-world projects, I would expect to have 5 or more js/css resources, so I feel like you shouldn't have to repeat some messy boilerplate to provide fallbacks for all of them. Furthermore, every time you add or update a resource, you now have to

• Update the CDN link
• Update the local fallback copy by manual download or changing version in npm/bower config
• Update the link to the fallback
• Update the SRI hash

Whereas in the Ideal World, I would expect to add/update the resource in one configuration file, and have all the other steps execute automatically (and then run tests to see if the update broke anything).

Is there already an established workflow to achieve this?

Or are CDNs, and especially SRI, still too recent?

Or do most people simply not care to provide fallbacks for CDN resources?

---

_{1. Although you could have a dev build that doesn't rely on CDNs, but I also consider that a form of fallback, since it also needs to be maintained.}

Answer 1

I think you perhaps misunderstand how larger sites which might need this kind of resilience use CDNs.

it's not just a matter of hosting jQuery or some images. The majority of the site will be hosted on the CDN, with only dynamically generated things like payment pages or shopping baskets being hosted on the 'primary webfarms'

Even these are moving more and more to being processed locally with JS and cookies to display user specific stuff without hitting server side processing.

If a CDN fails and you start getting all the traffic passed to your webserver, it is likely to fall over, otherwise you didn't really need the CDN.

Answer 2

The site I work on our CDN has become more and more important to the site. In the beginning we simply used it to cache Images/CSS/JS. At this stage we had a config property that rewrote the host name of these resources from www.mysite.com/ to www.cdn.com/ so if the CDN went down we could simply change this host value or turn it off completely and leave the urls pointing to our webserver.

However we have now moved on to caching basically entire pages with personalised content being loaded in via AJAX. Our CDN has become essential to our site and we could as much run without it as we could our own HTTP servers. We pay our CDN good money in part because of there resilience and SLA promises of uptime therefore putting time and effort into fallbacks seems a waste of time. We do have a DR plan in place just incase there is a major issue with our provider but it is not a simple automated process and would see a period of outage as we migrate to our fallback CDN.

So in answer to your question it depends on how integral to your site the CDN is. If it is just your assets you are putting into the CDN and assuming your http servers could handle the load of serving this content out then you can use a config switch to essentially turn on or off the CDN. Coupled with a monitoring tool you can automate that switch being on or off.

Answer 3

I see 3 very important reasons for using CDNs:

1. Reduce network latency for users in distant regions. When you have a web site for global audience, your hosting in North America would not seem fast for users in South Asia, especially, in China. The difference in user experience may be so huge that it will discourage users from using your site. In this case multi-regional CDN will be essential for your business.

2. Serve as much as possible from highly available resource. Reliability is one of the primary reasons for using cloud CDNs - the traffic is automatically rerouted to the available nodes and you can add some extra measures to reroute traffic if the whole cloud region is down.

3. CDN is easier to maintain and cheaper than application servers that serve dynamic content. When you have to deal with problems mentioned above, it's natural way to save the money.

All this means, that the goal of CDN is to increase availability of your content to end users. If CDN fails or becomes slow for some reason, the client-side fallback will significantly increase page load, because it will first try to get the resource that is not accessible. Better solution is to have the server-side design that will make a substitution of base URL in links like "{CDN}/js/jquery-version-min.js". This will allow to re-route the traffic to application server instead of CDN if CDN health check fails - clients will not perform unnecessary requests and will go directly to app server, which would be your fallback with client-side solution. This will also solve problem of local and staging deployments, because you can implement the substitution logic to determine the location of static resources based on environment and configuration.