Web Performance Optimization (WPO) retreat meli 2011

  • 545 views
Uploaded on

Resumen sobre los tips básicos a considerar para tener una web rápida

Resumen sobre los tips básicos a considerar para tener una web rápida

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
545
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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

Transcript

  • 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
  • 7.  
  • 8. Buenas Practicas
  • 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
  • 11.  
  • 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
  • 17.  
  • 18. Postcarga – Hay vida después del onload?
    • Después del onload
    • Script
    • Trackeos
    • Imágenes
    • CSS extras
  • 19.  
  • 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
  • 24.  
  • 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
  • 30.  
  • 31.  
  • 32.  
  • 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/