Github doit-il être utilisé comme CDN pour les bibliothèques javascript? [fermé]

94

Servir des bibliothèques javascript à partir d'un CDN au lieu de votre propre serveur présente d'énormes avantages. Moins de travail pour votre serveur, possibilité pour le CDN d'avoir une copie plus proche de l'utilisateur que de votre serveur, mais surtout une bonne chance que le navigateur de votre utilisateur l'ait déjà mis en cache à partir de cette URL. Le dernier signifie moins de travail total pour tout le monde, donc c'est clairement une victoire partout, et il est plus probable que plus nous (les développeurs) comptons sur les CDN pour servir notre javascript.

Mais les CDN javascript populaires (Google, Microsoft, autres?) N'hébergent qu'un petit nombre de fichiers. Pour d'autres, nous avons le choix de les héberger nous-mêmes, ou ... d'utiliser le serveur de contrôle de source comme une sorte de CDN. Il est peu probable que Github ou similaire dispose d'un cache distribué géographiquement de fichiers optimisé pour une diffusion mondiale. Mais si c'est une pratique courante, il y a de bonnes chances que le navigateur de l'utilisateur l'ait mis en cache. L'argument du déchargement du travail de nos serveurs vers github n'est valable que si Github s'est volontairement porté volontaire pour le faire.

Alors, est-ce une pratique courante? Devrions-nous nous encourager mutuellement à faire cela? Est-ce que Github vous dérange? Ont-ils une politique officielle énoncée?

javascript  performance  hosting 
— Léopd
source
5
Que se passe-t-il si l'auteur réorganise sa structure de fichiers? Ce n'est pas son code de problème sur des centaines de pauses de sites Web.
— Raynos
2
@Raynos Si vous êtes "l'auteur" du dépôt GitHub, vous contrôlez les modifications.
— Chris Jacob
2
@ChrisJacob c'est le point. Si je change ma propre structure de fichier, ce n'est pas mon problème que vous pointez sur un morceau de code qui n'existe plus.
— Raynos
5
Vous pouvez utiliser rawgithub.com pour partager des travaux en cours HTML, JavaScript ou CSS avec quelqu'un pour une démonstration rapide, ou peut-être pour l'utiliser dans un test jsPerf.
— Giovanni Cappellotto
La question devrait être rouverte car il y a maintenant une bonne réponse dans le commentaire ci-dessus de @GiovanniCappellotto.
— Supersharp

Réponses:

93

Vous ne devriez pas faire cela pour les fichiers JavaScript si vous vous souciez des performances ou de la compatibilité IE9.

GitHub ne sert pas ses fichiers "bruts" avec un en-tête d'expiration lointain. Sans possibilité de mise en cache intersites, vous perdez le plus grand avantage de l'utilisation d'un CDN public pour héberger votre JavaScript. En fait, utiliser GitHub en tant que CDN sera plus lent que simplement héberger les fichiers sur votre propre serveur après la première demande de fichier de chaque utilisateur (en supposant que vous configuriez correctement la mise en cache sur votre serveur).

Un autre problème est que GitHub ne sert pas de fichiers «bruts» avec un en-tête de type de contenu qui correspond au type MIME réel du fichier. Dans IE9 (et peut-être dans d'autres navigateurs / proxies / pare-feu / etc.), les fichiers JavaScript qui ne sont pas servis avec le type de contenu correct sont bloqués par défaut. Vous pouvez le voir en action sur la page de démonstration BlockUI, par exemple:

entrez la description de l'image ici

— Dave Ward
source
10
Aussi ... "Lorsque vous demandez le fichier brut comme ça, vous n'accédez pas directement au fichier à partir du système de fichiers! Vous passez également par des couches de code d'application, ce qui ralentira certainement votre site. Ne faites pas cela . Au lieu de cela, créez une branche gh-pages, et chargez-la à partir de là "- viatropos.com/blog/github-as-a-cdn
— Chris Jacob
RawGit sert les fichiers bruts directement depuis GitHub avec les en-têtes Content-Type appropriés. Utilisez une balise spécifique ou un hachage de validation dans l'URL (pas une branche). Les fichiers sont mis en cache en permanence en fonction de l'URL. rawgit.com
— Kerem Baydoğan
11

Cela a été récemment demandé dans les forums de support de github , et la réponse officielle était que ça allait.

Cela dit, je suis d'accord avec d'autres réponses: github n'a jamais vraiment été conçu pour être un CDN, alors que Google et Microsoft ont une infrastructure spécifique pour cela.

— Mauricio Scheffer
source
7
Clarifier. Cette réponse du forum de support est en relation avec l'article auquel j'ai lié dans ma réponse (Pages GitHub en tant que CDN - pas fichiers GitHub "bruts"): stackoverflow.com/questions/5502540/… ).
— Chris Jacob
10

C'est bien pour le prototypage / les trucs personnels, mais pour la production, je regarderais:

http://www.cdnjs.com/

http://cachedcommons.org/ - n'est plus disponible

— Meleyal
source
J'espère que vous savez que CachedCommons.com sert juste de github.com
— ocodo
Mais les URL semblent pointer vers CachedCommons cachedcommons.org/cache/mootools/1.2.4/javascripts/mootools.js , pourrait être un proxy, je suppose.
— meleyal
Désolé, ce que je veux dire, c'est que les anciennes informations sur l'utilisation de Github en tant que CDN ne s'appliquent plus, apparemment, et tout va bien. Outre les problèmes de disponibilité possibles à l'avenir, il vaut la peine de créer une bibliothèque pour éviter cela.
— ocodo
2
Il semble que les liens vers Github ne seront bientôt plus une option: github.com/blog/…
— meleyal
1
En fait, ce n'est pas un problème, si vous prévoyez d'utiliser une ressource basée sur GitHub comme cdn, assurez-vous simplement qu'elle est hébergée dans le cadre d'un site de pages statiques (maintenant GitHub.io) - C'est comme ça que vous auriez dû le faire dans le première place d'ailleurs.
— ocodo
-2

Je le fais depuis des mois maintenant, j'avais quelques inquiétudes en premier, mais c'est totalement cool si vous n'avez aucun problème avec vos fichiers disponibles au public, utilisez des versions minifiées si vous vous en souciez.

Mais quand même - Google et MS régissent l'espace pour les modèles jQuery et jQuery - donc je les utilise pour cela.

— ezmilhouse
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.