Frontend optimization para devs con poco tiempo

1. Cómo volarle la peluca a
tus usuarios con la
velocidad de tu sitio?
Optimización de frontend para devs con poco
tiempo
Martin Siniawski
Co-founder de Streema
@msinia

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

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

4. Streema Team (primeros 3 años y 1/2)
Quiénes somos y hacia dónde
vamos

5. - 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)

6. 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.

7. Ojo al piojo con la regla de oro
“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."
Los autores de otra regla de oro: "The 3-way"
Justin Timberlake, Andy Samberg, et. al, The Lonely Island, Mayo 2011

8. 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.

9. Un poco de historia...

10. 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

11. Los 28 mandamientos de Souders

12. Los 28 mandamientos de Souders
● Make Fewer HTTP Requests
● Use a Content Delivery Network ● Understanding Ajax Performance
● Add an Expires Header
● Creating Responsive Web Applications
● Gzip Components
● Splitting the Initial Payload
● Put Stylesheets at the Top
● Loading Scripts Without Blocking
● Put Scripts at the Bottom
● Coupling Asynchronous Scripts
● Avoid CSS Expressions
● Positioning Inline Scripts
● Make JavaScript and CSS External
● Writing Efficient JavaScript
● Reduce DNS Lookups
● Scaling with Comet
● Minify JavaScript
● Going Beyond Gzipping
● Avoid Redirects
● Optimizing Images
● Remove Duplicate Scripts
● Sharding Dominant Domains
● Configure ETags
● Flushing the Document Early
● Make AJAX Cacheable
● Using Iframes Sparingly
● Simplifying CSS Selectors

13. 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/

14. 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.

15. 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.

16. 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:

17. Medición en detalle

18. 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!
=

19. New Relic

20. New Relic

21. New Relic

22. New Relic

23. En sintesis
=

24. Five Point Streema Peluca
Exploding Technique

25. 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

26. 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!

27. 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.

28. 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

29. Punto 3: muy largo para el titulo
1) 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
nginx
sprockets django-compress (HttpGzipStaticModule)

30. 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

31. 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.
COMPRESS_JS = {
'main_scripts': {
'source_filenames': ('javascripts/streema_main.js',),
'output_filename': 'javascripts/main_compressed.r?.js',
},...
{% compressed_js 'main_scripts' %}
http://d27dlc8m4co2dl.cloudfront.net/javascripts/main_compressed.r1320173653.js

32. 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.

34. Punto 4: JS Custom
Dato 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.

35. Punto 4: JS Custom

36. 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.

37. Esta estudiado:
+ Mejor experiencia de usuario
+ Platita
+

38. Bonus Track
Nunca está de
más tirar un YSlow
o un PageSpeed

39. 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?

40. Para profundizar más
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/

41. Gracias!
Martin Siniawski
martin@streema.com
@msinia