1) Qué es el tiempo de contestación del servidor
El tiempo de contestación del servidor es el tiempo que tarda un servidor en responder a la petición 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 y en todo momento habrá un tiempo extra de espera, que afectará al mismo tiempo de carga total.
Para que los usuarios realmente perciban tu página como rápida, es fundamental reducir el tiempo de contestación del servidor al mínimo.
Según las indicaciones de Google, un buen .
1.1) Tiempo de respuesta del servidor vs TTFB
El Time to First Byte o TTFB es una métrica utilizada a menudo para medir cuánto tarda una página en empezar a cargar, desde el instante en que el usuario pide la carga, hasta que el primer byte llega hasta su navegador.
No es lo mismo que tiempo de respuesta del servidor, en tanto que el TTFB incluye 4 fases:
-
- Establecer una conexión
- Hacer llegar la petición desde el navegador al servidor
- El tiempo de respuesta del servidor
- Enviar un primer byte de información hasta el navegador
- Establecer una conexión
- Hacer llegar la solicitud desde el navegador al servidor
- El tiempo de respuesta del servidor
- Enviar un primer byte de información hasta el navegador
Por tanto, incluye factores que dependen de la conexión y que son absolutamente 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 (al menos de manera significativa) las otras 3 fases. También es verdad que cuando una página es lenta, la mayor parte se marcha en la respuesta del servidor, no en las otras 3 etapas.
El TTFB tampoco es exactamente 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, ficheros CSS, etcétera Todos esos elementos comienzan a cargarse una vez ha terminado el TTFB.
El TTFB termina en el momento en el que el primer byte de información llega a nuestro navegador, y en consecuencia se puede empezar a mostrar algo en la pantalla.
A ojos del usuario, el TTFB es un tiempo “muerto”, a lo largo del cual no pasa nada, o al menos en su navegador no se ve 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 contestación 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, necesitamos medirlo. Existen varias herramientas para medir el tiempo de contestación del servidor:
1.2.1) Pagespeed Insights de Google
No necesita presentación, por el hecho de que 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, pues es completamente subjetiva (depende de lo que Google afirma que es esencial). 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 precisa mejorar.
Pero en el tiempo de respuesta del servidor, que es lo que deseamos medir, no hay subjetividad posible. Google nos lo muestra en segundos y con dos decimales. Además de esto, muestra un aviso siempre y cuando el tiempo de contestación 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.
1.2.2) 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 utilizar.
Ojo, en la vista resumida te afirma el TTFB de una página (ellos 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 precisamente lo que queremos, 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. Entonces, al asignarnos una puntuación (de la A a la F), lo hace teniendo presente nuestra distancia física a ese punto, con lo cual quita de la ecuación los 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 genera una url única que puedes guardarte y volver a visitar siempre que quieras, para equiparar y confirmar si has mejorado. Pagespeed Insights no ofrece esto.
1.2.3) Pingdom
Como opción alternativa a Webpagetest, tienes Pingdom, quizá 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 indica el tiempo de respuesta del servidor.
Aunque semeja más veloz, su desventaja respecto a webpagetest es que solo hace un test, al paso que webpagetest hace 3 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. Finalmente, cada test sí tiene una url única, por 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 prosperar mi tiempo de contestación, siempre y en todo momento hago una primera medición con estas dos herramientas, que guardo (en el caso de Pagespeed me lo apunto) como benchmark o bien vara de medida para ver mi evolución.
Luego, toda vez que hago un cambio en mi sitio, 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, vamos a ver cómo reducir el TTFB. Me fijaré sobre todo en WordPress, que es el CMS más frecuente y en el que más he trabajado con este factor.
Back to top2) 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 3 acciones repetibles y que por sí mismas pueden prosperar tu tiempo de contestación.
Las 2 primeras implican hacer cambios en la configuración de tu Wordpress, pero no en tu servidor.
Las otras dos implican cambiar el servidor que utilizas para alojar tu sitio. Estas podrían servir precisamente igual para otras webs que no sean WP, pero yo no lo he probado. Por ello, recomiendo consultarlo antes con tu proveedor de alojamiento, tal vez te deje hacer una prueba para ver si es la solución que necesitas.
Ojo, no afirmo que las 4 soluciones que planteo sean las únicas. Un tío que sepa de qué manera se procesan las peticiones en WP puede optimizar el tiempo de contestación 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 de nuevo. Con los cuatro métodos que planteo, logrará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 tema más ligero
No en todos y cada uno de los proyectos puedes dejarte mudar sin más de tema, mas si puedes hacerlo, es una de las formas más sencillas de progresar la respuesta del servidor. Cambia tu plantilla actual por otra más ligera (o bien mejor programada).
¿Por qué razón? Las plantillas de WP se han ido complicando hasta el punto de que muchas incluyen cientos de opciones en el backend que las transforman en herramientas para crear sitios a la medida, de manera frecuente con maquetadores visuales incorporados.
Todo esto supone un exceso de requests y scripts que fuerza 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 fabulosas para edificar un lugar 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 bien que esté programada específicamente para cargar rápido. Ciertos ejemplos son Twenty Twelve y todas y cada una de las plantillas por defecto de WordPress, Basic, Schema…
Seguro que hay más, pero no puedo contarlas todas y cada una. Si hallas 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 solo 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; a la inversa, soy un persuadido de Divi y me da la sensación de que está realmente bien programada y es quizás la mejor plantilla de WordPress para crear un sitio genial 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 cuanto he explicado ya antes.
¿Y si ya estás comprometido con la plantilla escogida y, por las razones que sea, necesitas mantenerla? Por fortuna, todavía tienes varias opciones.
2.2) Instalar WP-Rocket
La primera es WP-Rocket. No recomiendo cualquier complemento de cacheado, como por poner un ejemplo Super Cache o W3 Total Cache, porque 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 contestación 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 uno con dos seg
Si después deseas continuar jugando y ajustando cosas, casi seguro que rasguñarás alguna décima más, y te recomiendo que hagas pruebas, mas no puedo dar una configuración que funcionará para cualquier WP, por el hecho de que nuevamente acá 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. Mas 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 deseo compartir son repetibles para cualquiera con unos pocos pasos, me limito a aconsejar esto: si quieres una solución veloz y fácil, gasta treinta euros en WP-Rocket, instálalo 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 tanto más técnicos. Entramos en el tema servidor y plan de alojamiento escogido.
Habrás oído múltiples veces que si tienes un plan de alojamiento compartido no puedes aguardar unas grandes posibilidades. Esto en principio es cierto, pero también lo es que puedes llevar tu página web a un plan más profesional y por lo tanto más costoso, ya sea cloud o bien servidor dedicado, y que tus posibilidades 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. mas el servidor y su configuración quizás sean exactamente lo mismo que tenías antes. Entonces, ¿de qué forma va a contestar más rápido?
Ojo, que solo el hecho de tener una mayor seguridad ya justifica el hecho de no estar en un hosting compartido. Mas, si vas a mudar de alojamiento para prosperar 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 utilizar NGINX, un servidor más rápido que Apache, aunque existen dos formas de emplearlo. Como servidor propiamente dicho, y como reverse proxy.
Cuando lo usas como servidor propiamente dicho, estás cambiando un servidor de posibilidades normales (generalmente Apache) por un servidor prensando para dar respuestas rápidas: NGINX. Es como mudar 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 quiere decir esto? Que ya no necesitas complicarte con el tema de los plugins de caché en tu WP. 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 eficaz que el habitual HTTP once, que era el utilizado por todos y cada uno de los servidores hasta hace poquísimo (se introdujo a mediados de 2015 y se estima que en mayo de 2017 sólo el trece por ciento de los sitios webs lo aguantaban).
El extra que da HTTP/2 es en especial útil para webs con muchas solicitudes (requests) al servidor. Puesto que un navegador que funcione por HTTP once solo aguanta 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 muchas más requests simultáneas.
Así que si deseas sostener 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 destructor.
Tenía un WP con Divi y un child theme comprando en Elegant marketplace; lo elegí pues me agradaba estéticamente, mas en performance era un desastre, puesto 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 dos,6 segundos conforme 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.
2.4) Caché activa de Supercacher de Siteground
Queda la opción de usar NGINX como reverse proxy server. De todas las opciones comerciales, que yo sepa esta configuración.
Es decir, sobre el papel tienes un simple Apache, mas 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 cerció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 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 contestación de servidor puede tener 3 beneficios SEO:
- El tiempo de carga de una página es un factor posicionamiento SEO reconocido por Google.
- La respuesta del usuario mejora cuando una web carga veloz. Puedes conseguir un menor rebote y mayor tiempo en página.
- 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 sitio.
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 veloz particularmente, Google ha reconocido varias veces que el tiempo de carga es una señal que tienen presente al posicionar una web.
La primera de ellas fue mediante un blog post en su blog Webmaster Central, en 2010: “”. En este mismo blog post informaron, 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 dos páginas con una relevancia afín para el término de búsqueda introducido por el usuario, Google puede presentar primero la página que carga más veloz, puesto que el usuario va a preferir navegar por la más rápida de las 2.
¿De qué manera 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 página 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 a través de un “headless browser”, o sea, un navegador que sencillamente 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 lee el código tan pronto como está libre y pasa a la siguiente url. Que las imágenes pesen mucho, por poner 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 sencillamente una hipótesis, puesto que hay al menos dos estudios a gran escala que relacionan TTFB y rankings en Google:
- Un estudio llevado a cabo por Zoompf y publicado en Moz en 2013: “”. Este estudio analizaba 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.
- Otro llevado a cabo por Neil Patel, con datos de Ahrefs, sobre catorce mil trescientos urls y que de nuevo halla la misma correlación entre TTFB y rankings. Está en español, si bien con una traducción un poro robótica: “Analizamos 143,827 URLs y Descubrimos los ”
3.2) Mejora en contestación 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 iniciar siquiera a mostrar algo… existen muchas posibilidades de que me dé la vuelta y haga click en el segundo resultado. En móvil, más todavía.
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 de forma perfecta, 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 adecuado y asimismo como campo de pruebas cuando están experimentando con un nuevo update (los conocidos tests A/B en los que muestran resultados alternativos a un 1 por cien de los usuarios).
3.3) Optimización del presupuesto de rastreo
Queda saber cómo afecta al presupuesto de rastreo o bien crawl budget, uno de los temas estrella en el posicionamiento web en buscadores moderno.
El tema está tan de moda que el propio blog de administradores web de Google lo tocó a principios de dos mil diecisiete (“¿?”. En este artículo, 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 web es veloz, la experiencia del usuario es mejor y el lugar asimismo se rastrea con más frecuencia. Para el robot de Google, si un sitio es veloz significa que los servidores están en buen estado, y puede conseguir 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 lugar al día, y en ese tiempo el bot puede hacer cien solicitudes en vez de 30, estamos ganando el rastreo de 70 urls al día.
El beneficio de esto para el posicionamiento web en buscadores es importantísimo. Cuanto más reciente o más “fresca” está una página en su índice, más posibilidades de posicionar alto, por el hecho de que 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 (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 disminuir al mínimo las redirecciones, errores y páginas que solo 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 afirmé antes, sólo con este cambio, y sin tocar solamente, mi tiempo de respuesta del servidor, conforme Pagespeed Insights, pasó de prácticamente 2,6 segundos a 0,25 segundos. El resultado de ahorrarle 2 segundos y medio por petición a Googlebot destaca.
Pero, ¿y de qué manera ha influido esto en mi tráfico orgánico? Porque de nada me sirve tener al bot leyendo todos los días trescientos urls de mi weblog, si Google luego no me manda más tráfico.
Pues aquí están los datos: un 6 por ciento más de sesiones, en un mes en el que no publiqué ningún artículo (de hecho llevaba desde mayo sin publicar nada) y que no se identifica por ser bueno para el tráfico.
En cuanto a usuarios únicos, la mejoría fue mayor (+14 por cien ), pero es que, además, mejoro en todas y cada una de 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 progresar el tiempo de contestación merece 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 la noche a la mañana.
Como en 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 exactamente lo mismo optimar un lugar pequeño, por poner un ejemplo de 200 urls, y pasar de 50 a cien cada día, que optimar un sitio de veinte.000 urls y pasar de 500 a mil cada día.
Los beneficios para el posicionamiento en buscadores se apreciarán más en el segundo caso. Puesto que en el primer caso el “ciclo” de rastreo del sitio entero ya era corto en todo caso. De ahí que mi pequeño weblog, con menos de 20 urls publicadas, tampoco vio una mejora increíble, si bien el cambio a mejor fue indiscutible. Ahora, imagina aplicar esto a un “mostrenco” de ecommerce con múltiples miles de páginas.
En cualquier caso, las ventajas SEO que se derivan de los 2 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 webs, .
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 servirnos de un ejemplo imágenes, archivos CSS, JS, PDF, etc.
Si quieres ver un caso, rastrea tu lugar con Screaming Frog y verás de que, pese a que sólo contiene cincuenta páginas, Screaming Frog ha rastreado cuatrocientos documentos. Eso mismo hace Googlebot.
Por eso, optimizar la respuesta del servidor y con esto el crawl rate para un sitio pequeño (de menos de 1000 urls) es posible 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 deseas optimar la carga de tu sitio para prosperar en posicionamiento SEO y para progresar la experiencia de tus usuarios, preocúpate en primer lugar del tiempo de carga del servidor. Lo demás puede esperar.
Back to top
