Web Performance Optimization (WPO) retreat meli 2011
•Transferir como PPT, PDF•
0 gostou•458 visualizações
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)
![Agenda ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Semelhante a Web Performance Optimization (WPO) retreat meli 2011
Semelhante a Web Performance Optimization (WPO) retreat meli 2011 (20)
Último
Último (20)
Web Performance Optimization (WPO) retreat meli 2011
- 1. Web Performance Optimization Retreat 2011 [email_address] [email_address]
- 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
- 13. Second View
- 20. Hasta acá está todo muy al alcance de nuestras manos..ahora hilemos un poco más fino
- 28. Herramientas
- 34. Preguntas
Notas do Editor
- The Google Analytics exit rate for different page load times collected from Wikia data. Measured over 29 million pageviews ( 2009 )
- Cargar el Css y el Js desde archivos, en vez de consumirlo "inline" 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.
- 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.
- 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
- 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.
- 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.
- 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.
- genera tráfico de red que implica enviar cookies a servers que no las usan Algunos proxies no cachean componentes que viene con cookies
- usar png en vez de gif salva algo de peso
- 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.
- 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