Web Performance Optimization rapidez por defecto

Transcripción

1 Web Performance Optimization rapidez por defecto

2 Qué es Web Performance Optimization? Steve Souders acuña el térmico WPO Cuanto más rápido va un sitio, mejor. Rapidez por defecto: muchas aplicaciones que se construyen para CMS, lenguajes de programación, la nube, bibliotecas de JavaScript, navegadores, servidores ya están pensadas para ir rápido. Maquetación del navegador: con el fin de hacer que las páginas web más rápido los desarrolladores necesitan la capacidad de encontrar qué partes son más lentas. Esto requiere revisar el tiempo que tarda en cargar y ejecutarse el JavaScript, los CSS, la maquetación de los elementos, la gestión del DOM

3 Qué es Web Performance Optimization? Consolidación: las herramientas de rendimiento de la web, servicios y similares no han llevado un único camino, sino que cada uno ha puesto sus esfuerzos de forma separada. Eso va a cambiar y pronto veremos herramientas que combinan la depuración de JavaScript, el perfil de JavaScript, DOM, el uso de la red todo en una sola herramienta. Las métricas de rendimiento se gestionarán desde un único panel en lugar de tener que visitar múltiples servicios separados. La consolidación también va a ocurrir a nivel de empresa, donde las empresas más pequeñas relacionados con el rendimiento son adquiridos por las grandes empresas de consultoría y servicios. TCP y HTTP: Los protocolos por los que funciona Internet deben ser optimizados, y SPDY es una propuesta. Tenemos que tratar de conseguir más apoyo para el pipelining. Cualquier mejora en la red llegará a todos los sitios y usuarios.

4 Qué es Web Performance Optimization? Estándar: hay que establecer un estándar sobre las formas de medir, los datos, las pruebas La Web Timing Spec es un primer ejemplo a tener presente. Organizaciones en la industria: dentro del mundillo de la WPO veremos nacer y crecer organizaciones profesionales, formación, certificaciones, organismos de normalización Un ejemplo podría ser que los editores web compartan información acerca de los anuncios de publicidad lentos. Los datos: hacer seguimiento de los resultados y encontrar nuevas oportunidades de rendimiento requiere un gran análisis de datos. Es probable que comiencen a verse repositorios públicos de datos relacionados con el rendimiento.

5 Qué es Web Performance Optimization? Verde: los estudios realizados que cuantifican cómo mejorar el funcionamiento web confirman la reducción del consumo de energía y por ello la contaminación que generan los centros de datos. Rendimiento móvil: es como un nuevo punto de partida, se necesita recopilar todo tipo de información hasta encontrar los principales problemas, las causas y encontrar soluciones y crear herramientas para así poder ofrecer información sobre todo esto. La velocidad como elemento diferenciador: muchas de las decisiones que se tomarán sobre Internet se basarán en el rendimiento. Cuando alguien adquiera un dispositivo, elija un proveedor, se revise un sitio web, la lealtad de los usuarios será un factor importante a la hora de hacer mediciones.

6 Algunas cifras Amazon: 0,1 segundos de retraso implican una pérdida del 1% de los ingresos. AOL: hizo una revisión del número de páginas vistas en muchos sitios web y concluyó que aquellos que funcionan rápido tienen unas 7-8 páginas vistas por usuario y que las lentas tan sólo 3-4 páginas vistas por usuario. Bing: 1 segundo de retraso implica una caída del 2,8% de los ingresos; 2 segundos de retraso implican una bajada del 4,3% de los ingresos por usuario. Facebook: 0,5 segundos más lento provoca una caída de tráfico del 3%; 1 segundo provoca una caída del 6%. Google: 0,4 segundos de retraso causan una caída del 0,59% de las búsquedas por usuario; 0,5 segundos más en cargar implica un 25% menos de búsquedas. Yahoo!: 0,4 segundos de retraso causan una caída entre el 5% y el 9% del tráfico.

7 Algunas cifras Google Maps: redujo un 30% el tamaño de sus ficheros y el número de peticiones aumentó un 30%. Hotmail: 6 segundos de retraso en la carga implica 40 millones de anuncios menos al mes, lo que supone 6 millones de dólares menos al año. Mozilla: hizo su página de descargas 2,2 segundos más rápida y hubo un crecimiento de descargas de un 15,4%. Netflix: activó el sistema gzip en sus servidores consiguiendo un aumento de entre el 13% y 25% de velocidad de carga y reducción de un 50% del volumen de tráfico. Shopzilla: consiguió reducir el tiempo de carga de las páginas de 7 segundos a 2 segundos y la conversión se incrementó entre un 7% y un 12%, además de aumentar un 25% las páginas vistas del sitio y pudiendo reducir la cantidad de servidores a la mitad.

8 Algunas cifras El 47% de los usuarios esperan que una página cargue en menos de 2 segundos. El 14% cambia de tienda online si la página tarda en cargar. El 40% de los usuarios abandona una página que tarda más de 3 segundos en cargar. El 64% de los compradores que no están satisfechos cambia de sitio para su próxima compra. El 52% de los compradores afirman que un sitio que carga rápido los fideliza.

9 Cómo? El WPO se separa en 2 partes: FEO y SSO FEO: Front-End Optimization SSO: Server Side Optimization

10 Qué se puede mejorar FEO - Lo que el usuario ve: HTML CSS JavaScript HTTP o sea, el SITIO WEB SSO - Lo que el usuario no ve: Servidor Web Servidor SQL Servidor Proxy TCP/IP Virtualización o sea, la INFRAESTRUCTURA

11 Herramientas boomerang es un código JavaScript que te permite medir el rendimiento de las páginas enviando la información al servidor para analizar los resultados. Google mod_pagespeed: es un módulo para Apache 2 que lleva la configuración por defecto de muchas opciones (compresión, agrupar CSS y JS ). Google Page Speed: es una herramienta que se puede instalar en Mozilla Firefox junto al añadido Firebug y también en Google Chrome y permite revisar una serie de elementos de WPO. Yahoo! YSlow: es una herramienta que se puede instalar en Mozilla Firefox junto al añadido Firebug que permite revisar una serie de elementos WPO, también para Google Chrome.

12 Navigation Timing 2

13 Peticiones HTTP Premisas: - Es mejor hacer pocas llamadas a ficheros de tamaños más elevados. - Hay que tener presente el bloqueo de las peticiones HTTP por los navegadores. - Los navegadores gestionan de media 6 peticiones simultáneas por hostname. Combinar varios CSS o JS en uno o pocos El objetivo es reducir todos los CSS y los JavaScript de la página en uno único. En el caso de los CSS suele ser algo sencillo de hacer, pero los JavaScript pueden no serlo. Si hay que versionarlos, es mejor hacer un cambio de nombre del fichero que no usar parámetros con variables cambiantes. Además, estos ficheros son cacheables en un servidor externo, se pueden enviar mediante compresión y se pueden reducir mediante sistemas de minify. Para hacer esto podemos usar herramientas como JSMin, JavaScriptCompressor, Minify o CSSMin.

14 Peticiones HTTP CSS en la parte superior Los CSS se usan para maquetar por lo que cuanto antes se sepa cómo va a ser la página, antes sabrá el navegador dónde ha de colocar los elementos. Es recomendable usar un CSS externo y no usar CSS inline. Podemos cargar cualquier CSS de una forma relativamente sencilla para que no bloquee: var h = document.getelementsbytagname('head')[0]; var link = document.createelement('link'); link.href = ' link.type = 'text/css'; link.rel = 'stylesheet'; h.appendchild(link);

15 Peticiones HTTP JavaScript en la parte inferior Esto no es del todo cierto. En la parte superior hay que incluir todo aquel JavaScript que se pueda cargar sin que bloquee la página (por ejemplo, funciones o códigos que no se ejecutan sin acción del usuario), además de código asíncrono. En la parte inferior de la página incluiremos aquellos JavaScript que bloquean o que actúan sobre el código de la página impidiendo su carga en tiempo real. Podemos cargar cualquier JavaScript de una forma relativamente sencilla para que no bloquee: var js = document.createelement('script'); js.src = ' var head = document.getelementsbytagname('head')[0]; head.appendchild(js);

16 Peticiones HTTP Combinar imágenes o iconos en CSS Sprites Lo ideal es hacer una carga con la mayor cantidad de imágenes e iconos posibles. Han de ser iconos o imágenes de navegación, no fotografías. Estos ficheros deberían estar en 8 bits e intentar no dejar espacios entre los iconos (o sea, que no haya blancos ). AJAX Si es necesario realizar peticiones en AJAX han de ser en GET (POST es bastante malo a la hora de gestionar cantidades de datos) y es preferible el uso de JSON como almacenamiento.

17 Peticiones HTTP Evitar llamar a contenidos erróneos (código 404) Esto no significa que haya enlaces a páginas que devuelven un 404, sino a contenidos que se incluyen en la página (CSS, imágenes, scripts ) que al hacer la llamada devuelven un 404. Por ejemplo, que la página no tenga favicon.ico puede implicar que la carga de la página se retrase más de 10 segundos. Evitar redirecciones Esto no significa que no se puedan hacer redirecciones para migrar paginas, sino utilizar llamadas continuas a elementos que no lo necesitan.

18 Peticiones HTTP Usar protocolo HTTP 1.1 Es un estándar del año No hay ninguna razón para usar el HTTP 1.0. Usar sistemas de compresión Ya sean deflate, gzip o compress (en este orden de prioridad). Debería aplicarse a todos los contenidos textuales. Los contenidos binarios (algunos) ya van con un algoritmo de compresión, por lo que no es necesario recomprimirlos. Los ficheros de bajo tamaño (menos de 1 KB) no suelen mejorar mucho con compresión.

19 Caché ETag y Last-Modified Es un sistema de caché muy pensado para contenidos estáticos. Son excluyentes uno del otro (por lo que o usamos ETag o usamos Last-Modified) El ETag es en principio más eficiente ya que controla el servidor, fecha de actualización y tamaño del fichero. Si uno de estos elementos cambia automáticamente el ETag cambia. Hay que vigilar cuando se utilizan CDN ya que el ETag hay que configurarlo de una manera distinta si queremos que sea eficiente. El Last-Modified es anterior, pero sigue vigente. Sólo controla la fecha de modificación. Ambos sistemas realizan peticiones cada vez para verificar si se ha actualizado el fichero. Si se ha actualizado se descarga y se actualizan los valores. Si no se han actualizado devuelve un código 304.

20 Caché Expires y Caché Control El sistema de Cache-Control indica cuanto tiempo (desde el momento de descarga) se ha de almacenar el contenido en la caché del navegador. Por norma general los estáticos se almacenan entre 1 mes y 1 año, los semi-estáticos (CSS, JS, etc ) se almacenan 1 semana y los dinámicos se almacenan 1 hora. El Expires indica el momento final hasta el que se ha de cachear el elemento, con fecha y hora. Cada uno de estos sistemas tiene sus ventajas e inconvenientes; en principio el Expires es más eficiente, aunque el Caché Control es más sencillo de gestionar, por lo que acaba siendo el más utilizado. Estos sistemas suelen ir acompañados de la cabecera Age que indica los segundos que lleva cacheado el elemento.

21 Caché Content Delivery Network Las CDN acercan los contenidos al usuario. No siempre devuelven la misma dirección para un mismo contenido. Son útiles en proyectos de gran cobertura internacional, pero pierden eficacia cuando la mayoría de tráfico es de un mismo país. En casos de necesidad de expansión internacional es mejor hacer una distribución de todos los frontales por los distintos países o zonas e intentar distribuir por BGP. Otro sistema es el uso de proxy-caché como Varnish o Traffic Server.

22 Caché Domain Sharding Permite una distribución de contenidos en varios hostname (recomendablemente en un dominio sin cookies). En la actualidad ha perdido bastante utilidad debido a que los navegadores aceptan de media 6 peticiones simultáneas por hostname. Móviles Los terminales móviles, en general,tienen limitaciones importantes en cuento a cachés, por lo que el almacenamiento de información se complica ligeramente. Las últimas versiones de teléfonos inteligentes (ios, Android, BlackBerry, etc ) pueden almacenar cachés de 1 MB por contenido, a diferencia de sus antecesores que la limitación media era de 25 KB.

23 Cookies Pocas cookies y pequeñas Hay que intentar usar lo mínimo las cookies. Cuando se usan deberían hacer referencia a identificadores que se encuentran en el servidor de donde sacar la información. Aplicación a nivel de hostname Las cookies por defecto se heredan de un dominio a sus subdominios. Lo ideal es siempre indicar que las cookies se ejecutan en un hostname concreto, de forma que no se aplican al resto.

24 Cookies Fecha de aplicación Cada cookie ha de disponer de su propio tiempo de aplicación. Cuando sea posible serán cookies de sesión, que pueden ser de mayor tamaño. Cuando sean permanentes lo mejor es que sean de menor tamaño y que la información se almacene en el servidor. Dominios sin cookies Aquellos contenidos que no necesiten cookies estarán alojados en un dominio distinto. Se recomienda dominio para evitar el cross-domain de cookies. Los dominios sin cookies ni envían ni reciben cookies. Se eliminan las cookies a todos los niveles (servidor web, servidor proxy ). Esto va muy relacionado con los sistemas de caché.

25 DNS Reducir peticiones DNS Hay que intentar hacer la menor cantidad de peticiones a los servidores DNS. Para esto hay que cachear elementos externos en dominios internos. Entradas DNS y TTL La configuración de las DNS es básica. Hay que evitar el uso de entradas DNS a excepción de aquellos servicios externos ya que duplican las peticiones y el tiempo de respuesta. Los TTL (tiempos de caché) se pueden aumentar en la mayoría de casos hasta 24 horas. A menos que haya un cambio programado de DNS (caso en el cual se podría reducir días antes el TTL a un nivel más bajo, por ejemplo 1 hora) no sirve de nada tener TTL bajos.

26 Imágenes Optimización de las imágenes Hay que optimizar a varios niveles: - Paleta de colores: Guardando sólo los colores en uso en la paleta y no toda la gama. - Reducir el peso: Eliminando metainformación, principalmente. Herramientas Herramientas en línea: Online Image Optimizer, PunyPNG, SiteReportCard Image Optimization, Smush.it. Herramientas de escritorio: ImageOptim (Mac OSX), JPG & PNG Stripper (Windows), OptiPNG, PNGGauntlet (Windows), PNGOUT (Windows), Radical Image Optimization Tool (Windows), Shrink O Matic (Adobe AIR), TweakPNG (Windows).

27 Diseño Adaptativo Por qué una URL ha de ser distinta para un navegador de escritorio y uno de dispositivo móvil? Mediante el uso de web-proxy se puede distribuir y adaptar determinada información. El diseño adaptativo es un primer paso, pero no es la solución final. Además, no se ha establecido como estándar todavía. Durante un tiempo vamos a tener que trabajar de forma mixta ya que no hay una solución estandarizada para el problema de los dispositivos.

28 Analítica Google Webmaster Tools Existe una pestaña en SALUD llamada ESTADÍSTICAS DE RASTREO que incluye una gráfica MUY importante: Tiempo de descarga de una página (en milisegundos). Este es el tiempo en que GoogleBot tarda en descargarse el HTML de la página en cuestión. El tiempo recomendado está entre 200 y 500. Esto significa que Google se descarga la página en un cuarto de segundo!

29 Google Analytics Analítica Analytics graba datos reales, en gran parte gracias a la API de Web Performance que tienen algunos navegadores ya integrados. Está en CONTENIDO con VELOCIDAD DEL SITIO. Estos datos son parciales pero dan mucha información:

30 Analítica PERO! Has probado distintos datos según el país de origen?

31 Analítica

32 El futuro del WPO Navigation Timing Datos en JavaScript de valores en milisegundos desde el 01/01/1970 Navigation Timing 2 Datos en JavaScript de valores desde el 01/01/1970. Se supone que añade más elementos y datos cliente-servidor. Probablemente añadan gran precisión. Resource Timing Acceso al tiempo de todos los recursos de un documento.

33 El futuro del WPO User Timing Acceso mejorado del tiempo de rendimiento de las aplicaciones (gran precisión). Performance Timeline Sistema para almacenar y recuperar la información de forma unificada. Page Visibility Define cuando o qué partes de la página ve el usuario para reducir el consumo en zonas o elementos no visibles.

34 El futuro del WPO Timing control for script-based animations Control de CPU de los scripts para controlar la frecuencia de refresco de las animaciones y de sus imágenes, principalmente según el Agente (navegador). High Resolution Time Ofrecer tiempos en sub-milisegundos (aká gran precisión ). Efficient Script Yielding Control de limpieza del navegador para la recepción y envío de eventos y callbacks.

35 Javier keepitsimplelab.com Guía WPO gratuita: