¿Qué es Web Performance Optimization?

La primera vez que oí hablar a alguien de WEB PERFORMANCE OPTIMIZATION (WPO) u Optimización del Rendimiento de Web fue a Steve Souders, trabajador de Google (y anteriormente en Yahoo!, conocido allí como Yahoo! Superstar) que se centra sobre todo en el rendimiento web y código abierto.

En esos primeros artículos venía a resumir que CUANTO MÁS RÁPIDO VA UN SITIO, MEJOR. Aunque existen una serie de puntos de inicio cuando hablamos del WPO:

  • 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…
  • 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.
  • 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.
  • 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.

¿QUÉ TIENE EN CUENTA EL WEB PERFORMANCE OPTIMIZATION?

Lo primero y principal: ES 100% TECNOLOGÍA. La optimización se basa en las mejoras referentes a la conectividad de redes, la optimización de los servidores web y la mejora de los diferentes elementos que tienen los propios sitios web, desde el HTML hasta el JavaScript, pasando por los CSS o la cantidad de peticiones a servidores DNS.

WEB PERFORMANCE OPTIMIZATION Y LAS MEJORAS DE CONVERSIÓN

Los datos lo dicen todo:

De forma general ya nos encontramos con:

  • 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.

¿CÓMO SE PUEDE ORGANIZAR EL WEB PERFORMANCE OPTIMIZACION?

Aunque las mejoras de WPO se pueden organizar de muchas maneras, podríamos reducirlas a los siguientes grandes grupos:

  • Conectividad
  • Contenidos
  • Cookies
  • CSS
  • Imágenes
  • JavaScript
  • Móvil
  • Servidor

HERRAMIENTAS QUE AYUDAN AL WEB PERFORMANCE OPTIMIZATION

Los grandes sitios como Yahoo! o Google han lanzado distintas herramientas para revisar la velocidad y rendimiento de los sitios web, ya sean desde sus plataformas web como con aplicaciones externas que funcionan en algunos navegadores.

  • Apache JMeter permite hacer pruebas Web, SOAP, bases de datos…
  • 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.
  • Fidder2 es un Web Debugging Proxy que permite monitorizar todo el tráfico contra Internet.
  • 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.
  • Httperf es una herramienta de Hewlett-Packard que permite hacer peticiones de estrés a los servidores y ver cómo se comportan.
  • IBM Page Detailer es una herramienta que permite ver cómo se manda la información de un sitio a los navegadores.
  • Loads.In permite analizar el tiempo de carga de una página desde diferentes puntos del mundo y comparar los resultados.
  • OctaGate SiteTimer permite monitorizar el tiempo de descarga de cada uno de los elementos de una página.
  • Pylot realiza pruebas de carga HTTP de forma que se puede calcular el estrés.
  • Site-Perf permite calcular el tiempo de carga de una página de manera realista dando información de todo tipo.
  • Web Page Analyzer permite calcular el tamaño de la página, tiempo de descarga y ofrece recomendaciones.
  • WebLOAD permite hacer pruebas de estrés a aplicaciones JavaScript de forma que se puede mejorar su rendimiento.
  • 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.

NAVIGATIONTIMING, EL ESTÁNDAR DEL W3C

El W3C (organismo que vela por los estándares de Internet) creó hace un tiempo un grupo de trabajo para crear un estándar en lo que a tiempos de carga se refiere.

Aunque la propuesta no es definitiva, ya existe una primera versión del estándar que permite ver algunos datos de la propuesta. Ahora mismo funciona en Internet Explorer 9 y en Google Chrome 11. Puedes acceder a esta página para ponerlo a prueba.

Este estándar tiene una serie de atributos con los que podremos tener ciertos datos:

  • navigationStart:
    El valor corresponde al tiempo inmediatamente después que el navegador hace un “unload” del documento anterior. En caso de que no haya documento anterior, devolverá lo mismo que fetchStart. Si existen redirecciones anteriores o no hay origen, el valor será 0.
  • unloadEventStart:
    Si el documento anterior y el actual tienen el mismo origen se devolverá el valor que haya justo antes de ejecutar el “unload”. Si no hay documento previo o es una redirección, será 0.
  • unloadEventEnd:
    Si el documento anterior y el actual tienen el mismo origen, se devolverá el valor que haya justo después de ejecutar el “unload”. Si no hay documento previo, o el “unload” no se lleva a cabo correctamente se devolverá 0.
  • redirectStart:
    Si hay redirecciones y son del mismo origen, se devolverá el momento de inicio en el que se inicia la redirección. Sino estará a 0.
  • redirectEnd:
    Si hay redirecciones y son del mismo origen, se devolverá el momento en el que se reciba el último byte de la última redirección. Sino estará a 0.
  • fetchStart:
    Si el recurso que se va a mostrar se llama mediante una consulta GET, se devolverá el valor anterior de que el navegador compruebe si existe algún tipo de caché del recurso. En cualquier otro caso devolverá el valor en el que el navegador comience a recuperar el recurso.
  • domainLookupStart:
    Se devolverá el valor inmediatamente anterior a que el navegador haga la petición DNS del documento. En el caso de conexiones persistentes o que esté cacheado, devolverá el mismo valor que fetchStart.
  • domainLookupEnd:
    Se devolverá el valor inmediatamente después a que el navegador haya realizado la petición DNS y haya sido contestada. En el caso de conexiones persistentes o que esté cacheado, devolverá el mismo valor que fetchStart.
  • connectStart:
    Devuelve el momento inmediatamente anterior a que el navegador haga la petición para recuperar el documento. En el caso de que existan cachés o conexiones persistentes se devolverá el mismo valor de domainLookupEnd.
  • connectEnd:
    Devuelve el momento inmediatamente después a que el navegador acabe la petición para recuperar el documento actual. En el caso de que existan cachés o conexiones persistentes se devolverá el mismo valor de domainLookupEnd. En el caso de que haya un error en la conexión, se devolverá los valores de la nueva conexión. Este valor también incluirá la conexión en el protocolo SSL.
  • secureConnectionStart:
    (Opcional). Devuelve el tiempo inmediatamente anterior a que el navegador comience a procesar la petición de protocolo seguro. Si no se utiliza, devolverá 0.
  • requestStart:
    Devuelve el momento inmediatamente anterior a que se solicite el documento actual. Es aplicado antes de comprobar las cachés. Si hay un error en la conexión, se devuelve el momento en el que se inicia la nueva petición.
  • responseStart:
    Devuelve el tiempo inmediatamente anterior a que el navegador reciba el primer byte de información desde el servidor o desde la caché.
  • responseEnd:
    Devuelve el tiempo inmediatamente posterior a que el navegador reciba el último byte del documento o se cierre la conexión.
  • domLoading:
    El momento en el que el navegador comienza el “loading” de la página.
  • domInteractive:
    El momento en el que el navegador permite la “interactive” de la página.
  • domContentLoadedEventStart:
    Devuelve el instante en el que el navegador establece el evento DOMContentLoaded.
  • domContentLoadedEventEnd:
    Devuelve el instante en el que el navegador finaliza el evento DOMContentLoaded.
  • domComplete:
    El momento en el que el navegador marca el “complete” de la página.
  • loadEventStart:
    Devuelve el tiempo en el que el documento se dispara, quedando a 0 mientras esto no ocurra.
  • loadEventEnd:
    Devuelve el tiempo en el que el documento está completo, quedando a 0 mientras esto no ocurra o sea erróneo.