¿Debería usarse Github como CDN para bibliotecas javascript? [cerrado]

94

El servicio de bibliotecas javascript desde un CDN en lugar de su propio servidor tiene enormes ventajas. Menos trabajo para su servidor, posibilidad de que la CDN tenga una copia más cercana al usuario que su servidor, pero lo más importante es una buena posibilidad de que el navegador de su usuario ya la tenga en caché desde esa URL. El último significa menos trabajo total para todos, por lo que claramente es una victoria en general, y es más probable que entre más a menudo (los desarrolladores) dependamos de los CDN para servir nuestro javascript.

Pero los populares CDN de JavaScript (¿Google, Microsoft, otros?) Solo alojan una pequeña cantidad de archivos. Para otros, tenemos la opción de alojarlos nosotros mismos, o ... usar el servidor de control de fuente como una especie de CDN. Es poco probable que Github o similar tenga un caché de archivos distribuido geográficamente y optimizado para servir a nivel mundial. Pero si es una práctica común, existe una buena posibilidad de que el navegador del usuario lo tenga almacenado en caché. El argumento de descargar el trabajo de nuestros servidores a github solo es válido si Github se ha ofrecido voluntariamente para hacer esto.

Entonces, ¿es una práctica común? ¿Deberíamos animarnos unos a otros a hacer esto? ¿Le importa a Github? ¿Tienen una política oficial establecida?

javascript  performance  hosting 
— Leopd
fuente
5
¿Qué sucede si el autor reorganiza su estructura de archivos? No es su código de problema en cientos de sitios web que se rompen.
— Raynos
2
@Raynos Si eres el "autor" del repositorio de GitHub, entonces controlas los cambios.
— Chris Jacob
2
@ChrisJacob ese es el punto. Si cambio mi propia estructura de archivos, no es mi problema que apuntes a un fragmento de código que ya no existe.
— Raynos
5
Puede usar rawgithub.com para compartir HTML, JavaScript o CSS del trabajo en progreso con alguien para una demostración rápida, o tal vez para usarlo en una prueba jsPerf.
— Giovanni Cappellotto
La pregunta debería reabrirse ya que ahora hay una respuesta correcta en el comentario anterior de @GiovanniCappellotto.
— Supersharp

Respuestas:

93

No debe hacer eso con archivos JavaScript si le preocupa el rendimiento o la compatibilidad con IE9.

GitHub no sirve sus archivos "sin procesar" con un encabezado de caducidad en el futuro lejano. Sin la posibilidad de almacenamiento en caché entre sitios, pierde el mayor beneficio de usar una CDN pública para alojar su JavaScript. De hecho, usar GitHub como CDN será más lento que simplemente alojar los archivos en su propio servidor después de la primera solicitud del archivo de cada usuario (suponiendo que configure el almacenamiento en caché correctamente en su servidor).

Otro problema es que GitHub no sirve archivos "sin procesar" con un encabezado de tipo de contenido que coincida con el tipo MIME real del archivo. En IE9 (y quizás en otros navegadores / proxies / firewalls / etc.), los archivos JavaScript que no se entregan con el tipo de contenido correcto se bloquean de forma predeterminada. Puede ver eso en acción en la página de demostración de BlockUI, por ejemplo:

ingrese la descripción de la imagen aquí

— Dave Ward
fuente
10
Además ... "Cuando solicitas el archivo sin procesar de esa manera, ¡no estás accediendo directamente al archivo desde el sistema de archivos! También estás pasando por capas de código de aplicación, lo que definitivamente ralentizará tu sitio. No hagas eso. . En su lugar, cree una rama de gh-pages y cárguela
— Chris Jacob
RawGit sirve archivos sin procesar directamente desde GitHub con los encabezados de tipo de contenido adecuados. Use una etiqueta específica o confirme un hash en la URL (no una rama). Los archivos se almacenan en caché de forma permanente según la URL. rawgit.com
— Kerem Baydoğan
11

Esto se preguntó recientemente en los foros de soporte de github , y la respuesta oficial fue que está bien.

Habiendo dicho eso, estoy de acuerdo con otras respuestas: github nunca tuvo la intención de ser una CDN, mientras que Google y Microsoft tienen una infraestructura específica para eso.

— Mauricio Scheffer
fuente
7
Para aclarar. Esa respuesta del foro de soporte está relacionada con el artículo al que he vinculado en mi respuesta (páginas de GitHub como CDN, no archivos "sin procesar" de GitHub): stackoverflow.com/questions/5502540/… ).
— Chris Jacob
10

Está bien para la creación de prototipos / cosas personales, pero para la producción, miraría:

http://www.cdnjs.com/

http://cachedcommons.org/ - ya no está disponible

— leal
fuente
Espero que sepas que CachedCommons.com solo sirve desde github.com
— ocodo
Pero las URL parecen apuntar a CachedCommons cachedcommons.org/cache/mootools/1.2.4/javascripts/mootools.js , podría ser un proxy, supongo.
— meleyal
Lo siento, lo que quiero decir es que la información anterior sobre el uso de Github como CDN ya no se aplica, aparentemente, y todo está bien. Aparte de los posibles problemas de disponibilidad en el futuro, vale la pena bifurcar una biblioteca para evitarlo.
— ocodo
2
Parece que la vinculación a Github pronto no será una opción: github.com/blog/…
— meleyal
1
En realidad, eso no es un problema, si va a utilizar un recurso basado en GitHub como un cdn, solo asegúrese de que esté alojado como parte de un sitio de páginas estáticas (ahora GitHub.io). Así es como debería haberlo hecho en el primer lugar por cierto.
— ocodo
-2

Lo estoy haciendo durante meses, primero tenía algunas preocupaciones, pero es totalmente genial si no tiene problemas con que sus archivos estén disponibles públicamente, use versiones minificadas si le importa.

Pero aún así, Google y MS gobiernan el espacio para las plantillas jQuery y jQuery, así que las uso para eso.

— ezmilhouse
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.