¿Hay algún beneficio al NO usar un CDN público para cargar bibliotecas de Javascript?

Question

He escuchado todos los casos a favor de usar un CDN como Google APIs para alojar bibliotecas de JavaScript como JQuery y Prototype para mi aplicación web. Es más rápido, ahorra ancho de banda, permite la carga paralela de scripts, y más. Pero recientemente encontré el siguiente comentario en la secuencia de comandos json2.js de Douglas Crockford:

USE SU PROPIA COPIA. ES EXTREMADAMENTE DESAPROBADO CARGAR EL CÓDIGO DE LOS SERVIDORES QUE NO CONTROLAS.

estoy curioso lo que su argumento podría estar detrás de esta afirmación, y si está específicamente dirigido a los usuarios de CDN públicos como Google, o algo más?

Answer 1

Suponiendo que está hablando profesionalmente organizada CDN como Google, a continuación, la mejor apuesta es hacer esto:

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary --> 
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script> 
<script>window.jQuery || document.write("<script src='js/libs/jquery-1.5.1.min.js'>\x3C/script>")</script> 

(tomado de http://html5boilerplate.com/)

De esta manera, se obtiene todos los beneficios, sin la riesgo de que su sitio web se rompa si el CDN de Google falla.

Pero, dijo:

Use su propia copia. ES EXTREMADAMENTE DESCONECTADO PARA CARGAR EL CÓDIGO DE LOS SERVIDORES USTED NO CONTROLAR.

En realidad, no creo que esté hablando de CDN. Creo que solo dice "no enlazar secuencias de comandos de sitios web aleatorios".

Usted no querrá hacer esto porque el sitio web podría cambiar dónde se encuentra el script, o incluso cambiar el script. Un CDN nunca haría esto.

Answer 2

La razón es que si el servidor del que depende se cae y el suyo no. La experiencia de su sitio sufre. Hay formas de tener un respaldo en su lugar, de modo que si jquery u otro script no se carga, entonces puede usar una copia que aloja como respaldo.

La otra vez que no debe usarlo es en una situación de aplicación de Intranet, donde el ancho de banda no suele ser un problema.

Una forma de crear un repliegue de Jon Galloway: http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cdn-hosted-jquery-with-a-local-fall-back-copy.aspx

<script type="text/javascript" src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js"></script> 
<script type="text/javascript"> 
if (typeof jQuery == 'undefined') 
{ 
    document.write(unescape("%3Cscript src='/Scripts/jquery-1.3.2.min.js' type='text/javascript'%3E%3C/script%3E")); 
} 
</script> 

Answer 3

Si js de un servidor público se ve comprometida (disponibilidad, seguridad o error-wise), a continuación, los visitantes a su sitio se verá afectada y es probable culparte. Por otro lado, ¿cuáles son las posibilidades de que la CDN de Google se vea comprometida por las posibilidades de que algún servidor de una empresa más pequeña funcione? También pierde todas las ventajas de almacenamiento en caché que le proporciona una CDN cuando realiza la instalación localmente.

Answer 4

Si bien algunas de estas otras respuestas son ciertamente válidas, tenemos una razón ligeramente diferente/adicional.

Tenemos un proceso que determina, a primera solicitud, evalúa qué contenido estático se requiere para una página determinada. En segundo plano, este contenido estático (js, css) se fusiona y se minifica en un solo archivo (1 para JS, 1 para CSS), y luego todas las solicitudes futuras se sirven con un único archivo, en lugar de múltiples.

pesar de que podría, en teoría, excluir archivos que pueden ser servidos en un CDN y utilizan la CDN para los que, en realidad es más fácil (porque habíamos hecho, tenemos a añadimos código para manejar las exclusiones) y, en algunos casos, más rápido que usar un CDN.

Answer 5

jQuery es de código abierto. Si ha realizado una modificación en las partes internas, obviamente no puede alojar el servidor de otra persona. En general, alojar secuencias de comandos de otras personas es un riesgo de seguridad; Podrían cambiar el guión sin decírtelo nunca, y ahora lo vinculas a tus páginas.

Es una cuestión de confianza; ¿Confías en que cualquier CDN será seguro para no alojar un script malicioso en la ubicación del script que deseas?

Answer 6

Básicamente, es una cuestión de confianza. Debe confiar en que el host no cambiará nada en el archivo alojado y deberá confiar en la disponibilidad del archivo. ¿Puedes estar absolutamente seguro de que la URL no cambiará? ¿Se siente cómodo con el hecho de que el tiempo de inactividad de sus servidores provoca el tiempo de inactividad de su aplicación?

Answer 7

Además de todas las otras respuestas:

Usted quiere preocuparse por servir a sus páginas a través de SSL (es decir https), pero sus JS a través de HTTP directamente de una fuente diferente. Los navegadores pueden quejarse (a veces de manera alarmante) sobre artículos asegurados y no asegurados.

Además, las personas que navegan con la extensión noscript (o similar) necesitan permitir que JS se ejecute desde múltiples fuentes diferentes. No es gran cosa si estás usando un CDN importante (ya que es posible que lo hayan permitido en algún momento del pasado), pero entonces debes preocuparte de que solo permitan ALGUNOS de tus JS.