You may have already heard about Single Points Of Failure (SPOF), generally dealing with network matters. Did you know that SPOF is also an issue at front-end dev stage? Could you imagine your website to be reliant on Twitter or Facebook’s servers?
About frontend SPOF
A Single Point Of Failure is a part of a system whose failure brings an overall breakdown. That could be called a critical dependency. To prevent such an overall breakdown, failover measures can be set, as duplicating the critical element (redundancy).
From a frontend perspective, while building a web page , you may also introduce a critical dependency, and then a SPOF. Those dependencies are generally related to third-party content. Occasions are quite numerous: according to httparchive.org data, a single web page typically loads assets from 21 domains. Widgets from social networks, adservers or analytics tags, A/B testing… Each of these external components can become a SPOF.
A script, a stylesheet or even a font file can have a blocking behaviour: web browsers wait for these assets to load before displaying the rest of the web page. If you use DareBoost website speed tests, you already know it: those blocking components are disastrous for web performance, as a page loading time will depend on the response time of all those various elements.
Talking about Frontend SPOF is about the same idea, but it’s the worst scenario: what if these assets response times weren’t slow but not responding at all? What happens then? A blank web page for a looooooong time (they’re blocking!). With a variable duration depending on the web browser (several timeout policies, generally dozens of seconds)… Anyway an unbearable situation for any visitor, who is not going to wait this long before leaving!
You could argue that most of these third-party content’s providers, like Facebook or Google for instance, are solid enough to prevent you from any risk of such failures.
You would be mistaken.
Previous famous failures
In 2012, Facebook had to face a 3 hours long period of slow down and repeated failures. Even if the availability of a social network for a few hours doesn’t seem so dramatic, consequences have been severe for thousands of web sites… Those using a blocking integration of the famous Like button! As Forbes magazine explained it, this simple social widget leads then to dramatic economic consequences: web surfers don’t make the difference between this type of failure and a “real” unavailability of your own web site: they will just move to your competitors’.
Another example: in 2014, a failure at DoubleClick (Google’s ad server) affected thousands of websites worldwide, causing severe slow-down and even total breakdown for some of them. Almost 2 hours of nightmare for those publishers as related in this article.
More recently (2015) that has been Typekit’s turn. This font provider outage brought similar consequences on a lot of websites. Still, we can appreciate this detailed Typekit’s post about this outage, including an emergency update of their documentation in order to promote a new snippet that load fonts asynchronously…
Multiple sources of failure
In those cases, failures are directly due to content providers. Unfortunately, There are many other sources that can reveal SPOF within your website.
Example: Chinese users whose access to a lot websites is blocked by the Great Firewall. Some of these blocked domains are 3rd party content providers. As a consequence, chinese people will experience SPOF the same way than if these content providers were down.
Similar issues can occur with other audiences, even without any censorship measures: you are never totally safe from a network issue.
How to avoid SPOF?
Let’s start ensuring you have got the right point of view: considering that any third-party content may (will?) experience an outage, you will spontaneously try to reduce these dependencies. Even if those kinds of accidents are quite rare (especially with big providers quoted previously in this post), the more you cumulate third-party content, bigger is the failure probability for your website.
In most of cases, you have no other choice but to use some third-party content. Then you should choose asynchronous integrations (which are not necessarily the ones to be promoted by the providers).
Make sure you have a fallback in case of problem. For example, if you use a public CDN for your Javascript framework, it could be useful to host a local copy on your own site (that will be used if the CDN is down). A few libraries can help you to set this kind of mechanisms and to control the loading of your assets (as LABjs, Head.JS,…).
In a few days, we’re going to announce the list of the main cases of SPOF that DareBoost will be able to detect (from the end of this month). As usual, you will find related guides to help you to optimize your website.
At last, let us remind you that you can use DareBoost’s monitoring tool to warn you in any case of slow-down of your web site!