La lentitud de Asp.net Ajax
Hace un año os contaba mi mala experiencia con las últimas betas y release candidates de Asp.net Ajax, conocido anteriormente como codename Atlas. Pues bien, la versión definitiva, aunque planteaba sustanciales mejoras en estabilidad, usabilidad y consistencia con respecto a las betas, seguía conteniendo los mismos defectos de éstas:
Excesivo tamaño y excesivo número de los archivos a descargar por el navegador, lo cuál se traduce en una lentitud manifiesta a la hora de cargar toda la página. Si a esto le unimos el factor de tener un alojamiento compartido que no destaque precisamente por su velocidad de conexión o, en el otro lado, una conexión lenta (RDSI o módem) o saturada, acabaremos con la paciencia de nuestros valiosos visitantes, quienes probablemente se acabarán yendo a otro sitio de la competencia por aburrimiento, por mucha interactividad y vistosas animaciones que hayamos incorporado a nuestra web.
La causa de esta lentitud, como hemos avanzado antes, se debe a que Asp.Net Ajax genera de dos a tres archivos javascript, los cuáles son, incluso aunque se autocomprimen con Gzip, gigantes incluso para las conexiones de hoy día: 80kb el más grande. A ésto debemos añadir que cada carga individual de archivo produce una ligera latencia, provocándose en el navegador la sensación de que el navegador “descansa” un instante entre cada archivo descargado. Por otro lado, si probamos el proyecto en local, nos dará la falsa sensación de una gran velocidad, debido a que la carga directa desde el disco es muchísimo más rápida que cualquier red de datos, no está sujeta a las mismas saturaciones y la latencia es mínima.
De ahí el asombro de los desarrolladores cuando tras probar con gran éxito y rapidez la aplicación en nuestro querido localhost, desesperamos de lentitud al probarla por primera vez en nuestro servidor de producción con una conexión a Internet real. Las siguientes cargas son más rápidas debido a qu los archivitos gigantes de javascript son almacenados en la caché de nuestro navegador para no tener que descargarlos de la web cada vez. Sin embargo, esto no es solución puesto que ya sabemos que en la web, muchas veces la primera impresión es la que queda y algunos usuarios no tendrán paciencia suficiente para permitir la carga completa.
Si agregamos las funcionalidades adicionales que nos brinda el Microsoft Ajax Control Toolkit, nos saldrá hasta barba de esperar a que cargue la página. Esos estupendos controles facilísimos de utilizar y en algunos casos espectaculares (dropdowns que se autocompletan, animaciones, capas, etc.) nos saldrán, valga la redundancia, espectacularmente caros en cuanto a recursos de red consumidos y tiempo de espera. Incluso con la última novedad que une en un solo archivo todos los necesarios para el Control Toolkit que utilicemos, aunque no une por desgracia la funcionalidad básica, no servirá de mucho. Apenas alivia un poco las latencias.
Como en muchas otras ocasiones, Microsoft tiene el mérito de consiguir lo mismo que otros fabricantes al precio de únicamente requerir el doble de memoria y procesador y ofreciendo un producto que es al final apenas tres ó cuatro veces el tamaño de los de la competencia (sarcasmo).
No puedo menos que cerrar el artículo recomendándoos alternativas mucho más ligeras que la de Microsoft para el mismo marco de trabajo de Asp.Net.
La primera de ellas es Athem.net. Hablaré en detalle de esta magnífica librería en otra ocasión pero simplemente deciros que (al menos a mí) me parece tan fácil de usar como la de MS pero generando unos archivos muchísimo más pequeños y teniendo un rendimiento muy superior. También conviene echar un vistazo a JQuery, si bien no es específica de .Net sino multiplataforma y extremadamente útil y ligera.



El motivo de que Asp.net AJAX sea tan lento
Entre privativo y libre el usuario medio y muchos programadores suelen defender (que no preferir) el primero por ignorancia.
Pero sin embargo en la comparación de ASP (y Asp.net) contra PHP siempre he visto un apoyo enorme hacía la opción libre po…