El tamaño importa, ¿pero cuánto? Pues las pruebas que se han hecho dicen que tener una conexión a 5 Mbps es suficiente para que un sitio web funcione de forma bastante razonable siempre desde el punto de vista del cliente, claro. Y es que Internet, como en muchas ocasiones dice Jaime Ferré es como un milagro que funcione, pero tiene limitaciones físicas, porque la velocidad de la luz es la que es.

En muchas ocasiones hablamos que una web ha de cargar rápido y que cargue rápido significa que ha de tardar entre 1,5 y 2,5 segundos. En este tiempo hemos de incluir el tiempo desde que el usuario pulsa “Intro” en su navegador hasta que la página se muestra por pantalla. Y en la mayor parte de veces nos paramos a revisar los pequeños detalles de la carga del propio sitio: que si unir y minimizar CSS y JavaScript, hacer la menor cantidad de peticiones, CSS Sprites… pero hay una limitación física sobre la que la mayor parte de gente no piensa: la distancia.

Imagina que tienes tu servidor web en Estados Unidos, en Boston, por ejemplo. Tú vives en Madrid. Cada vez que hagas una petición a tu sitio web has de ir de tu casa al centro de datos de Madrid, de este a París, Londres, Nueva York, Boston, y volver. En total más de 7.700 kilómetros de cable con varios routers de por medio. Teniendo en cuenta que la velocidad de la luz por cables de fibra óptica es de 200.000 km/h (a diferencia de los 300.000 km/h que tiene en el vacío), sólo por la distancia de cable ya tenemos un tiempo de espera de 38ms, que en ida y vuelta son el doble, 76ms. Y este tiempo es sin contar con los routers y la electrónica que pueda haber, sin tener en cuenta pérdidas y suponiendo que la conexión es directamente con fibra de punto a punto yendo un bit a la máxima velocidad. Esto significa que, prácticamente, 1 décima de segundo se pierde en la conectividad en sí.

Ahora pongamos un ejemplo más práctico. Tenemos una imagen en el servidor que pesa 25KB. Hacer la petición a esa imagen desde Madrid hasta Boston implicaría unos 45ms en la petición, otros 45ms en la respuesta y unos 5ms en traer la información. Esto sería con una conexión de 5 Mbps sin pérdidas. Esto significa que de los 95ms que tarda en hacerse todo el proceso, más del 90% de la información se reduce a tiempos de latencia de la red.

Y ahora que sabes esto… ¿aún te preguntas porqué tu sitio web carga lento? Recuerda que es importante que tus servidores estén cerca (físicamente) de tus usuarios, y si no puede ser así, utilizar sistemas como BGP para conseguirlo.

Una de las API más interesantes que nos trae el W3C en los últimos tiempos y que han implementado algunos navegadores es la Navigation Time API. Si queréis ver una prueba de datos, podéis probar la página de Navigaton Timing de la Guía de WPO.

Pero claro, estos datos dependen de los usuarios y en la mayoría de ocasiones no los tenemos disponibles… así que, ¿por qué no añadirlos a Google Analytics? Sí, como he dicho no estarán en todas las páginas y tendremos información parcial ya que sólo está disponible en algunos navegadores, pero al menos tendremos cierta información.

La información que propongo guardar es la siguiente:

• DNS: es el tiempo que se dedica a hacer peticiones DNS.
• Connect: es el tiempo que se dedica a procesos propios de TCP; esto puede implicar colas en peticiones por problemas de paralelización.
• Petición: es el tiempo que se tarda desde que se hace la petición (enviamos el primer byte) hasta que se devuelve el contenido (recibimos el último byte).
• DOM: es el tiempo que tarda el navegador en maquetar la página con sus elementos.
• Carga: es el tiempo que se tarda desde que se empiezan han recibido los contenidos hasta que la página se ha cargado completamente (incluye el tiempo DOM).

Una vez tenemos caros los distintos tiempos que vamos a tomar como medida, vamos a guardarlos como Eventos en Google Analytics.

function getPerformanceTiming() {
  var timing = window.performance.timing;
  dns = timing.domainLookupEnd - timing.domainLookupStart;
  connect = timing.connectEnd - timing.connectStart;
  peticion = timing.responseStart - timing.connectEnd;
  dom = timing.domComplete - timing.domLoading;
  carga = timing.loadEventEnd - timing.responseEnd;
  return {
    dns, connect, peticion, dom, carga
  };
}

Y ahora que ya tenemos estos datos guardados en variables, tan sólo hay que enviarlos a Google Analytics mediante las funciones de eventos:

window.onload = function() {
  if (window.performance && window.performance.timing) {
    var tiempos = getPerformanceTiming();
    _gaq.push(["_trackEvent", "Navigation Timing API", "DNS", undefined, tiempos.dns, true]);
    _gaq.push(["_trackEvent", "Navigation Timing API", "Connect", undefined, tiempos.connect, true]);
    _gaq.push(["_trackEvent", "Navigation Timing API", "Peticion", undefined, tiempos.peticion, true]);
    _gaq.push(["_trackEvent", "Navigation Timing API", "DOM", undefined, tiempos.dom, true]);
    _gaq.push(["_trackEvent", "Navigation Timing API", "Carga", undefined, tiempos.carga, true]);
  }
};

Aunque todavía supongo que se puede mejorar bastante, aquí os dejo un ejemplo de datos:

El ser humano tiene unas necesidades, y eso es lo que el Señor Maslow puso en formato gráfico en una pirámide… pero Internet también tiene su público y esas necesidades no son tan personales sino que te las da el sitio web que estás visitando. Y es que la pirámide del internauta es muy sencilla.

En la parte más baja de la pirámide, en la base encontramos algo muy simple: el sitio web ha de funcionar. Y es que si un sitio web no funciona, apaga y vámonos. Ya digo que puede parecer una tontería, pero que un sitio web esté caído creo que es de las cosas más duras que te puede pasar. De ahí todo el tema del “cloud” y la virtualización, distribución de cargas, etc… es importante que un proyecto en Internet siempre esté en línea. En resumen: infraestructura.

El siguiente escalón es el de conseguir que el sitio cargue rápido. Si ya has conseguido que el usuario llegue a tu sitio web, es importante que tenga una sensación de velocidad para que se sienta a gusto y pueda navegar por el sitio con tranquilidad. Esto, ya personalmente, partiendo de unas conexiones a Internet mínimas. Para mi, por ahora, me baso en conexiones de 3 Mbps, algo mínimo en todos los países de Europa, Norte América y parte de Sud América. En resumen: Web Performance Optimization.

El siguiente escalón, ya por encima de la mitad, tenemos algo que hará que el proyecto sobreviva: que sea útil. En Internet hoy en día prácticamente tenemos de todo, pero lo que nunca sobra son herramientas y servicios de utilidad. La mayoría de los sitios web de Internet que duran más de un año es porque son útiles, ya sea como Google (buscador), Facebook (red social), Twitter (comunicación), Amazon (compras), eBay (mercadillo / subastas)… ejemplos hay muchos, proyectos que duren mucho no tantos.

Y para acabar, en lo alto de la pirámide, encontramos algo que puede ser un poco feo de decir, pero el sitio web ha de ser “cool”. Está bien que sea útil, que cargue rápido, que funcione, pero una vez tienes todo eso… ¿no debe ser cool? Debe tener ese punto que lo haga accesible a todos pero a la vez con su punto de exclusividad. Recuerdo cuando tener una cuenta en GMail era difícil y si lo tenías, “molabas”. Lo mismo pasa en Facebook, que como todo el mundo lo tiene, tú has de tenerlo, tiene aplicaciones, permite hacer muchas cosas…

4. “cool”
3. utilidad
2. velocidad
1. ¡está en línea!

Y ahora que has visto esa pirámide… ¿en qué escalón está tu sitio web y qué escalón quiere tu usuario?

Por norma general nos toca a los creadores de sitios web decidir dónde va la publicidad o los bloques de contenidos… esto, junto al departamento de marketing acaba constituyendo la creación de un sitio web. Pero, en muchas ocasiones tener la publicidad o determinados bloques de contenido “que generan beneficios” no es siempre el adecuado… ¿qué tal si dejamos a Yahoo! decidir cuál es el sitio óptimo para colocar un bloque de contenido relacionado (tal y como explica en System and method using sampling for allocating web page placements in online publishing of content?

Los medios de comunicación offline, principalmente los periódicos, tienen una estructura de contenidos que poco puede variar, ya que el espacio es limitado en espacio… pero en Internet el espacio no lo es tanto, ya que si es necesario la página se puede estirar o enlazar a otro lugar donde colocar galerías de imágenes u otros elementos.

Es cierto que existen sistemas de testing A/B que pueden ayudar a decidir qué elemento o versión de página es más recomendable para sacar mayor rendimiento, herramientas que permiten personalizar a los usuarios determinados tipos de contenidos dentro de las páginas pero… ¿y si esto se pudiera hacer de forma automática?

El objetivo es tener una herramienta que te permita decidir qué bloques se pueden “mover”, qué tipos de bloques se pueden añadir (por ejemplo poner un bloque de enlaces relacionados, de contenidos relacionados, de galerías, de últimos contenidos, publicidad, etc…) con el objetivo de maximizar los beneficios. De esta forma, el sistema de forma automática iría tomando muestras y probando los contenidos en distintos sitios midiendo lo que el usuario hace cuando navega o pulsa en enlaces. De esta forma se conseguiría que los contenidos que mejor conversión tienen se queden en la página y en las zonas donde mejor conversión hay.

If there may be a significant proportion of potential content items to be sampled that do not have click-through rates, then web page placements may be allocated for content items to be sampled using fair chance slotting. In this case, web page placements sorted in ascending order may be matched with the content items sorted in descending order. This may allow content items with a lower payoff to be allocated locations of web page placements with a higher click probability in order to provide a fair chance to learn click through rates of content items. Otherwise, web page placements may be allocated for content items to be sampled using iterative sampling. In this case, web page placements may be sorted in rank order by normalized click probability. Then a content item may be randomly selected from an optimal subset of content items for allocation to the highest ranked unallocated web page placement. After the content item may be allocated, the content item may be removed from the set of content items. Each remaining highest ranked unallocated web page placement may be similarly allocated a content item randomly selected from an optimal subset of content items until the unallocated web page placements are allocated.

Aunque esto puede parece bastante sencillo, sin duda es un sistema interesante de análisis que podría hacer que el diseño de los sitios cambiase radicalmente e incluso que se personalizase por un determinado perfil de usuario, consiguiendo maximizar los ingresos de los sitios al máximo.

En SEO y WPO hay muchas cifras a tratar. Como expliqué en el artículo que comparaba el WPO con la Fórmula 1 la cosa va de décimas, pero… ¿cuáles son las décimas que importan?

En los paneles de Google Webmaster Tools tenemos muchas cifras relacionados con tiempos, y estas cifras significan muchas cosas distintas. Voy a ver si soy capaz de explicar cada una de ellas.

Una de las primeras gráficas que tenemos es la de “Rendimiento del Sitio”:

Esta gráfica lo que muestra es el tiempo de carga de la página, desde que se descarga el primer byte hasta que se descarga el último, incluyendo la descarga del HTML y de todos los ficheros relacionados (CSS, JavaScript, imágenes, publicidad, etc…). Como digo es el tiempo desde que se recibe el primer byte, y no el tiempo que tarda en conectarse. Esta gráfica va íntimamente relacionada con el Google Page Speed, de forma que supuestamente un buen Page Speed te debería dar un buen tiempo de respuesta. Lo que sí tiene que ver esta gráfica es la conectividad que tienes. Si está limitada en ancho de banda o a Google le cuesta llegar a tu sitio web, el tiempo será malo. Se supone que estas cifras deberían estar rondando los 2,5 segundos, aunque si tu página tiene bastantes contenidos multimedia puede rondar hasta los 5 segundos.

Un siguiente dato que debemos revisar se encuentra en la pestaña “Explorar como Googlebot”:

Tipo de robot de Google: Web
Tiempo de descarga (en milisegundos): 780

Este es el tiempo que Google tarda en descargar únicamente el fichero HTML. En este caso se cuenta el tiempo que tarda el software en generar la página, por lo que se nota enormemente si la página está cacheada de no estarla. El tiempo medio que debería aparecer es de unos 150 a 300 milisegundos (dependiendo del tamaño de la página, aunque una de 100 KB no debería pasar de los 300 si está bien cacheada).

Para acabar tenemos la gráfica de “Tiempo de descarga de una página”:

En este caso, por experiencia propia, sí que influye el tiempo de respuesta de la conectividad, de forma que estar “bien conectado con Google” influye mucho. En este caso el tiempo medio debería estar entre 250 y 400 milisegundos.

Hay que tener en cuenta que las mediciones de estas cifras son bastante distintas según “desde dónde Google” lea los datos. Claro está que no es lo mismo venir de un Centro de Datos que esté en el mismo país en el mismo en el que se encuentra el propio sitio alojado que tener que conectarse desde Mountain View que estar en un país cercano. La simple conectividad hará variar estas cifras.

Tampoco hay que confundir estas cifras con las que puede dar Google Page Speed o Yahoo! YSlow. Hay que diferenciar una cosa que es la conectividad y los tiempos de generación de ficheros, y otra cosa es el tiempo que tarda el navegador en paralelizar las descargas añadidas a un HTML (imágenes y similares) y luego “pintarlo” por pantalla.

Hace unos días que Google ha anunciado una mejora de velocidad en el botón de Google Plus One. ¿Pero realmente estos códigos aumentan la velocidad?

Cuando hice el plugin para WordPress del Social Share Button hice algunos cambios en el código que te daban anteriormente por defecto. Y es que con la llegada de HTML5 se ha introducido un elemento en los scripts, el async que funciona en todos los navegadores desde hace algunas versiones.

Es curioso que Google esté apostando por dejar de dar soporte a varios navegadores (principalmente Explorer 7 para abajo, de Firefox 3.5 para abajo y versiones ya algo antiguas de Chrome y Opera). Sin duda Opera es el mejor navegador en cuanto a soporte de HTML5, por detrás pondría Chrome y Firefox y finalmente Explorer…

Ahora mi pregunta es… ¿realmente es necesario poner un código tal que así?

<script type="text/javascript">
  (function() {
    var po = document.createElement('script');
    po.type = 'text/javascript';
    po.async = true;
    po.src = 'https://apis.google.com/js/plusone.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(po, s);
  })();
</script>

¿O es mejor ya directamente dar soporte a algo tal que así?

<script async type="text/javascript" src="http://apis.google.com/js/plusone.js"></script>

En ambos casos el sistema funciona “igual” de rápido, y pongo el igual entre comillas porque en una versión actualizada de los navegadores el segundo código funciona más rápido ya que no ha de ejecutar la función, algo que consume recursos.

El dilema está servido… por un lado hay que ir dejando de dar soporte a los navegadores antiguos (algo que llevo haciendo desde hace muchos años) y por otro los que deberían presionar para que esto ocurra siguen haciendo cosas extrañas según les parece.

Esto me lleva a pensar en el código de Google Analytics que también, decenas de veces he intentado optimizar… La situación es similar: ¿dejamos el código que nos ofrecen ellos, o ponemos el que realmente deberíamos poner?

<script type="text/javascript">
  (function() {
    var ga = document.createElement('script');
    ga.type = 'text/javascript';
    ga.async = true;
    ga.src = 'http://www.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(ga, s);
  })();
</script>

Lo podemos enfrentar tranquilamente a algo más simple como:

<script async type="text/javascript" src="http://www.google-analytics.com/ga.js"></script>

Personalmente creo que voy a empezar a aplicar ya la segunda opción en la mayoría de los proyectos, al menos en los que estoy seguro de que el segundo código va a funcionar (que van a ser todos los proyectos, con excepción de alguno concreto)… Y es que desde hace ya bastante tiempo sigo la norma básica que me va a hacer ganar dinero: quien tiene un Explorer 6 no ve Youtube y todavía menos va a pagar dinero en mi sitio para comprar algún producto.