Esta entrada está basada en un estudio muy reciente de Neil Patel sobre 143.827 URLs, es decir, es un estudio complejo pero bastante ilustrativo sobre factores que normalmente no miramos y pueden marcar la diferencia.

La velocidad de carga importa

Si, eso está más que claro, hace tiempo que nos bombardean con la velocidad de carga y si sois usuarios de WordPress veréis que existen multitud de plus instituciones orientados a bajarla.

Además, la tendencia a cargar rápido, las AMP pages y muchas otras actualizaciones de Google están orientadas a la velocidad.

Qué sabemos sobre la velocidad de carga

Además de ser un factor importante, también es un factor de incremento de las conversiones, algo a tener muy en cuenta.

Pero al bucear un poco en la herramienta de Google sobre la velocidad de carga (PageSpeed Insights) vemos como el tema se complica por segundos sin llegar a darnos una pista para poder actuar sobre nuestra web.

Dentro de la velocidad de carga hay otros parámetros como son sobre todo los plug-ins (cantidad instalados y activos), el tamaño de las imagenes, el cacheo de página, el tiempo de respuesta del servidor, el tiempo del primer Byte (TTFB), ratios de renderizado, la ubicación del servidor donde se aloja nuestra web, el tiempo de DNS, las descargas paralelas (desde más de un host), la codificación de las cabeceras, el contenido estático, la compresión o vinificación de código, las redirecciones y otros muchos pequeños factores.

Hay webs como por ejemplo Varvy.com donde se muestran montones de soluciones y explicaciones para este tipo de situaciones.

Cómo se ha hecho el estudio

El estudio se ha basado en 5 métricas después de analizar todos los datos de todas las URLs, y estas son:

• Tiempo de primer byte (TTFB): Cuando nuestro navegador obtiene una URL, envía un mensaje al servidor preguntando por el documento HTML en esa URL. Esto mide la cantidad de tiempo que el primer bit de una página web se envía a nuestro navegador. Si esta medida es rápida, indicará que el resto de la página cargará pronto.
• Visualización completa: Esto ocurre cuando la renderización del sitio ha acabado y el sitio web es totalmente visible para el usuario.
• Documento completo: Aunque el sitio web sea visible completamente, existen operaciones por detrás (en el fondo o en background) que añaden funcionalidad es a la página. Una vez se descargan todos estos scripts, el servidor indica que el HTML se ha cargado completamente. Esto es lo que habitualmente nos ofrecen las herramientas online y lo que se conoce por tiempo de carga.
• Totalmente cargado: Una vez el documento HTML ha completado su descarga en nuestro navegador, el código asíncrono comienza a funcionar y empieza a cargar más elementos. Esto no estorba al usuario que ya ha podido empezar a navegar por la página, por lo que no se considera dentro del tiempo de carga. Esta métrica se mide cuando toda la actividad de carga de la web ha parado por 2 segundos.
• Número de peticiones de archivos: Cuando el sitio web se ha cargado, todavía quedan por cargar archivos como CSS, JS o imágenes.

Para poder hacer el test necesitamos una web que en este caso nos ha “prestado” un amigo cercano (gracias Alex) al ser un sitio relativamente nuevo y destinado a pruebas, el sitio web es relativo a juguetes de la patrulla canina (si sois padres sabréis de qué hablo). Y por otro lado, necesitaremos la herramienta de medida de tiempos, que en esta ocasión es webpagetest.org.

Para el estudio se recolectaron los datos de resultados sobre Chrome ejecutado en windows con una resolución de 1024×768 (desktop). Se generaron 5.000 palabras clave con un volumen mínimo de 10 búsquedas mensuales y se tomaron los primeros 30 resultados de Google para tomar todas las URLs del estudio. Se necesitaron dos días en 100 servidores virtuales de Amazon (AWS) para poder realizar el test.

Resultados del estudio

Se confirma del resultado que una web más rápida en cuestión de carga está correlacionada con rankings más altos en Google, pero ahora viene lo interesante: En el estudio se ha encontrado que a partir de la posición 6, las webs son de media un 20% más lentas que la URL de la posición 1.

Además, si se mejora el tiempo de visualización y de documento completo se contribuye directamente a mejorar la posición en los SERPs.

Pero la mayor correlación del estudio se encuentra en el tiempo de primer byte, es decir, esta métrica si que está correlada perfectamente con los puestos 1º, 2º y 3º.

Los datos medios de todas las métricas estudiadas son los siguientes:

De modo que nos podamos hacer una idea de los tiempos que deben cumplir nuestras webs.

Haciendo un poco de historia

Inicialmente, Google si podría haber considerado una métrica simple como el TTFB, pero actualmente y por lo que se desprende de este estudio, el tiempo de documento completo y tiempo de visualización son las variables que pueden cambiar el comportamiento y mejorar los rankings.

Aún así, el TTFB es uno de los factores que continúa siendo más fuerte a la hora de que Google tome nuestra web como una web rápida y tiene un impacto similar al de variables menos significativas o de menor correlación como son las otras dos variables vistas significativas (documento completo y tiempo de visualización).

Por lo que como conclusión y sabiendo que podemos actuar sobre el TTFB directamente mejorando así nuestra web, vamos a intentar dar unas pautas para mejorar en TTFB.

Manos a la obra, ¿cómo mejoramos nuestro TTFB?

Pues lo primero es meter nuestra web en la herramienta webpagetest.org desde el servidor más cercano a nuestra posición. En los resultados del test veremos lo siguiente:

Se puede comprobar como el TTFB (o tiempo para el primer Byte) es de 1,433 segundos.

Lo importante aquí es saber si necesitamos o no hacer mejoras según nuestros datos, en este caso:

Estamos en el 4º escalón, no en el último pero lo que está claro es que no estamos bien.

Lo que podemos hacer para mejorar (puedes pasar esta lista a tu desarrollador) es aplicar unas cuantas o todos estos pasos:

1. Usar un CDN
2. Optimización de código de aplicación
3. Optimizar las llamadas a bases de datos
4. Reducir el número de peticiones HTTP
5. Asegurar un tiempo rápido de respuesta del servidor
6. Utilizar un método de cacheo RFPL (responde first, process later)

En nuestro caso y al ser una web en wordpress, le comenté a Alex poner en marcha el CDN de imágenes gratuito del plus in Jetpack (photon) y el plugin de cacheo W3 Total Cache con unas cuantas configuraciones propias.

Después de aplicar la solución propuesta, tenemos una respuesta como sigue:

0.256 segundos, no está nada mal, por encima de la media y lo que da una oportunidad para aparecer en primera página.

El procedimiento a seguir para cada página que queramos posicionar sería testar cada landing y compararlas con las de los competidores para asegurarnos que en cuestión de velocidad de carga estamos dentro de los márgenes que nos permitan estar pujando por las primeras plazas.

Si nuestro site se basa en un CMS (content manager system) no haría falta que mirásemos todas las páginas, pero mirarlas individualmente nos puede desvelar alguna que otra sorpresa.

A modo de resumen

La velocidad importa, pero es un factor entre muchos otros. Lo que si es importante es saber que si no cumplimos unos mínimos, nuestra página se va a ver relegada a posiciones mucho más bajas.

Lo importante es entrar dentro de la media del sector en cuestión de velocidad y no dejarlo de lado, ir mejorando el resto de factores de posicionamiento mientras la velocidad se va mejorando paulatinamente.

Por eso es importante intentar optimizar el TTFB primero en vez de luchar por todas las variables, lo que no asumirá en una espiral de esfuerzo con poca recompensa.