Cómo volarle la peluca a tus usuarios con la

velocidad de tu sitio?

Martin SiniawskiCo-founder de Streema@msinia

Optimización de frontend para devs con poco tiempo

- Red social para oyentes radios.- 40,000 radios de todo el mundo.

- Empezamos hace 4 años y 1/2.

Quiénes somos y hacia dónde vamos

Streema Team (primeros 3 años y 1/2)

- Empezamos hace 4 años y 1/2.- El año pasado fue uno de grandes cambios- Hoy somos: - Cashflow positive. - Felices. Streema Team (ultimo año)

De qué vamos a hablar hoy?

- Un toque de teoría detrás de optimización de frontend.- La técnica milenaria de optimización desarrollada en Streema.- Compartamos experiencias, ideas, dudas, etc.

“Sólo el 10-20% del tiempo de carga es invertido en bajar el documento HTML. El otro 80-90% se invierte bajando el resto de los componentes de la página."

Ojo al piojo con la regla de oro

Los autores de otra regla de oro: "The 3-way"Justin Timberlake, Andy Samberg, et. al, The Lonely Island, Mayo 2011

Esto es muy bueno!!!!

- Optimización de backend suele implicar cambios más complicados y drásticos que los de frontend. - El frontend no será lo más fachero, pero con mejores prácticas se puede lograr gran parte del resultado total.

Un poco de historia...

Steve Souders (@souders) - Co-founder - Liga de la Justicia del Frontend - Autor de la regla de oro (la 1era) - Un loco lindo - Autor de YSlow

Los 28 mandamientos de Souders

● Make Fewer HTTP Requests● Use a Content Delivery Network● Add an Expires Header● Gzip Components● Put Stylesheets at the Top● Put Scripts at the Bottom● Avoid CSS Expressions● Make JavaScript and CSS External● Reduce DNS Lookups● Minify JavaScript● Avoid Redirects● Remove Duplicate Scripts● Configure ETags● Make AJAX Cacheable

● Understanding Ajax Performance● Creating Responsive Web Applications● Splitting the Initial Payload● Loading Scripts Without Blocking● Coupling Asynchronous Scripts● Positioning Inline Scripts● Writing Efficient JavaScript● Scaling with Comet● Going Beyond Gzipping● Optimizing Images● Sharding Dominant Domains● Flushing the Document Early● Using Iframes Sparingly● Simplifying CSS Selectors

Los 28 mandamientos de Souders

Es clave entender el browser

Importa lo básico:- Creación, parseo, rendering de la página. Y también las sutilezas (según el browser): - Rotura del progressive rendering. - Paralelización. - Ver "How Browsers Work": http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

Es clave entender el browser

Qué factores influyen en el tiempo de carga? - Cantidad de recursos totales a bajar, por el overhead de los HTTP requests para bajarlos. - Latencia de red. - Peso de los archivos. - Orden de los archivos.

Hay que medir!Es clave: - Para saber por dónde nos conviene empezar. - Para entender si lo que hicimos dio resultados o no. Se necesitan dos tipos de herramientas, ninguna es suficiente: - Para entender cómo se comporta en detalle nuestras páginas. - Para entender qué le ocurre a nuestros usuarios.

Medición en detalle- Sirve para entender "qué está pasando" en el cliente.- Cosas como: - Cuántos recursos el browser necesita bajar. - Peso de c/u de ellos y total. - Se está usando minificación, compresión, etc.? - Bloqueos entre recursos?

Para esto, con el Firebug o Chrome Dev Tools estás:

Medición en detalle

Medición "Big Picture"- La idea es saber, con un buen grado de confianza: - Cuánto tiempo le tarda a los usuarios acceder al sitio (tiempo de backend + tiempo de frontend). - Verificar cómo impactan los cambios que vamos haciendo en nuestros usuarios reales. Esto es clave!

=

New Relic

New Relic

New Relic

New Relic

En sintesis

=

Five Point Streema Peluca Exploding Technique

Punto 1: Spriting mantenible

- Combinar imágenes para bajar HTTP requests (uno en vez de N).- Forma fácil de bajar drásticamente cantidad de HTTP requests.- Art. original: http://www.alistapart.com/articles/sprites

spritemapper

- http://yostudios.github.com/Spritemapper/- Genera el sprite "con un solo botón".- Cada vez que se agrega/cambia una imagen, se agrega al css original y se regenera el sprite.

Permite mantener las reglas de imagenes en tu CSS de una forma sostenible!

Punto 2: Comprimir Imagenes

Dato picante: "En promedio el 50% del peso de una página son imagenes". 1) Seguir la regla general: - GIF para animaciones. - JPEG para fotos. - PNG para todo lo demás.2) Comprimir imagenes usando lossless compression.

Smush.it

- http://www.smushit.com/ysmush.it/ - Compresor de imagenes (lossless). - Se suben las imagenes, y el sitio las devuelve comprimidas en unos segundos. - No se puede scriptear (por ahora) pero es rápido y permite outsourcear la elección del mejor algoritmo/herramientas.

Imagenes más livianas con unos minutos de trabajo

Punto 3: muy largo para el titulo1) Unificar JS/CSS para disminuir # de HTTP requests.2) Minificarlos (remueve caracteres innecesarios del código para bajar su tamaño).3) Gzippear los recursos minificados.

Entre minificar y gzippear, se calcula ~ 70% de reducción del tamaño de archivo

sprockets

django-compress

nginx (HttpGzipStaticModule)

sprockets- https://github.com/sstephenson/sprockets- gem de Ruby, la versión anterior (1.X) tiene una command line utility.- Declarar dependencias entre JS, para poder escribir código separado en módulos y luego "buildear" los distintos archivos.- También constantes.

sprocketize -I ./lib -I ./constants src/player/player.js src/ui/player/Player.js > javascripts/player.js

django-compress- http://code.google.com/p/django-compress/- Desde el template se lo invoca para incluir el archivo.- Maneja la concatenación, minificación y generación de nombres para evitar problemas de cacheos con nuevas versiones.- Pensando en migrar a django-pipeline o django-compressor.

{% compressed_js 'main_scripts' %}

http://d27dlc8m4co2dl.cloudfront.net/javascripts/main_compressed.r1320173653.js

COMPRESS_JS = { 'main_scripts': { 'source_filenames': ('javascripts/streema_main.js',), 'output_filename': 'javascripts/main_compressed.r?.js', },...

Fabric

- fabfile.org- Libreria Python y command-line tool que permite uso de SSH para deploys de apps y otras tareas de Sysadmin.- Lo usamos para hacer nuestros deploy y sus disintas etapas, en particular lo relacionado a assets.- Llama a las distintas utilidades mencionadas para armar los recursos estáticos listos para deployear.

Punto 4: JS CustomDato picante: "the average top ten U.S. web site only executes 25% of the JavaScript functionality before the onload event." (2008)- Puede ocurrir que: - Se tenga un solo JS para todo el sitio. - Copado porque se cachea de una. - Puede llegar a ser muy pesado, y tal vez las landing necesitan un % chico del archivo.- Se pierde tiempo bajando y parseando código que no es requerido.

Punto 4: JS Custom

Punto 5: Guarda con los Social Plugins!

- Cargarlos siempre asincrónicamente.- Sino frenan el progressive rendering.- La mayoria ofrece forma de incluirlos async, sino se puede hacer fácil insertándolos en "domready" u "onload".- Guarda que son realmente turros.

=

Esta estudiado: + Mejor experiencia de usuario+ Platita+

Bonus Track

Nunca está de más tirar un YSlow o un PageSpeed

Reflexiones Finales

- Decir "la webapp carga en Xs en promedio" no sirve. Hay que ir más allá.- Medir el tiempo de rendering de la página, y optimizar para eso, no sólo el tiempo total.- Siempre antes de empezar, preguntarse:

- Todas las páginas son igual de importantes?

- Hay alguna/s que concentren la mayoría del tráfico? Y del revenue?

Hacerle un poquito de stalking a Super Souders: - Seguirlo en Twitter (@souders) - Leer sus dos tomos: - "High Performance Websites". - "Even Faster Websites". - Chequear el archivo en su blog.Otros interesante: - @paul_irish (Google)Google Speed: http://code.google.com/speed/Yahoo!: http://developer.yahoo.com/performance/

Para profundizar más

Gracias!

Martin Siniawskimartin@streema.com@msinia