Pocas veces me vais a oir hablar de tecnicalidades sobre si es mejor usar XHTML Strict o si Ruby on Rails es chanchipiruli de la muerte. Pero me veo obligado a sacar a relucir un tema que mucha gente se olvida a la hora de hacer una aplicación web:
La optimización de recursos.
Hace un par de años estuve involucrado en un proyecto cuyos requerimientos planteaban la posibilidad de que el navegador del usuario recibiese un fichero XML en su navegador y que el interfaz lo manejase con transformaciones XSLT (es decir, similar a lo que hace Kayak con la busqueda de vuelos).
Este fichero podia llegar a tener, por ejemplo, 5.000 entradas, y cada una podia pesar en torno 1 kilobyte. Y sí, en el proyecto en cuestión nos plantabamos en un hipotético archivo de 5 megas del ala. Por suerte los navegadores parecia que si que tragaban con semejante monstruosidad de fichero, sin pestañear. El problema era que al cliente le parecia demasiado tráfico para una sola busqueda. Razonable. Y se me ocurrió preguntar si por casualidad tenian activado la compresión de todas las peticiones que fuesen archivos de texto (html, xml, js, css, etc). Un archivo de 5 megas de texto se puede quedar en 100 kilobytes con cierta facilidad. Pensaba que era algo de cajón que seguro que lo tenian activado, que cualquier sysadmin que se precie comprimia sin parar. Pero no. Decian que es que consumia demasiados recursos de proceso.
En fin.
No me voy a meter a evaluar si es mejor pagar ancho de banda que costes de proceso en servidor. Pero existe la posibilidad de poner un contenido más rápidamente en el navegador del usuario, pues quemaré Roma o lo que haga falta para que así sea. Y sí, Google gzipea todos sus resultados de busqueda.
Para que os hagais una mejor idea aquí teneis una muestra con cero rigor cientifico del peso de las páginas principales de algunos periódicos que tiene versión online:
| Docs | Img | Obj | Scripts | CSS | Total | Ek | |
| Marca | 19 kb | 366 kb | 154 kb | 52 kb | 11 kb | 602 kb | 35717 j |
| New York Times | 34 kb | 275 kb | 85 kb | 99 kb | 23 kb | 516 kb | 10040 j |
| Le Monde | 34 kb | 209 kb | 208 kb | 109 kb | 57 kb | 617 kb | 5643 j |
| The Guardian | 140 kb | 447 kb | 0 kb | 45 kb | 31 kb | 663 kb | 4007 j |
| El Mundo | 25 kb | 500 kb | 103 kb | 26 kb | 96 kb | 750 kb | 3215 j |
| As | 28 kb | 314 kb | 23 kb | 217 kb | 82 kb | 664 kb | 2257 j |
| El País | 36 kb | 260 kb | 47 kb | 265 kb | 151 kb | 759 kb | 2137 j |
| las casillas en amarillo indican que esos datos han sido enviados comprimidos desde el servidor | |||||||
¿Y que quiere decir exactamente eso de energía cinética? Pues es un combo de la velocidad de descarga de la página principal y de su tamaño. Cuanto más grande (tanto en volúmen como en peso) y más rápido se descargue más energía. Es una medida del mundo de la física que he aplicado para ahorrarme tener que poner más columnas, pero que creo es bastante buen indicativo (aunque obviamente poco rigurosa). Pero si os fijais quien más comprime más arriba esta en la tabla y más rápido pone su contenido en el navegador del usuario.Todo esto viene por la lectura de una presentación de Stoyan Stefanov y de un video de Steve Souders, ambos pertenecientes el primero trabaja para el equipo de Yahoo especializado en mejorar el rendimiento de las aplicaciones web y el segundo esta actualmente en Google (gracias a Jose via Ana por la actualización). Si quereis ahorrar tiempo basta con leerse este artículo sobre la importancia de la velocidad en el interfaz.
Curiosamente, si aplicamos el criterio del Yahoo Extreme Optimization Group todas las webs arriba mencionadas ‘suspenden’ el exámen. También curiosamente Marca.com tiene la mejor nota de todas.
Puedes tener al mejor diseñador de paisajes del mundo, pero como no tengas aun buen jardinero que sepa lo que hace y que pode con cariño y fruición tu jardín se va a ir al carajo.
Conclusión: Quien tiene un buen sysadmin tiene una joya. Y no, hoy no es el dia Apreciación del Administrador de Sistemas.
FICHA TÉCNICA: los datos de la tabla han sido obtenidos en tres tomas entre las 15.30 y las 16.00 horas del 27 de marzo de 2008 usando tres herramientas distintas (YSlow, Web Developer Toolbar y el Speed Report de WebSiteOptimization.com). En ningún momento certificamos que esto tenga ningún tipo de rigor ciéntifico.
Leave a Reply