El día de hoy queremos adentrarnos a cómo utilizar y entender mejor los datos de esta popular herramienta de prueba de velocidad de sitios, llamada Pingdom. Usted puede usarla para hacer a lo que nosotros llamamos, análisis de cascada de su sitio web de WordPress. Este puede ayudarle a rápidamente diagnosticar problemas de desempeño, y también a no dar un mal diagnostico al problema.

Muchas veces vemos a los usuarios de WordPress interpretando los datos incorrectamente en Pingdom, y esto lleva a que en algunas ocasiones se configure el sitio a un estado aún peor que antes. Recuerde que todas las herramientas como esta se usan mejor como guías, nunca son 100% precisas. Lo más importante es ser consistente y utilizar la misma herramienta en todas sus pruebas.

Pingdom

Pingdom es una compañía Sueca (ahora parte de SolarWinds) que ofrece una variedad de distintos servicios, como el monitoreo de tiempo de actividad, monitoreo de velocidad de página, monitoreo de transacción, monitoreo de servidor, y visiones del visitante (RUM). Probablemente una de las cosas por la que es reconocida es por su sitio web gratuita de prueba de velocidad. Es una de las herramientas de prueba de desempeño más populares en la comunidad de WordPress.

¿Por qué es tan popular? Bueno, principalmente, ¡porque probablemente es la herramienta de prueba de velocidad más sencilla de usar! No todos son un experto en desempeño web, así que para el usuario típico de WordPress, algunas de las otras alternativas pueden ser un poco abrumadoras. Algunas veces menos, es más, como dice la gente. Después de todo, a usted le deben importar solo dos cosas: que tan rápido es su sitio web y cómo hacerlo más rápido.

Pingdrom preuba de velocidad
Pingdrom preuba de velocidad

Pingdom actualmente le permite hacer pruebas de velocidad de cualquier sitio en 7 ubicaciones distintas (5 continentes) estratégicamente colocadas alrededor del mundo:

  • Asia- Japón – Tokio
  • Europa – Alemania – Frankfurt
  • Europa – Reino Unido – Londres
  • Norte América – Estados Unidos – Washington D.C
  • Norte América – Estados Unidos – San Francisco
  • Pacifico – Australia – Sídney
  • América del Sur – Brasil – São Paulo

Nota: Hemos notado que ocasionalmente no todas las ubicaciones de prueba estarán disponibles. Esto es probablemente porque han sido dadas de baja por mantenimiento o fueron sobrecargadas con mucha gente intentando hacer pruebas en esta. Si una ubicación de sitio de prueba que usted ha usado con anterioridad ya no se encuentra ahí, cheque de nuevo en una o dos horas. Probablemente aparezca de nuevo.

La ubicación de prueba que elija es realmente importante, ya que se relaciona a la ubicación física de donde se encuentra albergado su sitio web. Aquí es donde entra en juego la latencia de la red. Pero hablaremos más en detalle de esto abajo.

Análisis de Cascada con Pingdrom

Una página web está hecha con varios activos, como HTML, JavaScript, CSS, imágenes y videos. Cada una de estas genera peticiones para hacer visualizar a lo que usted ve en su sitio web. Típicamente entre más peticiones tenga, más lento el sitio cargará. Este no siempre es el caso, pero la mayoría del tiempo lo es.

Abajo hablaremos de casa sección de Pingdom y explicaremos en detalle qué significa cada información, según lo que hace en el desempeño general del sitio web y cómo hacer el análisis de cascada.

Resumen de Pingdom

Cuando uno pone a prueba su sitio de WordPress con Pingdom este genera una calificación de desempeño, un tiempo de carga total, el tamaño total de la página y un número de peticiones que usted tiene en su sitio web. En nuestro ejemplo, estamos utilizando perfmatters.io, un sitio de ecommerce que utiliza Easy Digital Downloads. Hospedado en los súper rápidos servidores de Kinsta.

Como puede ver, hicimos nuestra primera prueba y obtuvimos una calificación de 88/100 en Pingdom y un tiempo de carga total de 541 ms. Esto nos permite saber el tamaño total de nuestros activos combinados y número de peticiones.

Las pruebas de velocidad de Pingdom antes del DNS y la cache
Las pruebas de velocidad de Pingdom antes del DNS y la cache

¡Luego hicimos una prueba adicional y nuestro tiempo de carga total es de 392 ms con el mismo tamaño de página y número de peticiones! ¿Por qué sucede esto? 🤔 Podría notar esto si prueba su sitio a través del Pingdom varias veces. Los sitios más grandes tendrán incluso diferencias mayores.

Hay tres razones principales por las que esto sucede: DNS caching, CDN caching, y WordPress caching. Esta es la razón por la que uno debería hacer varias pruebas. Por supuesto, las llamadas externas a recursos externos y API podrían tener un impacto en esto. Descubra el por qué en nuestro análisis de cascada.

La prueba de velocidad en Pingom después de DNS
La prueba de velocidad en Pingom después de DNS

¿Quiere obtener una puntuación mejor de Pingdom en sus sitios web? Dependiendo de su sitio y configuración no siempre será posible conseguir una calificación perfecta de 100/100, especialmente para aquellos que tengan sitios de ecommerce y marketing pixels. Pero simplemente pasar un tiempo tratando de mejorar su calificación es una buena forma de comenzar. La velocidad total es lo que importa.

En algunas ocasiones la experiencia de usuario podría superar algunos de los trucos de desempeño de la red que podrá encontrar en la red. ¡No se puede olvidar de la experiencia de usuario! Pero usted tranquilo, le compartiremos algunos de los consejos y trucos más adelante, y la forma en que logramos que el sitio de arriba llegase a ese punto, así que siga leyendo.

Mejorar el Desempeño de la Página

La sección de comentarios de desempeño, ahora “Mejorar el desempeño de la página” fue actualizada en 2018 y han eliminado algunos artículos viejos y agregaron unos nuevos. Esto probablemente fue por algunas de las sugerencias que reportaban que ya no son relevantes como lo eran antes. Cuando se trata de optimizaciones de desempeño de la red, las cosas siempre están cambiando. Y en algunas ocasiones puede llegar a ser un poco molesto si la gente simplemente está intentando conseguir la calificación perfecta de Pingdom.

Comentarios sobre el desempeño de Pingdom
Comentarios sobre el desempeño de Pingdom

Sin embargo, estamos dejando esta sección entera en nuestra publicación (algunas viejas y nuevas) porque es importante entender cómo se calculan estas calificaciones. Estas están basadas esencialmente en las reglas de Google PageSpeed Insights. Generalmente, si usted mejora estas en su sitio, usted debería ver un descenso en sus tiempos de carga en general.

Aquí hay algunas de las categorías que la sección de “Mejorar desempeño” de la página tiene:

Ahora hablemos de algunas de estas para ver cuáles siguen siendo relevantes.

Usar una Red de Entrega de Contenidos (CDN)

Uno de los servicios más importantes a implementar en su sitio de WordPress hoy en día es el Content Delivery Network (CDN). Estos son una red de servidores (también conocidas como POPs) ubicadas alrededor del mundo. Están diseñadas para hospedar y entregar copias de su sitio con contenido estático de WordPress (y en algunas ocasiones dinámico) como las imágenes, CSS, JavaScript, y streaming de video.

Si usted es cliente de Kinsta, nosotros incluimos una CDN en todos nuestros planes de hosting. Activarla tan sólo requiere unos clics. Algunos beneficios de una CDN incluyen una mejora en el desempeño (mejor TTFB y latencia de red), mejor ancho de banda y costos de hosting, e incluso ventajas de SEO.

Los clientes de Kinsta también pueden disfrutar de un rápido y fácil impulso a la optimización general del sitio minificando tu código utilizando la función de minificación de código que está integrada en el panel de control de MyKinsta. Esto permite a los clientes habilitar la minificación automática de CSS y JavaScript con un solo clic, acelerando efectivamente tus sitios sin ningún esfuerzo manual.

Importante: La recientemente actualizada herramienta de Pingdom actualmente tiene un bug que correctamente detecta cualquier proveedor de CDN de forma precisa.

Utilizando una CDN
Utilizando una CDN

Algunos proveedores de CDN que recomendamos son:

En nuestras propias pruebas de velocidad de CDN, ¡hemos descubierto que una CDN puede reducir los tiempos de carga hasta por un 50% en algunos casos!

Evite el Error HTTP 404 (Not Found)

Esta sección antes se llamaba “Evite malas peticiones.” ¡Y esto siempre es relevante! Esta advertencia es como suena, es una petición que no pudo ser completada con éxito. Esto típicamente sucede cuando uno manualmente enlaza a un activo o imagen que ya ha sido borrada, resultando en un error 404. Esto aparece como un circulo naranja en Pingdom, junto con un 404 en el encabezado del estado de respuesta.

Evite malas peticiones – 404 error
Evite malas peticiones – 404 error

Siempre asegúrese de que cada petición en su sitio regrese con un estado de éxito. Esto asegurará de que no se generen peticiones a activos que ya no existen.

Minimice las Redirecciones

Uno siempre tiene que estar atento cuando haya muchas redirecciones. Una simple redirección como un 301, HTTP a HTTPS o de un www a un sitio sin www (o al revés) están bien. Y en muchas ocasiones estas son necesarias en ciertas áreas de su sitio. Sin embargo, cada una tiene un costo en el desempeño de su sitio. Y si uno empieza a apilar redirecciones, una sobre la otra, es importante darse cuenta de que esto impactará a su sitio. Esto aplica a redirecciones de página y de publicaciones, redirecciones de imagen, todo.

Una redirección aparece como un circulo azul en Pingdom, junto con un 301 o 302 en el encabezado de estado de respuesta.

Minimize redirects - 301

¿Qué tanto afectan a su sitio estas redirecciones? Hagamos una pequeña prueba. Primero, haremos una prueba de velocidad en nuestra página de contacto: https://perfmatters.io/contact/. Como puede ver a continuación obtuvimos un tiempo de carga total de 417 ms.

Prueba de velocidad de un sitio web sin redirecciones
Prueba de velocidad de un sitio web sin redirecciones

Luego, modificamos la URL un poco y hacemos otra prueba de velocidad para ver el impacto de múltiples redirecciones. http://www.perfmatters.io/contact. Como puede ver, la misma página ahora carga en 695 ms. ¡Eso es un incremento de 66%!

Prueba de velocidad de un sitio web con múltiples redirecciones
Prueba de velocidad de un sitio web con múltiples redirecciones

Cheque nuestro articulo sobre las redirecciones de WordPress, y las mejores practicas para tener un desempeño más rápido.

Agregando Encabezados que Expiran

Esta sugerencia antes era llamada “levarage browser caching”. Usando palabras más simples, cada script en su sitio de WordPress debe tener atado un encabezado HTTP e cache (o por lo menos así debería ser). Esto determina cuándo expira la cache en el archivo. Para arreglar esto, su host de WordPress tiene las configuraciones apropiadas de los encabezados de cache-control y encabezados de expires. Kinsta tiene estos encabezados en lugar en todos nuestros servidores. Aprenda los pasos de cómo agregar encabezados de caché en su servidor de forma manual y lee nuestra guía sobre cómo añadir encabezados que expiran.

Leverage browser caching – encabezados de caché
Leverage browser caching – encabezados de caché

El otro problema es que cuando uno carga scripts externos, no tiene acceso a agregar encabezados de cache, ya que no tendrá control de sus servidores web. Los culpables más comunes incluyen el script de Google Analytics y pixels de marketing, como Facebook y Twitter. Para arreglar esto, usted puede hospedar los scripts de Google Analytics localmente (aunque esto no es soportado oficialmente) con un plugin como Perfmatters. WP Rocket también tiene una opción para hospedar el Facebook marketing pixel localmente.

Mover los scripts localmente puede variar en términos de cuánto impacta al desempeño de su sitio. La única ventaja es que usted tendrá control total del archivo y puede servirlo desde su propia CDN. Esto también remueve peticiones de otro DNS externo. Sin embargo, también es importante recordar que estos archivos podrían ya estar albergados en los navegadores de la gente.

Vea nuestro articulo sobre cómo arreglar la advertencia de leverage browser caching.

Remueva los Query Strings de Recursos Estáticos

Otro problema común es tener que lidiar con query strings (cadenas de consulta). Sus archivos de CSS y JavaScript usualmente tienen la versión del archivo al final de su URL, como https://domain.com/file.min.css?ver=4.5.3. Algunos servidores y servidores proxy no pueden cachear query strings. Así que, al eliminarlos, uno puede en algunas ocasiones mejorar la cache.

Puede usar un plugin premium como Perfmatters que tiene una opción fácil de un solo clic para eliminar cadenas de consulta.

O puede agregar manualmente el siguiente código al archivo functions.php de su tema. Una mejor alternativa sería usar un plugin gratuito como Code Snippets para agregar el código. De esta manera no tiene que editar directamente su tema.

function remove_query_strings() {
   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);
   return $output[0];
}
add_action('init', 'remove_query_strings');

Sin embargo, antes de ir inmediatamente a quitar todos los query strings en su sitio, es importante saber por qué los query strings son usados. Las versiones en los archivos típicamente usados por desarrolladores de WordPress para resolver problemas de caching.

Por ejemplo, si lanzan una actualización y cambian style.css de ?ver=4.6 to ?ver=4.7, este será tratado como una URL completamente nueva y no será guardada en la cache. Si usted remueve el query string y actualiza un plugin, esto podría resultar en que la versión en la cache siga sirviendo. En algunos casos, esto podría romper la apariencia de su sitio hasta que el recurso en la cache expiré o la cache sea totalmente borrada.

También, algunas CDN pueden guardar en la cache query strings. La CDN de Kinsta puede y lo hace por defecto. Así que, si usted es cliente de Kinsta, los query strings ya están en la cache con sus activos.

Advertencia sobre remover query strings de recursos estáticos
Advertencia sobre remover query strings de recursos estáticos

Vea nuestro tutorial sobre cómo remover query strings de recursos estáticos.

Tenemos una publicación sobre cómo lidiar con advertencia sobre contenido de servidor estático de un dominio sin cookies. En muchas ocasiones uno puede ignorar esta advertencia ya que nuevos protocolos como el HTTP/2 ahora hacen que esto sea menos importante. El costo de una nueva conexión es usualmente más caro que hacer streaming a todo sobre la misma conexión. Sin embargo, dos formas de resolver esto es utilizando un proveedor de CDN que remueva las cookies o cree un domino separado o un subdominio.

Advertencia de servir contenido estático de un dominio sin cookies
Advertencia de servir contenido estático de un dominio sin cookies

Comprimir los 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 usado para reducir el tamaño de archivos de texto como documentos HTML y archivos CSS/JS. La compresión GZIP está habilitada en el servidor, y comprime las páginas web y los activos antes de enviarlos a un visitante. En nuestras pruebas, vimos que al habilitar la compresión GZIP se redujo 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 de habilitar el GZIP manualmente porque ya está habilitado por defecto en todos nuestros servidores. Si notas que tu host web no ha habilitado el GZIP, te recomendamos que te pongas en contacto con tu equipo de soporte para habilitarlo inmediatamente porque puede tener un gran impacto en la velocidad de tu página. Si todavía ves el «Comprimir componentes con GZIP» después de habilitar GZIP en tu servidor, es posible que un servidor que aloje un activo externo requerido por tu sitio no tenga GZIP habilitado. Si ese es el caso, no hay nada que puedas hacer en tu extremo para cambiar el comportamiento del servidor.

Parallelize Downloads Across Hostnames

La advertencia de “Paralelizar Descargas a Través de Hostnames” sucede por una limitación de HTTP/1.1 y porque los navegadores son limitados con el número de conexiones concurrentes que pueden alojar, siendo típicamente 6 conexiones. Esta advertencia es típicamente vista en sitos webs con un gran número de peticiones. En el pasado, la única forma de evitar esta limitación era implementando algo llamado fragmentación de dominio. Sin embargo, si usted está usando un web host o un proveedor de CDN que tenga soporte para HTTP/2 puede ignorar sin problema alguna esto, ya que múltiples recursos pueden ser ahora cargados paralelamente desde la misma conexión. Pero puede checar el tutorial sobre cómo arreglar las advertencias de descargas paralelizadas a través de hostnames al implementar fragmentación de dominio.

Parallelize downloads across hostnames warning
Parallelize downloads across hostnames warning

Specify a Cache Validator

Esta advertencia refiere a encabezados de caching HTTP ausentes que deberían ser incluidos en cada respuesta de servidor origen, ya que ambos vvalidan y establecen la duración de la cache. Si no se encuentran estos encabezados, este generará una nueva petición para el recurso todo el tiempo, lo cual incrementa la carga en el servidor. Estos encabezados incluyen last-modified, ETag, Cache-Control, y Expires. Igual que con la advertencia de leverage browser caching, estos encabezados automáticamente deberían ser agregados a su host de WordPress. Si tiene peticiones de terceros está viendo, no hay nada que pueda hacer ya que usted no tiene control sobre estos web servers.

Advertencia de Especifique un validador de cache
Advertencia de Especifique un validador de cache

Lea nuestro artículo sobre como arreglar la advertencia de especifique un validador de caché

Specify a Vary: Accept-Encoding Header

Tenemos un articulo sobre cómo arreglar la advertencia de Especifique una Variante: Acepte el Encabezado Decodificador. Este es un encabezado de HTTP y debería estar incluido en cada respuesta de servidor origen, ya que le dice al servidor si el cliente puede lidiar con las versiones compresas del contenido. Esto es agregado automáticamente en todos los servidores de Kinsta.

Advertencia de Especifique una Variante: Acepte el Encabezado Decodificador
Advertencia de Especifique una Variante: Acepte el Encabezado Decodificador

Códigos de Respuesta de Pingdom

La siguiente sección en la herramienta de Pingdom es el código de respuesta. Los códigos de respuesta, referidos como códigos de estado de HTTP son como notas cortas del servidor web que son apiladas en la parte superior de la página web. Es un mensaje del servidor web dejándole saber sobre qué paso cuando la petición para ver la página fue recibida. Algunas comunes son:

  • 200: “Todo está bien.” Este es el código que uno recibe cuando la página web o recurso actúa exactamente como debería.

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

  • 301: “El recurso pedido ha sido reubicado permanentemente.” Este es el código que uno recibe cuando una página web o recurso ha sido reubicado permanentemente con un recurso distinto. Esto es usado para una redirección de URL permanente.

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

  • 404: “El recurso pedido no fue encontrado.” El mensaje de error más común de todos. Este código significa que el recurso pedido no existe y el servidor no sabe si alguna vez existió.
404: “El recurso pedido no fue encontrado.” El mensaje de error más común de todos. Este código significa que el recurso pedido no existe y el servidor no sabe si alguna vez existió.
404: “El recurso pedido no fue encontrado.” El mensaje de error más común de todos. Este código significa que el recurso pedido no existe y el servidor no sabe si alguna vez existió.

Puede leer más sobre todos los códigos de respuesta distintos en nuestro articulo sobre códigos de estado HTTP.

Tamaño de Contenido y Peticiones por Tipo de Contenido

Las siguientes secciones son el tamaño de contenido por tipo de contenido y peticiones por tipo de contenido. Cada una de estas es útil para poder ver rápidamente qué está usando la mayoría de los recursos en su página web. De acuerdo al Archivo de HTTP, las imágenes ocupan generalmente un 43% del tamaño total de una página promedio. También vemos que esto es normalmente el caso. Sin embargo, como podrá ver abajo en este sitio, no siempre es así.

Tipo de contenido en Pingdom
Tipo de contenido en Pingdom

Para optimizar sus imágenes, recomendamos leer nuestro articulo sobre cómo optimizar las imágenes para la red y sobre WebP Hay muchas herramientas y plugins fantásticos para comprimir aún más sus imágenes y asegurarse de que no ocupen gran parte del tamaño de la carga de la página de su sitio. Y en nuestro caso anterior, el sitio perfmatters.io está tomando ventaja de estar utilizando sorprendentes y grandes iconos de fuente en lugar de imágenes. Esta puede ser una excelente estrategia que puede hacer una enorme diferencia. Y por supuesto, tenemos algunos consejos adicionales en nuestra guía de cómo acelerar su sitio y cómo reducir aún más el tamaño de su contenido.

Tamaño del Contenido y Peticiones por Dominio

La sección de tamaño del contenido y las peticiones por dominio es una buena forma para rápidamente ver qué servicios externos y scripts se encuentran en su sitio. En nuestro ejemplo, usted podrá ver que tenemos todos nuestros activos cargando desde nuestra CDN. También existe la carga inicial de HTML DOC para el sitio web desde el servidor web, y una llamada externa al dominio de Google Analytics. Dependiendo de su sitio quizás tiene más servicios externos como Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.

Peticiones por Dominio en Pingdom
Peticiones por Dominio en Pingdom

Generalmente entre menos peticiones externas necesite será mucho mejor, porque cada servicio externo implica su propia latencia, retrasos de TSL handshake, búsquedas de DNS, etc. Asegúrese de leer nuestro articulo sobre cómo identificar y analizar servicios externos en su sitio de WordPress.

Generalmente, es mejor reducir el número de peticiones lo más posible y hospedar los activos en un sólo lugar, tal como moverlos a su servidor web o CDN. Un ejemplo sería font awesome. En lugar de enlazar al script externo para font awesome, descárguelo y sírvalo directamente.

Gráfica de Cascada de Pindom

Por último, pero no por eso menos importante, tenemos la sección de peticiones de Pingdom que genera una gráfica de cascada de todas las peticiones individuales en su página web (como se muestra abajo). Luego puede analizar cada petición para ver qué es lo que está causando los retrasos y problemas de desempeño en su sitio web. Esto es lo que queremos decir cuando decimos que estamos haciendo un análisis de cascada. Abajo tenemos un resumen y/o la definición sobre qué significa cada color de estado.

Análisis de Cascada Pingdom
Análisis de Cascada Pingdom

DNS (Rosado)

¿Qué es un DNS? Bueno, véalo como un directorio telefónico. Hay servidores llamados Domain Name Servers los cuales retienen la información sobre su sitio y a qué IP debe ser ruteado. Cuando uno prueba su sitio por primera vez en Pingdom, este lleva a cabo una búsqueda fresca, y tiene que hacer consultas a los registros del DNS para obtener la información de IP. Esto resulta en un tiempo adicional de búsqueda. La ubicación del DNS también importa.

Retrasos de DNS en Pingdom
Retrasos de DNS en Pingdom

Cuando uno pone a prueba su sitio en Pingdom más de una vez, este almacena en la cache el DNS porque ya sabe la información de la IP y no tiene porque volver a buscarlo. Esta es una razón por la que su sitio web aparenta estar más rápido después de pasarlo varias veces por Pingdom.

Como puede ver a continuación, en la segunda prueba que hicimos, el tiempo de búsqueda del DNS en la carga inicial de DOC es de 3.6 ms. Típicamente esta llegará a 0 ms, de hecho, así debería ser, ya que la petición ya ha sido guardada en la cache. ¡Este es un área que mucha gente malinterpreta!

DNS cacheado en Pingdom
DNS cacheado en Pingdom

Además, usted puede optimizarlo aún más usando el servicio de DNS premium, este incluye muchos otros beneficios adicionales. ¡O el DNS gratuito de Cloudflare es igualmente muy rápido! Mira la optimización automática de la plataforma de Cloudflare.

También hay otras razones por las que su sitio web parece ser más rápido después de varias pruebas. Una de esas sucede si está utilizando una CDN. Para aquellos que no estén familiarizados con una CDN, esta es una red de servidores globales que almacenan en la cache su contenido (JS, CSS, Imágenes, etc.) en ubicaciones cercanas al visitante. Cuando uno pasa su sitio por primera vez en Pingdom, podría obtener activos de una CDN fresca. Una cache de CDN funciona de forma muy similar al DNS, una vez que el DNS esté en la cache, se volverá mucho más rápido en cargas consecutivas.

Otro consejo para acelerar el DNS es utilizar DNS precargados. Esto le permite al navegador llevar a cabo búsquedas de DNS en una página mientras hace otras cosas. Puede hacer eso agregando unas líneas de código en el encabezado de su sitio WordPress. Vea algunos ejemplos.

<!-- 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 está usando la versión 4.6 de WordPress o una más reciente, podría querer usar los consejos sobre los recursos. Los desarrolladores pueden utilizan el filtro wp_resource_hints para agregar dominios personalizados y URLs para dns-prefetch, preconnect, prefetch o prerender.

SSL (Morado)

El color de estado morado representa el tiempo que su navegador toma para dar un SSL/TLS handshake. Cuando usted tenga un sitio sobre HTTPS esto quiere decir que hay un certificado SSL involucrado y más de tiempo de espera debido al proceso de encriptación (SSL/TLS handshake). En nuestro dominio de ejemplo, tenemos un certificado en nuestro servidor web en Kinsta y en nuestra CDN, KeyCDN. Así que hay una negociación SSL en la carga inicial de HTML doc desde el servidor web y nuestros activos.

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

Mientras que hay una ligera sobrecarga por utilizar HTTPS, es muy mínima ahora, gracias a HTTP/2, ¡la cual es un nuevo protocolo que ayuda a acelerar la red! Debido al soporte de navegador, HTTPS es requerido para utilizar HTTP/2. Cheque nuestra guía sobre HTTP/2.

También es importante tener en cuenta que incluso en 2018, no todos los proveedores soportan HTTP/2. Esto incluye del lado del hosting y del lado de la CDN. Así que cuando esté buscando hosting y CDN, asegúrese de que ambos lo soporten. Kinsta está orgulloso de decir que soporta HTTP/2 para todos sus clientes de WordPress.

A mediados del 2018, Pingdom finalmente actualizo su herramienta para utilizar Chrome 60 y en adelante. Puede ver el user-agent ser usado en el encabezado de petición. Anteriormente, ellos utilizaban Chrome 39, y Chrome no tenía soporte para HTTP/2 hasta la versión 49. Así que nos estamos agradecidos porque podemos decir que la herramienta de Pingdom ahora muestra las ventajas de HTTP/2 al hacer pruebas. 👏

Suporte HTTP/2 Pingdom
Suporte HTTP/2 Pingdom

Conectado (Turquesa)

El tiempo de conexión en Pingdom es referente a la conexión TCO, o al total requerido para crear una conexión TCP. No tiene porque entender cómo funciona, pero este simplemente es un método de comunicación entre host/cliente y el servidor que tiene que suceder.

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

Espera (Amarillo)

El tiempo de espera en Pingdom realmente refiere al tiempo hasta el primer byte, también conocido como el TTFB en algunas herramientas. El TTFB es la medida usada como una indicación de la respuesta de un servidor web u otros recursos de redes. Generalmente, cualquier cosa por debajo de los 100 ms es aceptable y un buen TTFB. Si se está acercando al rango de 300-400 ms podría tener algo mal configurado en su servidor o podría ser momento de conseguir un mejor web stack.

Tiempo de espera – TTFB
Tiempo de espera – TTFB

¿La forma más fácil para reducir el TTFB? Las dos mejores formas son una caching eficiente y una CDN. Así que hagamos un par de pruebas.

TTFB Sin Cache del Host de WordPress

Primero hicimos una prueba después de haber limpiado la cache en nuestro sitio de WordPress. Esto quiere decir que tiene que precargar la cache de nuevo. Como puede ver el 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 cache de WordPress
Pingdom TTFB sin la cache de WordPress

TTFB con Cache de Host de WordPress

Luego hicimos la prueba de nuevo. Ahora sirve directamente desde la cache. Como puede ver los tiempos de carga bajaron hasta 392 ms y el TTFB en la petición inicial es de 52.8. Esta es la diferencia que aporta la cache.

Pingdom TTFB con la cache de WordPress
Pingdom TTFB con la cache de WordPress

Pingdom TTFB with WordPress cacheSi tiene un sitio que está sirviendo a visitantes en distintas partes del país, o del mundo, la otra forma para drásticamente reducir su TTFB es utilizar una CDN. De nuevo hicimos algunas pruebas para mostrarle la diferencia.

TTFB sin CDN

Primero hicimos una prueba con nuestra CDN deshabilitada, como puede ver nuestro tiempo de espera era de 1.93 y nuestro promedio TTFB en un activo fue de 176 ms.

TTFB sin CDN
TTFB sin CDN

TTFB con CDN

Luego habilitamos nuestra CDN e hicimos unas pruebas de nuevo. ¡Como puede ver nuestra carga total redujo a 1.21 ms y nuestro TTFB promedio en una CDN activa es 4.6 s ahora! Es increíble la diferencia que pueda hacer una CDN.

TTFB con CDN
TTFB con CDN

Otra cosa importante para tomar en cuenta es que elegimos la ubicación de “Pacifico – Australia – Sídney” para hacer esta prueba. ¿Por qué? Porque queríamos mostrarle la gran mejora que se podía obtener. Nuestro sitio de WordPress en este ejemplo tiene como host a Kinsta en Google Cloud y ubicado en una zona central en los EUA. Al llevar a cabo la prueba contra Australia, pudimos mostrar como la caching de la Kinsta CDN incrementa la velocidad y reduce el TTFB.

Y por supuesto, tener un buen host de WordPress con una arquitectura bien planeada es crucial para reducir su TTFB.

Enviar (Naranja) y Recibir (Verde)

Realmente no se requiere decir mucho del estado de enviar y recibir en Pingdom. El tiempo de envío es simplemente el tiempo que tarda el navegador en enviar datos al servidor. Y el tiempo que toma recibir los datos del servidor. Usualmente ni uno dará grandes resultados en sus pruebas.

HTTP Encabezados de Respuesta

También puede dar clic en una petición individual mientras hace el análisis de cascada y ver los encabezados de respuesta HTTP. Esto brinda información valiosa. En la pantalla de abajo podemos ver de forma instantánea cosas como el gzip está habilitado en el servidor web, y está siendo servido desde la cache (HIT o MISS nos mostraría si el activo fue o no cacheado), los encabezados de control de cache, encabezados que expiran, el navegador usuario-agente y más.

Encabezados de respuesta HTTP
Encabezados de respuesta HTTP

Estudio de Caso de Configuración de Dominio

Si ya llegó hasta aquí en nuestro articulo de análisis de cascada entonces le espera lo mejor. Siempre es molesto ver a gente compartir consejos y estudios de caso, pero luego no se comparten la forma en que llegaron a ese resultado. ¡Así que abajo es nuestra configuración exacta para el dominio que usamos como estudio de caso! Así que, si quiere, puede replicarla.

Arquitectura

  • El dominio que usamos como estudio de caso (perfmatters.io está siendo hospedado por Kinsta en Google Cloud Platform en los EUA (Council Bluffs, EUA (us-central1). Kinsta actualmente ofrece 37 diferentes centros de datos a elegir. La red premium de GCP está incluida en todos nuestros planes para una latencia súper rápida.
  • Kinsta utiliza HTTP/2, Nginx, MariaDB, todas contribuyen al tiempo de carga súper rápido.
  • El sitio está utilizando KeyCDN, el cual hace que funcione la CDN de Kinsta. Ancho de banda gratuito de CDN está incluido en todos nuestros planes de hosting.
  • Este sitio no está utilizando ni un plugin de cache.¡Kinsta cachea todo a nivel servidor lo cual simplifica bastante las cosas!
  • El sitio está utilizando PHP 7.3. Las nuevas versiones de PHP siempre han mostrado grandes mejores de desempeño. Cheques estos puntos de referencia de PHP. Kinsta permite que pueda cambiar entre las diferentes versiones con tan sólo presionar un botón.
Actualización de la versión PHP del sitio WordPress
Actualización de la versión PHP del sitio WordPress

Plugins y Temas de WordPress

Aquí tenemos una lista de plugins que utilizamos en el sitio de ecommerce de WordPress, todos estos impactan el desempeño.
Added:

Tutoriales Recomendados para Aprender un poco más

Resumen

Como puede ver, saber cómo funciona Pingdom y lo que significan todas las gráficas pueden ayudarle a tomar decisiones más precisas basándose en datos concretos cuando se trata sobre el desempeño de un sitio. Un análisis de cascada, como nosotros lo llamamos es crucial para saber cómo sus activos individuales cargan y cómo son impactados por su host de WordPress, ubicación física, CDN, etc. ¿Tiene algún consejo adicional sobre Pingdom?

Si quiere ver más artículos como el anterior, ¡por favor háganos saber en los comentarios de abajo!

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.