Pros y contras de los scripts alojados [cerrado]


12

He visto que algunos desarrolladores usan scripts alojados para vincular sus bibliotecas.

cdn.jquerytools.org Es un ejemplo.

También he visto a personas quejarse de que se ha secuestrado un enlace de script alojado.

¿Qué tan seguro es usar scripts alojados en la realidad? ¿Los guiones se actualizan automáticamente? Por ejemplo, si jQuery 5 va a 6, ¿obtengo automáticamente la versión 6 o necesito actualizar mi enlace?

También veo que Google tiene un gran conjunto de estos scripts configurados para hosting.

¿Cuáles son los pros y los contras?

Respuestas:


11

Pros

  • Sus scripts se cargan más rápido . Si tiene una gran cantidad de recursos que deben cargarse desde un solo dominio, su navegador generalmente lo bloqueará para que solo tenga un puñado de solicitudes paralelas al mismo host. Por lo tanto, si está cargando dieciséis scripts separados, varias imágenes y varios documentos CSS, habrá una cola ya que cada recurso espera su turno para cargarse. (Definitivamente busque concatenar sus archivos CSS y Javascript; cargar solo dos recursos de script será significativamente más rápido).
  • Sin embargo, si separa esos recursos en un dominio separado, su navegador no tendrá problemas para abrir conexiones adicionales a ese servidor, lo que significa que se cargan más recursos simultáneamente, lo que resulta en una ejecución de página más rápida. También está permitiendo que un servidor diferente maneje parte de la carga de su página, lo cual es bueno para su servidor que probablemente esté trabajando en varias solicitudes de ejecución de script tal como está.
  • Además, estos servidores CDN (redes de distribución de contenido) están configurados para funcionar como CDN. Por lo general, no contienen cookies (para paquetes más pequeños) y están configurados con un servidor extremadamente liviano que se ocupa exclusivamente de servir recursos y almacenar en caché los recursos de uso común y no tanto con el levantamiento diario que es algo así como un estándar de pantano El servidor Apache funcionará.
  • El uso de un CDN como Google o Akami también tiene otros beneficios: Google especialmente tiene servidores en todo el mundo y sus sistemas de enrutamiento son lo suficientemente inteligentes como para emparejar una solicitud de un recurso con la copia geográfica más cercana que existe. Su servidor podría estar tratando de servir jQuery.js a Vladimir en Rusia: Google probablemente tenga el mismo recurso en la calle de Vladimir, disminuyendo la latencia.
  • Además, dado que muchos sitios web ya usan estas CDN, existe una alta probabilidad de que el recurso que está sirviendo ya haya sido almacenado en caché por el usuario. jQuery.js de su servidor y jQuery.js del servidor de Google no se tratan como el mismo archivo, sin importar si son exactamente iguales; si carga desde Google, podrá usar la copia en caché del sitio anterior que el usuario visitó
  • Los archivos en sí no cambiarán, especialmente para los recursos de script como marcos de Javascript. Si sale una nueva versión, Google continuará alojando la versión anterior (no importa cuán atroces sean los errores) específicamente para que el CDN continúe funcionando normalmente y no atienda ninguna solicitud incorrecta. Es por eso que cualquier archivo CDN tiene el sufijo completo con el número de versión apropiado.

Contras

  1. Existe la posibilidad de que su CDN no esté disponible. Sin embargo, las posibilidades son más escasas que la caída de su sitio, probablemente. Las CDN más grandes como Google y Akami tienen múltiples capas de conmutación por error.
  2. Puede que no valga la pena crear una nueva conexión si solo tiene uno o dos recursos para cargar desde su propio servidor.
  3. No tiene ningún tipo de control sobre el archivo que se está sirviendo, por lo que usar su versión personalizada de jQuery o cualquier otra cosa que esté intentando cargar está fuera, a menos que esté pagando su propia CDN.

Seguridad

Recomendaría esta publicación de El Stack más una buena cantidad de Google del tema. Cada CDN será diferente, aunque en pocas palabras creo que esto sería una preocupación menor.


1

Algo que nadie mencionó es otra opción de seguimiento para Google. No están ofreciendo todos estos servicios sin costo alguno sin ningún motivo. AdSense y Analytics son suficientes y al menos se pueden filtrar. Esa es una gran estafa en mi libro.


0

Pros:

  • No tiene que pagar por el ancho de banda relacionado con el servicio de los archivos y, en general,

Contras:

  • Usted está sujeto a la disponibilidad del proveedor de alojamiento que está utilizando (si caen por algún motivo, usted también está caído).
  • Obligó a las versiones de los scripts que tienen los proveedores de hosting.

Hay otros beneficios de usar un CDN pero no se relacionan directamente con el uso de un tercer servicio de alojamiento de scripts.


0

En lo que respecta a las mejores prácticas, el enfoque común para optimizar la carga de la página es agrupar todos sus recursos JS, debido a la cantidad limitada de conexiones hacia un solo dominio, como mencionó Jarrod, y establecer un encabezado de vencimiento en el futuro en la respuesta.

Lo que los CDN aportan a esta mezcla, especialmente los populares, como también señaló Jarrod, es que el usuario ya habría accedido previamente a la URL y puede recuperar el recurso JS inmediatamente del caché de su cliente sin siquiera requerir establecer una conexión.

A tal efecto, si todos usamos CDN y empleamos las mejores prácticas, podemos evitar que el usuario recupere unos ~ 10-50 KB adicionales cuando acceden inicialmente a nuestras URL y les permite cargar sus páginas más rápido.

Recomiendo encarecidamente usar CDN por dos razones: los contras que Jarrod mencionó están ahí, es cierto, pero completamente insignificante y si ya está agrupando sus fuentes en un solo documento, obligará a todos a recuperar, por ejemplo, la parte estática de jQuery de el documento (~ 33 KB) cada vez que actualiza uno de los recursos incluidos.

No sé lo importante que te suena, pero con una gran base de usuarios esto lleva a un corte de ancho de banda significativo y ahorros significativos, bot de los cuales podemos desviarnos a asuntos más urgentes, como la transmisión de pornografía y la compra de cervezas.


-2

No lo hagas

Personalmente, no confiaría en los scripts alojados por terceros. Si aprovecha los guiones de otras personas, está a su merced. Hay varias cosas a considerar:

  1. Si su sitio deja de funcionar, su página puede expirar o producirse un error.
  2. Si se van a la quiebra y apagan el alojamiento, perderá toda esa funcionalidad.
  3. Si son pirateados, también podría ser pirateado.
  4. Las secuencias de comandos entre sitios pueden causar estragos con los certificados SSL
  5. Los tiempos de carga de la página pueden aumentar dramáticamente
  6. Si la interfaz cambia, debe modificar todas las llamadas a funciones

Es más seguro alojar el código en su propio sitio, confíe en mí. Solo necesita quemarse una vez y tener 250 sitios web que creó y el host comenzó a actuar de manera divertida porque confiaba en un script alojado de una tercera parte que dejó de funcionar.


1
Creo que si usa un CDN grande y confiable, es probable que no enfrente muchas de sus preocupaciones. 1.) Espero que el CDN de Google tenga un tiempo de actividad muy bueno, 2.) No veo que Google vaya a la quiebra en el corto plazo, 3.) Es plausible, pero nuevamente esperaría parches / arreglos muy rápidos, 4 .) No he visto ningún problema, 5.) Si se trata de un CDN respetable, las cargas de página deberían ser más rápidas de lo que probablemente pueda servir (entre canalización, almacenamiento en caché de sitios múltiples y dominios sin cookies), 6.) Para Las bibliotecas de versiones principales como jQuery no deberían ser un problema.
scunliffe

1
... además, no hay nada que le impida implementar sus propios scripts de respaldo en caso de que los CDN remotos fallen.
scunliffe

Ninguna de estas razones enumeradas en Cape Cod Gunny son preocupaciones válidas con CDN modernas como Google, o los muchos otros grandes proveedores de CDN que existen.
Jarrod Nettles
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.