Twitter tiene una fama de innovador en cuanto a las tecnologías que emplea en su web. Por ejemplo, en septiembre de 2010 rompió con la típica arquitectura de cliente de las páginas web, pasando de servir a los navegadores web HTML y JavaScript a sólo servir JavaScript que tira contra las API de Twitter (las mismas API que emplea, por ejemplo, una aplicación para terminal móvil) para recuperar los datos que debe mostrar y después los renderiza en el navegador.
Los análisis de rendimiento que han hecho con este experimento han mostrado que, dependiendo del navegador y la potencia de la máquina del usuario, el usuario puede tardar un tiempo considerable en comenzar a ver contenido en Twitter.com. La métrica que ellos más les interesa es el "tiempo necesario para ver el primer Tweet". Y, efectivamente, si uno visita Twitter.com primero suele ver una página en blanco (sólo se le ha servido el JavaScript) y tarda por lo menos unas cuantas décimas de segundo en comenzar a mostrar contenido (el tiempo de que se ejecute el JavaScript, realizar las peticiones contra el API REST de Twitter, recuperar el contenido, y lo muestre).
Pues bien, parece que Twitter ha decidido que ésta no es la arquitectura más adecuada y vuelve a un modelo más tradicional donde la página web ("html") se crea en el servidor, y no en el cliente. Con esto en promedio esperan reducir a la quinta parte del "tiempo necesario para ver el primer Tweet". Una de las consecuencias de este cambio es que desaparecerá el #! (por lo general bastante odiado) de la URL de Twitter.
Por otro lado, también tienen pensado optimizar la cantidad de JavaScript que sirven a cada cliente, esforzándose por servir la mínima cantidad necesaria en cada caso y así incrementando el rendimiento de la aplicación. En las próximas semanas Twitter.com va a comenzar a desplegar en distintas regiones del mundo estos cambios.
Desde mi punto de vista, es una lección interesante el hecho de que Twitter finalmente haya descubierto que su idea de convertir al navegador web en un mero cliente que tira contra Apis REST para recuperar contenido, y después lo renderiza, puede dar como resultado un rendimiento bastante subóptimo en el cliente.
La forma de vender este cambio desde Twitter es un tanto triunfalista: "vamos a incrementar el rendimiento de Twitter.com un 80% con una nueva arquitectura". Sin embargo, podría hacerse una lectura negativa de esto: llevan un año y medio empleando una arquitectura para su web que ha demostrado tener un rendimiento bastante pobre. Y simplemente "volviendo a hacer lo de toda la vida" la web va 5 veces más rápido.
En cualquier caso, se trata de una lección interesante para tener en cuenta en nuestros desarrollos.