Inclusión de Javascript, como mejorar la carga y otros alegres consejos
En este artículo explicaré aquellas decisiones técnicas que he seguido para la inclusión de javascript en Manager Deportivo. Estos consejos hasta ahora me han dado buen resultado y espero que os sirvan de ayuda (o al menos de referencia).
Estar el último para ser el primero.
Es importante saber donde ubicar la inclusión de los ficheros ".js", he optado por añadir todo el javascript al final del documento html, justo antes del </body>. De esta manera el navegador puede cargar y renderizar imágenes y HTML mejorando de esta manera el tiempo de respuesta. Por ejemplo, Google Analytics insiste siempre en que se sitúe su script al final del documento.
Evitar conflictos con el gremio de diseñadores/maquetadores.
Es una buena costumbre el separar el código Javascript del HTML puro y duro. Todas la funciones javascript deben ir en ficheros externos. Aunque todos los diseñadores que conozco dominan javascript, igualmente es importante separar la capa de presentación y la de funcionalidad.
En este caso "Consejos vendo, pero para mi no tengo", reconozco que en mi portal aún no tengo en cuenta mis propios briconsejos.
En grupo mucho mejor.
Realizar una sola llamada que nos devuelva todo el JS, así se minimiza las peticiones HTTP y se mejora el tiempo de respuesta. Mediante el mod_rewrite redirecciono la llamada del js a un fichero PHP que montará todos los includes en uno solo.
RewriteRule ^general\.js$ /group_javascript.php
Este fichero será el que devolverá agrupados todos los includes JS.
Con el verano llega la operación bikini.
Utilizo la librería de PHP JSMin (http://crockford.com/javascript/jsmin.html), se trata de un filtro para borrar comentarios y espacios en blanco y reducir así el tamaño del fichero.
Desde group_javascript.php:
include( 'jsmin-1.1.0.php' );
// Jquery.
echo JSMin::minify( file_get_contents( JAVASCRIPT_PATH.'jquery.js' ) );
// Thickbox.
echo JSMin::minify( file_get_contents( JAVASCRIPT_PATH.'thickbox.js' ) );
Pero que pasa cuando cambio el JS??
Un simple control de versiones me permite evitar que se cachee el js. Muy útil cuando se suben cambios importantes en el JS.
RewriteRule ^([0-9]+)/general\.js$ /group_javascript.php
De esta manera las llamadas al javascript pueden ser del estilo : hhtp://www.ejemplo.com/15/general.js, yo tengo la versión guardada dentro de un fichero de configuración.
Caché, que gran invento.
Que contar que a estas alturas no sepáis sobre la grandeza del caché.
Desde group_javascript.php:
header("Content-type: text/javascript; charset: UTF-8");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);
Realmente todo este lío sirve para algo?
Para responder a esta pregunta instalad el plugin "YSlow" para Firefox. Comprobad la carga de vuestro sitio web antes de las modificaciones y después. Sacad vuestras propias conclusiones y comentadlas en este Blog.
Resumen y conclusiones
- Javascript al final del documento.
- Javascript en ficheros externos.
- Agrupar ficheros js para reducir las peticiones HTTP.
- Optimizar y minimizar el código de tus archivos JS.
- Realizar un control de versiones.
- Cachear siempre que se pueda.
- Experimentar y probar alternativas.
Como podéis ver es una manera limpia,rápida y eficaz de optimizar vuestro código JS.
Os recomiendo la lectura del siguiente artículo sobre como optimizar el tiempo de carga de javascript



Comentarios
Tener una sola llamada HTTP es ideal, ya que cada petición HTTP castiga mucho el tiempo de carga. Pero todavía sería mejor precalcular esa agrupación JS y servirla como un fichero estático JS directamente, porque la caché que propones es a nivel de navegador. Por lo tanto, dos peticiones desde navegadores diferentes, te harían calcular ese fichero agrupado dos veces, y eso, con un volumen de peticiones importantes penalizaría tu site.
Si haces en cambio un sencillo script que te genera el JS final, resultado de tu agrupación, mucho mejor :)
Buen artículo
Estoy completamente de acuerdo. Es una mejora que ya me había planteado. De momento, con 50 visitas al día, el rendimiento del servidor no es mi mayor preocupación, en cambio el rendimiento de cada página sí. Igualmente lo acabaré implementando en un futuro cercano.