Bibliothèque hébergée Google jQuery

14

Y a-t-il un avantage réel à utiliser la bibliothèque hébergée Google jQuery? Ou devons-nous simplement le télécharger sur notre serveur?

quelles sont vos opinions a ce sujet?

jquery library hosted-service

— Leo
source

1

Une simple recherche sur Google aurait fourni la réponse ...

— Francisco Presencia

18

L'utilisation d'un CDN externe tel que Google pour héberger jQuery présente deux avantages majeurs:

C'est plus rapide. Il sera certainement plus rapide que votre site, et probablement plus rapide que n'importe quel CDN que vous avez configuré vous-même.
Il peut déjà être mis en cache . De nombreux sites référencent également jQuery sur le CDN de Google, donc s'ils ont visité un autre site avec lui avant le vôtre, ils n'auront même pas besoin de le télécharger.

Inconvénients potentiels:

Le domaine peut être bloqué (c'est assez courant dans des endroits comme la Chine). Vous pouvez résoudre ce problème en ayant une solution de secours locale ( voir ici pour savoir comment ).
La fragmentation des numéros de version est assez élevée, donc les visiteurs de votre site peuvent avoir de nombreuses versions différentes mises en cache, mais pas celle que vous avez référencée ( voir ici pour quelques statistiques récentes ). Ce n'est cependant qu'un problème lors du premier chargement de la page.

— Chèvre mécontente
source

3

Pouvez-vous publier une référence pour savoir comment configurer une solution de secours locale?

— Stephen Ostermiller

1

Comme Zistolen le fait remarquer auparavant, un autre avantage est qu'il téléchargera en parallèle à vos sites Web d'autres actifs. Vous voudrez peut-être ajouter cela également à cette excellente réponse.

— nathangiesbrecht

C'est un peu trompeur. Les navigateurs téléchargent des ressources en parallèle, quel que soit l'endroit où ils sont hébergés, mais il y a une limite au nombre de choses qu'ils téléchargeront à partir du même hôte à la fois.

— Tim Fountain

J'ai ignoré qu'honnêtement, ce n'est ni ici ni là-bas - le fichier peut être téléchargé en parallèle mais c'est aussi une recherche DNS supplémentaire. De plus, quelle que soit la différence de temps de ces deux marques, elle est de toute façon négligeable.

— DisgruntledGoat

C'est suffisant. Mais sur des connexions rapides, cela ne peut-il pas entraîner un temps de chargement total plus rapide, car une plus grande partie du "tuyau" peut être utilisée?

— nathangiesbrecht

11

Un autre inconvénient:

L'utilisation d'un CDN permet à l'opérateur du CDN de suivre les visiteurs du site. C'est pourquoi ils ne coûtent pas d'argent.

— Jost
source

Suivi sûr, mais pas les visiteurs: le CDN jquery et le jquery de Google sont hébergés sur des domaines qui ne définissent pas ou n'utilisent pas de cookies (c'est probablement aussi une optimisation des performances), et il n'y a pas d'informations vraiment identifiables dans la demande. Le fournisseur CDN peut se faire une idée des adresses IP et des statistiques sur les chaînes d'agent utilisateur et les référents. C'est probablement précieux, mais ce n'est pas en soi un énorme risque pour la confidentialité (si ces enregistrements étaient corrélés avec une autre base de données - par exemple, des publicités personnalisées diffusées à des moments similaires - alors cela pourrait peut-être être un moyen de suivi).

— Eamon Nerbonne

Je pense qu'il peut être tenu pour acquis (dans le cas de Google), que les données sont corrélées avec d'autres bases de données, car presque tout le monde utilise Google pour rechercher tout le temps. Même chose avec les polices google: j'ai récemment essayé d'auto-héberger les polices sur un serveur, mais j'ai découvert qu'il est très difficile de le faire. Google ne l'interdit pas (Open Source), mais ils ne vous fournissent pas les fichiers de manière prête à l'emploi: vous pouvez soit les compiler vous-même (mais il n'y a pas de makefile), soit vous pouvez forger des demandes au serveurs qui sont utilisés pour les livrer normalement. Les deux ne sont pas réalisables pour un non-technicien.

— Jost

Peut-être. Je n'ai aucune information privilégiée, il est donc difficile de dire avec certitude. Je suis certain que ce sera buggé et qu'il y aura des lacunes importantes, cependant: la plupart des endroits où j'utilise Internet sont NAT, et plusieurs ont pas mal d'utilisateurs avec des machines similaires (probablement des chaînes UA identiques) - il serait impossible de savoir lequel demande vient de qui. Et bien sûr, avec les boutons AdSense et de partage social, ils peuvent avoir un moyen plus fiable presque toujours, donc je peux imaginer qu'ils ne dérangent pas. En ce qui concerne les polices - je les ai téléchargées plusieurs fois, donc je ne comprends pas très bien ce que vous entendez par être difficile?

— Eamon Nerbonne

Pour être clair: je suppose en quelque sorte que la majorité des visites sur le site Web que vous effectuez peuvent et seront suivies par les grands collecteurs de statistiques grâce aux boutons de partage social (assez répandus) et aux annonces, qui sont à peu près partout. Je me demande donc à quel point les informations trompeuses des demandes js fortement mises en cache sont précieuses - je parie, pas très, donc je suppose qu'ils ne prennent pas la peine d'identifier personnellement les personnes utilisant JS desservies par CDN.

— Eamon Nerbonne

Ce n'est pas aussi mis en cache qu'on pourrait le penser - Lorsque vous incorporez des polices en utilisant la manière dont Google le préfère en insérant un lien CSS vers fonts.googleapis.com, chaque affichage de page ouvre une connexion à Google (vous pouvez les voir dans Firebug). Peu importe si mis en cache ou non. En ce qui concerne le téléchargement: pouvez-vous m'indiquer un endroit où je peux télécharger les polices au format eot, woff, ttf et svg de haute qualité (mêmes versions fournies par google, pas de convertisseurs externes)?

— Jost

3

L'utilisation de CDN (s) pour partager vos dépendances sur de nombreux serveurs comme celui-ci représente essentiellement un compromis entre la bande passante et la latence, en supposant que vous ne vous souciez que des performances.

Je suppose d'ailleurs que l'alternative n'est pas simplement de l'héberger localement, mais de la concaténer avec une demande locale différente - il n'y a généralement aucune bonne raison de ne pas concaténer quand vous le pouvez.

Si la bande passante est infinie, il vaut mieux NE PAS partager, car vous serez aussi lent que votre service le plus lent - puisque les latences ne sont pas parfaitement prévisibles, avec suffisamment de services, même s'ils sont rapides, vous n'avez besoin que d'un bit de malchance pour provoquer un lent chargement de la page.

Si la latence est de 0, la répartition de votre charge sur de nombreux serveurs peut améliorer la bande passante en utilisant de nombreux serveurs (pas très utile car les limites de bande passante sont probablement proches des clients, pas des serveurs), mais plus important encore, cela peut réduire la quantité de données transmises légèrement en augmentant l'efficacité de la mise en cache.

Cela dépend de votre scénario, mais je m'attends généralement à ce que la latence soit plus un problème que la bande passante, à moins que vos scripts ne soient incroyablement énormes (ce qui n'est pas le cas de jquery). À ce stade, il est généralement plus rapide d'héberger jquery dans le cadre d'un fichier local concaténé.

Les raisons de ne pas héberger localement sont par exemple lorsque vous payez pour la bande passante, ou que vous hébergez sur un serveur lent (votre connexion au client est goulot d'étranglement de votre côté, pas celle du client), ou vous savez que vos clients auront une bande passante vraiment faible (DSL ou modems bas de gamme, par exemple - le mobile a tendance à avoir plus de problèmes de latence que les problèmes de bande passante), ou vos clients paient pour la bande passante (par exemple mobile) et les scripts en sont une partie tellement notable que la mise en cache mineure gagne en importance (peu probable ).

Dans tous les cas: beaucoup plus pertinent sera de savoir si vous avez d'abord couvert les bases; en-têtes de mise en cache appropriés, concaténation, minification et gzipping (de préférence avec un taux de compression élevé). Et voici le nœud du problème: si vous ne faites pas cela, alors au moins le CDN le fera, alors c'est gagnant ...

TL; DR: si vous avez concaténé + minification + gzipping + mise en cache tous couverts, alors servir de petits scripts localement est plus rapide que depuis un CDN malgré les meilleures performances du CDN - mais seulement si vous avez fait vos devoirs, peut-être pas sur la première page charge, et il y a certainement des exceptions à cette règle.

— Eamon Nerbonne
source

Soit dit en passant, il y a des copeaux d'octets gagnés en utilisant une seule demande: les en-têtes représentent à eux seuls près de 1 Ko, ce qui sur une charge utile de 28 Ko n'est rien. gzip fonctionne mieux avec plus de contexte, ce qui économise encore 0,5k. Les frais généraux TCP, DNS, HTTPS peuvent tous facilement ajouter un KB ici ou là, et pire, les RTT. C'est pourquoi pour de petits fichiers comme celui-ci, un CDN n'est pas aussi rapide qu'on pourrait le penser.

— Eamon Nerbonne

1

L'utilisation de la bibliothèque hébergée jQuery par Google permet à votre page d'être chargée plus rapidement. En effet, la bibliothèque est chargée en même temps de votre page plutôt qu'après.

— Zistoloen
source

Mais comment cela affecte-t-il le chargement de la page?

— Leo

1

Les bibliothèques locales sont également chargées pendant le chargement de la page - Dans les deux cas, le téléchargement de l'actif commence lorsque le navigateur (moderne) voit l'extrait de code qui déclenche le téléchargement, ce qui se produit généralement avant le téléchargement du document entier. Voir cette capture d' écran de Firebug pour un exemple

— Jost

Bibliothèque hébergée Google jQuery - est-ce bon?