No sabía muy bien cómo titular este post porque tiene un objetivo muy claro, pero no tiene un “nombre” como tal. En inglés, esto que voy a explicar se llama Server Timing: es el nombre de una API que ayuda al navegador a desglosar los distintos “pasos” que sigue el navegador del visitante durante una petición HTTP (o HTTPS) y los tiempos que tarda en cada paso.
Yo no lo quería titular Server Timing a secas y por eso he añadido “Analizando peticiones HTTP (WPO)”. Quería dejar claro que todo lo que voy a explicar, aunque se puede usar para otros fines técnicos, lo voy a orientar siempre a WPO.
Cuando hago auditorias trabajo mucho con el concepto Server Timing y con los tiempos de las peticiones HTTP (y HTTPS) desglosadas, es decir, las peticiones que realiza el navegador web.
Saber el tiempo que invierte el navegador en cada petición me ayuda a detectar cuellos de botella en la carga de una web, o, mejor dicho, en la descarga de elementos. Y cuando detecto un cuello de botella en una petición, precisamente las herramientas como Pingdom Tools o las herramientas de desarrollador de Google Chrome me ayudan a tener datos de la API Server Timing para saber dónde puede estar el problema.
Para que te hagas una idea, aquí tienes el mejor ejemplo posible de esto:
Para detectar un firstbyte lento (TTFB), analizamos los tiempos de WAIT dentro de la primera petición HTTP.
Ahora que ya hemos explicando un poco por encima el concepto y lo que vamos a ver en este post, vamos a entrar en materia.
Antes de nada, si quieres más información acerca de las cabeceras de la API Server Timing puedes consultar este enlace: https://www.smashingmagazine.com/2018/10/performance-server-timing/
También quiero aclarar que, aunque en el post mencione una petición HTTP, también me refiero a las peticiones HTTPS. De hecho, mi explicación es más válida para una petición HTTPS. Lo único que no debes olvidar es que, para peticiones con SSL (peticiones HTTPS) tenemos que añadirle 1 fase a la petición, ya que realiza el SSL handshake.
Estas son las fases que nos encontramos en una petición HTTP:
Complejo, ¿no?
No te preocupes, vamos a intentar simplificar al máximo con el siguiente gráfico la carga de una petición HTTPS:
Lo que ves en la imagen de arriba es el desglose de la primera petición a mi web medido con Pingdom Tools: es la petición que indica el firstbyte o TTFB.
Pero para saber datos más concretos necesitamos tiempos. Eso es lo que conseguimos al pasar el ratón por encima:
¿Lo ves? ¿A que ahora es más fácil de entender?
Una de las razones por las que uso Pingdom Tools para medir y auditar en WPO es porque me gusta el desglose de tiempos en las peticiones.
Pues ahora vamos a ver lo mismo, pero con las herramientas de Google Chrome en lugar de con Pingdom Tools.
La herramienta de Google Chrome nos da más datos, pero mucho menos “gráficos” y menos intuitivos a primera vista. Otra cosa interesante de esta herramienta de Google Chrome es que es muy fácil distinguir si una petición en concreto carga alguna cookie. Resulta ideal para comprobar si están funcionando bien los subdominios o CNAMEs cookie-less.
¿Quieres más información sobre esta herramienta? Pues aquí tienes todo lo que necesitas sobre server timing en Google Chrome: https://developers.google.com/web/tools/chrome-devtools/network/reference#timing-explanation
Ahora que conocemos las dos herramientas de las que voy hablar en el post (Pingdom Tools y la herramienta de Google Chrome), vamos a empezar con los conceptos del desglose de Pingdom Tools que debes conocer:
- DNS: Es el tiempo que tarda el navegador en realizar la petición DNS correspondiente. Si esa petición está cacheada mediante DNS-prefetch o si el servidor DNS es “bueno” (como un CloudFront o Amazon Route53, que son DNS geodistribuidos) el tiempo de espera será mínimo (milisegundos).
- SSL: Es el tiempo que tarda en realizarse el famoso “SSL handshake” mediante el cual se intercambia información de encriptado entre el servidor web y el navegador del visitante. Todo se basa en encriptar y desencriptar datos.
- CONNECT: Es el tiempo invertido en realizar la conexión con el servidor al hacer la petición HTTP. El tiempo será menor o mayor dependiendo de la latencia o PING desde el ordenador del visitante al servidor web. Podemos agilizar esta fase con los Resource Hints, concretamente el Preconnect.
- SEND: Se trata de la petición como tal. En esta parte del proceso, el navegador web del visitante es el que envía datos al servidor web. Salvo en formularios de contacto o subidas de datos, no suele ser relevante.
- WAIT: Es el tiempo más crítico a nivel WPO, ya que es donde más suele retrasarse el asunto. En una petición que requiere ejecución PHP, el tiempo de Wait es el más largo. Realmente, llamamos TTFB al tiempo de Wait de la primera petición realizada al cargar una página web.
- RECEIVE: Es el tiempo de descarga de los datos tras realizar la petición. Aunque puede parecer lógico que sea uno de los que más retrasan la carga, la verdad es que con las conexiones actuales y si no hay nada “raro”, el tiempo en milisegundos de Receive no suele ser relevante.
- BLOCKED: El tiempo de Blocked es lo que su propio nombre indica. Se trata de un recurso bloqueado durante algunos milisegundos o segundos debido a la descarga de otros elementos o de lo que se puede llamar priorización de recursos. Esto suele darse algunas veces al cargar javascript sin carga asíncrona.
En el caso de Google Chrome la cosa cambia. Como dije antes, ofrece muchos más datos, pero mucho más variables también.
El caso es que no quiero explicarlo con mis palabras como hice con Pingdom Tools, ya que muchos de los datos que puede dar la herramienta de Google Chrome no los he visto en la vida (por eso digo que son más variables). Por eso, dejo aquí lo que he sacado directamente del enlace anterior: https://developers.google.com/web/tools/chrome-devtools/network/reference#timing-explanation
Ahora vamos a volver a Pingdom Tools para determinar a qué pueden ser debidas las ralentizaciones en las distintas partes de la carga de una petición HTTP:
- WAIT: Problemas relacionados con el servidor o con la falta de cache de página. También problemas relacionados con el overselling del server o con algún problema de ejecución del lenguaje interpretado (en este caso, PHP). En estos casos, es necesario inspeccionar el problema en más profundidad desde el punto de vista del desarrollo.
- DNS: Problemas con los servidores DNS, es decir, DNS lentos o peticiones DNS innecesarias. Un DNS geodistribuido puede ayudar a solucionar esto. CloudFlare es un ejemplo que puedes usar de forma gratuita.
- SSL: En algunos casos esporádicos podemos encontrarnos retrasos a la hora de realizar el SSL handshake. Suelen estar causados por problemas en el servidor web. Sí, has leído bien: problemas en el servidor web por una mala implementación o falta de potencia.
- RECEIVE: Si esto va lento, hay dos opciones. O los archivos que estas intentando descargar son muy grandes o el servidor tiene la conexión saturadísima y no puede descargar datos más rápido.
Te faltan partes, ¿no? Pues es porque esas partes no suelen dar problemas y, si por alguna razón los dan, el fallo no está en ellas sino en la waterfall en general, es decir, en el esquema de carga completo. Esto se debe a que puede haber situaciones donde una petición bloquee a otras, como es el caso de las dependencias de Javascript.
Por ejemplo, en el caso de encontrarte peticiones ralentizadas por BLOCKED, esto suele ser por no tener una carga asíncrona efectiva en el Javascript. Lo expliqué en este otro post: https://alvarofontela.com/optimizar-carga-javascript-css-wordpress/
Lo malo es que, en algunos casos, por razones de dependencias o de peticiones externas no podemos solventar los excesivos tiempos de BLOCKED.
También quiero recomendarte que nunca te fíes de las barras en la carga de elementos o peticiones de Pingdom Tools.
- Ejemplo de la carga de Techcrunch: https://alvarofontela.com/wp-content/uploads/enlace1.png
Ves que hay mucho amarillo de WAIT en el ejemplo anterior, ¿no? Pero aun así la web carga rápido, en 247 milisegundos o lo que vendrían a ser 0,2 segundos.
Las barras hacen siempre referencia al tiempo de carga total de la web. Por tanto, no hay que dejarse engañar y siempre hay que pasar el ratón por encima de la barra de la petición para saber los tiempos, aunque las barras sirven para comparar tiempo entre peticiones y detectar los cuellos de botella.
Cualquiera de estos datos, si los analizamos con Google Chrome, pueden tener un resultado completamente diferente. ¿Cuál es la razón? Pues que el Google Chrome de nuestro ordenador puede tener mucha más variación en los resultados al depender de una conexión doméstica, una potencia compartida con procesos en background y, en definitiva, unas circunstancias muy variables y muy difíciles de aislar a no ser que tengamos un equipo (ordenador) solo para realizar estas pruebas siempre en las mismas condiciones.
Pero las herramientas de Google Chrome y Pingdom Tools no son las únicas que nos dan datos de Server Timing. GTMetrix, otra herramienta muy popular en WPO, también ofrece datos de este tipo:
A mí la herramienta de waterfall de GTMetrix me parece que ofrece MUCHA más información detallada de cada petición, pero el conjunto es diferente y el acceso a los datos es mucho menos visual.
¿Te ha quedado claro todo? ¿Lo has entendido? No es un post fácil de comprender para gente poco experimentada, pero me parece un artículo muy necesario y el inicio de una serie de posts donde quiero introducir toda la teoría con algo de práctica, con el fin de explicar finalmente el procedimiento que utilizo en mis auditorias WPO.
Esto aún no ha acabado aquí: ahora vamos con la parte práctica, que es la “chicha” de este post.
En primer lugar, te dejo este vídeotutorial que he grabado para ti y he subido a mi canal de Youtube. Aquí puedes ver un poco más sobre este proceso:
Vamos a empezar poniendo un ejemplo a lo grande: la web de la Casa Blanca.
¿Por qué elijo esta de todas las webs que hay en Internet? Pues porque es una web creada con WordPress que tiene gran relevancia a nivel mundial.
- Ejemplo de carga de whitehouse.gov: https://alvarofontela.com/wp-content/uploads/enlace2.png
Y, antes de nada, quiero decir que para mí lo que veo en este waterfall es una implementación perfecta con WordPress a nivel WPO. Sin embargo, también es un ejemplo perfecto de cómo una sola petición externa puede destrozarte una velocidad de carga perfecta, ya que el server a donde se realiza la petición tiene algún tipo de problema con el certificado SSL:
También hay que mencionar que aún se puede ver claramente en el waterfall. Si aplicas la lógica, verás que el tiempo “extra” no se suma al total, ya que la petición se está realizando en async y termina de cargar cuando el usuario ya está viendo la web perfectamente montada. Sin embargo, lo que quiero que veas es cómo una petición externa puede ralentizarte toda la web por problemas de DNS o SSL que se pueden detectar con una herramienta como las que estamos comentando en este post.
Te voy a poner otro ejemplo muy claro para que veas que una simple petición puede llegar a ralentizarte toda la web. En la web de Nginx.com (el servidor web del que soy fan) podemos encontrarnos una petición externa que destaca sobre las demás:
Se trata de una petición externa que tarda más en cargar. No tiene por qué representar un problema en la carga, pero en algunas ocasiones si esa petición no se realiza de forma async puede dar fallos importantes.
En sitios web grandes también debemos tener cuidado con el API Heartbeat (admin-ajax.php), del que ya hemos hablado en este blog.
La petición al admin-ajax.php de WordPress no tiene por qué representar una ralentización en la carga, excepto si el WAIT es tan largo que se acaban de cargar el resto de las páginas sin que los datos que tienen que cargar por AJAX se hayan podido visualizar.
Esto ocurre bastante en sitios web complejos como tiendas online WooCommerce o webs que necesitan cargar muchos datos de forma dinámica sin necesidad de recargar la página, es decir, mediante AJAX.
Si quieres más información sobre este tipo de problema, puedes leer mi post sobre el API Heartbeat de WordPress: https://alvarofontela.com/api-heartbeat-admin-ajax-php-wordpress/
Finalmente, solo quiero aclarar un par de puntos como resumen de lo que es el Server Timing revisado con Pingdom Tools:
- Si el tiempo se excede en DNS, intenta usar unas DNS mejores o geolocalizadas: CloudFlare DNS o Amazon Route53.
- Si el tiempo se excede el SSL, intenta revisar qué tipo de SSL tienes (gratuito o de pago) y si está bien configurado en el servidor web.
- Si el tiempo se excede en WAIT, tienes alguna ralentización de proceso en el servidor que puede ser causada por distintas causas.
- Si el tiempo se excede en RECEIVE, el servidor está teniendo problemas al enviar el contenido y puede darse por distintas causas. La más normal es la saturación.
- Si hay un BLOCKED, el problema está en la priorización de contenidos al servirlos al navegador del visitante.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
2 comentarios
Hola pregunta me ayudarias? Obvio que pagaría tus honorarios. Necesito poder encontrar la forma de minimizar el tiempo de carga de una página ( donde Dan turnos) y es muy complejo porque todos los usuarios entran a una hora predeterminada. Si podes ayudarme aguardo tus comentarios (es https)
Hola Gabriela, contáctame a través del contacto, dándome el mayor número de detalles posible y te pondré en contacto con mis compañeros para que te presupueste la resolución del problema.
https://alvarofontela.com/contacto/