¿Cuánto ralentizan los Ad Servers la web?

Slashdot trae un interesante artículo sobre cuánto ralentizan los Ad Servers la carga de las páginas web.

Muchas veces que una página tarda en cargar, o «se queda a mitad», no es problema de los servidores propios de ésa web si no de algún elemento externo, como (muy comunmente) publicidad, algún script p.ej. para generar estadísticas, algún efecto chorra tipo contador/reloj el flash, etc. Por muy optimizado que esté nuestro código y muy bueno que sea el rendimiento de nuestras infraestructuras, muchas veces no nos damos cuenta de que estamos en manos del rendimiento del código e infraestructuras de terceros, por recurrir a éste tipo de servicios.

Batallita del abuelo, que aunque no es al 100% sobre lo que estamos hablando sirve para ilustrarlo: hace un tiempo uno de los diarios del grupo se quejó de mal rendimiento. Como siempre, la queja es simplemente «no va» o «va mal», no «vemos que a ciertos usuarios les pasa ésto». Bien, conseguimos ponernos en contacto con uno de los usuarios que tenía el problema. Desde casa la página le cargaba bien, pero desde el trabajo sólo salía la cabecera, y a los cinco minutos el resto (¡¡algo descabellado!!).  Nos ponemos en contacto con el dpto. de informática (era una institución oficial) y tras algún tira y afloja descubrimos que su proxy/firewall bloqueaba el puerto 8080, y por aquel entonces uno de nuestros servidores de AdServing usaba ese puerto. ¿Resultado? Cuando el navegador encontraba el primer iframe a éste servidor de AdServing, se quedaba bloqueado hasta que se cumplía un determinado timeout, tras el cual se acababa de renderizar la página. Imaginaros ahora que en vez de ser un proxy que estuviera filtrando ese puerto, simplemente el problema fuera de rendimiento por falta de CPU o ancho de banda en un servicio externo. El resultado sería el mismo, ya que muchas veces los navegadores detienen el renderizado de la página cuando tienen problemas al cargar un iframe o cargar/ejecutar algún código JavaScript.

En resumen: nos podemos matar a optimizar nuestros servidores y nuestros programas, pero mientras que dependamos de terceros, estamos en sus manos.

¿Soluciones? Un cron que se baje cualquier JavaScript externo, de forma que lo sirvamos en local. Proxies inversos para servir el contenido. Usar las cabeceras de control de caché del protocolo HTTP para dar caducidades muy altas a los banners, para así aprovechar mejor las cachés de los navegadores y de cualquier proxy que pueda haber por enmedio.

Otra solución que lleva tiempo rondándome la cabeza es ésta: en lugar de cargar directamente cualquier JavaScript/iframe externo, registrarlos con una función JavaScript que vaya recopilándolos en un array, y en el onLoad del body html llamar a una función que recorra ese array y vaya activando uno a uno los recursos externos, una vez que todo el contenido «real» del sitio ya se ha cargado y renderizado. Estuve una vez haciendo probatinas a éste respecto y más o menos funcionaba, aunque según el código a adaptar (algunos adServings) podía dar problemas o ser más o menos complicado. Pero el efecto era el deseado: el contenido se cargaba «de pantallazo», y luego iban apareciendo todos los recursos externos. Es una forma de que nuestro producto se vea sin ningún retraso, aunque alguno de los servidores de terceros no de el rendimiento que debería, salvaguardando así nuestro servicio y nuestra imagen.

Titulares vía Google Reader

Llevo una temporada usando Google Reader como lector de RSS. La verdad es que resulta bastante cómodo y fácil de usar, y además al ser una aplicación web puedes acceder desde casa, desde el trabajo, etc. y se va guardando los artículos que lees estés donde estés.

Una opción muy interesante que tiene es la de compartir las noticias que consideres interesantes, con las que te genera una página y un feed RSS. Acabo de añadir éste feed con un widget a la barra de la derecha, bajo el título de «Noticias». Así irán apareciendo por aquí enlaces a noticias que me parecen curiosas/interesantes/divertidas, independientemente de que me dé por comentarlas en más detalle en algún artículo.