Reducir el tiempo de respuesta del servidor, clave para el SEO

Cómo reducir el tiempo de respuesta del servidor. Mejora el factor que más influye en el tiempo de carga de tu web y mejora también tu SEO.

Qué es el tiempo de respuesta del servidor

El tiempo de respuesta del servidor es el tiempo que tarda un servidor en responder a la solicitud de un navegador.

No importa lo mucho que hayas optimizado tu página web para que se cargue rápido; si el servidor en el que se aloja tu página responde lento, siempre habrá un tiempo extra de espera, que afectará al tiempo de carga total.

Para que los usuarios realmente perciban tu página como rápida, es fundamental reducir el tiempo de respuesta del servidor al mínimo.

Según las directrices de Google, un buen tiempo de respuesta del servidor debe estar por debajo de los 200 milisegundos.

Tiempo de respuesta del servidor vs TTFB

El Time to First Byte o TTFB es una métrica usada a menudo para medir cuánto tarda una página en empezar a cargar, desde que el usuario solicita la carga, hasta que el primer byte llega hasta su navegador.

No es lo mismo que tiempo de respuesta del servidor, ya que el TTFB incluye cuatro fases:

1. Establecer una conexión
2. Hacer llegar la solicitud desde el navegador al servidor
3. El tiempo de respuesta del servidor
4. Enviar un primer byte de información hasta el navegador

Por tanto, incluye factores que dependen de la conexión y que son totalmente ajenos al servidor donde se aloje la página.

Reducir el tiempo de espera del servidor puede estar en nuestra mano, pero difícilmente podremos reducir (al menos de forma significativa) las otras 3 fases. También es cierto que cuando una página es lenta, la mayor parte se va en la respuesta del servidor, no en las otras 3 etapas.

El TTFB tampoco es lo mismo que el tiempo de carga total, ya que esto sería el tiempo que tardan en cargarse todos los recursos de una url al completo, incluyendo todas las imágenes, scripts, archivos CSS, etc. Todos esos elementos empiezan a cargarse una vez ha terminado el TTFB.

El TTFB acaba en el instante en el que el primer byte de información llega a nuestro navegador, y por tanto se puede empezar a mostrar algo en la pantalla.

A ojos del usuario, el TTFB es un tiempo “muerto”, durante el cual no está pasando nada, o al menos en su navegador no se ve absolutamente nada. Lo único que ve es un pequeño spinner dando vueltas en la pestaña activa del navegador.

Cuanto mayor se hace este tiempo de espera, más impaciente se vuelve el usuario. Una página tiene más posibilidades de ser percibida como lenta por parte de los usuarios si tiene un alto TTFB.

Por supuesto, este efecto es más grave aún desde un móvil y más si la conexión es lenta. Si la página no está bien optimizada, el TTFB puede llegar a ser algo desesperante para el usuario.

Entonces, ¿cómo reducir este molesto tiempo de espera para nuestros usuarios?

Como ya he dicho, el principal elemento que está en nuestra mano mejorar es el tiempo de respuesta de nuestro servidor, que suele ser la fase más larga de todas las que componen el TTFB.

Herramientas para medir el tiempo de respuesta del servidor

Para mejorar algo, necesitamos medirlo. Existen varias herramientas para medir el tiempo de respuesta del servidor:

Pagespeed Insights de Google

No necesita presentación, porque es de Google y todos hemos mirado alguna vez a ver qué puntuación le da a nuestra página.

Lo que quizá no sepas es que no sirve de mucho obsesionarse con esa puntuación, porque es totalmente subjetiva (depende de lo que Google dice que es importante). Y no sólo eso, sino que cada x meses Google cambia los baremos por los que te da un aprobado o te casca un necesita mejorar.

Pero en el tiempo de respuesta del servidor, que es lo que queremos medir, no hay subjetividad posible. Google nos lo muestra en segundos y con dos decimales. Además, muestra un aviso siempre que el tiempo de respuesta del servidor pase por encima de 0,2 segundos, que es el máximo recomendado en sus directrices.

Bajar de esa marca no es fácil, pero es posible. Sigue leyendo.

Webpagetest.org

Para mí la herramienta más completa de todas las que miden el tiempo de carga, aunque no la más sencilla de usar.

Ojo, en la vista resumida te dice el TTFB de una página (ellos lo llaman First Byte a secas), que como hemos visto incluye el tiempo de respuesta del servidor y otros factores de conexión. Pero en la vista detallada, podemos ver exactamente lo que queremos, un tiempo que sólo incluye la respuesta del servidor.

Además, webpagetest.org tiene la ventaja de que podemos elegir el punto geográfico desde el que vamos a medir. Luego, al asignarnos una puntuación (de la A a la F), lo hace teniendo en cuenta nuestra distancia física a ese punto, con lo cual quita de la ecuación los miles de kilómetros que a veces tiene que recorrer una url desde su servidor hasta que empieza a cargarse en nuestro navegador.

Además, en esta herramienta cada medición de tiempo de carga de una página genera una url única que puedes guardarte y volver a visitar siempre que quieras, para comparar y confirmar si has mejorado. Pagespeed Insights no ofrece esto.

Pingdom

Como alternativa a Webpagetest, tienes Pingdom, quizá más intuitiva y sencilla de usar. Cuando miras la carga de la página en detalle, tienes la métrica Wait, que es la que te indica el tiempo de respuesta del servidor.

Aunque parece más rápida, su desventaja respecto a webpagetest es que sólo hace un test, mientras que webpagetest hace 3 y te da una media de los resultados de las 3 pruebas. Para tener ese nivel de fiabilidad, que es el recomendable, con Pingdom necesitarías hacer 3 tests a mano.

Además, tiene menos opciones de puntos geográficos para realizar el test que webpagest. Por último, cada test sí tiene una url única, por lo que puedes guardarlos para medir y revisar tu evolución.

Mi método para medir

Antes de hacer algún cambio con el objeto de mejorar mi tiempo de respuesta, siempre hago una primera medición con estas dos herramientas, que guardo (en el caso de Pagespeed me lo apunto) como benchmark o vara de medida para ver mi evolución.

Luego, cada vez que hago un cambio en mi sitio, vuelvo a medir y apunto los resultados, junto a la fecha del cambio y el cambio realizado.

Ahora que ya sabemos cómo medir, vamos a ver cómo reducir el TTFB. Me voy a fijar sobre todo en WordPress, que es el CMS más común y en el que más he trabajado con este factor.

Cómo mejorar el tiempo de respuesta del servidor en WordPress

Aquí vienen las malas noticias, o no tan buenas. No hay una fórmula universal, aplicable a cualquier sitio, ni siquiera a cualquier sitio de WordPress.

Lo que voy a compartir contigo son tres acciones repetibles y que por sí solas pueden mejorar tu tiempo de respuesta.

Las dos primeras implican hacer cambios en la configuración de tu WordPress, pero no en tu servidor.

Las otras dos implican cambiar el servidor que usas para alojar tu sitio. Estas podrían servir exactamente igual para otras webs que no sean WordPress, pero yo no lo he probado. Por ello, recomiendo consultarlo antes con tu proveedor de hosting, quizá te permita hacer una prueba para ver si es la solución que necesitas.

Ojo, no digo que las 4 soluciones que propongo sean las únicas. Un tío que sepa cómo se procesan las peticiones en WordPress puede optimizar el tiempo de respuesta de cualquier sitio, sea cual sea su plantilla y servidor, si le echa unas horitas.

Pero, ¿sabes qué es lo malo? Que si luego se cambia algo en ese WP, hay que hacer el trabajo de nuevo. Con los 4 métodos que propongo, lograrás los máximos beneficios en poco tiempo y sin preocuparte por si luego cambia algún detalle en tu sitio. Vamos a ello:

Instalar un theme más ligero

No en todos los proyectos puedes permitirte cambiar sin más de theme, pero si puedes hacerlo, es una de las maneras más sencillas de mejorar la respuesta del servidor. Cambia tu plantilla actual por otra más ligera (o mejor programada).

¿Por qué? Las plantillas de WordPress se han ido complicando hasta el punto de que muchas incluyen cientos de opciones en el backend que las convierten en herramientas para crear sitios a medida, a menudo con maquetadores visuales incorporados.

Todo esto supone un exceso de requests y scripts que obliga al servidor a hacer demasiados cálculos antes de devolver una simple página o post. Plantillas muy populares, como Divi y Avada, que dan unas opciones fantásticas para construir un sitio a tu medida, cojean de este pie, y mucho.

El remedio es volver a lo básico, una plantilla que se limite a lo básico, o que esté programada específicamente para cargar rápido. Algunos ejemplos son Twenty Twelve y todas las plantillas por defecto de WordPress, Basic, Schema…

Seguro que hay más, pero no puedo enumerarlas todas. Si encuentras ejemplos que te han funcionado, agradeceré que los compartas en los comentarios.

Para que veas que lo que digo es cierto, puedes ver esta tabla en la que muestro el tiempo de respuesta de servidor de una instalación de WordPress vacía (con sólo el post de Hola Mundo) y distintas plantillas instaladas.

Divi                         1,2 seg

Twenty Twelve     0,47 seg

Basic                       0,34 seg

Fuente: Pagespeed tiempo de respuesta del servidor en versión móvil de la web

Esto no es una crítica a Divi; al contrario, soy un convencido de Divi y me parece que está muy bien programada y es quizá la mejor plantilla de WordPress para crear un sitio web excelente a tu medida. Pero cuando se trata de conseguir el mejor tiempo de respuesta posible, no es la mejor opción «de serie», por todo lo que he explicado antes.

¿Y si ya estás comprometido con la plantilla elegida y, por las razones que sea, necesitas mantenerla? Afortunadamente, todavía tienes varias opciones.

Instalar WP-Rocket

La primera es WP-Rocket. No recomiendo cualquier plugin de cacheado, como por ejemplo Super Cache o W3 Total Cache, porque su buen funcionamiento y sobre todo su influencia sobre el TTFB depende de muchos factores.

Con WP-Rocket y la configuración que trae por defecto, en cambio, la bajada en tiempo de respuesta del servidor está prácticamente garantizada, según mi experiencia.

Este es el tiempo de respuesta del servidor de una instalación de WP vacía, con Divi y WP-Rocket, configuración por defecto.

Divi con WP-Rocket         0,71 seg

Divi sin WP-Rocket         1,2 seg

Si después quieres seguir jugando y ajustando cosas, casi seguro que arañarás alguna décima más, y te recomiendo que hagas pruebas, pero no puedo dar una configuración que funcionará para cualquier WP, porque de nuevo aquí dependemos de varios factores.

Con una plantilla ligera y escogiendo las opciones de minificar archivos estáticos y hacer carga asíncrona de CSS y defer JS, casi seguro bajarías de 0,2 segundos y Pagespeed ya no te molestaría más. Pero con una plantilla complicada como Divi o Avada, eso es harina de otra costal. Hay ahí mucho que probar, sobre todo para estar seguros de que no se “rompe” nada.

Como las opciones que quiero compartir son repetibles para cualquiera con unos pocos pasos, me limito a recomendar esto: si quieres una solución rápida y sencilla, gasta 30 euros en WP-Rocket, instálalo tal y como viene, y voilá, tu servidor responderá más rápido y te podrás permitir tener una plantilla de las grandes y lentas. Punto.

NGINX con Varnish + HTTP/2

Aquí nos ponemos un poco más técnicos. Entramos en el tema servidor y plan de alojamiento elegido.

Habrás oído varias veces que si tienes un plan de alojamiento compartido no puedes esperar unas grandes prestaciones. Esto en principio es cierto, pero también lo es que puedes llevar tu web a un plan más profesional y por tanto más caro, ya sea cloud o servidor dedicado, y que tus prestaciones se queden exactamente igual.

Ya que estás pagando por tener más espacio, más seguridad, por no compartir tu ip con otras webs, etc. pero el servidor y su configuración quizá sean exactamente lo mismo que tenías antes. Entonces, ¿cómo va a responder más rápido?

Ojo, que sólo el hecho de tener una mayor seguridad ya justifica el hecho de no estar en un hosting compartido. Pero, si vas a cambiar de alojamiento para mejorar el tiempo de respuesta, necesitas pasar a un servidor o a una configuración distinta. No hay otra.

Las dos opciones que conozco implican pasar a usar NGINX, un servidor más rápido que Apache, aunque existen dos formas de usarlo. Como servidor propiamente dicho, y como reverse proxy.

Cuando lo usas como servidor propiamente dicho, estás cambiando un servidor de prestaciones normales (generalmente Apache) por un servidor prensando para dar respuestas rápidas: NGINX. Es como cambiar un coche familiar por un deportivo. No van a llegar de 0 a 100 en el mismo tiempo.

La configuración que yo he probado y recomiendo es NGINX, más Varnish como caché de servidor. ¿Qué quiere decir esto? Que ya no necesitas complicarte con el tema de los plugins de caché en tu WordPress. El cacheado se hace a nivel servidor.

El plan de alojamiento que yo he probado con estas características, además, incluye el uso de HTTP/2, que es un protocolo más rápido y eficiente que el habitual HTTP 1.1, que era el utilizado por todos los servidores hasta hace muy poco (se introdujo a mediados de 2015 y se estima que en mayo de 2017 sólo el 13% de los sitios webs lo soportaban).

El extra que da HTTP/2 es especialmente útil para webs con muchas peticiones (requests) al servidor. Ya que un navegador que funcione por HTTP 1.1 sólo soporta 6 peticiones simultáneas a un mismo servidor (el resto las pone en espera), pero HTTP/2 ya no tiene esta limitación y puede trabajar con muchas más requests simultáneas.

Así que si quieres mantener tu Divi, o tu Avada, una opción viable y que te ahorrará quebraderos de cabeza puede ser pasar a un plan de alojamiento que te ofrezca NGINX con Varnish y soporte HTTP/2. Yo he probado con un WP Cloud de Host Europe con estas características y el resultado ha sido demoledor.

Tenía un WP con Divi y un child theme comprando en Elegant marketplace; lo escogí porque me gustaba estéticamente, pero en performance era un desastre, ya que añadía más tiempo de espera a la ya de por sí lenta Divi. Con lo que mi tiempo de respuesta era 2,6 segundos según Pagespeed, un horror.

Al cambiar a Host Europe con un servidor NGINX + Varnish + HTTP/2, mi tiempo de respuesta bajó de golpe a 0,25 segundos. ¿Mereció la pena el cambio? Ya lo creo.

Caché dinámica de Supercacher de Siteground

Queda la opción de usar NGINX como reverse proxy server. De todas las opciones comerciales, que yo sepa sólo Siteground ofrece esta configuración.

Es decir, sobre el papel tienes un simple Apache, pero lleva acoplado un NGINX que funciona como mecanismo de caché y encargándose de que la respuesta sea más rápida.

Para aprovechar esta configuración, contrata cualquiera de los servicios de Siteground con Supercacher y asegúrate de que tienes activada las opciones “Caché dinámica” y “Memcached”, que es otra forma de caché que te puede dar un extra, no en respuesta del servidor necesariamente, pero sí sirviendo recursos habituales a usuarios que ya han visitado antes tu página.

OFERTA ESPECIAL: AHORA TODOS LOS PLANES DE HOSTING WORDPRESS DE SITEGROUND A PARTIR DE 0,99 € AL MES

Estas son mis 4 soluciones para bajar el tiempo de respuesta de tu WP. Ahora, vamos a lo que más me interesa: cómo beneficia todo esto al SEO.

Cómo influye el tiempo de respuesta del servidor en el SEO

Reducir el tiempo de respuesta de servidor puede tener 3 beneficios SEO:

1. El tiempo de carga de una página es un factor SEO reconocido por Google.
2. La respuesta del usuario mejora cuando una web carga rápido. Puedes conseguir un menor rebote y mayor tiempo en página.
3. Optimiza tu presupuesto de rastreo. Si tus páginas responden más rápido, el bot de Google puede leer más páginas cada vez que visita tu sitio.

Patente de tiempo de carga como factor SEO

Dentro de su “obsesión” por hacer de internet un lugar más amigable para el usuario en general y más rápido en particular, Google ha reconocido varias veces que el tiempo de carga es una señal que tienen en cuenta al rankear una web.

La primera de ellas fue mediante un post en su blog Webmaster Central, en 2010: “Using site speed in web search ranking”. En este mismo post avisaron, eso sí, de que la velocidad de una web no influye tanto como su relevancia, algo que han repetido varias veces.

¿Qué más sabemos? La patente de Google que habla de este factor dice que dadas dos páginas con una relevancia similar para el término de búsqueda introducido por el usuario, Google puede presentar primero la página que carga más rápido, ya que el usuario preferirá navegar por la más rápida de las dos.

¿Cómo mide exactamente el tiempo de carga Google? Esto no lo sabemos (ojalá).

Pero podemos suponer. La lógica dice que Google mide el tiempo de carga al mismo tiempo que rastrea la web, ya que lo contrario sería duplicar esfuerzos, y con el tamaño actual de la web eso sería absurdo.

Lo más probable es que Google rastree la web por medio de un “headless browser”, es decir, un navegador que simplemente no tiene interfaz gráfico. Y lo que es casi seguro es que el bot no se espera a que la carga de una página esté completa, sino que lee el código tan pronto como está disponible y pasa a la siguiente url. Que las imágenes pesen mucho, por ejemplo, no influye para el rastreo de Google.

Entonces, la métrica que realmente están registrando es el tiempo de espera del servidor.

Esto no es simplemente una hipótesis, ya que hay al menos dos estudios a gran escala que relacionan TTFB y rankings en Google:

1. Un estudio llevado a cabo por Zoompf y publicado en Moz en 2013: “How Website Speed Actually Impacts Search Ranking”. Este estudio analizaba 100.000 páginas y encontraba que el único factor de tiempo de carga que tenía una correlación con los rankings orgánicos era el TTFB.
2. Otro llevado a cabo por Neil Patel, con datos de Ahrefs, sobre 143.00 urls y que de nuevo encuentra la misma correlación entre TTFB y rankings. Está en castellano, aunque con una traducción un poro robótica: “Analizamos 143,827 URLs y Descubrimos los Factores de Velocidad Olvidados que Impactan tus Rankings en Google”

Mejora en respuesta o experiencia de usuario

Aparte de todo esto, el factor humano no deja dudas. Si tengo mucha prisa, hago clic en el primer resultado que me ofrece Google y tarda varios segundos en empezar siquiera a mostrar algo… hay muchas posibilidades de que me dé la vuelta y haga clic en el segundo resultado. En móvil, más todavía.

Ese “regreso” a la página de resultados para hacer clic en un resultado de la competencia es algo que Google puede medir y de hecho mide perfectamente, ya que es una acción que ocurre “dentro“ de su buscador y queda registrada en sus logs.

Desde que Google es Google, ha usado esta métrica de rebote para detectar búsquedas en los que sus algoritmos no estaban ofreciendo el resultado adecuado y también como campo de pruebas cuando están experimentando con un nuevo update (los famosos tests A/B en los que muestran resultados alternativos a un 1% de los usuarios).

Optimización del presupuesto de rastreo

Queda saber cómo afecta al presupuesto de rastreo o crawl budget, uno de los temas estrella en el SEO moderno.

El tema está tan de moda que el propio blog de webmasters de Google lo tocó a principios de 2017 (“¿Qué significa el presupuesto de rastreo para el robot de Google?”. En este post, nos da una de las confirmaciones más claras que he leído nunca en fuentes oficiales de Google:

P: ¿La velocidad de un sitio afecta al presupuesto de rastreo? ¿Y los errores?

R: Si un sitio web es rápido, la experiencia del usuario es mejor y el sitio también se rastrea con más frecuencia. Para el robot de Google, si un sitio es rápido significa que los servidores están en buen estado, y puede obtener más contenido con el mismo número de conexiones.

Poco hay que añadir. El mecanismo está claro: si Google destina un tiempo fijo que sus bots pueden pasar en nuestro sitio al día, y en ese tiempo el bot puede hacer 100 peticiones en lugar de 30, estamos ganando el rastreo de 70 urls por día.

El beneficio de esto para el SEO es importantísimo. Cuanto más reciente o más «fresca» está una página en su índice, más posibilidades de posicionar alto, porque Google se fía, sabe que la información que tiene en su index sobre esa página está actualizada.

No tenemos ninguna forma comprobada o rápida de hacer que Google nos conceda más presupuesto de rastreo (de nuevo según Google depende de la “popularidad” de nuestra web), pero sí podemos hacer que ese presupuesto nos aproveche más, y que el ritmo al que se actualizan nuestras páginas en la caché de Google sea mayor.

La solución es sencilla: reducir el tiempo de respuesta del servidor, y minimizar las redirecciones, errores y páginas que sólo dan contenido duplicado.

Como siempre un ejemplo. Esto es lo que mostró Google Search Console, en su panel estadísticas de Rastreo, cuando pasé mi blog de un servidor Apache sin server caché y en HTTP 1.1, al alojamiento de Host Europe con NGINX, Varnish y HTTP/2.

Como dije antes, sólo con este cambio, y sin tocar nada más, mi tiempo de respuesta del servidor, según Pagespeed Insights, pasó de casi 2,6 segundos a 0,25 segundos. El resultado de ahorrarle dos segundos y medio por petición a Googlebot salta a la vista.

Pero, ¿y cómo ha influido esto en mi tráfico orgánico? Porque de nada me sirve tener al bot leyendo todos los días 300 urls de mi blog, si Google luego no me manda más tráfico.

Pues aquí están los datos: un 6% más de sesiones, en un mes en el que no publiqué ningún post (de hecho llevaba desde mayo sin publicar nada) y que no se caracteriza por ser bueno para el tráfico.

En cuanto a usuarios únicos, la mejoría fue mayor (+14%), pero es que, además, mejoro en todas las métricas: páginas por sesión, duración de la sesión y rebote.

El único cambio que hice en este periodo respecto al mes anterior fue el cambio de servidor. ¿Queda alguna duda de que mejorar el tiempo de respuesta merece la pena?

Antes de cerrar, una pequeña aclaración. Bajar la respuesta del servidor no es una píldora mágica para empezar a rankear como Amazon de la noche a la mañana.

Como en cualquier otra técnica de optimización del crawl budget, los efectos son mayores cuanto mayor es el sitio, y mayor el número de páginas que Google está rastreando.

No es lo mismo optimizar un sitio pequeño, por ejemplo de 200 urls, y pasar de 50 a 100 diarias, que optimizar un sitio de 20.000 urls y pasar de 500 a 1000 diarias.

Los beneficios para el SEO se notarán más en el segundo caso. Ya que en el primer caso el “ciclo” de rastreo del sitio entero ya era corto en cualquier caso. De ahí que mi pequeño blog, con menos de 20 urls publicadas, tampoco vio una mejora espectacular, aunque el cambio a mejor fue innegable. Ahora, imagina aplicar esto a un “mostrenco” de ecommerce con varios miles de páginas.

En cualquier caso, los beneficios SEO que se derivan de los dos primeros puntos (el uso del tiempo de carga como señal para mejorar el ranking de una página y la mejora de la respuesta de usuario) siguen siendo aplicables para un sitio pequeño, igual que para uno grande.

Inciso: ojo con tomar al pie de la letra los datos de Google Search Console en el apartado “Estadísticas de Rastreo”. Lo que muestra la primera gráfica, a pesar de que han titulado el eje Y como Páginas, no son páginas web, sino cualquier documento que requiera una petición del servidor.

Es decir, incluye todas las peticiones que hace Googlebot cuando rastrea una página y que pueden dar un código de respuesta, como por ejemplo imágenes, archivos CSS, JS, PDF, etc.

Si quieres ver un ejemplo, rastrea tu sitio con Screaming Frog y verás de que, a pesar de que sólo contiene 50 páginas, Screaming Frog ha rastreado 400 documentos. Eso mismo hace Googlebot.

Por eso, optimizar la respuesta del servidor y con ello el crawl rate para un sitio pequeño (de menos de 1000 urls) puede que no dé beneficios increíbles, pero tampoco es irrelevante. Ya que Google no se lo rastrea todos los días entero, aunque muestre en Search Console que ha procesado “200 páginas”. No son páginas. Cuidado con Google, que nunca nos da toda la información.

En fin, cierro ya. Si quieres optimizar la carga de tu sitio para mejorar en SEO y para mejorar la experiencia de tus usuarios, preocúpate en primer lugar del tiempo de carga del servidor. Lo demás puede esperar.