Cómo Usar MyKinsta Analytics para Solucionar los Problemas en Su Sitio

Actualizado December 01, 2017

A veces puede ser frustrante cuando se da cuenta de que no tiene suficiente acceso a los datos necesarios para solucionar los problemas en su sitio WordPress. Afortunadamente, con el nuevo modernizado MyKinsta Analytics ahora puede investigar y diagnosticar muchos de estos problemas justo dentro del panel de control. Hoy profundizaremos en cada sección de MyKinsta Analytics y compartiremos algunos ejemplos (y escenarios reales) de cómo usted puede tomar ventaja de estos nuevos informes para mejorar y corregir sus sitios WordPress. ¡Averigüe qué es lo que ocurre bajo el capó!

MyKinsta analytics

MyKinsta analytics

Sumergiendo en MyKinsta Analytics

En el panel principal de MyKinsta tiene algunas percepciones rápidas sobre el uso de recursos, así como la transferencia de datos y visitas únicas. Para sumergirse en los informes más a fondo haga clic sobre “Analítica” en la barra lateral.

Acceso a MyKinsta Analytics

Acceso a MyKinsta Analytics

En la parte superior puede filtrar las estadísticas individualmente o ver los datos de todas ellas combinadas. Después, puede optar por ver los datos de los últimos 7 días o las últimas 24 horas. Nota: Estamos añadiendo un filtro de 30 días también.

Filtrar Analítica

Filtrar Analítica

MyKinsta Analytics ha sido dividida en seis secciones diferentes de las cuales nos adentraremos en cada una más abajo:

1. Recursos

En la sección de uso de recursos, puede ver el número total de visitantes, el uso de ancho de banda total de solicitudes por bytes, y solicitudes totales por visitas.

Visitantes

El informe del visitante le permite ver el número total de personas que han visitado su sitio WordPress. Si selecciona un punto de tiempo específico en el gráfico este le mostrará algunas estadísticas de comparación, como el número total de visitantes se forma en comparación del día anterior, etc. Este es el número exacto de visitantes del servidor web. Recuerde que sus filtros y reglas de Google Analytics no funcionan aquí. En caso de que le guste saber el número de los visitantes humanos de su sitio web, todos los servicios se muestran un número diferente basado en su propio conjunto de reglas — que consideran ser tráfico irrelevante/bot y aquellos que no consideran como tales.

Visitantes - uso de recursos

Visitantes – uso de recursos

Los planes de hosting de Kinsta se basan en el número de visitantes de su sitio. Lea más sobre cómo Kinsta cuenta las visitas.

Uso de Ancho de Banda

El informe de uso de ancho de banda muestra el total de datos que su sitio ha utilizado. Esto es importante porque Kinsta le cobra basando en el número de visitas que su sitio tiene mensualmente. El uso del ancho de banda le ayuda solucionar los problemas de rendimiento. Si selecciona un punto de tiempo específico en el gráfico le muestra algunas estadísticas de comparación, como el total es inferior al promedio del período, etc.

El uso de los recursos - uso de ancho de banda

El uso de los recursos – uso de ancho de banda

Recomendamos encarecidamente que cada cliente implemente una CDN. No sólo porque usted verá un aumento en la velocidad, sino porque esto puede ser una manera muy rentable para disminuir el ancho de banda y recursos de su sitio. El ancho de banda con una CDN es muy barato o incluso gratuito. Eche un vistazo a nuestra publicación en profundidad sobre los beneficios de una WordPress CDN y por qué usted debe usar una. En este artículo puede aprender cómo habilitar KinstaCDN en su sitio.

Solicitudes Principales por Bytes

Un byte es una secuencia de bits binarios en un flujo de datos seriados en sistemas de transmisión de datos. Cuando se trata de su sitio WordPress, esta es normalmente medido en MB, GB, TB. El número total de bytes transferidos en su sitio conforma su ancho de banda. En el reporte de principales solicitudes por bytes, puede ver exactamente qué solicitudes en su sitio web están utilizando la mayoría del ancho de banda.

Uso de los recursos - Solicitudes principales por bytes

Uso de los recursos – Solicitudes principales por bytes

Solicitudes Principales por Visitas

Similares a las del informe anterior, los reportes de solicitudes principales por visitas muestran el principal ancho de banda utilizado por los visitantes a su sitio. Usar este reporte y los anteriores pueden ayudarle a solucionar problemas y averiguar adonde el ancho de banda está yendo. Muchas veces, usted puede fácilmente observar una pauta.

El uso de recursos - Solicitudes principales por visitas

El uso de recursos – Solicitudes principales por visitas

2. Dispersión

Bajo esta sección puede ver distintas percepciones sobre el tráfico  de su sitio.

Móvil vs Escritorio

El reporte sobre móvil vs. escritorio le permite ser qué tipo de dispositivos visitan su sitio. En el ejemplo de abajo que domina la visita por escritorio en un 86%.

Dispersión - móvil vs escritorio

Dispersión – móvil vs escritorio

3. Monitoreo de Rendimiento

En la sección de monitoreo de rendimiento, puede ver su promedio de tiempo de respuesta PHP + MySQL, rendimiento PHP, utilización de AJAX, tiempo de upstream medio, y tiempo de upstream máximo.

Promedio de Tiempo de Respuesta PHP + MySQL

Cuando usted visita su sitio WordPress, PHP y MySQL están acostumbrados a compilar y consultar los datos que se muestran en la página. Este gráfico muestra el tiempo de respuesta medio de los motores PHP y MySQL para todas las solicitudes dinámicas no cacheadas. Conocer estos tiempos de respuesta puede ayudar a solucionar problemas de lentitud. Si usted está viendo enormes picos aquí, no dude en abrir un ticket de soporte con nuestro equipo.

Monitoreo de rendimiento PHP + MySQL - Promedio de tiempo de respuesta

Monitoreo de rendimiento PHP + MySQL – Promedio de tiempo de respuesta

Rendimiento de PHP

Rendimiento indica el número de transacciones por segundo, que una aplicación puede manejar, y en este informe, se refiere a rendimiento de PHP desde su sitio WordPress. Con otras palabras muestra cuántas veces fue requerido un activo de PHP.

Supervisión del rendimiento: el rendimiento de PHP

Supervisión del rendimiento: el rendimiento de PHP

Uso de AJAX

AJAX es un script de parte de cliente que se comunica con el servidor/base de datos sin la necesidad de una devolución o una completa actualización de la página. Cuando se trata de WordPress, muchos de ustedes probablemente han visto esto en sus pruebas de velocidad. Los dos principales problemas con AJAX incluyen plugins provocando picos y los problemas de la CPU en el back-end. Asegúrese de leer nuestra publicación en profundidad sobre cómo diagnosticar el uso de admin-ajax en su sitio WordPress.

Uso de admin-ajax

Uso de admin-ajax

El informe de uso de AJAX en MyKinsta analytics puede ser una gran manera de ayudarle a solucionar estos tipos de problemas, ya que puede ver si usted está viendo ciertos picos de AJAX durante ciertos períodos. Este gráfico muestra el recuento de las solicitudes admin AJAX. Después, puede utilizar algunas de las sugerencias en el post que mencionamos anteriormente para determinar de donde podrían estar viniendo.

Rendimiento - Uso de AJAX

Rendimiento – Uso de AJAX

Tiempo de Upstream Medio

El tiempo de upstream es el tiempo total necesario para NGINX (y servidores upstream) para procesar una solicitud y enviar una respuesta. El tiempo se mide en segundos, con una resolución de milisegundos. Lea más acerca de las métricas de NGINX. Esta lista muestra el tiempo de respuesta (combinado) medio superior de PHP y MySQL para sus solicitudes.

Rendimiento: Tiempo promedio superior de upstream

Rendimiento: Tiempo promedio superior de upstream

Tiempo de Upstream Máximo

Esta lista muestra los tiempos de respuesta superiores de PHP y MySQL. Por favor tome nota de que estos números pueden ser picos de una vez, le sugerimos compara esta lista con la de Tiempo de Upstream Medio.

Supervisión del rendimiento - tiempo de upstream máximo

Supervisión del rendimiento – tiempo de upstream máximo

4. Respuesta

Bajo la sección de análisis de respuesta, puede ver el desglose de código de respuesta, estadísticas de respuesta, desglose de error 500, de error 400 y de redirecciones.

Desglose de Código de Respuesta

El reporte de desglose de código de respuesta permite ver un resumen de los errores en su sitio. Los códigos de respuesta, también conocidos como códigos de estado de HTTP, no siempre son malos. Por ejemplo, un código de estado HTTP 200 significa que “todo está bien”. Este es el código que se ejecuta cuando una página web o recurso actúa exactamente de la manera que se esperaba. Entraremos en los otros más adelante.

Respuesta - desglose de código de respuesta

Respuesta – desglose de código de respuesta

Estadísticas de Respuesta

El reporte de estadísticas de respuesta le permite ver el número total de redirecciones sucediendo, errores, índice de éxito e índice de error. Cada sitio WordPress normalmente tiene una pequeña tasa de error, esto es completamente normal.

Análisis de respuesta – estadísticas de respuesta

Análisis de respuesta – estadísticas de respuesta

Desglose de Error 500

El reporte de desglose de error 500 muestra el número total de errores 500 que se han producido en el servidor. Aquí está una explicación más a fondo de lo que cada uno de estos significa:

  • 500: “Hubo un error en el servidor y no se ha podido completar la solicitud”. Un código genérico que significa simplemente “error interno del servidor”. Algo ha ido mal en el servidor y el recurso solicitado no fue entregado. Este es el código generado por WordPress cuando la conexión a la base de datos se rompe. Lea nuestro artículo detallado sobre cómo arreglar el error al establecer conexión con la base de datos.
  • 502: “Bad Gateway”. Este código de error significa normalmente que un servidor ha recibido una respuesta no válida de otro. A veces, una consulta o una solicitud tardará demasiado tiempo y por lo tanto es cancelada o matada por el servidor.
  • 503: “El servidor no está disponible para manejar esta solicitud ahora”. No se puede completar la solicitud en este momento. Este código puede ser devuelto por una sobrecarga en el servidor que no es capaz de gestionar peticiones adicionales.
Análisis de respuesta - desglose de error 500

Análisis de respuesta – desglose de error 500

Desglose de Error 400

El reporte de desglose de Error 400 le muestra el número total de errores 400 que se han producido en el servidor. Aquí está una explicación más a fondo de lo que cada uno de estos significa:

  • 401: “No autorizado.” Este código vuelve del servidor si el recurso de objetivo no tiene credenciales de autenticación válidas.
  • 403: “El acceso a ese recurso está prohibido”. Se devuelve este código cuando un usuario intenta acceder a algo a lo que no tiene permiso de acceso. Por ejemplo, intentar ver el contenido protegido con contraseña sin iniciar sesión podría producir un error 403.
  • 404: “No se ha encontrado el recurso solicitado”. El mensaje de error más común de todos ellos. Este código significa que el recurso solicitado no existe y que el servidor no sabe si alguna vez ha existido.
  • 405: “Método no permitido”. Este mensaje es generado cuando el server del origen apoya el método recibido pero el recurso de objetivo no.
  • 429: “Demasiadas solicitudes”. Esto normalmente es generado por el servidor cuando el usuario ha enviado demasiadas solicitudes en un período de tiempo determinado (limitación de velocidad). Un montón de veces esto podría suceder por bots o scripts intentando forzar su camino en su página de inicio de sesión por defecto de WordPress. Usted puede ayudar a bloquear el sitio cambiando su URL de inicio de sesión de WordPress.
  • 499: “El cliente cerró la solicitud”. Este mensaje es devuelto por NGINX cuando el cliente cierra la solicitud mientras NGINX está procesándola.
Análisis de respuesta - desglose de error 400

Análisis de respuesta – desglose de error 400

Si usted está viendo una gran cantidad de errores 404, como en el ejemplo anterior, es recomendable que usted vaya a través de su sitio y los arregle por SEO y usabilidad. Puede instalar un plugin de error 404 o buscarlos en Google Search Console bajo errores de rastreo.

Solucionar errores 404

Solucionar errores 404

Descomposición de Redirecciones

El reporte de descomposición del error 300 le muestra el número total de errores 300 que se han producido en el servidor. Recuerde que, al igual que códigos de respuesta 200, no todos los errores son malos. Los errores 300 normalmente significan que simplemente ha movido el contenido a otra parte. Las redirecciones 301, por ejemplo, son muy importantes ya que ayudarán a mantener su posicionamiento SEO para cambios en URL y en el sitio. Aquí está una explicación más a fondo de lo que cada uno de estos significa.

  • 301: “El recurso solicitado ha sido movido permanentemente”. Este código se ejecuta cuando una página web o un recurso ha sido reemplazado permanentemente con un recurso diferente. Se utiliza para la redirección de URL permanente.
  • 302: “El recurso solicitado se ha movido, pero fue encontrado”. Este código se utiliza para indicar que el recurso solicitado se encuentra, no en el lugar donde se esperaba. Se utiliza para la redirección de URL temporal.
  • 304: “El recurso solicitado no se ha modificado desde la última vez que accedió. “Este código indica al navegador que los recursos almacenados en la cache del navegador no han cambiado. Se utiliza para acelerar la entrega de páginas web mediante la reutilización de los recursos descargados previamente.
respuesta - descomposición de redirecciones

Respuesta – descomposición de redirecciones

5. Análisis de Cache

Bajo la sección de análisis de la cache, usted puede ver la pila de componente de caché, derivaciones totales de caché, y gráfico de componente de caché.

Pila de Componente de Cache

Siempre que un archivo o un recurso solicitado desde los servidores Kinsta envíe un valor en el encabezado de la respuesta HTTP (X-Kinsta-Cache) que le permite conocer el estado de la cache.

Encabezado de la respuesta HTTP

Encabezado de la respuesta HTTP

Hay cuatro tipos de respuestas de cache que los encabezados regresaron:

  • HIT: Un HIT significa que el recurso está siendo servido de la cache de los servidores Kinsta. Normalmente, esto es lo que usted querrá ver.
  • BYPASS: Esto significa que probablemente hay una regla o un conflicto que está impidiendo que el recurso se almacene en cache. Tenemos reglas en lugar de modo que ciertas cosas en su sitio WordPress no se almacenan en cache. Por ejemplo, la página /wp-login.php es una. Esto es para asegurar la funcionalidad correcta cuando inicie sesión en el panel.
  • MISS: Esto significa que el contenido no estaba todavía en la cache, pero lo estará después de la primera solicitud. La segunda solicitud de archivo será un HIT de cache. Recuerde que cada vez que purgue la cache en su sitio WordPress este tiene que reconstruir por quienes lo visiten. Esta es la razón por la que recomendamos no borrar la cache completa constantemente. El Kinsta Cache Plugin purga automáticamente sólo ciertas secciones del sitio, de manera que el resto puede permanecer en la cache. Lea más acerca de cómo Kinsta gestiona cache.
  • EXPIRED: Esto significa que el contenido de la cache ha caducado y el nuevo contenido desde el servidor de alojamiento ha sido traído.

El reporte de pila componente de cache le permite ver el número total de valores de encabezado de respuesta que se han generado desde su sitio.

Cache - pila de componentes de cache

Cache – pila de componentes de cache

Derivaciones Principales de Cache

El reporte de derivaciones principales de cache le permite ver algunas de las principales peticiones que están omitiendo la cache de los servidores Kinsta. Es bueno tomar un vistazo a esto y asegurarse de configurar todo bien. En este ejemplo a continuación, podemos ver que el plugin de notificaciones push de OneSignal tiene unos cuantos archivos que están desviándose de la cache. Debido a la forma en que el plugin funciona, esto es en realidad OK. También podemos ver que /wp-cron.php no está en cache, que una vez más, está bien.

Cache – principales derivaciones de la cache

Cache – principales derivaciones de la cache

Gráfico de Componente de Cache

El gráfico de componente de cache es otra forma de ver el total de peticiones de cache.

Análisis de la cache: gráfico de componentes de cache

Análisis de la cache: gráfico de componentes de cache

6. Análisis Geográfica & IP

En la sección Geo Análisis, puede ver a sus principales países y ciudades y las direcciones IP que visitan su sitio.

Los Países Principales

El reporte de principales países puede ser una buena manera para determinar dónde debería colocar su sitio WordPress. Este es un geo análisis por país de las solicitudes de las direcciones IP de los visitantes. En el ejemplo siguiente, el sitio probablemente debe ser colocado en un servidor en los Estados Unidos, ya que la mayoría del tráfico es de allí. Asegúrese de leer nuestros posts en profundidad acerca de la latencia de la red y por qué es importante colocar estratégicamente su sitio. Kinsta ahora tiene 13 lugares de Google Cloud Platform alrededor del mundo donde usted puede alojar su sitio WordPress.

Geo & IP - Principales Países

Geo & IP – Principales Países

Regiones Principales

Este es un geo análisis por región de las solicitudes de las direcciones IP de los visitantes.

Geo & IP - Regiones Principales

Geo & IP – Regiones Principales

Ciudades Principales

Este es un geo análisis por ciudad de las solicitudes de las direcciones IP de los visitantes.

Geo & IP - ciudades principales

Geo & IP – ciudades principales

IPs Principales de Cliente

El informe de IPs Principales de Cliente puede ser muy útil si su sitio está de repente generando una gran cantidad de ancho de banda o recibiendo muchos bots. La lista muestra las direcciones IP principales listadas por recuento de solicitudes.

Geo & IP - IPs de cliente principal

Geo & IP – IPs de cliente principal

¿Cómo puede usar estos datos? Bueno, recientemente hicimos estudio de caso sobre un pequeño sitio de comercio electrónico de WordPress. Analizando las principales 10 IPS de cliente durante los últimos 7 días en el sitio al instante mostró alguna actividad sospechosa. La mayoría de ellas tenían más de 10,000 solicitudes, y no eran pocas. Fue más probable un DDoS o ataque de fuerza bruta. Usted siempre puede confiar en Google para proporcionarle los datos. Introduciendo un par de las IPs principales en búsqueda, podríamos ver fácilmente que la mayoría de ellas eran todas direcciones proxy, es decir, alguien quería más probablemente ocultar su tráfico.

Proxy IP

Proxy IP

El siguiente paso en este escenario que recomendaríamos es contactar al equipo Kinsta para bloquear las IPs por usted, o considerar un firewall de aplicaciones web como Cloudflare o Sucuri. Puede echar un vistazo a nuestro estudio de caso en el cual Sucuri instantáneamente bloqueó todo este tráfico malo.

Con todos los datos anteriores, ahora usted tiene una mejor comprensión de cómo Kinsta está entregando contenido a sus visitantes.

Artículos Relacionados

¿Le resultó útil este artículo?
No, o no fue completo

Artículos relacionados

kinsta newsletter

¿Utilizas WordPress?

¡Únete a más de 20.000 lectores que ya reciben nuestro newsletter semanal GRATUITO con consejos de WordPress sobre cómo generar más tráfico e ingresos para tu negocio!

You have Successfully Subscribed!

Send this to a friend