Optimizar velocidad web (bajar de 1,2s de media / página)

[frans]

según google webmasters tools (cf. gráfico adjunto) estamos encima de 1s de tiempo medio d ecarga de las páginas (considerado como "lento"). No estamos tan mal (2,7s de media) pero deberíamos intentar colocarnos en la zona verde (debajod e 1,2 de media).

¿podrías ver por dónde podemos optimizar?

[frans]

se hará por tickets específicos

[carlos]

He arañado algunos KBs re-optimizando todas las imágenes.

[frans]

a la espera medir el impacto de haber quitado las sparklines de los listados y de la home

[carlos]

Cosillas:

• Las GWT en estos momentos nos ofrece estadísticas de cuando el site tenía los ficheros JS y CSS por separado. Tampoco incluye por tanto las últimas optimizaciones de imágenes que hemos hecho (pues fueron cambios que se hicieron a la par en la misma milestone). Esto debería haber ganado ya unos puntos.

Los principales factores de lentitud en nuestro caso, por orden de mayor a menor, son:

• Carga de etiquetas Facebook: Para renderizar los nombres y avatares de usuarios de Facebook, el proceso es bastante complejo (y lo peor es que no se puede simplificar): El navegador del usuario debe cargar el SDK externo e inicializarlo (en cada petición), luego debe parsear todo el DOM para buscar las etiquetas de Facebook, luego debe mandar dichas etiquetas a Facebook para que le devuelva los nombres e imágenes correspondientes, y por último debe hacer las sustituciones en el DOM. Esto son dos peticiones HTTP externas extra, más todo el proceso Javascript (que es pesadillo, sobre todo para un motor tan lento como el de los Internet Explorer).

• Carga de Uservoice: También requiere de al menos una petición HTTP externa extra, y también parece que le cuesta un poco a IE. Quitándolo se resta algo más de tiempo de carga.

• Recursos en Amazon S3: Todos sabemos que S3 no es la panacea del rendimiento. Se aprecia a simple vista que las imágenes locales cargan mucho antes que las que vienen de S3. Midiéndolo con time y curl, hay un overhead de unos 350ms por imagen (aunque me salen picos de hasta 600ms).

• Las sparklines: Si bien estas son ya bastante rápidas (las hemos quitado de la home, y no parece que haya habido una notable diferencia de rendimiento según Google), es también una fuente de retraso en el renderizado. Los navegadores con motores JS rápidos las pintan casi instantáneamente. A IE le cuesta un poquitín más.

En general, cuando se visita la página con Chrome, Safari o Firefox, todo parece ir bastante rápido (aunque lo que tarda más son los puntos anteriores que he mencionado). Con IE, estos puntos se agravan bastante. Yo creo que la media proporcionada por las GWT no es tan representativa, pues aún hay pocos sitios que usen cosas como Facebook Connect para sacar nombres y avatares de usuarios a mansalva (como hacemos nosotros), así que es normal que los sitios que no tengan que ejecutar estas tareas vayan mucho más rápido.

Para ir tomando soluciones, Sergio y yo hemos pensado en quitar la ventana modal de Uservoice y simplemente enlazar con el foro de sugerencias. Esto hace restar ya algo de tiempo de carga. Pero prescindir de Facebook o de Amazon S3 no creo que sean alternativas realistas.

[carlos]

Me confirma Sergio que estamos usando los datacenters de Europa para EC2 y S3, así que ahí poco podemos ganar.

[carlos]

Otra cosilla: Navegadores como Firefox o Chrome descargan los recursos (JS, CSS, imágenes...) en batería. Pero IE 7 (puede que también alguna versión posterior, aunque creo que no es el caso), si mal no recuerdo, descarga en batería sólo hasta 2 ó 5 recursos como máximo si éstos están en el mismo dominio. Una forma habitual de "engañar" a IE y hacer que descargue más recursos (por ejemplo, las imágenes) en batería es hacer que se utilicen distintos nombres de dominio cada vez. Por ejemplo, en lugar de usar unas URL como:

 http://images.voota.es/partidos/cc_s_psoe.gif  http://images.voota.es/partidos/cc_s_22df8165a89760d00cb4c279d601eb9e65620798.png  http://images.voota.es/partidos/cc_s_Logo-ciudadanos.png  http://images.voota.es/partidos/cc_s_Esquerra.png

que utilice los subdominios images1, images2, images3... de forma rotativa:

 http://images1.voota.es/partidos/cc_s_psoe.gif  http://images2.voota.es/partidos/cc_s_22df8165a89760d00cb4c279d601eb9e65620798.png  http://images3.voota.es/partidos/cc_s_Logo-ciudadanos.png  http://images4.voota.es/partidos/cc_s_Esquerra.png

Es una solución bastante común para dar un pequeño empujoncito a esos navegadores que se empeñan en descargar los recursos más pausadamente.

[carlos]

Aquí hay un ejemplo de cómo preparar un CDN basado en Amazon S3 con Rails:

 http://blog.dynamic50.com/2009/11/12/how-we-used-amazon-cloudfront-as-a-cdn-with-rails-assets/

Básicamente, hay que añadir los CNAME de los distintos subdominios, y hacer que los helpers que generan las URL a las imágenes los vayan usando cíclicamente.

[carlos]

Otro detalle (aunque es el menos preocupante, pero ya que hablamos de rendimiento): Amazon tiene un producto específico para servir de CDN. Si bien S3 está dedicado a almacenamiento, y puede servir de CDN, es lento. Amazon Cloudfront, en cambio, está pensado precisamente para servir recursos de un site, y es muchísimo más rápido que S3 en esta tarea:

 http://aws.amazon.com/cloudfront/