Single Point of Failure : votre site web indisponible à cause des scripts externes ?

Vous avez peut-être déjà entendu parlé de SPOF (Single Point Of Failure), que l’on pourrait traduire par “point unique de défaillance”. Mais saviez-vous que cette notion, qu’on applique souvent aux infrastructures réseaux, est également présente en matière de développement front-end ? Imaginez-vous que votre site puisse être dépendant du bon fonctionnement de Twitter ou encore de Facebook ?

SPOF, généralités et application au Front-End

Un Single Point Of Failure désigne un élément d’une infrastructure, d’un système, dont le dysfonctionnement entraîne une panne complète. C’est une dépendance critique.
Pour faire face à ces dépendances, on met généralement en place des contre-mesures (Fail-Over) comme la redondance (dupliquer l’élément dont on est dépendant).

Appliqué au développement front-end, c’est à dire à la construction d’une page web, un
Single Point of Failure se caractérise également par une dépendance critique.

Cette dépendance va généralement être liée à une tierce partie, et les “candidats” ne manquent pas de ce côté, puisqu’en moyenne aujourd’hui, les ressources d’une page web proviennent de 21 domaines différents. Widgets sociaux, publicité, solution d’analytics, A/B testing, etc. sont autant de risques d’introduire un SPOF.

Un script, une feuille de style ou encore une police de caractères peuvent en effet avoir des comportements bloquants. C’est à dire que les navigateurs web vont attendre le chargement de ces ressources pour afficher la suite de la page web.
Si vous utilisez les audits qualité Dareboost, vous le savez déjà : les comportements bloquants sont désastreux du point de vue de la performance web, puisque l’affichage de votre page sera dépendante du temps de réponse de ces différents éléments.

La notion de SPOF front-end en est le prolongement : on ne s’intéresse pas au cas où l’élément est lent, mais à celui d’un dysfonctionnement total et d’une absence de réponse.
Que se passe-t-il ? Pendant de longues secondes, la page va rester blanche. Une durée qui va dépendre du navigateur web notamment (politique de timeout variable, généralement plusieurs dizaines de secondes), mais qui dans tous les cas est inacceptable pour un internaute. Lequel partira bien avant de voir la page s’afficher !
Vous pourriez répondre, que Facebook, Google et autres fournisseurs de contenus externes, sont suffisamment solides et que vous ne prenez pas de risques à appeler leurs scripts et autres de manière bloquante.

Détrompez-vous.

Quelques précédents qui ont marqué le web

En 2012, Facebook a connu pendant une période de 3 heures environ des ralentissements et défaillances répétées. Même si l’indisponibilité d’un réseau social durant quelques heures ne parait pas bien dramatique, les conséquences ont été bien plus graves pour des milliers de sites, qui disposaient d’une intégration bloquante du fameux bouton Like… Des répercussions économiques désastreuses pour un simple widget social, car comme le souligne l’article de Forbes à ce sujet, un internaute ne fera pas la différence entre l’indisponibilité de votre site, et une défaillance de ce type : il ira tout simplement chez votre concurrent.

Autre exemple en 2014, avec une défaillance de la régie publicité DoubleClick (service de Google), qui a affecté des dizaines de milliers de sites web, allant du ralentissement du chargement au blocage pur et simple. Le cauchemar pour les éditeurs a duré près de 2 heures, vous pouvez retrouver des détails dans cet article (en anglais).

Plus récemment, en 2015, c’est le service de polices de caractères Typekit qui a connu d’importants dysfonctionnements, avec les mêmes effets sur beaucoup de sites. On appréciera le post mortem détaillé de l’incident, incluant une mise à jour rapide de la documentation pour proposer un mode d’appel non bloquant, et éviter donc de communiquer à ses utilisateurs une intégration présentant un SPOF…

Les risques de défaillance sont multiples

Dans les exemples précités, les défaillances sont en lien direct avec les fournisseurs des contenus. Malheureusement, il existe bien d’autres cas ou un SPOF pourra être néfaste pour votre site.
Exemple avec les internautes en Chine, qui se voient bloquer l’accès à de très nombreux sites par le grand pare-feu. Certains des domaines bloqués sont justement des fournisseurs de contenus externes. Ainsi pour ce public, l’existence de SPOF se révélera avec les mêmes effets que l’indisponibilité du fournisseur concerné.
Le même type de cas peut très bien se présenter sur un public ne faisant pas face à la censure : vous n’êtes jamais à l’abri d’un problème réseau.

Que faire pour éviter les SPOF ?

Commencez tout d’abord par vous assurer d’avoir le bon point de vue : en supposant que tout contenu externe peut être défaillant, vous aurez naturellement tendance à éliminer les dépendances.
Car même si globalement les incidents sont rares chez les géants que nous avons évoqués plus tôt, avec l’accumulation des contenus de tierces parties, la probabilité d’une erreur augmente.
Evidemment, pour beaucoup il est irréaliste de se passer de contenus de tierces parties. Veillez dans ce cas à choisir une intégration asynchrone, qui n’est pas toujours celle mise en valeur dans les documentations des éditeurs.
N’oubliez pas non plus de gérer des fallbacks (alternatives) utilisées en cas de problème. Si vous vous basez sur un CDN public par exemple pour appeler votre framework Javascript, il peut être très utile de prévoir une copie hébergée sur votre site en cas de timeout ou d’erreur !
Plusieurs librairies peuvent vous aider pour mettre en place ces mécanismes et contrôler le chargement de vos ressources (ex: LABjs, Head.JS, etc).

D’ici quelques jours nous vous annoncerons les principaux cas de SPOF que Dareboost sera à même de détecter d’ici la fin du mois, avec comme toujours des guides détaillés pour vous aider à optimiser votre site web !

Enfin, c’est l’occasion pour nous de vous rappeler que nos fonctionnalités de surveillance de la performance web vous permettront d’être alerté si jamais votre site rencontre le moindre ralentissement !

2 réflexions au sujet de « Single Point of Failure : votre site web indisponible à cause des scripts externes ? »

Les commentaires sont fermés.