Hablar de la rapidez de un sitio web, generalmente se asocia al rendimiento front-end y optimizaciones ideadas para dar mayor rapidez de carga de una página. Pese a ello, eventualmente, conviene virar la vista para enfocarse en la perspectiva del servidor, es decir desde el yacimiento de la carga. Por ello, nuestra propuesta de hoy es reducir los tiempos de respuesta del servidor (TTFB) en WordPress, y determinar su impacto, y ofrecer ciertas ideas para bajar estos niveles.
Indice De Contenidos
Reducir los tiempos de respuesta del servidor TTFB, clave para el SEO
El tema objeto de análisis de hoy, tiene como título reducir los tiempos de respuesta del servidor (TTFB) en plugin, donde las siglas TTFB se refieren al idioma anglosajón, como indicativos de tiempo hasta el primer byte. En términos más coloquiales, quiere decir, que obedece a una medida tiempo, es decir, el tiempo durante el cual un navegador tiene que aguardar cargar el primer byte de datos de un servidor.
Mientras más tiempo de tome en lograr dichos datos, mayor tiempo llevará en mostrar alguna página. Al respecto se suele creer, que esto se debe calcular luego de los tiempos de búsqueda del DNS, no obstante, el cálculo nativo para TTFB en el entramado, procura albergar la latencia de red.
Qué es el tiempo de respuesta del servidor
A los fines de comprender mejor el tema objeto del presente artículo sobre reducir los tiempos de respuesta del servidor (TTFB); es menester tener bien claro y definido lo que significa dicha frase. La misma se refiere al tiempo que se demora un servidor para responder a una demanda de un navegador cualquiera.
Sin importar, lo poco o mucho que esté optimizada una página web, con la intencionalidad de que esta se cargue a gran velocidad; pues si el servidor o fuente donde se hospeda dicha página responde con lentitud, siempre habrá un lapso adicional de espera, que impactará el tiempo total de carga. Por tanto, a los fines de que los usuarios en realidad tengan una página rápida, es crucial disminuir el tiempo de tales respuestas al mínimo; y el cual de acuerdo a Google, debería estar por debajo de los 200 milisegundos.
Tiempo de respuesta del servidor vs TTFB
El denominado time to First Byte o TTFB, se relaciona con una métrica que se emplea para valorar el tiempo que demora un sitio para cargarse, partiendo desde que el usuario requiere la carga, hasta que el primer byte arriba hasta el navegador. Por ello, tiene un comportamiento distinto al del servidor, puesto que el TTFB se concluye en 4 fases a saber:
- Fijar una conexión.
- Permitir que llegue la solicitud desde el navegador al servidor.
- Reducir los tiempos de respuesta del servidor (TTFB).
- Mandar el primer byte de datos hasta el navegador.
Es decir, tiene inmerso elementos que está sujetos a la conexión, pero que son totalmente distintos o extraños a este, y donde se hospede la página. Por tanto reducir los tiempos de respuesta del servidor (TTFB) sin saberlo, puede estar en las manos del usuario, aunque con dificultad se pueden reducir en algo, las otras 3 fases. Pese a que es cierto que si un sitio es lento, buena parte de la responsabilidad de la respuesta, está en el servidor, no en las otras 3 etapas.
En cuanto al TTFB, este también tiene una enorme responsabilidad en el cargado total, por lo que el período que tarden en cargarse los recursos de una url, inclusive, imágenes, scripts, archivos CSS, entre otros, que comenzarán a cargarse cuando finalice la labor de TTFB. El mismo como bien se ha referido, termina cuando el primer byte de datos alcanza al navegador, por lo que se puede empezar a visualizar algún elemento de estos en la pantalla.
A la simple vista del usuario, el TTFB represente un tiempo inerte, donde aparentemente no sucede en su navegador, puesto que no se ve nada en absoluto. Apenas se visualiza un pequeño spinner girando en la pestaña activa del navegador. Mientras más demore este tiempo de espera, el usuario se tornará más impaciente. Porque la página tendrá mayor probabilidad de percibirse más lenta por parte del usuario en caso de tener un alto TTFB.
Herramientas para medir el tiempo de respuesta del servidor
A los fines de mejorar el escenario anterior, donde el usuario se impacienta por los tiempos de respuesta del servidor, afortunadamente, existen algunos mecanismos no sólo para medirlo, sino también para optimizarlo, y justamente, es la propuesta que nos trae acá hoy, sobre cómo reducir los tiempos de respuesta del servidor (TTFB), para ello, veamos las 4 sugerencias siguientes:
Pagespeed Insights de Google
La carta de presentación de esta herramienta, es nada más y menos que del gigante Google, ampliamente conocido y recomendado por quienes lo han usado para atender la puntuación suministrada por sus sitios. Aunque vale acotar, que en realidad no sirve vale de mucho obsesionarse con la puntuación, ya que la misma es muy subjetiva, es decir, actúa según lo que a Google lo percibe como importante. Donde además, cada x meses Google modifica sus baremos, por los que suministra un aproximado.
No obstante, en el tiempo de respuesta del servidor, que es el punto de interés, por ser lo que se pretende medir, si es más objetivo, o por lo menos se acerca en lo posible. Pues Google muestra el tiempo en segundos y con 2 decimales; y adicional a ello, despliega un aviso cuando el tiempo de respuesta del servidor sobrepase los 0,2 segundos, que es el máximo sugerido en sus directrices. Debiendo aclarar, que reducir los tiempos de respuesta del servidor (TTFB), por debajo de ese valor o marcación no es tarea fácil, pero si posible.
Webpagetest.org
Para muchos usuarios, Webpagest.org representa el instrumento más eficiente y completa del total de aquellas para medir los tiempos de carga, pero en contraparte, no resulta muy fácil de usar. Pero atención, en resumidas cuentas señala que el TTFB de una página, referida por estos como First Byte a secas, adiciona el tiempo de respuesta del servidor, entre otros elementos de conexión. Per al detalle, se puede apreciar exactamente lo que se desea, es decir, un tiempo que sólo incluye la respuesta del servidor.
Pingdom
Una forma alterna a la ofrecida por Webpagetest, está Pingdom, la cual para muchos, es más intuitiva y fácil de usar; al observar la carga de la página con precisión, ofrece una métrica Wait, como indicativa del tiempo de respuesta del servidor. Lo que sin duda tiende a reducir los tiempos de respuesta del servidor (TTFB).
La misma, pese a que pareciera ser más veloz, tiene como contra con relación a webpagetest, es que sólo realiza un test, en tanto que webpagetest realiza 3, ofreciendo una media de los resultados de las 3 pruebas. No obstante, para alcanzar este nivel de confianza recomendable, con Pingdom se necesitarán efectuar 3 tests manuales.
Mi método para medir
Por su parte otros usuarios más experimentados en reducir los tiempos de respuesta del servidor (TTFB), previo a cualquier cambio para mejorar estos lapso de respuesta, realizan una primera medición con los instrumentos anteriores, especialmente, Pagespeed y observan su evolución.
Después de lo cual, se procede a efectuar algún cambio en el sitio, y volver a medir, al tiempo de anotar los resultados, con la fecha del cambio y el propio cambio llevado a cabo. Donde una vez, completado este proceso de medición, es que viene la tarea propiamente para reducir los tiempos de respuesta del servidor (TTFB). Fijándose especialmente en WordPress, como el CMS más habitual.
Cómo mejorar el tiempo de respuesta del servidor en WordPress
Es preciso saber que no existe un método estándar que aplique a todos los sitios, ni tan siquiera a uno de WordPress, como una de las plataformas más amigables y flexibles existentes. Pese a ello, si es posible mejorar o reducir los tiempos de respuesta del servidor (TTFB), con la intervención de 3 modelos repetibles para mejorar el tiempo de respuesta.
De estas 3 propuestas, 2 de ellas conllevan a cambios en la forma de configurar a WordPress, no así a nivel de servidor usado como alojamiento del sitio. Y que pudiera servir de manera idéntica para otras webs distintas a WordPress.
Instalar un theme más ligero
Todos los proyectos no son susceptibles de cambios, por lo que hay que saber los que sí lo son, y mejorar con ello la respuesta del servidor. Además, de poder cambia la plantilla actual por alguna menos pesada o mejor programada. La razón es porque las plantillas de WordPress ahora son más complicadas, inclusive, algunas incluyen cuantiosas alternativas en el backend, que las convierten en instrumentos para generar sitios a medida, frecuentemente, con maquetadores visuales incorporados.
Con el propósito de mostrar lo anterior, y mostrar el comportamiento del lapso para responder del servidor de una instalación de WordPress sin nada, o con apenas un contenido, y diferentes plantillas instaladas. Veamos algunos ejemplos sobre reducir los tiempos de respuesta del servidor (TTFB) con Divi:
- 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.
Instalar WP-Rocket
Sobre WP-Rocket se debe agregar, que es compatible con cualquier plugin cacheado, como Super Cache o W3 Total Cache, es muy recomendado, gracias a su excelente operatividad, y especialmente por su poder en TTFB, quien depende de ciertos factores. Además, con él, su configuración por defecto nativo, la disminución del tiempo de respuesta del servidor está casi garantizada. Veamos su comportamiento:
- Divi con WP-Rocket 0,71 seg.
- Divi sin WP-Rocket 1,2 seg.
Si luego de probar con este medio para reducir los tiempos de respuesta del servidor (TTFB), se desea continuar en el juego y hacer ajustes, con seguridad se logrará conseguir alguna décima adicional, por lo que se sugieren las convenientes pruebas, aunque no es posible ofrecer una configuración funcional para cualquier WP, toda vez que se depende de ciertos elementos.
Por ser una plantilla ligera y seleccionado las alternativas para minificar archivos fijos, y efectuar una carga asíncrona de CSS y defer JS, con seguridad bajará unos 0,2 segundos y Pagespeed ya no molestará más. Aunque con una plantilla más compleja como Divi o Avada, es otro nivel. Además, para soluciones rápidas y fáciles, se pueden invertir 30 euracos en WP-Rocket, e instalarlo tal y como se presenta, y listo, el servidor responderá con mayor velocidad, además de permitir disponer de una plantilla grande y lenta.
NGINX con Varnish + HTTP/2
En este punto, la cosa se pone más técnica, pero no por ello, tan difícil como parece; tal es el caso del servidor y el plan de hospedaje seleccionado. Seguramente existen referencias sobre que en una plan de alojamiento compartido no se pueden esperar grandiosas prestaciones. Lo que en principio es verdad, aunque también lo puede conducir una web a un plan más profesional, y por tanto, más costoso, bien sea cloud o servidor dedicado, donde los atributos permanecen iguales.
Como este caso es de paga, y por tanto se dispone de más capacidad y más seguridad al no compartir la ip con otros sitios, entre otros. No obstante, quizá el servidor y su configuración sean idénticos al anterior. Pero ¿Cómo entonces podrá responder más rápido?; pues bien, el supuesto de disponer de mayor seguridad, no justifica el hecho de no estar en un hosting compartido. Mientras que de cambiar de alojamiento para mejorar el tiempo de respuesta, se requiere de un servidor o a una configuración diferente.
Ambas opciones conocidas, precisan usar NGINX, el cual es un servidor más veloz que Apache, pese a que hay dos formas de usarlo; ya sea como un servidor propiamente o bien como reverse proxy. En caso de usarse como servidor, se estará cambiando un servidor con atributos genéricos, como Apache, por otro que dará respuestas más rápidas, como NGINX; algo similar a cunado se cambia un carro familiar por uno deportivo; siendo una obviedad que no llegarán de 0 a 100 km/h en el mismo tiempo.
Al respecto se sugiere, configurar NGINX, adicional a Varnish en forma de caché de servidor, lo que significa, que ya no se requerirá complicarse con el asunto del plugin para caché en WordPress; pues este cacheado se lleva a cabo a nivel servidor. Este tipo de alojamiento con estas prestaciones, adicionalmente incluye el uso de HTTP/2,el cual es un protocolo más veloz y eficiente que el HTTP 1.1 común, y usado por todos los servidores hasta hace poco.
Caché dinámica de Supercacher de Siteground
Como última alternativa está usar un NGINX como reverse proxy server; donde del total de opciones comerciales, conocidas, Siteground ofrece este tipo de configuración. Lo cual significa, que sobre el tapete se coloca un simple Apache, pero lleva consigo un acople de NGINX que opera como formato de caché, y que propicia una respuesta más rápida.
Para sacar provecho de esta configuración, se sugiere contratar algún servicio de Siteground con Supercacher, asegurando de activar las opciones de caché dinámica, o Memcached, como otra modalidad de caché para ofrecer un plus, no en respuesta del servidor precisamente, pero que servirá como un recurso habitual, para usuarios que ya han visitado con anterioridad la página. Y con esto se culminan las 4 posibles soluciones para reducir los tiempos de respuesta del servidor (TTFB) en WP. Siguiendo con el beneficio de estas propuestas para el SEO.
Cómo influye el tiempo de respuesta del servidor en el SEO
Se debe comenzar diciendo que el hecho de reducir los tiempos de respuesta del servidor (TTFB), conlleva a su vez a 3 beneficios en SEO, tal como se señala a continuación:
- El tiempo de carga de una página es un factor SEO reconocido por Google.
- La respuesta del usuario mejora, una web que tiene una carga rápida. Se puede alcanzar un menor rebote, y un mayor tiempo en una página.
- Optimiza el presupuesto de rastreo; en caso de aquellas páginas que responden con prontitud, como el bot de Google, donde se pueden leer más páginas en cada visita al sitio.
Patente de tiempo de carga como factor SEO
Con el propósito de lograr que la internet sea un ambiente más amigable para el usuario en general, y mucho más veloz, Google se encarga de conocer, el tiempo de carga como una señal para tener en cuenta al ranking de una web. La primera a través de un post en el blog Webmaster Central, en 2010, con Using site speed in web search ranking. En dicho post notificaron que la velocidad de una web no impacta tanto como su importancia, un elemento que han repetido varias veces.
Por su parte, la patente de Google que refiere de este elemento, señala que dadas 2 páginas con un significado similar para el término de búsqueda colocado por el usuario, este gigante, puede ofrecer primero aquella página que carga más rápido, puesto que el usuario optará por navegar por la más rápida de ambas.
Aunque no sabemos, el modo de medir el tiempo de carga Google, se puede inferir que Google mide el tiempo de carga en el mismo momento que rastrea la web, pues de lo contrario, se duplicarían los esfuerzos, y con el volumen actual de la web sería absurdo. Por lo que seguramente, Google rastrea la web usando un headless browser, o lo que es lo mismo, un navegador sin interfaz gráfico.
Lo anterior se traduce, en que la métrica que de verdad está registrando, es el tiempo de espera del servidor. Lo cual no es sólo una premisa, puesto que existen, por lo menos 2 estudios a gran escala que vincular al TTFB y al rankings en Google, a cuyos fines, a continuación se colocan ambos estudios:
- El primero se llevó a cabo por Zoompf, sacado a la luz pública en Moz en 2013: llamado como How Website Speed Actually Impacts Search Ranking. Se tomaron como muestra 100 mil páginas, donde se encontró que el único factor de tiempo de carga que guardaba correlación con los rankings orgánicos, fue el TTFB.
- El otro, estuvo a cargo de Neil Patel, con datos de Ahrefs, donde se estudiaron 143 mil urls, donde nuevamente se detectó la misma correlación entre TTFB y el rankings; descubriendo los factores de velocidad olvidados, que afectan el Ranking en Google.
Mejora en respuesta o experiencia de usuario
Adicional a lo anterior, el elemento humano no deja dudas; donde en caso de tener mucha prisa, pinchar en el primer resultado ofrecido por Google es una opción válida, el cual demora unos segundos para comenzar a mostrar algo; pero con alta probabilidad de que arroje de vuelta, debiendo pinchar esta vez, en el segundo resultado.
Dicho retorno o regreso, a la página de resultados para hacer pulsar en un resultado de la competencia, en cuyo caso Google puede medir, y de lo hace perfectamente, puesto que es una acción que sucede en el interior del buscador, quedando registrado en los logs. De tal modo, quedes que Google es tal, ha usado esta métrica de rebote para ubicar búsquedas donde sus algoritmos no ofrecían el resultado ideal, y además, como campo de prueba cuando experimentan un nuevo update.
Optimización del presupuesto de rastreo
Sólo basta conocer cómo afecta al presupuesto de rastreo o crawl budget, uno de los asuntos estrella en el SEO actual. Este dicho tema está tan en auge, que el mismo blog de webmasters de Google lo tocó iniciando el 2017. Pero ¿Qué quiere decir, presupuesto de rastreo?, para comprender mejor esta propuesta, es pertinente descomponer y formular algunas interrogantes: ¿La velocidad de un sitio, afecta al presupuesto de rastreo? ¿Y los errores?
En respuesta a lo anterior, sólo hay que referir que en aquellos casos de un sitio web rápido, la experiencia del usuario será mejor, si el sitio además se rastrea con mayor periodicidad. Para Google, si un sitio es rápido, quiere decir que los servidores están en buena forma, y puede por tanto, lograr más contenido con la misma cantidad de conexiones. Debiendo agregar, que en caso de que Google destina un tiempo estático para que sus bots pasen en un sitio al día, y en dicho tiempo el bot es capaz de realizar 100 solicitudes en vez de 30, se está ganando el rastreo con 70 urls diario.
Vale agregar, que el beneficio de este escenario es de suma importancia para el SEO, pues mientras más fresca sea una página en su índice, mayor posibilidad existe para posicionarse bien alto, en vista de que Google confía, sabe que la información que tiene en su index sobre dicha página se encuentra actualizada.
Si te gustó, este tema puedes revisar también los siguientes enlaces: