Web

Partis tiers : maîtrisez leurs impacts sur la vitesse et la sécurité de vos sites

Article par (CEO, Rennes)
Créé le (23754 lectures)
Tags : javascript, optimisation, performance, performance web

Partis Tiers, pourquoi s’y intéresser ?

Les partis tiers (third-party en anglais) désignent les ressources d’une page web sur lesquelles vous n’avez pas vraiment de contrôle, puisque ces dernières sont éditées et hébergées par un tiers

Widgets des réseaux sociaux, collecteurs de statistiques, régies publicitaires ou encore fournisseurs de fontes de caractères sont autant de partis tiers auxquels vous êtes confrontés régulièrement. 

Gratuits ou payants, dans les 2 cas il nous permettent souvent d’enrichir un site web de fonctionnalités qui n’auraient pas été envisageables sinon.
Mais les partis tiers sont de plus en plus nombreux sur nos sites, et nous n’y prêtons pas l’attention qu’ils méritent ! La preuve :

  • en 2012, des milliers de sites connaissent des ralentissements majeurs.... à cause du bouton “Like” de Facebook (détails en anglais)
  • Plus récemment, on se rappellera de l’incident de Typekit (service de polices de caractères) qui a là encore touché des milliers de sites (détails en anglais)

Oui, un parti tiers mal intégré peut aller jusqu’à rendre indisponible un site web !

La décision d’utiliser ou non un parti tiers n’est peut-être pas la vôtre, mais quelle que soit la situation, suivre la documentation technique du contenu concerné ne doit pas être votre seul travail : imaginez le parti tiers comme un parasite a priori amical, mais qui peut devenir un véritable danger pour un site web si certaines précautions ne sont pas prises. 

Je vous propose dans cet article un tour d’horizon de bonnes pratiques à appliquer pour limiter les risques et améliorer l’intégration des partis tiers sur vos projets.

Vitesse et partis tiers, un mariage compliqué !

Dans cette première partie, je vous propose de nous intéresser à la vitesse de chargement de vos pages web et aux différents impacts des partis tiers. 

C’est un point sensible pour plusieurs raisons. Premièrement, la ressource est externe et est donc chargée via un nom de domaine différent de celui de votre site web, ce qui entraînera souvent une résolution DNS, suivie de l’établissement d’une nouvelle connexion TCP.  

On peut se poser la question de la localisation du serveur fournissant la ressource : si ce dernier ne s'appuie pas sur un CDN (Content Delivery Network), vos internautes peuvent être confrontés à une latence importante (délai minimum pour la transmission des données entre l’internaute et le serveur, due à la distance les séparant). Quand vous avez un public “national” sur un site web ce problème ne se pose pas pour vos propres ressources. Il est cependant fréquent d’utiliser des partis tiers de fournisseurs étrangers, et donc de faire face à cette contrainte. 

Si la requête utilise du HTTPS, alors vous allez encore rajouter un délai supplémentaire, puisque ce protocole implique des échanges additionnels pour établir la connexion sécurisée.

Enfin, vous serez dépendant du temps de réponse du serveur du parti tiers, ainsi que de son débit sortant. 

Voici les résultats d'un comparatif réalisé sur dareboost.com pour illustrer ces impacts.
En bleu foncé, les résultats de performance de Presse-Citron.net. En bleu clair, le même site mais dont tous les partis tiers ont été exclus (whitelist sur le nom de domaine).

Les partis tiers ralentissent Presse-Citron.net

Comme je l’évoquais en introduction : vous n’avez aucun contrôle sur ces différents aspects ! Rien ne vous empêche de mettre en place un SLA (garantie de qualité de service) avec un fournisseur, mais il est rare qu’on soit en position de procéder ainsi. 

Les partis tiers viennent avec des impacts non négligeables, et il est préférable de limiter au maximum de telles dépendances.

Inutile de charger toute la librairie fournie par un réseau social pour afficher un simple bouton de partage alors que vous pouvez le mettre en place simplement.  Imaginer une alternative native, même un peu moins riche éventuellement, peut constituer un gain très intéressant à moyen/long terme. 

Si vous ne pouvez pas vous en passer, votre seule marge de manoeuvre restera alors d’être très vigilant lors de l’intégration de la technologie concernée.

Excluez les partis tiers du chemin critique de rendu

Chemin critique et partis tiers : les exclure pour accélérer le chargement

L’affichage d’une page web est conditionné par de nombreuses opérations : réception du HTML, construction du DOM, de l’arbre CSS, etc. 

Certaines opérations sont bloquantes, et freinent l’affichage de la page, comme c’est par exemple le cas du Javascript lorsqu’il est chargé de manière synchrone dans le <head> d’une page web. 

Les techniques d’optimisation de la performance web portent une vigilance extrême à tout ce qui concerne le chemin critique de rendu, c’est à dire aux éléments qui conditionnent l’affichage des informations utiles à l’internaute.  

Avec ce que nous avons vu plus tôt, il est donc essentiel d’éliminer tous les partis tiers de ce chemin critique, car c’est une zone sensible sur laquelle vous  devez avoir un contrôle complet ! 

Si l’on reprend les 2 exemples de dysfonctionnements de mon introduction, qui conduisent à perturber le chargement de milliers de sites web, c’est justement parce que ces sites n’avaient pas éliminé ce risque. Ils étaient totalement dépendant de ces partis tiers appelés de façon bloquante.
Non seulement, la vitesse d’affichage de la page en est alors dépendante, mais cela constitue même un Single Point of Failure, puisque le dysfonctionnement d’un fournisseur peut se traduire par une page inaccessible sur votre propre site. 

Même si un parti tiers défectueux reste un problème, l’éliminer du chemin critique rendra l’essentiel du contenu de vos pages indépendant de la récupération de ces ressources.
Malheureusement, pour certains partis tiers, il est nécessaire de conserver un comportement bloquant. C’est par exemple le cas avec des solutions d’A/B Testing en SaaS, qui doivent souvent modifier la page avant qu’elle ne soit affichée à l’utilisateur. 

Dans ce cas, attention malgré tout à éliminer le SPOF que cela constitue : le timeout par défaut d’un appel à un fichier JS bloquant est bien trop long pour être conservé sur une ressource qui n’est pas vitale au fonctionnement du site (le timeout par défaut est variable d’un navigateur à l’autre, de 20 sec à plus d’une minute - source en anglais).

À vous de vous assurer de mettre en place un timeout pertinent, avec pourquoi par une alternative à la fonctionnalité qui manquerait en cas d’échec (fallback). 

Vous pouvez par exemple vous inspirer de Typekit (paragraphe “Code incorporé avancé”), qui, depuis son fâcheux incident, a largement communiqué sur les différentes intégrations possibles. 

Pour conclure à ce sujet, nombre d’entre vous travaillent probablement sur des projets utilisant Google Tag Manager, qui permet de centraliser la gestion de certains partis tiers. GTM rend possible à des équipes non techniques de bénéficier d’un point d’entrée pour ajouter des fonctionnalités supplémentaires, généralement à portée marketing. 

La bonne nouvelle est que GTM  est chargé en asychrone et qu’il procède de même pour les éléments qui lui sont confiés. 

un grand pouvoir implique de grandes responsabilités

 

Le tag manager s’adresse souvent à des publics qui n’auront pas de vigilance sur les impacts des contenus injectés. Des risques en termes de performance, mais aussi de sécurité comme nous l’évoquerons plus loin. Si vous mettez en place GTM, je ne peux que vous encourager à sensibiliser ses utilisateurs, voire à mettre en place un processus de validation.  

Auditez la qualité de vos partis tiers

Audité la qualité des partis tiers

Nous l’avons évoqué : on peut rarement se permettre de négocier un SLA avec le fournisseur d’un parti tiers. Mais une approche indispensable - lorsque des alternatives existent - va consister à mettre en avant la qualité technique dans vos critères de choix lors de la mise en compétition des  fournisseurs. 

Je me rappelle par exemple avoir abandonné une solution de click2chat que j’envisageais d’utiliser car (entre autre) l’image utilisée au format icône faisait plus de 250Ko, alors qu’optimisée elle aurait été près de 100 fois plus légère. 

N’oubliez pas qu’une ressource, même chargée en asychrone, aura un impact pour vos internautes, notamment sur mobiles pour lesquels bande passante ou encore batteries sont des ressources limitées.

Les budgets de performance peuvent constituer une approche intéressante pour vous assurer de ne pas vous laisser déborder par une avalanche de partis tiers ! 

Je ne pousse pas plus loin le sujet, car vous pouvez déjà retrouver ici une checklist (en anglais) avec de nombreux points de vigilance.

Enfin, si vous repérez un problème, n’hésitez pas à le signaler à l’éditeur : c’est toujours une excellente nouvelle quand une correction est apportée, puisque cela va probablement permettre à des milliers de sites d’en bénéficier !

Limitez les risques !

Installer un parti tiers sur une page web, c’est un peu donner les clefs d’une pièce de sa maison à quelqu’un qu’on connaît, mais uniquement de réputation. 

Si vous avez appliqué ce qui est évoqué plus haut, vous vous êtes au final contenté de cacher quelques objets précieux...  juste au cas où. Et même si cet invité dispose des meilleurs intentions, ça ne l’empêchera pas de casser un vase par maladresse.

J’insiste là dessus : même un acteur très sérieux peut faire des erreurs ou connaître des dysfonctionnements (oh quand même, Google on peut bien leur faire confiance ?!? malheureusement, la réponse est non).

Maintenant que nous avons limité la casse du côté des performances, parlons un peu de sécurité.

Premier point, le HTTPS : si votre site se base déjà sur ce protocole, ne vous posez pas la question : cela doit être le cas également de vos partis tiers. Tout simplement car ils ne fonctionneront pas sinon ! 

En effet, les navigateurs appliquent une politique de sécurité sur les contenus mixtes, c’est à dire qu’ils bloqueront automatiquement toute ressource sensible chargée sur la version non sécurisée du protocole (voici une petite étude et quelques éléments complémentaires si le sujet vous intéresse)

Si vous n’utilisez pas encore HTTPS, vous risquez d’y venir : l’arrivée d’HTTP/2 va en faire une nécessité, et tous les grands acteurs du web poussent aussi dans ce sens (notamment en appuyant Let's Encrypt, pour des certificats gratuits). 

Ne vous engagez donc pas sur un parti tiers qui ne seraient pas encore disponible en HTTPS.    

Pour aller plus loin sur la sécurité, vous pouvez cloisonner l’espace de vos partis tiers, les limiter au niveaux des interactions possibles avec votre site et vos internautes. C’est le but par exemple de l’attribut sandbox disponible sur les iframes, qui vous permettra de limiter les impacts de ce type de conteneurs sur les navigateurs récents.  

Une autre approche, qui n’est pas spécifique aux iframes, est d’utiliser une politique de sécurité sur les contenus de la page, ou Content Security Policy.  

Si vous aviez la chance d’être à Paris Web cette année, Nicolas Hoffman y a consacré un excellent exposé, dont le support est disponible ici.

Le concept global : en utilisant un simple en-tête HTTP, vous allez autoriser explicitement les contenus qui peuvent s’exécuter sur votre page web. Tout contenu qui ne serait pas autorisé sera automatiquement bloqué, directement par le navigateur web de l’internaute.
Si une faille XSS (Cross-Site Scripting) est présente sur votre site, cette technique ne la corrigera pas. Vous vous protégez par contre de ses effets les plus dommageables, du moins pour les internautes disposant d’un navigateur récent (Can I Use).

Exemple : en exploitant l’un de vos formulaires, un attaquant réussit à injecter un script malicieux.js. L’appel à ce script est donc présent dans votre page. Mais puisque le script en question n’est pas autorisé par votre CSP, les navigateurs web ne vont tout simplement pas exécuter la requête vers ce fichier. 

Cela constitue donc une protection supplémentaire sur les partis tiers : si l’un d’eux est compromis, et permet l’injection d’un élément malveillant, vos internautes n’en subiront pas les effets, puisque votre politique de sécurité conduira à son blocage !

En conclusion

Les partis tiers sont de plus en plus nombreux. Pensez à leurs impacts et veillez à limiter leur usage. Auditez ceux dont vous avez besoin, et faites de leur qualité un impératif dans votre processus de sélection.
N’oubliez par leur caractère “parasite”, ce sont des organismes externes que vous ne contrôlez pas, pensez à surveiller leurs évolutions, même après avoir cloisonné aux maximum leurs impacts ! 

Des outils comme WebPageTest (gratuit et en anglais) ou Dareboost (freemium disponible en français) vous permettront d'analyser vos sites et les impacts de vos partis tiers. 

Commentaires

Finneas a dit le

Je ne sais pas si "partis tiers" est la traduction couramment admise de "third parties", mais je trouve que la version féminine "tierces parties" serait plus jolie et plus proche de ce qui existe déjà dans notre langue.
Et Dareboost est en effet un bel outil très complet et pertinent mais qui donne des parfois (rarement) des indications erronées – à ne pas prendre pour argent comptant, donc.

DareBoost a dit le

Merci pour le feedback ! alors oui je me suis posé la question sur la terminologie sans réussir à trouver quelque chose qui accroche vraiment. "Tierces parties" doit AMHA être précédé d'un nom à qualifier, que je n'ai justement pas trouvé. "Contenus", "éléments" ? Mais cela complexifie le propos au final d'où mon choix pour ce "partis tiers", mais je reconnais faire peut-être erreur.

Merci pour le mot sur notre service ! Si quelque chose est erroné, ne pas hésiter à nous le remonter directement sur l'outil (il y a des petits pouces à côté de chaque conseil pour faire du feedback.)

fla a dit le

Bonjour,

Très bon article. Je pense qu'il aurait mérité cependant d'étudier un peu plus les remplacements de ces parties tierces. Il est très facile par exemple de mettre une image à la place d'un bouton facebook ou une vidéo youtube et de remplacer à la volée en javascript le bouton / lancer la vidéo lors du clic de l'utilisateur, ainsi, seuls ceux qui se servent vraiment de la partie tierce en subissent les désagréments (tant de chargement certes, mais aussi tracking, l'article n'en parle presque pas). Concernant les polices, il est tout de même très facile de l'héberger soit même, je ne comprends pas l'utilisation de Google Font ou TypeKit...

DareBoost a dit le

Bonjour Fla,
Merci ! je mentionne bien la préférence à avoir pour des alternatives "natives" si possible, mais effectivement sans exemples concrets. Pourquoi pas un prochain sujet pour voir cela en détails, avec les plus courants !
Concernant les tracking & la confidentialité, la checklist mentionnée dans la partie audit aborde cet aspect, mais c'est un oubli volontaire dans l'article même, car c'est pour moi un sujet à traiter à part entière.

Pour les fournisseurs de fontes, plusieurs avantages : disposer d'un CDN, bénéficier du cache client plus largement, etc. Pour le cas de Google, c'est aussi des mécanismes d'UA Sniffing pour renvoyer une CSS adaptée au client.

TrAsHeR51 a dit le

j'ai appris quelques trucs, merci pour ce tutoriel :)

cevaho a dit le

Bonjour,
j'ai actuellement des lenteurs assez énormes probablement dues aux scripts de partis tiers. Je me retrouve assez bien dans tous les points de l'article, les script additionnels ne sont pas gérés par les mêmes personnes, je ne suis pas libre de modifier le head du site sur lequel je travaille.

Existe-t-il un outil, qui permettrait de visualiser une page en bloquant le script de son choix tout en laissant les autres activés lors du chargement d'une page ? J'aimerais bloquer l'ensemble des scripts des partis tiers pour vérifier les différences de performance.

Une sorte de nettoyage virtuel. Un outil pour activer certains scripts ou les désactiver sans toucher au code.

merci d'avance,

Cédric

DareBoost a dit le

@cevaho : Dareboost tout comme WPT proposent des mécanismes de blacklist, qui permettent de bloquer une ou plusieurs ressources et de mesurer les performances.

consultant_seo a dit le

La mode des fontes hébergées ici et là dont chez Google a tendance à pas mal ralentir bien de sites web, également. Parfois on se croirait de retour 10 ans en arrière à l'époque des sites en flash !

Commenter

Vous devez être inscrit et identifié pour utiliser cette fonction.

Vous identifier (déjà inscrit)

Nouvel inscrit

Être inscrit sur Alsacréations vous permet de :

  • participer à la communauté
  • intervenir sur les actualités
  • créer des sujets sur le forum et y répondre
  • participer aux concours
  • vous inscrire à des événements tels que la KiwiParty
  • publier votre profil

Indiquez un e-mail valide pour recevoir votre mot de passe :

Votre adresse e-mail restera strictement confidentielle, ne sera ni divulguée à un tiers ni spammée.

Annonces par e-mail

Souhaitez-vous recevoir les newsletters officielles par e-mail ?   Fréquence d'envoi : tous les 3 à 6 mois, annulation possible à tout moment

En vous inscrivant, vous confirmez accepter les règles d'utilisation.

Retour à l'accueil