Avantages et inconvénients des scripts hébergés [fermé]

J'ai vu certains développeurs utiliser des scripts hébergés pour lier leurs bibliothèques.

cdn.jquerytools.org en est un exemple.

J'ai également vu des gens se plaindre qu'un lien de script hébergé avait été détourné.

Dans quelle mesure l'utilisation de scripts hébergés est-elle réellement sûre? Les scripts sont-ils automatiquement mis à jour? Par exemple, si jQuery 5 passe à 6, est-ce que j'obtiens automatiquement la version 6 ou dois-je mettre à jour mon lien?

Je vois également que Google a un large ensemble de ces scripts de configuration pour l'hébergement.

quels sont les avantages et les inconvénients?

Avantages

• Vos scripts sont chargés plus rapidement . Si vous avez une abondance de ressources qui doivent être chargées à partir d'un seul domaine, votre navigateur goulot d'étranglement pour que vous n'ayez qu'une poignée de demandes parallèles vers le même hôte. Donc, si vous chargez seize scripts distincts, plusieurs images et plusieurs documents CSS, il y aura une file d'attente pendant que chaque ressource attend son tour pour être chargée. (Réfléchissez certainement à la concaténation de vos fichiers CSS et Javascript - le chargement de seulement deux ressources de script sera beaucoup plus rapide).
• Si vous supprimez ces ressources dans un domaine séparé, votre navigateur n'aura aucun problème à ouvrir des connexions supplémentaires à ce serveur, ce qui signifie que davantage de ressources sont chargées simultanément, ce qui accélère l'exécution des pages. Vous laissez également un autre serveur gérer une partie du chargement de votre page, ce qui est bon pour votre serveur qui travaille probablement sur plusieurs demandes d'exécution de script en l'état.
• De plus, ces serveurs CDN (réseaux de diffusion de contenu) sont configurés pour fonctionner comme des CDN. Ils sont généralement sans cookies (pour les petites tailles de paquets) et sont configurés avec un serveur extrêmement léger qui se préoccupe entièrement de servir les ressources et de mettre en cache les ressources couramment utilisées et pas tellement de lever au jour le jour quelque chose comme une tourbière. Le serveur Apache fonctionnera.
• L'utilisation d'un CDN comme Google ou Akami présente également d'autres avantages: Google a notamment des serveurs partout dans le monde et ses systèmes de routage sont suffisamment intelligents pour associer une demande de ressource à la copie géographique la plus proche qui existe. Votre serveur peut essayer de servir jQuery.js à Vladimir en Russie - Google a probablement la même ressource en bas de Vladimir, ce qui diminue la latence.
• De plus, étant donné que de nombreux sites Web utilisent déjà ces CDN, il est fort probable que la ressource que vous servez ait déjà été mise en cache par l'utilisateur. jQuery.js de votre serveur et jQuery.js du serveur de Google ne sont pas traités comme le même fichier, peu importe s'ils sont exactement les mêmes - si vous chargez depuis Google, il pourra utiliser la copie en cache du site précédent qui l'utilisateur visité.
• Les fichiers eux-mêmes ne changeront pas, en particulier pour les ressources de script comme les frameworks Javascript. Si une nouvelle version sort, Google continuera d'héberger l'ancienne version (peu importe la gravité des bugs) afin que le CDN continue de fonctionner normalement et ne réponde à aucune mauvaise demande. C'est pourquoi tout fichier CDN est suffixé avec le numéro de version approprié.

Les inconvénients

1. Il est possible que votre CDN ne soit pas disponible. Les chances, cependant, sont plus minces que la baisse de votre site, probablement. Les CDN plus grands comme Google et Akami ont plusieurs couches de basculement.
2. La création d'une nouvelle connexion peut ne pas valoir la peine si vous n'avez qu'une ou deux ressources à charger depuis votre propre serveur.
3. Vous n'avez aucun contrôle sur le fichier servi, donc l'utilisation de votre version personnalisée de jQuery ou de tout ce que vous essayez de charger est épuisée, sauf si vous payez pour votre propre CDN.

Sécurité

Je recommanderais cet article d'El Stack ainsi qu'une bonne quantité de recherches sur le sujet sur Google. Chaque CDN sera différent, bien qu'en un mot je pense que ce serait une préoccupation mineure.

Quelque chose que personne n'a mentionné est encore une autre option de suivi pour Google. Ils n'offrent pas tous ces services gratuitement sans raison. AdSense et Analytics sont tout à fait suffisants et au moins ceux-ci peuvent être filtrés. C'est un gros con dans mon livre.

Avantages:

• Vous n'avez pas à payer pour la bande passante liée à la diffusion des fichiers et généralement

Les inconvénients:

• Vous êtes soumis à la disponibilité du fournisseur d'hébergement que vous utilisez (s'ils tombent en panne pour une raison quelconque, votre down aussi).
• Vous avez forcé la ou les versions des scripts des hébergeurs

Il y a d'autres avantages à utiliser un CDN, mais ils ne sont pas directement liés à l'utilisation d'un troisième service d'hébergement de scripts.

En ce qui concerne les meilleures pratiques, l'approche courante pour optimiser le chargement des pages consiste à regrouper toutes vos ressources JS, en raison du nombre limité de connexions vers un seul domaine, comme l'a mentionné Jarrod, et de définir un en-tête expirant dans la réponse dans un avenir lointain.

Ce que les CDN apportent à un tel mélange, en particulier les plus populaires, comme l'a également souligné Jarrod, c'est que l'utilisateur aurait déjà accédé à l'URL et peut récupérer la ressource JS immédiatement dans le cache de son client sans même avoir besoin d'établir une connexion.

À cet effet, si nous avons tous utilisé des CDN et utilisé les meilleures pratiques, nous pouvons éviter à l'utilisateur de récupérer environ 10 à 50 Ko supplémentaires lorsqu'il accède initialement à nos URL et lui permettre de charger ses pages plus rapidement.

Je recommanderais fortement d'utiliser les CDN pour deux raisons: les inconvénients mentionnés par Jarrod sont là, vrais, mais complètement insignifiants et si vous regroupez déjà vos sources dans un seul document, vous obligerez tout le monde à récupérer, disons, la partie jQuery statique de le document (~ 33 Ko) chaque fois que vous mettez à jour l'une des ressources fournies.

Je ne sais pas à quel point cela vous semble important, mais avec d'énormes bases d'utilisateurs, cela entraîne une réduction significative de la bande passante et des économies importantes, dont nous pouvons nous détourner vers des questions plus urgentes, telles que la diffusion de porno et l'achat de bières.

Ne le fais pas

Personnellement, je ne compterais pas sur des scripts hébergés par des tiers. Si vous exploitez les scripts d'autres peuples, vous êtes à leur merci. Il y a plusieurs choses à considérer:

1. Si leur site tombe en panne, votre page peut expirer ou une erreur peut survenir.
2. S'ils cessent leurs activités et désactivent l'hébergement, vous venez de perdre toutes ces fonctionnalités
3. S'ils sont piratés, vous pouvez également être piraté.
4. Les scripts intersites peuvent faire des ravages avec les certificats SSL
5. Les temps de chargement des pages peuvent augmenter considérablement
6. Si l'interface change, vous devez modifier tous les appels de fonction

Il est plus sûr d'héberger le code sur votre propre site, croyez-moi. Vous n'avez besoin d'être brûlé qu'une seule fois et 250 sites Web que vous avez construits et hébergés commencent à agir de manière amusante parce que vous vous êtes appuyé sur un script hébergé en troisième partie qui a cessé de fonctionner.