Client point of failure: SPOF due to external JS libraries
In the quest for a fast site, many developers miss one important point: the client (front end) point of failure (frontend SPOF - single point of failure). Moreover, almost all tools for testing the speed of loading the site also do not reveal potential problems.
The ability of client SPOF is determined by the browsing features of the pages. For a better understanding of the rendering mechanism, I recommend reading my previous article on the critical page rendering path: habrahabr.ru/post/262239 .
A typical example of client SPOF:
The main thing that we know about the critical rendering path: the browser is blocked on the JS-code that it encounters on the page and on the CSS-files (for now let's omit the details). This means that we cannot see the page (all or part of it) until we get critical JS and CSS resources. If these resources are on the same server as the site, then this is a matter of time: wait, load and execute (or quickly get 404).
And what if we ship resources from other servers? In this case, the browser must first make a DNS request, connect to the server, send a request and wait for a response. And only then process the resulting resource and continue rendering the page.
This is where we come to understanding client SPOF. If your site has a critical JS or CSS resource loaded from an external source (another domain), you get a client point of failure (SPOF). At the same time, any server can act as an external source: a CDN node, an external site with JS-API, hosting of JS libraries, etc. If the external server responds slowly, we get guaranteed failure (slow or very slow rendering of the page). If the external server does not respond to requests at all, the browser will wait until the end of the timeout (maybe up to tens of seconds).
It may look like this (note the time above the screenshots).
For the user, the manifestation of SPOF at worst looks like a “site does not work”, at best as “a site is very slow”. In this case, your hosting works fine, there is no attack on the site, and the effect is like from a good DDoS.
The underlying article about the problem was written by Steve on June 1, 2010 , however, we constantly have to see sites that connect JS libraries to external hosting sites (apis.google.com, code.jquery.com, userapi.com, facebook, twitter, etc. .) The danger is the connection of scripts in the upper part of the HTML code in synchronous mode (without the “async” attribute).
Well, all this is scary, but we are loading files from super-reliable, never falling distributed CDN hosts! They always respond and do it quickly! Problems like and no ...
Unfortunately there is, that's why.
As a result, we get a time bomb. Usually, everything works fine, but there comes a time when the site suddenly “falls”. It is especially fun that the problem can be floating or affect only a fraction of the users.
What to do with all this? First, you need to find out the presence of SPOF on the site. To do this, we collect all the external hosts from which JS and CSS resources are being downloaded (you can also find out the sources of the connected fonts).
Secondly, you need to check what will happen if external hosts fail. The best tool for this, I consider Webpagetest.org with the SPOF tab. You can enter in this field all the hosts that will silently drop packets and do not respond. Select the test point of interest, the browser and run the usual test.
At the output we get two tests: normal and SPOF. On viewing screenshots of the page rendering, we see the severity of the effects of SPOF (as a rule, the moment of the start of rendering is delayed). Based on this data, it is already possible to make a decision on the transfer of resources or insurance against failures.
')
Such measures can be taken to eliminate or minimize the consequences of client SPOF.
That's all the recommendations. If you have accumulated your own experience in dealing with client SPOFs, write in the comments.
The essence of client SPOF
The ability of client SPOF is determined by the browsing features of the pages. For a better understanding of the rendering mechanism, I recommend reading my previous article on the critical page rendering path: habrahabr.ru/post/262239 .
A typical example of client SPOF:
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>jQuery UI Datepicker - Default functionality</title> <link rel="stylesheet" href="//code.jquery.com/ui/1.11.4/themes/smoothness/jquery-ui.css"> <script src="//code.jquery.com/jquery-1.10.2.js"></script> <script src="//code.jquery.com/ui/1.11.4/jquery-ui.js"></script> <link rel="stylesheet" href="/resources/demos/style.css"> <script> $(function() { $( "#datepicker" ).datepicker(); }); </script> </head> <body> <p>Date: <input type="text" id="datepicker"></p> </body> </html> The main thing that we know about the critical rendering path: the browser is blocked on the JS-code that it encounters on the page and on the CSS-files (for now let's omit the details). This means that we cannot see the page (all or part of it) until we get critical JS and CSS resources. If these resources are on the same server as the site, then this is a matter of time: wait, load and execute (or quickly get 404).
And what if we ship resources from other servers? In this case, the browser must first make a DNS request, connect to the server, send a request and wait for a response. And only then process the resulting resource and continue rendering the page.
This is where we come to understanding client SPOF. If your site has a critical JS or CSS resource loaded from an external source (another domain), you get a client point of failure (SPOF). At the same time, any server can act as an external source: a CDN node, an external site with JS-API, hosting of JS libraries, etc. If the external server responds slowly, we get guaranteed failure (slow or very slow rendering of the page). If the external server does not respond to requests at all, the browser will wait until the end of the timeout (maybe up to tens of seconds).
It may look like this (note the time above the screenshots).
For the user, the manifestation of SPOF at worst looks like a “site does not work”, at best as “a site is very slow”. In this case, your hosting works fine, there is no attack on the site, and the effect is like from a good DDoS.
Why is it important?
The underlying article about the problem was written by Steve on June 1, 2010 , however, we constantly have to see sites that connect JS libraries to external hosting sites (apis.google.com, code.jquery.com, userapi.com, facebook, twitter, etc. .) The danger is the connection of scripts in the upper part of the HTML code in synchronous mode (without the “async” attribute).
Well, all this is scary, but we are loading files from super-reliable, never falling distributed CDN hosts! They always respond and do it quickly! Problems like and no ...
Unfortunately there is, that's why.
- Even the most reliable hosting fall (even cloud).
- CDN distribution points can be far from the user (many do not have points in Russia).
- Static distribution services and library hosting are often free and do not have any guarantees of efficiency and responsiveness.
- The source host can be blocked at the level of the provider / country (for example, in China or in Russia).
As a result, we get a time bomb. Usually, everything works fine, but there comes a time when the site suddenly “falls”. It is especially fun that the problem can be floating or affect only a fraction of the users.
Check for the presence and severity of effects from SPOF
What to do with all this? First, you need to find out the presence of SPOF on the site. To do this, we collect all the external hosts from which JS and CSS resources are being downloaded (you can also find out the sources of the connected fonts).
Secondly, you need to check what will happen if external hosts fail. The best tool for this, I consider Webpagetest.org with the SPOF tab. You can enter in this field all the hosts that will silently drop packets and do not respond. Select the test point of interest, the browser and run the usual test.
At the output we get two tests: normal and SPOF. On viewing screenshots of the page rendering, we see the severity of the effects of SPOF (as a rule, the moment of the start of rendering is delayed). Based on this data, it is already possible to make a decision on the transfer of resources or insurance against failures.
')
Solution to the problem
Such measures can be taken to eliminate or minimize the consequences of client SPOF.
- If possible, convert all JS libraries to asynchronous mode (async attribute).
- To remove all external synchronous JS-libraries with the code down to the closing body.
- Use asynchronous versions of external API connections.
- Standard JS-libraries to transfer to the site hosting and load from it.
- Transfer the fonts and their CSS-code to the site hosting.
- Regularly check the site for the presence of SPOF.
That's all the recommendations. If you have accumulated your own experience in dealing with client SPOFs, write in the comments.
What more to read:
Source: https://habr.com/ru/post/265627/
All Articles