Auto-hébergement de ressources tierces: bonnes, mauvaises, mauvaises

Ces dernières années, de plus en plus de plateformes d'optimisation de projets frontaux offrent des opportunités d'hébergement indépendant ou de proxy de ressources tierces. Akamai vous permet de définir des paramètres spécifiques pour les URL auto-générées. Cloudflare dispose de la technologie Edge Workers. Fasterzine peut réécrire les URL des pages afin qu'elles pointent vers des ressources tierces situées sur le domaine principal du site.



Si vous savez que les services tiers utilisés dans votre projet ne changent pas trop souvent et que le processus de leur livraison aux clients peut être amélioré, alors vous pensez probablement à utiliser ces services par procuration. Avec cette approche, vous pouvez «rapprocher» ces ressources des utilisateurs et obtenir plus de contrôle sur leur mise en cache côté client. De plus, cela vous permet de protéger les utilisateurs contre les problèmes causés par la «chute» d'un service tiers ou la dégradation de ses performances.

Bon: productivité accrue

L'auto-hébergement des ressources d'autres personnes améliore les performances de manière très évidente. Le navigateur n'a pas besoin d'accéder à nouveau au DNS, il n'a pas besoin d'établir une connexion TCP et d'effectuer une négociation TLS sur un domaine tiers. La façon dont l'hébergement indépendant des ressources d'autres personnes affecte les performances peut être observée en comparant les deux figures suivantes.


Les ressources tierces sont téléchargées à partir de sources externes (prises à partir d'ici )


Les ressources tierces sont stockées au même endroit que le reste du matériel du site (extrait d'ici )

La situation est également améliorée par le fait que le navigateur utilisera les capacités de multiplexage et de hiérarchisation des données de connexion HTTP / 2, qui sont déjà établies avec le domaine principal.

Si vous n'hébergez pas de ressources tierces, puis, puisqu'elles seront téléchargées à partir d'un domaine autre que le domaine principal, elles ne peuvent pas être hiérarchisées. Cela les amènera à rivaliser pour la bande passante du client. Cela peut conduire au fait que le temps de chargement des matériaux critiques pour la formation de la page sera beaucoup plus long que le temps réalisable dans un ensemble idéal de circonstances. Voici un exposé sur la hiérarchisation HTTP / 2 qui explique tout cela très bien.

On peut supposer que l'utilisation d'attributs de preconnect dans les liens vers des ressources externes aidera à résoudre le problème. Cependant, s'il existe trop de liens de ce type vers différents domaines, cela peut en fait surcharger la ligne de communication au moment le plus crucial.

Si vous hébergez des ressources tierces par vous-même, vous pouvez contrôler la manière dont ces ressources sont données au client. À savoir, nous parlons de ce qui suit:

• Vous pouvez vous assurer que l'algorithme de compression de données le mieux adapté à chaque navigateur (Brotli / gzip) est appliqué.
• Vous pouvez augmenter le temps de mise en cache des ressources, qui ne sont généralement pas très grandes, même pour les fournisseurs les plus connus (par exemple, la valeur correspondante pour la balise GA est définie sur 30 minutes).

Vous pouvez même étendre le TTL pour une ressource, par exemple, jusqu'à un an en incluant les matériaux appropriés dans votre stratégie de gestion de la mise en cache (hachages d'URL, versioning, etc.). Nous en parlerons ci-dessous.

▍ Protection contre les interruptions dans le fonctionnement des services tiers ou contre leur déconnexion

Un autre aspect intéressant de l'hébergement indépendant de ressources tierces est que cela vous permet d'atténuer les risques associés aux interruptions dans le fonctionnement des services tiers. Supposons que votre solution tierce pour les tests A / B soit implémentée en tant que script de blocage chargé dans la section d'en-tête de la page. Ce script se charge lentement. Si le script correspondant ne parvient pas à se charger, la page sera vide. Si le chargement prend beaucoup de temps, la page apparaîtra avec un long délai. Ou, supposons que le projet utilise une bibliothèque chargée à partir d'une ressource CDN tierce. Imaginez que cette ressource se bloque ou soit bloquée dans un certain pays. Une telle situation entraînera une violation de la logique du site.

Afin de savoir comment fonctionne votre site dans des conditions d'inaccessibilité de certains services externes, vous pouvez utiliser la section SPOF sur webpagetest.org .


Section SPOF sur webpagetest.org

▍ Que diriez-vous des problèmes de mise en cache avec les navigateurs? (indice: c'est un mythe)

Vous pourriez penser que l'utilisation de CDN accessibles au public entraînera automatiquement une meilleure performance des ressources, car ces services ont des réseaux raisonnablement bons et sont distribués dans le monde entier. Mais tout, en fait, est un peu plus compliqué.

Supposons que nous ayons plusieurs sites différents: website1.com, website2.com, website3.com. Tous ces sites utilisent la bibliothèque jQuery. Nous le connectons à eux à l'aide de CDN, par exemple googleapis.com. Vous pouvez vous attendre à ce que le navigateur télécharge et mette en cache la bibliothèque une fois, puis l'utilise lorsque vous travaillez avec les trois sites. Cela pourrait réduire la charge sur le réseau. Cela permettra peut-être d'économiser de l'argent quelque part et d'améliorer la productivité des ressources. D'un point de vue pratique, tout semble différent. Par exemple, Safari implémente une fonctionnalité appelée Intelligent Tracking Prevention : le cache utilise des clés doubles basées sur la source du document et la source d'une ressource tierce. Voici un bon article sur ce sujet.

De vieilles recherches sur Yahoo et Facebook , ainsi que des recherches plus récentes de Paul Calvano, montrent que les ressources ne sont pas stockées dans les caches de navigateur aussi longtemps que nous le pensions: «Il y a un écart important entre le temps de mise en cache de nos propres ressources et celles des projets tiers. Il s'agit de polices CSS et Web. À savoir, la durée de mise en cache de 95% de leurs propres polices dépasse une semaine, tandis que la durée de mise en cache de 50% des polices tierces est inférieure à une semaine! Cela donne aux développeurs Web une bonne raison d'auto-héberger des fichiers de polices! »

Par conséquent, si vous hébergez des documents d'autres personnes, vous ne remarquerez pas de problèmes de performances causés par la mise en cache du navigateur.

Maintenant que nous avons examiné les points forts des ressources tierces auto-hébergées, parlons de la façon de distinguer une bonne mise en œuvre de cette approche d'une mauvaise.

Mauvais: le diable est dans les détails

Le déplacement de ressources tierces vers votre propre domaine ne peut pas être effectué automatiquement sans prendre soin de la mise en cache correcte de ces ressources.

L'un des principaux problèmes ici est le temps de mise en cache. Par exemple, les informations de version sont incluses dans les noms de script tiers comme ceci: jquery-3.4.1.js . Un tel fichier ne changera pas à l'avenir, par conséquent, il ne causera aucun problème avec sa mise en cache.

Mais si un certain schéma de version n'est pas appliqué lors de l'utilisation de fichiers, les scripts mis en cache, dont le contenu change lorsque le nom du fichier est inchangé, peuvent devenir obsolètes. Cela peut devenir un problème grave, car, par exemple, il ne permet pas d'introduire automatiquement des correctifs de sécurité dans les scripts que les clients doivent recevoir dès que possible. Le développeur devra faire un effort pour mettre à jour ces scripts dans le cache. En outre, cela peut provoquer des plantages d'application car le code utilisé sur le client à partir du cache diffère de la dernière version du code pour laquelle la partie serveur du projet est conçue.

Certes, si nous parlons de matériaux fréquemment mis à jour (gestionnaires de balises, solutions pour les tests A / B), leur mise en cache à l'aide de CDN est une tâche qui peut être résolue, mais elle est déjà beaucoup plus compliquée. Des services comme le Commanders Act, des solutions de gestion des balises, utilisent des crochets Web pour publier de nouvelles versions. Cela permet d'organiser le vidage du cache sur le CDN, ou, mieux encore, la possibilité d'appeler une mise à jour de hachage ou une version de l'URL.

▍ Livraison adaptative de matériaux aux clients

De plus, lorsque nous parlons de mise en cache, nous devons également prendre en compte le fait que les paramètres de mise en cache utilisés sur le CDN peuvent ne pas convenir à certaines ressources tierces. Par exemple, ces ressources peuvent utiliser la technologie de reniflage d'agent utilisateur, le service adaptatif, afin de fournir des versions de navigateur spécifiques de matériaux optimisés spécifiquement pour ces navigateurs. Ces technologies, pour découvrir les capacités du navigateur, s'appuient sur des expressions régulières ou sur une base de données qui collecte des informations sur l'en User-Agent tête HTTP User-Agent . En apprenant sur quel navigateur ils traitent, ils lui donnent du matériel conçu pour cela.

Ici, vous pouvez rappeler deux services. Le premier est googlefonts.com. Le second est polyfill.io. Le service Google Fonts fournit, pour une certaine ressource, divers codes CSS selon les capacités du navigateur (donnant des liens vers des ressources woff2 en utilisant la unicode-range ).

Voici les résultats de quelques requêtes Google Fonts effectuées à partir de différents navigateurs.


Résultat de la requête des polices Chrome


Résultat de la requête Google Fonts à partir d'IE10

Polyfill.io ne donne au navigateur que les polyfills dont il a besoin. Cette opération est effectuée pour des raisons de performances.

Par exemple, regardez ce qui se passe si vous exécutez la demande suivante à partir de différents navigateurs: https://polyfill.io/v3/polyfill.js?features=default

En réponse à une telle demande faite depuis IE10, 34 Ko de données viendront. Et la réponse, faite à partir de Chrome, sera vide.

Angry: quelques considérations de confidentialité

Cet article est le dernier en ordre, mais pas en importance. Nous parlons du fait que l'hébergement indépendant de ressources tierces sur le domaine principal du projet ou sur son sous-domaine peut compromettre la confidentialité des utilisateurs et nuire au projet Web principal.

Si votre système CDN n'est pas configuré correctement, il peut finir par envoyer des cookies de votre domaine à un service tiers. Si un filtrage approprié n'est pas organisé au niveau CDN, vos cookies de session, qui en conditions normales ne peuvent pas être utilisés en JavaScript (avec l'attribut httponly ), peuvent être envoyés à un hôte étranger.

C'est exactement ce qui peut arriver avec des trackers comme Eulerian ou Criteo. Les trackers tiers peuvent définir un identifiant unique dans les cookies. S'ils faisaient partie du matériel des sites, ils pouvaient lire l'identifiant à leur discrétion lors du travail de l'utilisateur avec différentes ressources web.

De nos jours, la plupart des navigateurs incluent une protection contre un tel comportement des trackers. En conséquence, les trackers utilisent désormais la technologie CNAME Cloaking , se déguisant en leurs propres scripts pour divers projets. À savoir, les trackers proposent aux propriétaires de sites d'ajouter CNAME à leurs paramètres de domaine pour un certain domaine, dont l'adresse ressemble généralement à un ensemble aléatoire de caractères.

Bien qu'il ne soit pas recommandé que les cookies du site Web soient accessibles à tous les sous-domaines (par exemple, * .website.com), de nombreux sites le font. Dans ce cas, ces cookies sont automatiquement envoyés au traqueur tiers déguisé. Par conséquent, vous ne pouvez plus parler de confidentialité.

De plus, la même chose se produit avec les en - têtes HTTP Client-Hints , qui sont envoyés uniquement au domaine principal, car ils peuvent être utilisés pour créer une empreinte numérique de l' utilisateur. Veuillez vous assurer que le service CDN que vous utilisez filtre correctement ces en-têtes.

Résumé

Si vous allez bientôt introduire un hébergement indépendant de ressources tierces - laissez-moi vous donner quelques conseils:

• Hébergez vos bibliothèques, polices et fichiers CSS les plus importants. Cela réduira le risque de défaillance du site ou de diminution de ses performances en raison du fait que la ressource vitale pour le fonctionnement du site n'était pas disponible en raison d'un service tiers.
• Avant de mettre en cache des ressources tierces sur un CDN, assurez-vous que vous utilisez un système de versioning pour nommer leurs fichiers, ou que vous pouvez contrôler le cycle de vie de ces ressources en vidant manuellement ou automatiquement le cache CDN lors de la publication d'une nouvelle version du script.
• Faites très attention aux paramètres de CDN, serveur proxy, cache. Cela vous permettra d'empêcher l'envoi de cookies de votre projet ou d'en Client-Hints têtes Client-Hints à des services tiers.

Chers lecteurs! Publiez-vous sur vos serveurs des documents d'autres personnes qui sont extrêmement importants pour vos projets?