Twitter incrementará hasta 5 veces el rendimiento de Twitter.com renderizando en el servidor
Abraham
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.
Reader Comments (6)
para que se usa el "#!" en la url ?
Para aquellos que esten interesados en el tema, la arquitectura que experimenta twitter se denomina Single Page Aplication, en escencia es imitar las aplicaciones desktop, llevo 2 años desarrollando este tipo de aplicaciones en mi trabajo y los problemas de renderizacion son mas notables en el explorador Microsoft Internet explorer, he notado que usar la propiedad innerHTML renderiza hasta 4 veces mas rápido que la creación de objetos con DOM. En Safari, Firefox y Google Chrome no son tan evidentes esos problemas.
"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."
Trayendo esto a casa, y rememorando los debates pasados sobre SPI (en el servidor o en el cliente).
Se de alguien que debe estar que se sale de la vaina por poner un "yo tenía razón"
:o)
Un saludo.
¿J.M. Arranz, por ejemplo? ;)
Muy interesante, sí señor.
Mi centavo va porque dentro de otro año y medio sacarán una nueva versión mixta: harán más cosas con JavaScript y menos con HTML (es lo de la ley del péndulo :-))
Vamos a ver que en mi opinión hay unas cuantas imprecisiones:
"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."
Sí y no, yo mismo me "asusté" cuando se estaba gestando este cambio hace meses por parte de Dan Webb, pensaba que el resultado iba a ser una versión más colorida de la mierdecilla paginada de la versión mobile que es la que muestra Twitter por defecto por ejemplo para tabletas (paradójicamente la versión para teléfonos está más currada).
En principio las críticas de Dan Webb a los hashbangs vaticinaban eso, una vuelta radical al pasado más convencional.
Pero no es exactamente así, Dan Webb ciertamente quiere fuera a los hashbangs lo cual no da opción a que Twitter sea verdaderamente SPI, pero es que a decir verdad Twitter apenas tiene fundamentalmente "tres páginas", por lo que el purismo SPI tampoco es que sea muy importante.
Esas "tres páginas" cada una de ellas tienen montones de subestados, sobre todo la principal, en la que todos estamos la mayor parte del tiempo, en programación muy convencional cada click supondría una recarga o apenas un cambio de visibilidad de algo, pero no es así, el cambio más importante del futuro Twitter es el renderizado en el servidor del HTML, pero no sólo en la carga de la página sino también en los subestados cargando dicho HTML via AJAX e inyectando via innerHTML, como se puede ver en lo que ya tienen portado:
https://twitter.com/danwrong/status/208922536048730113
Si pulsas por ejemplo alguna de las imágenes de los perfiles, verás una "ventana" popup que carga el nuevo subestado via AJAX ya renderizado como HTML envuelto en un objeto JSON (es decir en JavaScript).
Es decir los dos cambios importantes son:
1) Adios a los hashbangs
2) Renderización del HTML en el servidor
Pero esto no significa que abandonen el modelo Single Page Interface aunque al evitar los hashbangs ya no será tan SPI porque es la única forma posible en navegadores como Internet Explorer, sin embargo en los navegadores con History API proporcionarán una verdadera interfaz SPI (aunque como decía antes 3 páginas o 1 no es muy relevante).
Respecto al inconveniente de los hashbangs en la carga inicial, Twitter hace algo muy raro, si ves el código fuente de la página principal (twitter.com) obviamente logado verás como HTML el timeline y si miras los eventos AJAX de carga no verás que el timeline se cargue via AJAX. Es verdad que en otros estados twitter.com#!algo se carga el timeline como HTML cuando no viene a cuento y al volver a twitter.com#! se carga el timeline via AJAX, esa carga del HTML inicial no la entiendo (claramente está pensada para evitar el problema de la primera carga con hashbangs) y en ese sentido existe alguna alternativa, pero da igual la decisión de quitarse del medio los hashbangs estaba tomada desde hace tiempo.
En mi opinión los hashbangs son un mal menor para llegar a un bien mayor, que es el SPI hoy, y la mayor parte de las críticas son de un purismo retro absurdo que sólo podría entender de Tim Berners Lee. Afortunadamente con el History API (SPI de mañana) nos quitaremos de en medio a los hashbangs.
No es cierto eso de "volviendo a hacer lo de toda la vida", el volver a lo de toda la vida es paginar con un uso anecdótico de JavaScript. Se cuentan con los dedos de una mano los sitios web SPI (no hablo de aplicaciones web que es otra cosa) con este tipo de técnicas.
"la arquitectura que experimenta twitter se denomina Single Page Aplication" cierto pero la actual es SPA/SPI es más, la versión futura es un poco menos SPA por lo menos en navegadores sin History API por ejemplo Internet Explorer.
¿Qué ventajas se consigue con la renderización en el servidor e inyección via AJAX e innerHTML?
1) Sigues teniendo SPI
2) Generar un HTML complejo es infinitamente más sencillo en cualquier lenguaje de plantillas de servidor que en programación cliente
3) Datos y HTML están juntos en el servidor en memoria, los puentes cliente/servidor son extremadamente más sencillos que una solución REST
4) A nivel de código es infinitamente más gestionable el código en el servidor con tu lenguaje favorito que JavaScript (la única opción), incluso los lenguajes dinámicos (de JVM) son más gestionables en el servidor
5) La "aplicación" está fundamentalmente en el servidor, no tienes que cargar cientos de Kb en el cliente de JavaScript, el servidor puede escalar en cantidad de código, en el cliente es un indicador de degradación.
6) La velocidad de ejecución de Java es muy superior a JavaScript, paradójicamente en un navegador móvil se puede conseguir un rendimiento mucho mayor si se renderiza ya como HTML en vez de que el navegador lo haga a base de DOM.
7) innerHTML sigue teniendo más rendimiento que manipulación DOM (aunque también puede usarse innerHTML en lo posible en programación intensiva en cliente)
8) La renderización del HTML no es ni mucho menos lo más costoso en recursos de servidor, desde luego no en tiempo, no hay mucha diferencia entre servir datos puros JSON que esos mismos datos dentro de HTML
9) Es posible con facilidad que en una misma request se rendericen a la vez varias partes de la página que han de cambiar al mismo tiempo, en REST supone varias requests o "bastardizar" la API a base de casuísticas
10) Al llevar más lógica al servidor hay menos posibilidades de agujeros de seguridad y de exponer decisiones en el cliente.
11) Nada te impide hacer programación híbrida cliente/servidor céntrica
Respecto a lo que dice mi querido peyrona, ellos no van a renunciar a los efectos visuales con JavaScript a saco, digamos que han constatado que "se han pasao".