Recomendaciones para una web más rápida

Cal Henderson, desarrollador jefe de Flickr, nos hace una serie de recomendaciones para agilizar nuestra web. Iré explicándolas e intentando aportar mi propio punto de vista sobre ellas, de todas formas, es algo muy recomendable para leer.


Aunque las normas nos dicen que dividamos los javascript según su funcionalidad, es más efectivo tenerlo todo en un único javascript. Si tenemos 10 javascripts de 5k, se necesitarán más conexiones y enviar más cabeceras que si mandaramos solo 1 javascript de 50k.
A parte, IE y Firefox, según la especificación HTTP 1.1, solo se bajan dos recursos simultáneamente, por lo que mientras se baja dos scripts, el usuario no verá como se bajan las imágenes (lo cual le puede “desesperar”).
Aunque si juntamos todo, el usuario tendrá que bajárselo todo, cuando quizás no fuera necesitarlo porque no acceda a ciertos contenidos. Si hacemos que la página inicial sea lenta en descargar para conseguir que las páginas siguientes sean más rápidas, podemos hacer que el usuario se canse y no siga viendo el resto.
Pero el gran inconveniente de unir todos los archivos en uno es que si en nuestra aplicación se hace un pequeño cambio, todos los usuarios deberán volver a bajarse el archivo completo cambiado, en vez de bajarse solo la parte afectada. Claro, que esto no tiene mucho sentido en el caso de las CSS y los Javascript, porque a no ser que nos encontremos en beta, estos archivos no suelen sufrir muchas modificaciones.
El problema de dividir nuestras CSS y Javascripts, es que también tenemos que dividir nuestra aplicación para respetar el diseño estructurado. Si disponemos de un entorno de desarrollo y un entorno de producción, la solución es sencilla, cuando estamos desarrollando accedemos a todas las js (por ejemplo) y cuando pasamos producción, antes juntamos las js y tan solo es necesario acceder a una de ellas. Eso sí, el lío que podemos armar es gordo, lo digo por experiencias que he tenido en las subidas a real. Se podría hacer mediante PHP o como dice el autor con Smarty, pero o se hace con cuidado, o se puede liar una buena.
De igual manera se puede hacer con los scripts PHP, juntarlos para que en producción sea más rápida su descarga o ejecución. Y rizando el rizo, analizar que scripts, js o CSS son las que más se sirven y juntarlas y el resto dejarlas tal como están. Desgraciadamente, esto a veces suele ser obligatoriamente necesario.
Para CSS lo mejor es crear una hoja de estilos que sea general para la aplicación y luego otras para según que partes de la aplicación, así el usuario solo tendrá que bajarse un par de CSS.
Otra forma de ganar velocidad es mediante la compresión de lo que mandamos. Para ello pensamos en el módulo de Apache mod_gzip, pero Cal nos avisa que tengamos mucho cuidado con este módulo, porque a parte de necesitarse más CPU en el cliente y en el servidor, para comprimir/descomprimir, también tiene como inconveniente que el módulo usa el disco duro para crear un archivo temporal que será lo que se envie al cliente. Si se trata de muchas visitas, habrá un uso excesivo de disco, lo cual puede ser perjudicial.
Puede haber otras posibilidades, como el módulo mod_deflate, pero la mejor solución es cuánto menos envies mejor, y para ello es bueno eliminar tabulaciones, espacios, comentarios y demás cosas que hacen nuestro código legible, pero que aumentan el tamaño de lo que enviamos.
Algo difícil e importante es jugar con la caché, la cual nos puede resultar una enemiga, al evitar que páginas dinámicas se refresquen o recargando constantemente páginas que realmente no cambian con la frecuencia que son solicitadas.
Por último nos habla del problema de renombrar manualmente imágenes o archivos, y las consecuencias que nos puede acarrear, pero tampoco creo que vaya a ser un problema con el que nos vayamos a encontrar la mayoría, sobre todo cuando habla de versiones y los nombres renombrados, existiendo gestores de versiones disponibles para todos.
Serving JavaScript Fast
Vía / Digg