Post on 25-Jan-2015
description
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