Ces dernières années, de plus en plus de plateformes d'optimisation des projets frontend proposent des options d'hébergement autonome ou de proxy pour des ressources tierces. Akamai permet de définir pour les URL créées par vos soins. Cloudflare dispose de la technologie Edge Workers. Fasterzine peut les URL sur les pages de manière à ce 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 changent rarement et que le processus de livraison vers les clients peut être amélioré, vous vous demandez sûrement à propos du proxy de ces services. Avec cette approche, vous pouvez facilement "rapprocher" ces ressources des utilisateurs et obtenir un meilleur contrôle sur leur mise en cache côté client. Cela permet également de protéger les utilisateurs des désagréments causés par l'« effondrement » d'un service tiers ou la dégradation de ses performances.
Bon : amélioration des performances
L'hébergement autonome de ressources tierces améliore les performances de manière assez évidente. Le navigateur n'a pas besoin de se connecter à un DNS, d'établir une connexion TCP, ou d'effectuer une poignée de main TLS sur un domaine tiers. L'impact de l'hébergement autonome de ressources tierces sur les performances peut être constaté en comparant les deux images suivantes.
Les ressources tierces sont chargées à partir de sources externes (extrait de )
Les ressources tierces sont stockées là où se trouvent les autres contenus du site (extrait de )
La situation est encore améliorée par le fait que le navigateur utilisera les capacités de multiplexage et de priorisation des données de la connexion HTTP/2 déjà établie avec le domaine principal.
Si les ressources tierces ne sont pas hébergées chez vous, étant donné qu'elles seront chargées à partir d'un domaine différent de celui principal, elles ne pourront pas être prioritaires. Cela entraînera une compétition entre elles pour la bande passante du client. Cela peut conduire à des temps de chargement de contenus critiques pour le rendu de la page qui seront beaucoup plus longs que ce qui pourrait être atteint dans des conditions idéales. une présentation sur la priorisation HTTP/2, qui explique très bien tout cela.
On peut supposer que l'utilisation d'attributs dans les liens vers des ressources externes preconnect pourra aider à résoudre le problème. Cependant, si le nombre de ces liens vers différents domaines est trop élevé, cela pourrait en fait surcharger la liaison pendant le moment critique.
Si vous hébergez des ressources tierces vous-même, vous pouvez contrôler comment ces ressources sont fournies au client. En particulier, cela concerne les points suivants :
- Vous pouvez garantir l'utilisation d'un algorithme de compression de données, le mieux adapté à chaque navigateur (Brotli/gzip).
- Vous pouvez augmenter le temps de mise en cache des ressources, qui, même chez les prestataires les plus connus, n'est souvent pas très long (par exemple, la valeur correspondante pour la balise GA est fixée à 30 minutes).
Vous pouvez même étendre l'indicateur TTL pour une ressource, par exemple jusqu'à un an, en intégrant les matériaux appropriés dans votre stratégie de gestion du cache (haches d'URL, versioning, etc.). Nous en parlerons ci-dessous.
▍Protection contre les interruptions des services tiers ou leur désactivation
Un autre aspect intéressant de l'hébergement autonome de ressources tierces est qu'il permet d'atténuer les risques liés aux interruptions de services tiers. Supposons que la solution tierce que vous utilisez pour effectuer des tests A/B soit mise en œuvre sous la forme d'un script bloquant, chargé dans la section en-tête de la page. Ce script se charge lentement. Si ce script ne peut pas être chargé, la page sera vide. Si le chargement prend trop de temps, la page apparaîtra avec un grand retard. Ou, supposons qu'un projet utilise une bibliothèque chargée à partir d'une ressource CDN tierce. Imaginons que cette ressource ait échoué ou ait été bloquée dans un pays donné. Une telle situation entraînera une rupture de la logique de fonctionnement du site.
Pour savoir comment votre site fonctionne dans des conditions d'indisponibilité d'un service externe, vous pouvez utiliser la section SPOF sur .
La section SPOF sur webpagetest.org
▍Qu'en est-il des problèmes de mise en cache des ressources dans les navigateurs ? (indice : c'est un mythe)
On pourrait penser que l'utilisation de CDN publics conduit automatiquement à de meilleures performances des ressources, car ces services disposent de réseaux de qualité et sont répartis dans le monde entier. Mais en réalité, la situation est un peu plus complexe.
Supposons que nous ayons plusieurs sites différents : website1.com, website2.com, website3.com. Tous ces sites utilisent la bibliothèque jQuery. Nous l'intégrons via un CDN, par exemple — googleapis.com. On peut s'attendre à ce que le navigateur charge et mette en cache la bibliothèque une fois, puis l'utilise pour tous les trois sites. Cela pourrait réduire la charge sur le réseau. Peut-être que cela permettrait d'économiser quelque part et d'aider à améliorer les performances des ressources. En pratique, cependant, tout cela semble différent. Par exemple, Safari met en œuvre une fonctionnalité appelée : dans le cache, des clés doubles sont utilisées, basées sur la source du document et sur la source de la ressource tierce. un bon article à ce sujet.
De vieilles études et , ainsi qu'une plus récente de Paul Calvano, montrent que les ressources ne sont pas conservées aussi longtemps dans les caches des navigateurs que nous pourrions l'attendre : « Il existe un écart significatif entre le temps de mise en cache des ressources internes et externes du projet. Il s'agit de CSS et de polices Web. À savoir, le délai de mise en cache de 95 % des polices internes dépasse une semaine, tandis que le délai de mise en cache de 50 % des polices tierces est inférieur à une semaine ! Cela donne aux développeurs Web de solides raisons d'héberger eux-mêmes les fichiers de polices ! »
En conséquence, si vous hébergez des ressources tierces, vous ne constaterez pas de problèmes de performances liés à la mise en cache des navigateurs.
Maintenant que nous avons examiné les avantages de l'hébergement autonome des ressources tierces, parlons de la manière de distinguer une bonne mise en œuvre de cette approche d'une mauvaise.
Mauvais : le diable est dans les détails
Déplacer des ressources tierces sur votre propre domaine ne peut pas être fait automatiquement sans veiller à la bonne mise en cache de ces ressources.
Un des principaux problèmes ici est le temps de mise en cache. Par exemple, les informations sur les versions sont incluses dans les noms des scripts tiers de la manière suivante : jquery-3.4.1.js. Ce fichier ne changera plus à l'avenir, ce qui n'entraînera aucun problème avec sa mise en cache.
Mais si un certain schéma de versionnage n'est pas appliqué lors de la manipulation de fichiers, les scripts en cache, dont le contenu change avec un nom de fichier inchangé, peuvent devenir obsolètes. Cela peut poser un problème sérieux, car cela empêche, par exemple, d'apporter automatiquement des correctifs de sécurité aux scripts qui doivent être fournis aux clients le plus rapidement possible. Le développeur devra faire des efforts pour mettre à jour de tels scripts dans le cache. De plus, cela peut entraîner des dysfonctionnements de l'application, dus au fait que le code utilisé du cache côté client diffère de la version récente du code sur laquelle se base la partie serveur du projet.
Cependant, lorsqu'il s'agit de matériaux qui sont mis à jour fréquemment (gestionnaires de balises, solutions de test A/B), la mise en cache dans les réseaux de diffusion de contenu (CDN) est une tâche dont la complexité est bien plus élevée. Des services comme Commanders Act, solutions de gestion des balises, utilisent des webhooks lors de la publication de nouvelles versions. Cela permet d'organiser une purge du cache sur le CDN, ou mieux encore, d'appeler une mise à jour du hachage ou de la version URL.
▍Distribution adaptative de matériaux aux clients
De plus, lorsque nous parlons de mise en cache, il faut également tenir compte du 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 sniffing de l'agent utilisateur (user agent sniffing, adaptive serving) afin de fournir aux navigateurs spécifiques des versions de matériaux optimisées spécialement pour ces navigateurs. Ces technologies se basent sur des expressions régulières ou sur une base de données contenant des informations sur les en-têtes HTTP. User-Agent. En reconnaissant le navigateur avec lequel ils ont affaire, ils lui fournissent des matériaux adaptés.
On peut mentionner deux services. Le premier est googlefonts.com. Le second est polyfill.io. Le service Google Fonts fournit, pour une certaine ressource, différents codes CSS en fonction des capacités du navigateur (fournissant des liens vers des ressources woff2, en utilisant unicode-range).
Voici les résultats de plusieurs requêtes à Google Fonts effectuées depuis différents navigateurs.
Résultat de la requête à Google Fonts, effectué depuis Chrome
Résultat de la requête à Google Fonts, effectué depuis IE10
Polyfill.io ne fournit au navigateur que les polyfills nécessaires. Cela se fait pour des raisons de performance.
Par exemple, regardons ce qui se passe si nous exécutons la requête suivante depuis différents navigateurs :
En réponse à une telle requête effectuée depuis IE10, 34 Ko de données seront renvoyés. En revanche, la réponse effectuée depuis Chrome sera vide.
Malveillance : quelques considérations sur la vie privée
Ce point est le dernier en ordre, mais non en importance. Il s'agit du fait que l'hébergement autonome de ressources tierces sur le domaine principal du projet ou sur son sous-domaine peut menacer la vie privée des utilisateurs et avoir un impact négatif sur le projet web principal.
Si votre système CDN est mal configuré, cela peut aboutir à l'envoi des cookies de votre domaine à un service tiers. Si la filtration appropriée n'est pas mise en place au niveau du CDN, vos cookies de session, qui ne peuvent normalement pas être utilisés en JavaScript (avec l'attribut httponly), peuvent être envoyés à un hôte tiers.
C'est exactement ce qui peut se produire avec des trackers tels qu'Eulerian ou Criteo. Les trackers tiers pouvaient placer un identifiant unique dans des cookies. Ils pouvaient, s'ils faisaient partie des contenus des sites, lire cet identifiant à leur guise pendant que l'utilisateur interagissait avec différents ressources web.
De nos jours, la plupart des navigateurs comprennent des protections contre de tels comportements des trackers. En conséquence, les trackers utilisent maintenant la technologie , se déguisant sous leurs propres scripts issus de différents projets. En effet, les trackers demandent aux propriétaires de sites d'ajouter un CNAME dans leurs paramètres pour un certain domaine, dont l'adresse ressemble généralement à un ensemble aléatoire de caractères.
Bien qu'il ne soit pas conseillé de rendre les cookies du site accessibles à tous les sous-domaines (par exemple — *.website.com), cela est courant sur de nombreux sites. Dans ce cas, ces cookies sont automatiquement envoyés à un tracker tiers masqué. En conséquence, il ne peut plus être question de vie privée.
De plus, il en va de même pour les en-têtes HTTP , qui ne sont envoyés qu'au domaine principal, car ils peuvent être utilisés pour créer de l'utilisateur. Assurez-vous que le service CDN que vous utilisez filtre correctement ces en-têtes.
Résultats
Si vous envisagez de mettre en œuvre l'hébergement autonome de ressources tierces prochainement, permettez-moi de vous donner quelques conseils :
- Hébergez vos bibliothèques JS, polices et fichiers CSS les plus importants sur vos serveurs. Cela réduira le risque d'échec de votre site ou de baisse de performance en raison de l'indisponibilité d'une ressource cruciale pour le fonctionnement de votre site, due à un service tiers.
- Avant de mettre en cache des ressources tierces sur un CDN, assurez-vous que le nom des fichiers utilise un système de versioning, ou que vous pouvez gérer le cycle de vie de ces ressources, en vidant le cache du CDN manuellement ou automatiquement lors de la publication d'une nouvelle version du script.
- Soyez très attentif aux paramètres du CDN, du serveur proxy, du cache. Cela vous permettra d'éviter l'envoi de cookies de votre projet ou d'en-têtes
Client-Hintsvers des services tiers.
Chers lecteurs ! Hébergez-vous sur vos serveurs des matériaux étrangers qui sont extrêmement importants pour le bon fonctionnement de vos projets ?
Source : habr.com
