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 página web y mejora también tu posicionamiento web en buscadores.

Back to top

1) Qué es el tiempo de contestación 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 optimado tu página web para que se cargue rápido; si el servidor en el que se aloja tu página responde lento, siempre va a haber un tiempo extra de espera, que afectará al tiempo de carga total.

Para que los usuarios verdaderamente perciban tu página como veloz, es esencial reducir el tiempo de respuesta del servidor al mínimo.

Según las directrices de Google, un buen .

1.1) Tiempo de contestación del servidor vs TTFB

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

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

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

1. Establecer una conexión
2. Hacer llegar la petición desde el navegador al servidor
3. El tiempo de contestación 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 plenamente extraños al servidor donde se aloje la página.

Reducir el tiempo de espera del servidor puede estar en nuestra mano, mas difícilmente vamos a poder reducir (por lo menos significativamente) las otras 3 fases. Asimismo es cierto que cuando una página es lenta, la mayor parte se marcha en la contestación del servidor, no en las otras 3 etapas.

El TTFB tampoco es lo mismo que el tiempo de carga total, puesto 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 momento en el que el primer byte de información llega a nuestro navegador, y por lo tanto se puede comenzar a enseñar algo en la pantalla.

A ojos del usuario, el TTFB es un tiempo “muerto”, durante el como no está pasando nada, o bien 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 todavía desde un móvil y más si la conexión es lenta. Si la página no está bien optimada, el TTFB puede ser algo exasperante 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 prosperar es el tiempo de respuesta de nuestro servidor, que acostumbra a ser la fase más larga de todas las que componen el TTFB.

1.2) Herramientas para medir el tiempo de respuesta del servidor

Para mejorar algo, precisamos medirlo. Existen varias herramientas para medir el tiempo de contestación del servidor:

1.2.1) 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 tal vez no sepas es que no sirve de mucho ofuscarse con esa puntuación, por el hecho de que es absolutamente subjetiva (depende de lo que Google dice que es esencial). Y no sólo eso, sino 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 contestación del servidor, que es lo que deseamos medir, no hay subjetividad posible. Google nos lo muestra en segundos y con dos decimales. Además, muestra un aviso siempre y cuando el tiempo de respuesta del servidor pase sobre 0,2 segundos, que es el máximo recomendado en sus directrices.

Bajar de esa marca no es moco de pavo, pero es posible. Sigue leyendo.

1.2.2) Webpagetest.org

Para mí la herramienta más completa de todas y cada una de las que miden el tiempo de carga, si bien no la más fácil de usar.

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

Además, webpagetest.org tiene la ventaja de que podemos escoger 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 y miles de kilómetros que a veces debe recorrer una url desde su servidor hasta el momento en que empieza a cargarse en nuestro navegador.

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

1.2.3) Pingdom

Como opción alternativa a Webpagetest, tienes Pingdom, tal vez más intuitiva y fácil de usar. Cuando miras la carga de la página en detalle, tienes la métrica Wait, que es la que te señala el tiempo de contestación del servidor.

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

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

1.3) Mi procedimiento 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 2 herramientas, que guardo (en el caso de Pagespeed me lo apunto) como benchmark o encalla de medida para poder ver mi evolución.

Luego, toda vez que hago un cambio en mi lugar, vuelvo a medir y apunto los resultados, junto a la fecha del cambio y el cambio efectuado.

Ahora que ya sabemos de qué forma medir, veremos cómo reducir el TTFB. Me fijaré sobre todo en WordPress, que es el Content Management System más común y en el que más he trabajado con este factor.

Back to top

2) Cómo progresar el tiempo de contestación del servidor en WordPress

Aquí vienen las malas noticias, o no tan buenas. No hay una fórmula universal, aplicable a cualquier sitio, ni tan 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 contestación.

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

Las otras 2 implican cambiar el servidor que utilizas para alojar tu lugar. Estas podrían servir precisamente igual para otras webs que no sean WP, pero no lo he probado. Por este motivo, recomiendo consultarlo antes con tu proveedor de hosting, tal vez te permita hacer una prueba para ver si es la solución que precisas.

Ojo, no digo que las cuatro soluciones que planteo sean las únicas. Un tío que sepa cómo se procesan las solicitudes en WP puede optimar el tiempo de respuesta de cualquier sitio, sea como sea su plantilla y servidor, si le echa unas horitas.

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

2.1) Instalar un theme más ligero

No en todos y cada uno de los proyectos puedes dejarte mudar sin más ni más de theme, pero si puedes hacerlo, es una de las formas más sencillas de progresar la contestación del servidor. Cambia tu plantilla actual por otra más ligera (o mejor programada).

¿Por qué? Las plantillas de WP 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, de forma frecuente con maquetadores visuales incorporados.

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

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

Seguro que hay más, pero no puedo contarlas todas y cada una. 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 contestación de servidor de una instalación de WP vacía (con sólo el artículo de Hola Mundo) y diferentes plantillas instaladas.

Divi                         uno con dos seg

Twenty Twelve     0,47 seg

Basic                       0,34 seg

Fuente: Pagespeed tiempo de contestación del servidor en versión móvil de la página web

Esto no es una crítica a Divi; al contrario, soy un convencido de Divi y me da la sensación de que está muy bien programada y es quizá la mejor plantilla de WordPress para crear un sitio genial a tu medida. Mas cuando se trata de lograr el mejor tiempo de contestación posible, no es la mejor opción “de serie”, por todo cuanto he explicado antes.

¿Y si ya estás comprometido con la plantilla elegida y, por las razones que sea, necesitas mantenerla? A Dios gracias, todavía tienes múltiples opciones.

2.2) Instalar WP-Rocket

La primera es WP-Rocket. No recomiendo cualquier plugin de cacheado, como por poner un ejemplo Super Cache o W3 Total Cache, por el hecho de que su buen funcionamiento y sobre todo su repercusión 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 continuar jugando y ajustando cosas, prácticamente seguro que rasguñarás alguna décima más, y te invito a que hagas pruebas, mas no puedo dar una configuración que va a funcionar para cualquier WP, pues nuevamente aquí dependemos de múltiples factores.

Con una plantilla ligera y eligiendo las opciones de minificar archivos estáticos y hacer carga asíncrona de CSS y defer JS, prácticamente seguro bajarías de 0,2 segundos y Pagespeed ya no te incordiarí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 aconsejar esto: si quieres una solución veloz y sencilla, gasta treinta euros en WP-Rocket, instálalo tal como viene, y eureka, tu servidor responderá más veloz y te vas a poder permitir tener una plantilla de las grandes y lentas. Punto.

2.3) NGINX con Varnish + HTTP/2

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

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

Ya que pagas por tener más espacio, más seguridad, por no compartir tu ip con otras webs, etcétera pero el servidor y su configuración quizá sean precisamente lo mismo que tenías antes. Entonces, ¿de qué manera va a responder más veloz?

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 contestación, necesitas pasar a un servidor o bien a una configuración distinta. No hay otra.

Las 2 opciones que conozco implican pasar a emplear NGINX, un servidor más rápido que Apache, si bien existen dos formas de emplearlo. Como servidor propiamente dicho, y como reverse proxy.

Cuando lo empleas como servidor propiamente dicho, cambias un servidor de posibilidades normales (generalmente Apache) por un servidor prensando para dar respuestas rápidas: NGINX. Es como cambiar un turismo familiar por un deportivo. No llegarán de 0 a cien en exactamente el mismo tiempo.

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

El plan de alojamiento que he probado con estas peculiaridades, además, incluye el uso de HTTP/2, que es un protocolo más rápido y eficiente que el frecuente HTTP once, que era el usado por todos los servidores hasta hace muy poco (se introdujo a mediados de dos mil quince y se estima que en mayo de 2017 sólo el 13 por ciento de los sitios webs lo soportaban).

El extra que da HTTP/2 es en especial útil para webs con muchas peticiones (requests) al servidor. Puesto 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 restricción y puede trabajar con considerablemente más requests simultáneas.

Así que si deseas mantener tu Divi, o bien 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 con estas características y el resultado ha sido asolador.

Tenía un WP con Divi y un child theme comprando en Elegant marketplace; lo elegí por el hecho de que 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 mudar a Host Europe con un servidor NGINX + Varnish + HTTP/2, mi tiempo de contestación bajó de golpe a 0,25 segundos. ¿Mereció la pena el cambio? Ya lo creo.

2.4) Caché activa de Supercacher de Siteground

Queda la opción de utilizar NGINX como reverse proxy server. De todas las opciones comerciales, que sepa 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 contestación sea más veloz.

Para aprovechar esta configuración, contrata cualquiera de los 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 contestación del servidor necesariamente, mas sí sirviendo recursos frecuentes a usuarios que han visitado antes tu página.

OFERTA ESPECIAL:

Back to top

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

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

1. El tiempo de carga de una página es un factor posicionamiento web reconocido por Google.
2. La respuesta del usuario mejora en el momento en que una web carga veloz. Puedes lograr un menor rebote y mayor tiempo en página.
3. Optimiza tu presupuesto de rastreo. Si tus páginas responden más veloz, el bot de Google puede leer más páginas toda vez que visita tu lugar.

3.1) Patente de tiempo de carga como factor SEO

Dentro de su “obsesión” por hacer de internet un lugar más afable 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 presente al rankear una web.

La primera de ellas fue mediante un blog post en su blog Webmaster Central, en 2010: “”. En este blog post avisaron, eso sí, de que la velocidad de una web no influye tanto como su relevancia, algo que han repetido múltiples veces.

¿Qué más sabemos? La  que habla de este factor dice que dadas 2 páginas con una relevancia similar para el término de busca introducido por el usuario, Google puede presentar primero la página que carga más rápido, en tanto que el usuario va a preferir navegar por la más veloz de las dos.

¿Cómo mide precisamente 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, puesto que lo contrario sería duplicar sacrificios, 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”, esto es, un navegador que sencillamente no tiene interfaz gráfico. Y lo que es prácticamente 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 próxima url. Que las imágenes pesen mucho, por servirnos de un ejemplo, no influye para el rastreo de Google.

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

Esto no es simplemente una hipótesis, en tanto que hay cuando 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: “”. Este estudio examinaba cien.000 páginas y encontraba que el único factor de tiempo de carga que tenía una relació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 nuevamente encuentra exactamente la misma relación entre TTFB y rankings. Está en español, si bien con una traducción un poro robótica: “Analizamos ciento cuarenta y tres con ochocientos veintisiete URLs y Descubrimos los ”

3.2) Mejora en respuesta o experiencia de usuario

Aparte de todo esto, el factor humano no deja dudas. Si tengo mucha prisa, hago click en el primer resultado que me ofrece Google y tarda varios segundos en comenzar siquiera a enseñar algo… hay muchas posibilidades de que me dé la vuelta y haga click en el segundo resultado. En móvil, más aún.

Ese “regreso” a la página de resultados para hacer click en un resultado de la competencia es algo que Google puede medir y de hecho mide con perfección, puesto 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 buscas en los que sus algoritmos no ofrecían el resultado conveniente y asimismo como campo de pruebas cuando experimentan con un nuevo update (los famosos tests A/B en los que muestran resultados alternativos a un 1 por ciento de los usuarios).

3.3) Optimización del presupuesto de rastreo

Queda saber de qué manera afecta al presupuesto de rastreo o crawl budget, uno de los temas estrella en el posicionamiento web moderno.

El tema está tan de tendencia que el propio blog de administradores web de Google lo tocó a principios de dos mil diecisiete (“¿?”. En este post, nos da una de las confirmaciones más claras que he leído jamás en fuentes oficiales de Google:

P: ¿La velocidad de un lugar afecta al presupuesto de rastreo? ¿Y los fallos?

R: Si un sitio 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 quiere decir que los servidores están en buen estado, y puede obtener más contenido con exactamente el mismo número de conexiones.

Poco hay que agregar. 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 solicitudes en vez de treinta, estamos ganando el rastreo de setenta urls por día.

El beneficio de esto para el posicionamiento web es importantísimo. Cuanto más reciente o bien más “fresca” está una página en su índice, más posibilidades de posicionar alto, pues 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 bien rápida de hacer que Google nos conceda más presupuesto de rastreo (nuevamente conforme Google depende de la “popularidad” de nuestra web), mas 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 contestación del servidor, y minimizar las redirecciones, errores y páginas que solo dan contenido copiado.

Como siempre y en toda circunstancia 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 afirmé antes, solo con este cambio, y sin tocar nada más, mi tiempo de respuesta del servidor, según Pagespeed Insights, pasó de casi dos,6 segundos a 0,25 segundos. El resultado de ahorrarle 2 segundos y medio por solicitud a Googlebot salta a la vista.

Pero, ¿y de qué manera ha influido esto en mi tráfico desde buscadores? Pues de nada me sirve tener al bot leyendo todos y cada uno de los días trescientos urls de mi blog, si Google luego no me manda más tráfico.

Pues acá están los datos: un seis por ciento 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 por ciento ), 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 con respecto al mes precedente fue el cambio de servidor. ¿Queda alguna duda de que mejorar el tiempo de contestación vale la pena?

Antes de cerrar, una pequeña aclaración. Bajar la contestación del servidor no es una pastilla mágica para empezar a posicionar como Amazon de un día para otro.

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 lugar pequeño, por poner un ejemplo de 200 urls, y pasar de cincuenta a 100 al día, que optimizar un lugar de veinte.000 urls y pasar de 500 a mil cada día.

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

En cualquier caso, las ventajas SEO que se derivan de los dos primeros puntos (el empleo del tiempo de carga como señal para mejorar el ranking de una página y la mejora de la contestación de usuario) prosiguen siendo aplicables para un lugar 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, pese a que han titulado el eje Y como Páginas, no son páginas, .

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

Si deseas ver un caso, rastrea tu lugar con Screaming Frog y verás de que, pese a que solo contiene 50 páginas, Screaming Frog ha rastreado 400 documentos. Eso hace Googlebot.

Por eso, optimar la contestación del servidor y con esto el crawl rate para un sitio pequeño (de menos de mil urls) es posible que no dé beneficios increíbles, pero tampoco es intrascendente. Ya que Google no se lo rastrea todos y cada uno de los días entero, si bien muestre en Search Console que ha procesado “200 páginas”. No son páginas. Cuidado con Google, que jamás nos da toda la información.

En fin, cierro ya. Si quieres optimar la carga de tu sitio para progresar 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 aguardar.

Back to top