¿Cargando javascript principal en cada página? ¿O dividiéndolo en páginas relevantes?

Tengo un 700kbarchivo JS descomprimido que se carga en cada página. Antes tenía 12archivos javascript en cada página, pero para reducir las solicitudes http, los comprimí todos 1 file.

Este archivo es ~130kb gzippedy se entrega gzip. Sin embargo, en la computadora local todavía está desempaquetada y cargada en cada página. ¿Es este un problema de rendimiento?

He perfilado el Javascript con Firebug Profiler pero no vi ningún problema. El problema / ilusión que estoy enfrentando es que hay bibliotecas jquery comprimidas en ese archivo que a veces no se usan en la página actual.

Por ejemplo, jquery datatablestiene 200kb comprimidos y solo se carga en 2 de las páginas de mi sitio web. Otro es jqploty ese es otro 200kb.

Ahora tengo un 400kbexceso de código que no se ejecuta en 80%las páginas.

¿Debo dejar todo en 1 archivo?

¿Debo sacar las bibliotecas jquery y cargar solo JS relevantes en la página actual?

Puede usar requirejs para cargar dinámicamente las bibliotecas que necesita solo en esas páginas. Entonces solo tiene que cargar el requirejs (que es de aproximadamente 14k) en todas las páginas, ahorrando aproximadamente 385kb.

La integración también es muy fácil: simplemente "envuelva" el código que tiene con el requerimiento incluye cosas:

require(["jquery", "jquery.alpha", "jquery.beta"], function($) {
    //the jquery.alpha.js and jquery.beta.js plugins have been loaded.
    $(function() {
        $('body').alpha().beta();
    });
})

Si su framework / CMS / lo que sea tiene las funciones apropiadas, puede incluir la secuencia de comandos condicionalmente como sugiere @Michael, pero sin la biblioteca adicional.

Tomando su caso de tablas de datos, por ejemplo, WordPress podría manejar la situación a través de algo como:

// For reference; this isn't functional code.
if (is_page('whatever')) {
    <script src="/path/to/datatables.js"><script>
    <script>
        [Your datatables setup here]
    </script>
}

No hay nada malo con RequireJS; solo necesita evaluar si el nivel adicional de complejidad que agrega (además de aprender a usarlo en primer lugar) compensa lo que las herramientas más fácilmente disponibles pueden hacer por usted. Si solo tiene los dos casos que mencionó anteriormente, esta podría ser una mejor opción. Si tiene muchas más actividades, entonces RequireJS podría ser un mejor enfoque en general.

700kb de JavaScript ES un problema de rendimiento, ya que debe analizarse después de cargar la página. Por eso, debe tener cuidado de que solo se carguen los scripts necesarios. Un gran JavaScript puede estar bien en sitios AJAX completos, como GMail, cuando la navegación se maneja internamente sin salir de la página. Sin embargo, incluso los sitios AJAX completos realizan una carga dinámica de JS para evitar la carga innecesaria de JS al inicio (problemas de memoria y velocidad).

Dijiste que querías reducir el tráfico http. Deberías jugar con el almacenamiento en caché HTTP . El problema es que los cambios en el JS pueden no ser visibles hasta que caduque el caché, si establece un tiempo de caducidad demasiado alto.

Sin embargo, hay un truco al que no te refieres myscript.js, pero myscript.js?version={myversion}. Después de la actualización de la aplicación, cambia {myversion}y fuerza la recarga de JavaScript.

~ 700kb de JavaScript es un problema de rendimiento y si está comprimido y tenemos que ver las Reglas a seguir al tratar de optimizar el Código son:

1. Minify Javascripts : simplemente está comprimiendo y descomprimiendo, lo que no redujo el código. En primer lugar, use la buena herramienta Minify JS y Minify your code. Tienes 12 archivos y cada archivo se Minificaría separadamente antes de salir de fiesta para obtener el mejor rendimiento.

2. Use la carga asincrónica de JavaScript , al usar los resultados de carga asincrónica en un tiempo de carga muy rápido y la representación de la página. El impacto en el usuario es muy fuerte porque una buena carga asincrónica no bloqueará el proceso de representación y el tiempo de carga de la página disminuirá considerablemente. Las imágenes y otros elementos mostrados regularmente se mostrarán cuando no se cargue javascript.

3. Use GOOGLE cdn para JQUERY ; Creo que está utilizando JQUERY y lo está cargando desde su propio sitio web, lo que también es una desventaja adicional, utilice amablemente el GOOGLE CDN ​​(gratuito) para cargar el JQUERY. Como está siendo utilizado por casi cada 3er sitio web y, por lo tanto, ya está disponible en la computadora cliente en caché.

4. Encabezados de caducidad larga personalizada : de alguna forma en que el sitio web se carga con el problema del tiempo de carga, debe dar la caducidad larga para los archivos JS HTTP, de modo que no se puedan descargar cada vez, lo que reducirá la solicitud por segunda vez. Según mi investigación, el tiempo de carga en la segunda página tiene más salidas en comparación con la primera visita a la página.

5. Verificación con la velocidad de la página : Algunas veces, otros recursos también afectan la velocidad de carga de la página, y también intenta optimizar otros recursos. Como dar un paso en cada recurso, dedique un tiempo extra a nuestra carga de JS.