Web Performance Optimization (WPO) retreat meli 2011
Descargar como PPT, PDF0 recomendaciones459 vistas
Este documento presenta una agenda para una retirada sobre optimización del rendimiento web. Explica cómo tiempos de carga más lentos afectan negativamente el tráfico y las ventas de sitios web. Luego, cubre buenas prácticas como compresión gzip, cacheo de recursos estáticos, externalización de CSS y JS, y reducción de solicitudes. Finalmente, discute herramientas para medir y mejorar el rendimiento como Google PageSpeed y Speed Tracer.
![Web Performance Optimization Retreat 2011 [email_address] [email_address]](https://image.slidesharecdn.com/webperformanceoptimization2011-110920104641-phpapp01/85/Web-Performance-Optimization-WPO-retreat-meli-2011-1-320.jpg)
Web Performance Optimization (WPO) retreat meli 2011
- 1. Web Performance Optimization Retreat 2011 [email_address] [email_address]
- 2. Agenda Motivación Buenas practicas Herramientas
- 3. Motivación
- 4. The Google Analytics exit rate for different page load times collected from Wikia data. Measured over 29 million pageviews ( 2009 )
- 5. +500 ms -> -20% traffic (Google -2008) +400 ms -> -5 a 9% Full page traffic (Yahoo-2008) +100 ms -> -1% sales (Amazon-2008) +400 ms -> -0.59% searches/users (Google -2009) +2000 ms -> -4.3% revenues/users (Bing -2009)
- 6. #1 Anatomía de una web sana
- 9. Enviar contenido zipeado. Recursos estáticos bien cacheados. Js y Css externalizados. Css at the top, Js at the bottom. Lo básico
- 10. Gzip Para TODO el contenido (estático y dinámico) Reducción de un 70% del peso de la respuesta 90% de los browsers soportan gzip Hilando fino: para comprimir aún más... Css: Key-values ordenados alfabéticamente Html: Atributos ordenados alfabéticamente Usar sólo “ o sólo ‘ Minimización de JS y CSS Google mejoró un 1.5% la compresión
- 12. Cache Cachear componentes ayuda a reducir el número de requests 80% page views se hacen con la cache llena (Yahoo) Search HTML = 5minutos CSS,JS,imágenes = 1mes
- 13. Second View
- 14. Externalizar CSS y JS Mejora el cacheo Ayuda a compartir recursos (+cacheo) Tradeoff cantidad de requests (inline)
- 15. Reducir la cantidad de requests Combinar scripts en un archivo Combinar styles en un archivo Combinar imágenes en sprites
- 16. Stylesheet en el head Acelera el render Ayuda a que el render sea progresivo Javascript después de OnLoad Los elementos script blockean el render
- 18. Postcarga – Hay vida después del onload? Después del onload Script Trackeos Imágenes CSS extras
- 20. Hasta acá está todo muy al alcance de nuestras manos..ahora hilemos un poco más fino
- 21. Uso de CDN Mejor tiempo de respuesta en base a servir contenidos teniendo en cuenta la proximidad Contenido estático <- sin CDN <- con CDN
- 22. DNS Lookups Resolver un lookup cuesta entre 20-120 ms 1 dominio principal y hasta 4 de recursos Trade off paralelismo Los DNS lookups bloquean las descargas en paralelo Request por dominio
- 23. Dominios cookieless No enviar cookies en los dominios static, imágenes, css , js. Muchos proxies no cachean dominios con cookies CSS HTML
- 25. Imágenes Optimizar imágenes Eliminar metadatos reduce el peso sin perdida de calidad. Optimizar css sprites No escalar imágenes en el html Setear width y height acelera el render
- 26. Reducir el número de elementos del DOM Generación del DOM más rápida Búsquedas de elementos más rápida 700 elementos -> OK!
- 27. Buffer flushing La respuesta del backend toma entre 150 y 500ms Se puede enviar html que está listo en ese momento. Mejora la percepción del usuario
- 28. Herramientas
- 29. Tests con múltiples browsers y ubicaciones Network activity Detalles de los request Checklist + reporte de pageSpeed Repeat view Content breakdown by MIME and Domain *.har Load detail Comparaciones
- 33. Speed tracer Network activity Monitor de eventos
- 34. Preguntas
- 35. Imágenes http://www.flickr.com/photos/jamesgold/153504/ http://www.flickr.com/photos/toasty/472330111/ http://www.flickr.com/photos/booksin/3655138991/ http://www.flickr.com/photos/anavrin/194771480/ http://www.flickr.com/photos/halfangel36/2371628236/ http://www.flickr.com/photos/gru/148724512/
Notas del editor
- #5: The Google Analytics exit rate for different page load times collected from Wikia data. Measured over 29 million pageviews ( 2009 )
- #15: Cargar el Css y el Js desde archivos, en vez de consumirlo &quot;inline&quot; ayuda a que los recursos sean cacheados por el borwser. Si se encuentran inline, el css o el js se bajan cada vez que descargamos el html. Con los recursos inline evitamos requests, pero tenemos un html más pesado y perdemos la posibilidad de compartir los recursos ,además de cachearlos de forma independiente. Si los recursos son bien cacheados, se reduce la cantidad de request también sin tener un html más pesado. La decision de externalizar o no se basa en la posibilidad de cachear el recurso.
- #16: La mayoría del tiempo q el usuario pasa en el front end , es descargando componentes (img,css,js,etc). Reducir la cantidad de componentes , reduce la cantidad de request. Combinar archivos: combinar scripts css, js en un solo archivo. Sprites es una de las formas más sencillas y que mejor rinden para reducir la cantidad de request a imágenes. El sprite consiste en juntar todas las imagenes en una, mostrarlas como un background de css, pero solo dejar visible un área de pixeles, que correspondan a la imágene a mostrar.
- #17: Poner los styles en el head, permite un render progresivo, muchos render engines, evitan renderear hasta no cargar todos los estilos para evitar el re paint de los componentes, si es que los estilos cambian. Para evitar que la página permanezca en blanco y aparezca de golpe, y permitir un rendereo progresivo..styles en el head. El problema con el javascript es que bloquea las descargas en paralelo. Cuando el browser está bajando scripts bloquea cualquier tipo de descarga, por más de que sea a otro hostname. DEFER indica q no va haber un document.write...cosa de q el browser siga con el render. pero ff no lo soporta
- #19: El front end tiene que ser lo más simple posible, antes del onload en lo posible , solo tendríamos que cargar html y css..lo indispensable, las imágenes que no se pueden obviar..y luego una vez que cargo la pagina, los scripts, trackeos, imágenes restantes, estilos extra etc. Pensar en lo básico puede ser cubrir solo el area visiblie del usuario con la resoluciión más grande, dar funcionalidad minima indispensable hasta que se muestra la pagina y luego proveer funcionilidad full.
- #22: Que tan próximo está el end user al web server tiene impacto en el tiempo de respuesta. Usar una cdn , es decir tener una colleccion de webservers distribuidos en diferentes puntos geográficos, permite un mejor delivery de contenidos..no hay que olvidarse q el usario pasa la mayor parte del tiempo descargando componentes.
- #23: Resolver un mapeo DNS (Que consiste en mapear un nombre de domino con una dirección IP ) toma entre 20 y 120 ms. La resolución de los dns es cacheada en el ISP pero también en el browser. Reducir el número de dominios que manejamos implica menos lookups, pero también perdemos dominios para realizar descargas en paralelo. Los dominios a eliminar son aquellos que se usan para unas pocas descargas.
- #24: genera tráfico de red que implica enviar cookies a servers que no las usan Algunos proxies no cachean componentes que viene con cookies
- #26: usar png en vez de gif salva algo de peso
- #27: Tener un número excesivo de elementos en el dom es un sintoma de que tenemos contenido de más. Reducir la cantidad de elementos del dom implica menos peso, armado del arbol más rápido y búsquedas más rápidas Más allá de esto, hay que minimizar lo más posible el accero al dom, si queremos velocidad tenemos que en lo posible cachear accesos al dom, no hacer ajustes de layout con javascript, actualizar los nodos offline y luego agregarlos al arbol.
- #28: ayuda a reducir el time to first byte Un buen lugar para hacer flush es el header de la pagina, xq tenes el html ,csss y javascript básicos