Hoy queremos profundizar en cómo utilizar y comprender mejor los datos de la popular herramienta de pruebas de velocidad de sitios web Pingdom. Puedes usarla para realizar un análisis en cascada (waterfall) de tu sitio web de WordPress. Esto te puede ayudar a diagnosticar rápidamente los problemas de rendimiento y a no confundirte a la hora de identificar un problema.

A menudo vemos que los usuarios de WordPress malinterpretan los datos de la herramienta de pruebas de velocidad de Pingdom, lo que a veces lleva a configurar un sitio web de una forma aún peor que antes. Recuerda que todas las herramientas de este tipo deben usarse como guía. Nunca son 100 % precisas. Lo importante es ser coherente y usar la misma herramienta en todas tus pruebas.

¿Qué Es la Herramienta de Prueba de Velocidad Pingdom?

Pingdom es una empresa con sede en Suecia (ahora propiedad de SolarWinds) que ofrece varios servicios, como monitorización del tiempo de actividad, monitorización de la velocidad de las páginas, monitorización de transacciones, monitorización de servidores e información sobre visitantes (RUM). Una de las cosas por las que son más conocidos es su herramienta gratuita de prueba de velocidad de sitios web. Es una de las herramientas de comprobación del rendimiento más populares en la comunidad de WordPress.

¿Por qué es tan popular? Bueno, para empezar, ¡probablemente sea la herramienta de medición de velocidad más fácil de usar! No todo el mundo es un experto en rendimiento web, así que otras herramientas alternativas que hay por ahí pueden resultar bastante complicadas para el usuario típico de WordPress. A veces, como se suele decir, menos es más. Al fin y al cabo, lo único que te importa es lo rápido que es tu sitio web y cómo puedes hacerlo más rápido.

Prueba de velocidad del sitio web de Pingdom
Prueba de velocidad del sitio web de Pingdom

Actualmente, Pingdom te permite probar la velocidad de cualquier sitio web desde 7 ubicaciones diferentes (5 continentes) situadas estratégicamente por todo el mundo:

  • Asia – Japón – Tokio
  • Europa – Alemania – Frankfurt
  • Europa – Reino Unido – Londres
  • América del Norte – EE.UU. – Washington D.C.
  • América del Norte – EE.UU. – San Francisco
  • Pacífico – Australia – Sydney
  • América del Sur – Brasil – São Paulo

Nota: Hemos observado que, en ocasiones, no todos los puntos de prueba están disponibles. Lo más probable es que se deba a que el sistema está fuera de servicio por mantenimiento o a que se ha saturado debido a que hay demasiada gente intentando realizar pruebas. Si un punto de prueba que solías usar ya no aparece, vuelve a intentarlo dentro de una o dos horas. Lo más probable es que vuelva a aparecer.

La ubicación de prueba que elijas es fundamental para la ubicación física de donde está alojado tu sitio web. Aquí es donde entra en juego una cosa llamada latencia de red. Pero entraremos en esto con más detalle a continuación.

Análisis en Cascada con la Herramienta de Prueba de Velocidad Pingdom

Una página web se compone de diferentes activos, como HTML, JavaScript, CSS, imágenes y vídeos. Cada uno de ellos genera peticiones para renderizar lo que ves en tu sitio web. Normalmente, cuantas más peticiones tengas, más lento se cargará tu sitio web. No siempre es así, pero sí la mayoría de las veces.

A continuación, analizaremos cada sección de Pingdom y te explicaremos con más detalle qué significa la información en lo que respecta al rendimiento general de tu sitio web y cómo realizar un análisis en cascada.

Resumen de Pingdom

Cuando analizas tu sitio web de WordPress con Pingdom, este genera una puntuación de rendimiento, el tiempo total de carga, el tamaño total de la página y el número de solicitudes que hay en tu sitio web. En nuestro ejemplo, se trata de un sitio de comercio electrónico que utiliza Easy Digital Downloads. Está alojado en los servidores ultrarrápidos de Kinsta.

Como puedes ver, hemos hecho nuestra primera prueba y hemos sacado una puntuación de 88/100 en Pingdom, con un tiempo de carga total de 541 ms. Esto nos permite saber el tamaño total de nuestros recursos combinados y el número de solicitudes.

Prueba de velocidad de Pingdom antes de DNS y caché
Prueba de velocidad de Pingdom antes de DNS y caché

A continuación, realizamos una prueba adicional, ¡y ahora nuestro tiempo de carga total es de 392 ms con el mismo tamaño de página y número de peticiones! ¿A qué se debe todo esto? 🤔 Te darás cuenta si pasas tu sitio web varias veces por la herramienta de prueba de velocidad Pingdom. Los sitios más grandes notarán diferencias aún mayores.

Hay tres razones principales por las que ocurre esto: la caché del DNS, la caché de la CDN y la caché de WordPress. Por eso siempre debes hacer varias pruebas. Por supuesto, las llamadas externas a recursos de terceros y a la API también podrían influir en esto. Descubre por qué más abajo, en nuestro análisis en cascada.

Prueba de velocidad Pingdom tras DNS
Prueba de velocidad Pingdom tras DNS

¿Quieres mejorar tu puntuación en Pingdom para tu sitio web de WordPress? Dependiendo de tu sitio y de tu configuración, puede que no siempre sea posible conseguir una puntuación perfecta de 100/100, sobre todo si gestionas sitios de comercio electrónico o utilizas píxeles de marketing. Pero dedicar un poco de tiempo a mejorar tu puntuación es un excelente punto de partida. Lo que realmente importa es la velocidad general.

A veces, la experiencia del usuario puede incluso prevalecer sobre algunos trucos de rendimiento web que te encuentras por ahí. ¡No te olvides de la experiencia del usuario! Pero no te preocupes, más adelante te daremos algunos consejos y trucos sobre cómo conseguimos que el sitio anterior llegara a donde está, así que sigue leyendo.

WinningWP realizó de forma independiente unas pruebas de velocidad comparando Kinsta con otros proveedores de alojamiento líderes y descubrió que Kinsta era «mucho más rápido», con un tiempo medio de solo 394 ms.

Mejorar el Rendimiento de la Página

La sección de información sobre el rendimiento, ahora llamada «Mejorar el rendimiento de la página», se actualizó en 2018, y han eliminado algunos elementos antiguos y añadido otros nuevos. Probablemente esto se deba a que algunas de las sugerencias que ofrecían ya no son tan relevantes como antes. En lo que respecta a la optimización del rendimiento web, las cosas cambian constantemente. Y si la gente se limita a perseguir la puntuación perfecta en Pingdom, puede resultar problemático.

Información sobre el rendimiento de Pingdom
Información sobre el rendimiento de Pingdom

Sin embargo, dejamos toda esta sección en nuestro post (algunas partes antiguas y otras nuevas) porque es fundamental entender cómo se calculan estas puntuaciones. Básicamente, todas se basan en las reglas de Google PageSpeed Insights. En general, si mejoras estos aspectos en tu sitio, deberías reducir los tiempos de carga generales.

Estas son algunas de las categorías de la sección Mejorar el rendimiento de la página:

Ahora vamos a profundizar en algunas de ellas y ver cuáles siguen siendo relevantes hoy en día.

Utiliza una Red de Entrega de Contenidos (CDN)

Uno de los servicios más importantes que debes implementar hoy mismo en tu sitio de WordPress es una Red de Distribución de Contenidos (CDN). Se trata de una red de servidores (también conocidos como POP) repartidos por todo el mundo. Están diseñados para alojar y distribuir copias del contenido estático (y a veces dinámico) de tu sitio de WordPress, como imágenes, CSS, JavaScript y transmisiones de vídeo.

Si eres cliente de Kinsta, incluimos una CDN en nuestros planes de alojamiento. Activarla es cuestión de unos pocos clics. Entre las ventajas de una CDN se incluyen una mejora del rendimiento (menor TTFB y latencia de red), menores costes de ancho de banda y alojamiento, e incluso ventajas de SEO.

Importante: La herramienta Pingdom, recién actualizada, tiene actualmente un error que impide detectar correctamente cualquier proveedor de CDN.

Usa una Red de Distribución de Contenidos (CDN)
Usa una Red de Distribución de Contenidos (CDN)

Algunos proveedores de CDN de terceros que recomendamos son:

En nuestras propias pruebas de velocidad de CDN, hemos descubierto que una CDN puede reducir los tiempos de carga de las páginas en más de un 50% en algunos casos

Evita el error HTTP 404 (No encontrado)

Esta sección se llamaba antes «evitar peticiones erróneas» ¡Y eso siempre es relevante! Esta advertencia es justo lo que parece: una solicitud que no se ha podido completar con éxito. Esto suele ocurrir cuando enlazas manualmente a un recurso o una imagen que ya se ha eliminado, lo que da lugar a un error 404. En Pingdom aparece como un círculo naranja, junto con un 404 en el estado de la cabecera de respuesta.

Evitar peticiones erróneas - error 404
Evitar peticiones erróneas – error 404

Asegúrate siempre de que todas las peticiones de tu sitio vuelven con un estado de éxito. Esto asegurará que no se generen consultas a activos que ya no existen.

Minimiza las Redirecciones

Demasiadas redirecciones siempre son algo a lo que debes prestar atención. Las redirecciones sencillas, como una sola redirección 301, de HTTP a HTTPS o de www a no-www (y viceversa), son aceptables. Y muchas veces, son necesarias en algunas secciones de tu sitio web. Sin embargo, cada una de ellas afecta al rendimiento de tu sitio. Y si empiezas a encadenar redireccionamientos unos encima de otros, es fundamental que te des cuenta de cómo afectan al rendimiento de tu sitio. Esto se aplica a los redireccionamientos de páginas y entradas, a los de imágenes, a todo.

Una redirección aparece como un círculo azul en Pingdom, junto con un 301 o 302 en el estado de la cabecera de respuesta.Minimizar redireccionamientos - 301

¿Cuánto afectan las redirecciones a tu sitio? Hagamos una pequeña prueba. En primer lugar, realizamos una prueba de velocidad en nuestra página de contacto. Obtenemos un tiempo de carga total de 417 ms, como puedes ver a continuación.

Prueba de velocidad del sitio web sin redireccionamientos
Prueba de velocidad del sitio web sin redireccionamientos

A continuación, modificamos ligeramente la URL y hacemos otra prueba de velocidad para ver el impacto de las redirecciones múltiples. Como puedes ver, ahora la misma página tarda 695 ms en cargarse. Eso supone un aumento del 66 %. ¡Vaya!

Prueba de velocidad del sitio web con múltiples redireccionamientos
Prueba de velocidad del sitio web con múltiples redireccionamientos

Echa un vistazo a nuestro artículo detallado sobre las redirecciones en WordPress y las mejores prácticas para mejorar el rendimiento.

Añadir Cabeceras Expires

Esta sugerencia se denominaba anteriormente aprovechar la caché del navegador. En pocas palabras, cada script de tu sitio de WordPress debe tener asociado una cabecera de caché HTTP (o debería tenerlo). Esto determina cuándo caduca la caché del archivo. Para solucionarlo, asegúrate de que tu proveedor de alojamiento para WordPress tenga configurados correctamente las cabeceras cache-control y expires. Kinsta tiene estas cabeceras configuradas en todos nuestros servidores.

Echa un vistazo a los pasos para añadir cabeceras de caché a tu servidor manualmente y lee nuestra guía sobre cómo añadir cabeceras expires.

Aprovecha la caché del navegador - cabeceras de caché
Aprovecha la caché del navegador – cabeceras de caché

El otro problema es que no puedes añadir las cabeceras de caché cuando cargas scripts de terceros, ya que no tienes control sobre sus servidores web. Entre los culpables habituales se encuentran el script de Google Analytics y los píxeles de marketing, como los de Facebook y Twitter. Para solucionarlo, puedes alojar tu script de Google Analytics localmente (aunque esto no está oficialmente soportado) con un plugin de terceros. WP Rocket ahora también tiene una opción para alojar tu píxel de marketing de Facebook localmente.

Trasladar los scripts a tu servidor local puede tener un impacto variable en el rendimiento de tu sitio. La ventaja es que tienes control total sobre el archivo y puedes servirlo desde tu CDN. Además, así se elimina otra solicitud de DNS a un tercero. Sin embargo, también es importante recordar que es posible que estos archivos ya estén almacenados en la caché de los navegadores de los usuarios.

Echa un vistazo a nuestro artículo detallado sobre cómo solucionar la advertencia Leverage de la caché del navegador.

Eliminar Cadenas de Consulta de Recursos Estáticos

Otro problema común es lidiar con las cadenas de consulta. Tus archivos CSS y JavaScript suelen tener la versión del archivo al final de sus URLs, como https://domain.com/file.min.css?ver=4.5.3. Algunos servidores y servidores proxy no pueden almacenar en caché las cadenas de consulta. Así que, eliminándolas, a veces puedes mejorar el almacenamiento en caché.

También puedes añadir manualmente el siguiente código al archivo functions.php de tu tema. Una alternativa mejor sería utilizar un plugin gratuito como Code Snippets para añadir el código. De esta forma, no tendrás que editar tu tema directamente.

function eliminar_cadenas_de_consulta() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver||?ver)/", $src);
   devuelve $salida[0];
}
add_action('init', 'eliminar_cadenas_de_consulta');

Sin embargo, antes de eliminar inmediatamente las cadenas de consulta en tu sitio, es importante saber por qué se utilizan. Los desarrolladores de WordPress suelen utilizar el control de versiones en los archivos para evitar problemas de almacenamiento en caché.

Por ejemplo, si lanzan una actualización y cambian style.css de ?ver=4.6 a ?ver=4.7, se tratará como una URL completamente nueva y no se almacenará en caché. Si eliminas las cadenas de consulta y actualizas un plugin, la versión en caché podría seguir sirviendo. En algunos casos, esto podría romper la apariencia de tu sitio hasta que el recurso en caché caduque o la caché se vacíe por completo.

Además, algunas CDNs pueden almacenar en caché cadenas de consulta. La CDN de Kinsta puede hacerlo y, de hecho, lo hace de forma predeterminada. Así que, si eres cliente de Kinsta, las cadenas de consulta ya están almacenadas en caché en tus recursos.

Aviso de eliminación de cadenas de consulta de recursos estáticos
Aviso de eliminación de cadenas de consulta de recursos estáticos

Echa un vistazo a nuestro tutorial detallado sobre cómo eliminar cadenas de consulta de los recursos estáticos.

Tenemos un artículo detallado sobre cómo solucionar la advertencia serve static content from a cookieless domain (lidiar con advertencia sobre contenido de servidor estático de un dominio sin cookies). A menudo, puedes ignorar esta advertencia, ya que los nuevos protocolos, como HTTP/2, hacen que esto sea menos relevante. Establecer una nueva conexión suele ser más costoso que transmitir todo a través de la misma conexión. Sin embargo, hay dos formas de resolverlo: utilizar un proveedor de CDN que elimine las cookies o crear un dominio o subdominio independiente.

Advertencia sobre la publicación de contenido estático desde un dominio sin cookies
Advertencia sobre la publicación de contenido estático desde un dominio sin cookies

Para más información, consulta nuestro post sobre cómo utilizar dominios sin cookies.

Comprimir Componentes con GZIP

La advertencia «Comprimir componentes con GZIP» se produce cuando Pingdom detecta un activo que no ha sido comprimido con GZIP. GZIP es un método de compresión utilizado para reducir el tamaño de archivos basados en texto, como documentos HTML y archivos CSS/JS. La compresión GZIP se activa en el servidor y comprime las páginas web y los activos antes de enviarlos a los visitantes. En nuestras pruebas, vimos que activar la compresión GZIP reducía el tamaño del archivo de una solicitud en más de un 78%.

Comprimir componentes con GZIP
Comprimir componentes con GZIP

En Kinsta, no tendrás que preocuparte por activar GZIP, ya que todos los sitios de Kinsta ya se benefician de la compresión Brotli, una alternativa más rápida a la compresión GZIP. Todo ello gracias a nuestra exclusiva integración con Cloudflare. Esto significa que tu sitio alojado en Kinsta es más rápido que el de la competencia que utiliza GZIP y se carga rápidamente para quienes utilizan dispositivos más pequeños.

Si sigues viendo el mensaje «Comprimir componentes con GZIP» después de activar GZIP en tu servidor, es posible que el servidor que aloja un recurso externo que necesita tu sitio no tenga activada la compresión GZIP o Brotli. Si ese es el caso, no hay nada que puedas hacer por tu parte para cambiar el comportamiento del servidor.

Paralelizar las Descargas entre Diferentes Nombres de Host

La advertencia «Parallelize Downloads Across Hostnames» (paralelizar las descargas entre diferentes nombres de host) se debe a una limitación del protocolo HTTP/1.1 y a que los navegadores web tienen un límite en el número de conexiones simultáneas que pueden establecer con un servidor; normalmente, son seis conexiones. Esta advertencia suele aparecer en sitios web con un gran volumen de solicitudes. Antes, la única forma de sortear esta limitación era implementar lo que se conoce como domain sharding.

Sin embargo, imagina que utilizas un proveedor de alojamiento web o un proveedor de CDN que soporta HTTP/2. En ese caso, puedes ignorar esto sin problema, ya que ahora se pueden cargar varios recursos en paralelo a través de una sola conexión. Pero también puedes echar un vistazo a nuestro tutorial sobre cómo solucionar la advertencia de descargas en paralelo entre nombres de host mediante la implementación de la fragmentación de dominios.

Advertencia sobre la paralización de descargas entre nombres de host
Advertencia sobre la paralelización de descargas entre nombres de host

Especificar un Validador de Caché

Esta advertencia se refiere a las cabeceras de caché HTTP que faltan y que deberían incluirse en cada respuesta del servidor de origen, ya que validan y establecen la longitud de la caché. Si no se encuentran las cabeceras, se generará una nueva petición del recurso cada vez, aumentando la carga de tu servidor. Estas cabeceras incluyen last-modified, ETag, Cache-Control y Expires. Al igual que con la advertencia sobre el uso del almacenamiento en caché del navegador, tu proveedor de alojamiento para WordPress debería añadir estas cabeceras automáticamente. Si ves esto en solicitudes de terceros, no hay nada que puedas hacer, ya que no tienes control sobre sus servidores web.

Especificar una advertencia del validador de caché
Especificar una advertencia del validador de caché

Lee nuestra entrada detallada sobre cómo solucionar la advertencia especificar un valor de caché.

Especificar una cabecera Vary: Accept-Encoding

Tenemos un post en profundidad sobre cómo solucionar el aviso Especificar un Vary: Accept-Encoding. Se trata de una cabecera HTTP que debe incluirse en cada respuesta del servidor de origen, ya que indica al navegador si el cliente puede o no manejar versiones comprimidas del contenido. Se añade automáticamente a todos los servidores de Kinsta.

Especificar una advertencia de cabecera vary: accept-encoding
Especificar una advertencia de cabecera vary: accept-encoding

Códigos de Respuesta de Pingdom

La siguiente sección de la herramienta de prueba de velocidad de Pingdom son los códigos de respuesta. Los códigos de respuesta, también denominados códigos de estado HTTP, son como una breve nota del servidor web que se coloca en la parte superior de una página web. Es un mensaje del servidor web que te informa de cómo fueron las cosas cuando se recibió la solicitud para ver la página. Algunos de los más comunes son:

  • 200: «Todo va bien» Es el código que se entrega cuando una página o recurso web actúa exactamente como se espera que lo haga.

    Ejemplo de código de respuesta 200 de Pingdom
    Ejemplo de código de respuesta 200 de Pingdom

  • 301: «El recurso solicitado se ha movido permanentemente» Este código se entrega cuando una página web o un recurso ha sido sustituido permanentemente por otro recurso diferente. Se utiliza para la redirección permanente de URL.

    Ejemplo de código de respuesta 301 de Pingdom
    Ejemplo de código de respuesta 301 de Pingdom

  • 404: «No se ha encontrado el recurso solicitado» El mensaje de error más común de todos. Este código significa que el recurso solicitado no existe, y el servidor no sabe si existe.

    Ejemplo de código de respuesta 404 de Pingdom
    Ejemplo de código de respuesta 404 de Pingdom

Puedes leer más sobre los diferentes códigos de respuesta en nuestro post en profundidad sobre los códigos de estado HTTP.

Tamaño del Contenido y Peticiones por Tipo de Contenido

Las siguientes secciones son el tamaño del contenido por tipo de contenido y las peticiones por tipo de contenido. Cada una de ellas es útil para ver rápidamente qué es lo que ocupa más recursos en tu página web. Según HTTP Archive, las imágenes suelen representar el 43% del tamaño total medio de una página web. Nosotros también lo vemos así habitualmente. Sin embargo, como puedes ver a continuación en este sitio, no siempre es así.

Tipo de contenido Pingdom
Tipo de contenido Pingdom

Para optimizar tus imágenes, te recomendamos encarecidamente que leas nuestro post en profundidad sobre cómo optimizar imágenes para la web y sobre WebP. Hay muchas herramientas y plugins estupendos para comprimir aún más tus imágenes y asegurarte de que no son la mayor parte de la carga de la página de tu sitio web. En el ejemplo anterior, el sitio está aprovechando el uso de iconos grandes de Font Awesome en lugar de imágenes. Esta puede ser una estrategia genial que marque una gran diferencia. Y, por supuesto, en nuestra guía sobre la velocidad de la página te damos algunos consejos adicionales sobre cómo reducir aún más el tamaño de tu contenido.

Tamaño del Contenido y Solicitudes por Dominio

El tamaño del contenido y las solicitudes por dominio son una forma excelente de ver rápidamente qué servicios externos y scripts hay en tu sitio web. En nuestro ejemplo, puedes ver que todos nuestros recursos se cargan desde nuestra CDN. Después está la carga inicial del documento HTML del sitio web desde el servidor web, y una llamada externa al dominio de Google Analytics. Dependiendo de tu sitio, es posible que tengas más servicios externos, como Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.

Peticiones de Pingdom por dominio
Peticiones de Pingdom por dominio

En general, cuantas menos solicitudes externas realices, mejor, ya que cada servicio externo introduce latencia, retrasos en el protocolo de enlace TLS, búsquedas de DNS, etc. No te pierdas nuestro artículo detallado sobre cómo identificar y analizar los servicios externos de tu sitio de WordPress.

Por lo general, lo mejor es reducir el número de solicitudes al mínimo y alojar los recursos en un solo lugar, por ejemplo, subiéndolos a tu servidor web o a una CDN. Un ejemplo sería Font Awesome. En lugar de enlazar al script externo de Font Awesome, descárgalo y sírvelo directamente.

Gráfico de cascada de Pingdom

Y por último, pero no por ello menos importante, tenemos la sección de solicitudes de la herramienta de prueba de velocidad Pingdom, que genera un gráfico en cascada de todas las solicitudes individuales de tu página web (como se muestra a continuación). A continuación, puedes analizar cada solicitud para ver qué está causando retrasos y problemas de rendimiento en tu sitio. Nos referimos a esto cuando decimos que hacemos un análisis en cascada. A continuación encontrarás un resumen más detallado y/o una definición de lo que significa cada color de estado.

Análisis en cascada de Pingdom
Análisis en cascada de Pingdom

DNS (Rosa)

¿Qué es el DNS? Bueno, piensa en ello como en una guía telefónica. Hay unos servidores llamados Servidores de Nombres de Dominio que contienen la información sobre tu sitio web y a qué IP debe dirigirse. Cuando ejecutas por primera vez tu sitio web a través de Pingdom, éste realiza una nueva búsqueda y tiene que consultar los registros DNS para obtener la información de la IP. Esto supone un tiempo de búsqueda adicional. La ubicación del servidor DNS también es importante.

Retrasos de DNS en Pingdom
Retrasos de DNS en Pingdom

Cuando pasas tu sitio web por Pingdom más de una vez, almacena en caché los DNS porque ya conoce la información de la IP y no tiene que volver a realizar la búsqueda. Por eso tu sitio web aparece más rápido después de pasarlo varias veces por Pingdom.

Como puedes ver en la pantalla de abajo, en la 2ª prueba que realizamos, el tiempo de búsqueda de DNS en la carga inicial del DOC fue de 3,6 ms. Lo normal es que baje a 0 ms, como debería, ya que la solicitud ya se ha almacenado en caché. Éste es un aspecto que mucha gente interpreta mal

DNS en caché en Pingdom
DNS en caché en Pingdom

Puedes optimizarlo aún más si utilizas un servicio DNS premium, que además viene con un montón de ventajas adicionales. ¡Nuestro DNS gratuito de Cloudflare también es rápido! Echa un vistazo a la Optimización automática de la plataforma de Cloudflare.

Hay otras razones por las que tu sitio web puede parecer más rápido después de varias pruebas. Una de ellas es si estás utilizando una red de distribución de contenidos (CDN). Para quienes no estén familiarizados con una CDN, se trata de una red de servidores globales que almacenan en caché tu contenido (JS, CSS, Imágenes, etc.) en ubicaciones más cercanas al visitante. Cuando ejecutes por primera vez tu sitio web a través de Pingdom, es posible que tengas que tomar los activos de la CDN frescos. La caché de una CDN funciona de forma muy parecida al DNS. Una vez en caché, es mucho más rápido en cargas consecutivas.

Otro consejo para acelerar el DNS es utilizar el prefetching DNS. Esto permite al navegador realizar búsquedas DNS en una página en segundo plano. Puedes hacerlo añadiendo algunas líneas de código a la cabecera de tu sitio WordPress. Mira algunos ejemplos a continuación.

 <!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

O, si utilizas la versión 4.6 o posterior de WordPress, puedes utilizar resource hints (sugerencias de recursos). Los desarrolladores pueden utilizar el filtro wp_resource_hints para añadir dominios y URL personalizados para dns-prefetch, preconnect, prefetch o prerender.

SSL (Morado)

El color morado del estado indica el tiempo que tarda tu navegador en realizar un intercambio de datos SSL/TLS. Cada vez que accedes a un sitio web a través de HTTPS, hay un certificado SSL y se necesita un tiempo adicional debido al proceso de cifrado (intercambio de datos SSL/TLS). En nuestro dominio de ejemplo, tenemos un certificado tanto en nuestro servidor web de Kinsta como en nuestra CDN, KeyCDN. Por lo tanto, hay un tiempo de negociación SSL tanto en la carga inicial del documento HTML desde el servidor web como en nuestros recursos.

Tiempo de carga SSL en Pingdom
Tiempo de carga SSL en Pingdom

Aunque ejecutar HTTPS conlleva una ligera sobrecarga, ahora no es crucial gracias a HTTP/2, ¡un nuevo protocolo que ayuda a acelerar la web! Debido a la compatibilidad de los navegadores, se requiere HTTPS para utilizar HTTP/2. Consulta nuestra guía definitiva sobre HTTP/2.

También es importante tener en cuenta que, incluso en 2018, no todos los proveedores son compatibles con HTTP/2. Esto incluye tanto a los proveedores de alojamiento web como a los de CDN. Así que, cuando busques alojamiento y CDN, ¡asegúrate de que ambos lo soporten! Kinsta se enorgullece de ofrecer compatibilidad con HTTP/2 a todos sus clientes de WordPress.

A mediados de 2018, Pingdom por fin actualizó su herramienta para usar Chrome 60 y versiones posteriores. Puedes ver el user-agent que se utiliza en la cabecera de la solicitud. Antes usaban Chrome 39, y Chrome no era soportado por HTTP/2 hasta la versión 49. ¡Así que nos alegra poder decir que la herramienta de Pingdom ahora muestra todas las ventajas de HTTP/2 al realizar pruebas! 👏

Compatibilidad con HTTP/2 en Pingdom
Compatibilidad con HTTP/2 en Pingdom

Conectar (Verde Azulado)

El tiempo de conexión en Pingdom se refiere a la conexión TCP, o al tiempo total necesario para crear una conexión TCP. No es necesario que entiendas cómo funciona, pero se trata simplemente de un método de comunicación entre el host/cliente y el servidor que tiene que tener lugar.

Tiempo de conexión de Pingdom
Tiempo de conexión de Pingdom

Espera (Amarillo)

El tiempo de espera de Pingdom se refiere al tiempo hasta el primer byte, también conocido como TTFB en algunas herramientas. El TTFB es una medida utilizada para indicar la capacidad de respuesta de un servidor web u otro recurso de red. En general, todo lo que esté por debajo de 100 ms es aceptable y un buen TTFB. Si te acercas al rango de 300-400 ms, puede que tengas algo mal configurado en tu servidor, o puede que haya llegado el momento de mejorar tu pila tecnológica.

Tiempo de espera - TTFB
Tiempo de espera – TTFB

¿Cuál es la forma más fácil de reducir tu TTFB? Las dos mejores opciones son un buen sistema de caché de WordPress y una CDN. Así que vamos a hacer un par de pruebas.

TTFB sin caché de host de WordPress

Primero realizamos una prueba después de borrar la caché de nuestro sitio de WordPress. Esto significa que tiene que volver a precargar la caché. Nuestro tiempo de carga total fue de 541 ms, y el TTFB (tiempo de espera) en nuestra petición inicial fue de 185,2 ms.

Pingdom TTFB sin la caché de WordPress
Pingdom TTFB sin la caché de WordPress

TTFB con caché de host de WordPress

A continuación, volvimos a realizar la prueba. Ahora se sirve directamente desde la caché. Como puedes ver, nuestros tiempos de carga totales han bajado a 392 ms, ¡y el TTFB de la petición inicial es ahora de 52,8 ms! Esa es la diferencia que marca la caché.

Pingdom TTFB con la caché de WordPress
Pingdom TTFB con la caché de WordPress

Si tienes un sitio web dirigido a visitantes de diferentes partes del país o de todo el mundo, otra forma sencilla de reducir drásticamente tu TTFB es utilizar una CDN. Hemos vuelto a hacer unas cuantas pruebas para mostrar la diferencia.

TTFB sin CDN

Primero hicimos una prueba con nuestra CDN desactivada, y como puedes ver, nuestro tiempo de carga total fue de 1,93 s, y nuestro TTFB medio en un activo fue de unos 176 ms.

TTFB sin CDN
TTFB sin CDN

TTFB con CDN

A continuación, activamos nuestra CDN y volvimos a realizar la prueba. Nuestros tiempos de carga totales bajaron a 1,21 s, y nuestro TTFB medio en un activo CDN es ahora de ¡4,6 ms! Qué diferencia puede marcar una CDN.

TTFB con CDN
TTFB con CDN

Otra cosa esencial a tener en cuenta es que elegimos la ubicación «Pacífico – Australia – Sydney» para realizar esta prueba. ¿Por qué? Porque queríamos mostrarte la mejora real que se puede obtener. Nuestro sitio de WordPress en este ejemplo está alojado por Kinsta en una ubicación central en EEUU. Al realizar la prueba con Australia podemos mostrar cómo el almacenamiento en caché CDN de Kinsta aumenta la velocidad y reduce el TTFB.

Y, por supuesto, tener un buen alojamiento para WordPress con una arquitectura cuidadosamente pensada también es crucial para reducir tu TTFB.

Enviar (Naranja) y Recibir (Verde)

Los estados de envío y recepción en Pingdom no necesitan mucha explicación. El tiempo de envío es simplemente el tiempo que tarda el navegador en enviar datos al servidor. Y el tiempo de recepción es el tiempo que tarda el navegador web en recibir datos del servidor. Ambos suelen ser muy bajos o inexistentes en tus pruebas.

Cabeceras de Respuesta HTTP

También puedes hacer clic en una solicitud concreta mientras realizas el análisis en cascada y ver las cabeceras de respuesta HTTP. Esto te proporciona información muy útil. En la pantalla que aparece a continuación, podemos ver al instante datos como que gzip está habilitado en el servidor web y que se está sirviendo desde la caché (HIT; de lo contrario, aparecería MISS), las cabeceras de control de caché, las cabeceras de caducidad, el agente de usuario del navegador y mucho más.

Cabeceras de respuesta HTTP
Cabeceras de respuesta HTTP

Caso de Estudio de Configuración del Dominio

Si has llegado hasta aquí en nuestro post sobre el análisis en cascada, estás de enhorabuena. Siempre es molesto ver a la gente compartir consejos y casos prácticos pero no compartir cómo han llegado hasta ahí. Así que a continuación te mostramos nuestra configuración exacta para el dominio del caso de estudio utilizado anteriormente Siéntete libre de reproducirla.

Arquitectura

Actualizar la versión PHP del sitio WordPress
Actualizar la versión PHP del sitio WordPress

Plugins y Temas de WordPress

Aquí tienes una lista de los plugins que influyen en el rendimiento del sitio de comercio electrónico de WordPress.

Tutoriales recomendados para leer más:

Resumen

Como puedes ver, conocer un poco mejor cómo funciona la herramienta de prueba de velocidad Pingdom y qué significan todos los gráficos puede ayudarte a tomar una decisión más basada en datos cuando se trata de rendimiento.

Un análisis en cascada es crucial para saber cómo se cargan tus activos y cómo les afecta tu host de WordPress, tu ubicación física, una CDN, etc. Esperamos que este post te haya ayudado a solucionar mejor los problemas de velocidad y rendimiento de tu sitio.

¿Tienes algún otro consejo sobre Pingdom? ¡Háznoslo saber en los comentarios!

Brian Jackson

Brian tiene una gran pasión por WordPress, lo ha estado utilizando durante más de 10 años e incluso ha desarrollado un par de plugins premium. Brian disfruta de los blogs, las películas y el senderismo. Conéctese con Brian en Twitter.