cookie cdnjs bootstrap app javascript performance hosting

javascript - cdnjs - js-cookie npm



¿Se debería usar Github como un CDN para bibliotecas de JavaScript? (5)

Servir bibliotecas de 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 es claramente una victoria en general, y es más probable que más (los desarrolladores) confiemos en los CDN para servir a 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 origen como una especie de CDN. Es poco probable que Github o similar tenga un caché de archivos geográficamente distribuidos optimizados para servir globalmente. Pero si es una práctica común, entonces hay una posibilidad decente de que el navegador del usuario lo tenga en caché. El argumento de descargar el trabajo de nuestros servidores a github solo es válido si Github voluntariamente se ha ofrecido para hacerlo.

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

Esto fue preguntado 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 fue realmente una CDN, mientras que Google y Microsoft tienen una infraestructura específica para eso.

Lo estoy haciendo desde hace meses, tenía algunas preocupaciones primero, pero es genial si no tienes problemas para que tus archivos estén a disposición del público, utiliza versiones miniaturizadas si te importa.

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

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

GitHub no sirve sus archivos "en bruto" con un encabezado de expiración futuro lejano. Sin la posibilidad de almacenamiento en caché entre sitios, se pierde el mayor beneficio de utilizar un CDN público 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 por parte de cada usuario (suponiendo que configure el almacenamiento en caché correctamente en su servidor).

Otro problema es que GitHub no sirve archivos "en bruto" con un encabezado de tipo de contenido que coincida con el tipo MIME real del archivo. En IE9 (y tal vez en otros navegadores / proxies / firewalls / etc), los archivos JavaScript que no se sirven con el tipo de contenido correcto están bloqueados de manera predeterminada. Puede ver eso en acción en la página de demostración de BlockUI, por ejemplo: