Ticket #437 (reopened task)

Opened 4 months ago

Last modified 43 hours ago

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

Reported by: frans Owned by: sergio
Priority: low Milestone: 2.4 Twitter
Component: sistemas Version: 1.0
Keywords: Cc:

Description

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?

Attachments

chart-performance voota.png Download (13.6 KB) - added by frans 4 months ago.

Change History

Changed 4 months ago by frans

  • component changed from otros to sistemas

Changed 4 months ago by frans

Changed 4 months ago by frans

  • milestone changed from 1.7 mejoras to 2

Changed 3 weeks ago by frans

  • status changed from new to closed
  • resolution set to duplicate

se hará por tickets específicos

Changed 3 weeks ago by frans

  • status changed from closed to reopened
  • resolution duplicate deleted
  • milestone changed from 9 en reserva to 2.3 optimización

Changed 12 days ago by carlos

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

Changed 8 days ago by frans

  • milestone changed from 2.3 secreto to 2.4 Twitter

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

Changed 44 hours ago by 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.

Changed 44 hours ago by carlos

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

Changed 44 hours ago by 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.

Changed 43 hours ago by 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.

Changed 43 hours ago by 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/

Note: See TracTickets for help on using tickets.