paquete minificado JS y bibliotecas externas

Question

Quiero reducir la solicitud HTTP en mi sitio web tanto como sea posible.

¿Está bien minimizar todas las JS en un gran archivo minificado, incluidas las bibliotecas externas como jQuery?

Answer 1

Sí; esto está perfectamente bien, y es una práctica común.

Sin embargo, es posible que prefiera cargar jQuery desde el CDN de Google en lugar de incluirlo en el paquete.
Esto ahorra tiempo a las personas que ya tienen el jQuery de Google en su caché.

Answer 2

Se realiza con frecuencia. Solo tenga cuidado de que todo el equipo de desarrollo sepa lo que es y lo que no, en su archivo js. No puedo decirte cuántas veces veo que el sitio de un cliente contiene dos o tres o más instancias de jQuery, a veces porque alguien olvidó que ya estaba en un archivo maestro minificado.

Answer 3

Estoy de acuerdo con las otras respuestas aquí que esto está bien, pero podría añadir estas consideraciones:

• Como se menciona SLaks, yo creo que es preferible utilizar el CDN de Google para jQuery. Jquery tiene aproximadamente 60k y estoy seguro de que la mayoría tiene este almacenado en caché en sus navegadores de Google. Si utiliza este CDN, una gran parte de sus usuarios no tendrá que descargar esto en absoluto. Además, si no está sirviendo desde un CDN usted mismo, obtiene el beneficio adicional de un CDN.

• Supongo que está planeando cargar este JS único, desde la cabeza. Esa es generalmente una mala idea. Javascript en la cabeza bloqueará la carga del cuerpo. Desea limitar el javascript en Head a la cantidad mínima necesaria de la que dependan otros scripts de su página. Esto a menudo incluye a Jquery. Así que aunque signifique una solicitud adicional, creo firmemente que es mejor tener un script en la parte superior con el script que contiene dependencias para renderizar su cuerpo y luego un segundo script más grande al final que contenga todo lo demás. O incluso mejor un script al final que crea una etiqueta de script creada dinámicamente en la parte superior que carga el resto de su JS de forma asincrónica.

Aquí es un ejemplo de ese extremo de escritura de la página:

<script type="text/javascript"> 

    (function() { 

     var script = document.createElement('script'); 
     script.type = 'text/javascript'; 
     script.async = true; 
     script.src = 'http://mysite/js/mybigminifiedandmergedscript.js'; 
     var s = document.getElementsByTagName('script')[0]; 
     s.parentNode.insertBefore(script, s); 
    })(); 

</script> 

• Si usted tiene mucho script que si no se carga en absoluto, no interferiría con la experiencia del usuario de la página, Me gustaría poner eso en un tercer script que se carga al igual que el script anterior, pero diferido hasta que se complete el documento. De esta manera, esa secuencia de comandos no interferirá con el rendimiento "percibido" de la página. Se carga silenciosamente sin un ícono de navegador giratorio o barra de progreso.

• Si está utilizando .net, le animo a usar mi OSS RequestReduce que minimiza y combina css y javascript, así como los sprites y optimiza las imágenes sobre la marcha. Todo sin necesidad de cambiar tu código. Está disponible en Nuget y RequestReduce.com.

Answer 4

Como siempre, depende de la aplicación. Si bien estoy de acuerdo con todos los puntos anteriores, un enfoque de ingeniería a la antigua no funcionaría para crear la dependencia de estar siempre conectado a Internet para una pequeña optimización.

Tenemos una aplicación de navegador que requiere jquery, jquery ui, d3js, sus CSS relacionados y, por supuesto, nuestro propio código para funcionar. Además, los clientes necesitan poder editar el html de origen para generar diseños de variantes.

Así que hemos optado por una sola línea simple "no tocar" donde se encuentran todos los magic js y css. También hemos optado por un enfoque CDN para que el html se pueda editar sin conexión

Por lo tanto, tenemos una solución mucho más robusta a un precio de rendimiento minúsculo.

Ben