Cuando una web de WordPress se cuelga un viernes por la tarde, empieza la cuenta atrás para resolver dos problemas distintos: arreglar la web y ponerse de acuerdo sobre quién ha sido el culpable.
El segundo problema casi siempre lleva más tiempo. El desarrollador señala la campaña que acaba de ponerse en marcha. El especialista en marketing señala el servidor. La agencia atiende las llamadas de ambos y no tiene datos propios en los que basarse. Para cuando todos se ponen de acuerdo en dónde buscar, la interrupción del servicio ya ha costado dinero real, y la discusión también.
El problema de fondo no es que los equipos no se pongan de acuerdo. Es que cada equipo trabaja con una parte diferente de los datos. El desarrollador ve el código. El especialista en marketing ve el tráfico. La agencia ve la cola de tickets de soporte. Nadie ve lo mismo al mismo tiempo, así que nadie puede descartar nada.
El enfoque de Kinsta consiste en que todos los equipos partan de la misma base a la hora de diagnosticar problemas. Los datos que los ingenieros de soporte de Kinsta usan para investigar un problema, como los códigos de respuesta, el rendimiento de PHP, los índices de caché y los registros de solicitudes, son los mismos que tienen a su disposición todos los usuarios de MyKinsta con acceso a las estadísticas. Cuando todo el mundo interpreta los mismos indicios, un sitio web que no funciona se convierte en algo que el equipo diagnostica en conjunto, en lugar de ser motivo de discusión.
También cambia la forma en que los equipos interactúan con el soporte técnico. Esta guía te explica las herramientas de diagnóstico disponibles en MyKinsta, qué muestra cada una, cuándo usarlas y cómo utilizarlas como parte de un flujo de trabajo compartido, en lugar de una sesión de depuración individual.
Por qué los problemas de rendimiento acaban convirtiéndose en un juego de culpas
En una web moderna de WordPress, es raro que una sola persona se encargue de todo. Los desarrolladores gestionan el código. Los especialistas en marketing dirigen las campañas. Las agencias o los freelancers se encargan del alojamiento. Cada equipo hace su trabajo; el problema es que sus ámbitos de actuación no se solapan.
Cuando un sitio deja de funcionar, esa falta de visibilidad convierte silenciosamente un problema técnico en uno personal:
- Los desarrolladores revisan el código, pero no el servidor. Su visión se limita a la capa de aplicación, así que una causa del lado del servidor les pasa desapercibida.
- Los especialistas en marketing ven el tráfico, pero no la base de datos. Un pico en una campaña parece el desencadenante obvio porque es la única variable que pueden medir.
- Las agencias atienden la queja, pero no disponen de ningún dato. Se convierten en un mero enlace entre las partes, en lugar de ser una fuente de respuestas.
Sin un punto de referencia común, cada parte da por hecho que la culpa es de otra. Muchas plataformas de alojamiento refuerzan este patrón sin que te des cuenta al mantener los datos de diagnóstico solo en manos del equipo de soporte. Abres un ticket y esperas a que alguien revise los registros a los que tú no tienes acceso.
Kinsta adopta el enfoque contrario. Ahora veamos qué herramientas hay que usar primero y cómo utilizarlas como un flujo de trabajo colaborativo, no individual.
Lo que muestra el panel de analíticas de MyKinsta cuando algo va mal
Cuando tu sitio no funciona bien, lo primero que hay que hacer es averiguar a qué tipo de problema te enfrentas. Los sitios lentos, que no funcionan bien o que están sobrecargados requieren cada uno una respuesta diferente. Si te equivocas en el diagnóstico, por ejemplo, si tratas un problema de caché como si fuera un problema del servidor, o un pico de errores como si fuera un problema de tráfico, estás haciendo perder el tiempo a todo el mundo.
La sección de analítica de MyKinsta es donde empieza ese diagnóstico.
En la sección Analíticas de MyKinsta encontrarás datos a nivel de empresa. Para un sitio concreto, ve a Sitios > nombre del sitio > Analíticas. En cualquier caso, todos los usuarios con acceso a las analíticas pueden consultar los mismos informes.
Comprueba si el sitio realmente está dando errores
Antes de nada, averigua si el sitio realmente falla o simplemente va lento. Las causas y las soluciones son diferentes, y confundirlas es lo que da pie a las discusiones sobre quién tiene la culpa.
La pestaña Respuesta responde a esta pregunta. Su gráfico principal, el Desglose de códigos de respuesta, muestra la distribución de los códigos de estado HTTP que ha devuelto tu sitio durante el periodo de tiempo seleccionado.
Por lo tanto, un grupo de códigos 5xx apunta al servidor o a la aplicación, mientras que los códigos 4xx indican problemas de acceso a los recursos. Hay otros dos gráficos que te permiten profundizar aún más:
- El desglose de los errores 500 distingue entre un 500 genérico y un 502 (puerta de enlace incorrecta) o un 503 (servicio no disponible), que tienen causas diferentes.
- El desglose de los errores 400 separa los códigos del lado del cliente, distinguiendo una avalancha de errores 404 del resto de respuestas que indican problemas de autenticación, permisos o limitación de velocidad.
Como todos los usuarios con acceso a las estadísticas ven el mismo desglose, puedes ponerte manos a la obra con el fallo concreto en lugar de darle vueltas al tema.
Distingue un sitio lento de uno que falla
Una página que se carga en seis segundos y otra que da un error 500 te parecerán parecidas si eres un visitante frustrado, pero tienen causas totalmente diferentes. La pestaña Rendimiento es donde puedes distinguirlas.
Aquí hay varios informes que vale la pena consultar cuando investigues por qué una página va lenta:
- Tiempo medio de respuesta de PHP + MySQL muestra cuánto tarda la aplicación en procesar y consultar cada solicitud que no está almacenada en caché. Un pico repentino suele ser la primera señal de una pérdida de rendimiento, más que de un problema de infraestructura.
- El rendimiento de PHP muestra cuántas solicitudes se han ejecutado en ese periodo. Si una ralentización coincide con un pico de rendimiento y no con un cambio en el código, lo más probable es que la causa sea la carga, no un error.
- El uso de AJAX pone de manifiesto picos en la actividad de admin-ajax.php, un consumo habitual de recursos del back-end que pasa fácilmente desapercibido y que se debe a los plugins y a los usuarios que han iniciado sesión y están ejecutando tareas en segundo plano.
- Tiempo máximo de subida muestra las rutas individuales más lentas, así que puedes identificar directamente la página o el endpoint que está elevando la media de tu sitio, en lugar de tener que adivinarlo.
En conjunto, estos datos te indican si lo que hay que hacer a continuación es optimizar la aplicación o escalar una interrupción del servicio.
Comprueba qué parte del sitio se está almacenando en caché
Un sitio puede parecer lento por motivos que no tienen nada que ver con el código o la infraestructura: se está sirviendo muy poco contenido desde la caché. Cuando baja el porcentaje de caché, el servidor tiene que procesar peticiones que no debería tener que procesar, lo que aumenta los tiempos de respuesta. Esta es una de las causas más comunes de esas conversaciones del tipo «¿es culpa del proveedor de alojamiento?», y casi nunca es culpa del proveedor.
La sección Caché muestra cómo se gestionan las solicitudes a través de las capas de caché de Kinsta.
Cada solicitud se resuelve en uno de estos tres estados:
HITsignifica que Kinsta atiende la solicitud desde la caché, que es lo que te interesa para la mayor parte del tráfico.BYPASSsignifica que una regla o un conflicto impide que la solicitud se almacene en la caché.MISSsignifica que el contenido aún no está almacenado en caché, pero lo estará tras la primera solicitud.
El gráfico de caché de un sitio en buen estado se basa en gran medida en los HIT. Cuando la tasa de BYPASS sube, el informe Principales omisiones de la caché del servidor indica las rutas concretas que se saltan la caché.
Algunas excepciones no suponen ningún problema (como que la página de inicio de sesión de WordPress nunca se almacene en la caché). Sin embargo, si en esa lista aparece una página que sí se puede almacenar en la caché, eso indica que hay un conflicto entre plugins o un problema con las reglas de almacenamiento en la caché. Leer estos informes mientras ves que una página va lenta te permite comprobar si la página está almacenada en la caché, en lugar de dar por hecho que el problema está en el servidor.
Identifica qué es lo que está consumiendo recursos
Si un sitio no muestra errores pero consume más ancho de banda o capacidad de lo que debería, puedes encontrar el origen del problema en el informe Solicitudes principales. Los problemas relacionados con los recursos son los más difíciles de identificar: un exceso de ancho de banda o una ralentización bajo carga no suelen ir acompañados de ningún código de error.
Tres informes convierten esas conjeturas en datos concretos:
- Ancho de banda del servidor te muestra qué URLs recogen más datos directamente de tu servidor de origen.
- Ancho de banda total suma los datos servidos por la CDN y el edge cache, así que ves el peso total de cada solicitud.
- Las visitas muestran los recursos más solicitados, independientemente de su tamaño, lo que pone de manifiesto un endpoint sometido a una carga constante, en lugar de un único archivo de gran tamaño.
Juntos, te dicen si un pico en el uso de recursos se debe a un archivo multimedia demasiado grande, a un endpoint fuera de control o a un rastreador que visita la misma ruta miles de veces. A partir de ahí, la solución suele ser optimizar el recurso, redirigirlo a través de una CDN o solucionar el problema del endpoint.
Si el pico de tráfico se debe a rastreadores o bots, la Protección contra Bots de Kinsta te permite identificar, clasificar y bloquear el tráfico no humano directamente desde MyKinsta, sin tener que usar ningún plugin ni abrir un ticket de soporte.
Cómo el APM localiza el origen de un problema de rendimiento
Los informes de Analíticas te dicen qué está pasando en tu sitio. La herramienta APM de Kinsta te dice por qué. Mientras que Analíticas te muestra que el tiempo de respuesta de PHP se disparó a las 14:00, APM te indica qué función de un plugin, consulta a la base de datos o llamada a una API externa lo provocó.
El APM está incluido en todos los planes de Kinsta y se ejecuta desde MyKinsta.
Ejecuta APM como una sesión, no de forma constante
A diferencia del panel de Analíticas, que registra datos de forma continua en segundo plano, el agente APM supone una carga adicional para la CPU y la memoria de tu servidor mientras recopila datos. Kinsta recomienda que solo lo ejecutes cuando estés diagnosticando un problema de forma activa.
Para iniciar una sesión, ve a Sitios > nombre del sitio > APM, haz clic en Activar APM y, a continuación, selecciona un intervalo de monitorización: 2, 4, 12 o 24 horas. APM se desactiva automáticamente al final de ese intervalo.
Esto significa que tienes un flujo de trabajo sencillo:
- Activa APM cuando sospeches que hay un problema o puedas reproducirlo, para que no suponga una carga adicional para tu sitio durante el funcionamiento normal.
- Elige un intervalo de tiempo que abarque el problema, y luego reproduce el error o espera a que vuelva a ocurrir para que la herramienta lo registre con datos en tiempo real.
- Echa un vistazo a los resultados una vez que se hayan acumulado los datos y, cuando hayas terminado, desactiva APM.
Cómo leer los resultados de APM
APM organiza los datos recopilados en cuatro pestañas: Transacciones, WordPress, Base de datos y Externo.
Empieza por Transacciones para encontrar las solicitudes más lentas. Al hacer clic en cualquier transacción, se abre una línea de tiempo con todos los procesos implicados en esa solicitud y se resaltan los intervalos más pesados. Así sabrás si debes centrar tus esfuerzos de optimización en una consulta de base de datos lenta, en una función concreta de un plugin o en una API de terceros.
La pestaña Externo es especialmente útil para descartar el servidor. Si la ralentización de una transacción se debe a una llamada a una API externa, los datos de APM lo muestran claramente. Esa es la diferencia entre un ticket de soporte que dice «la web va lenta» y otro que dice «la ralentización está en la API de nuestro proveedor de correo electrónico, no en el servidor».
Cómo el visor de registros y el registro de actividad reconstruyen una línea temporal
Para resolver un incidente, lo normal es saber qué ha pasado y en qué orden. Hay dos registros en MyKinsta que te ayudan a reconstruir la cronología: el visor de registros recoge lo que hace tu sitio y el registro de actividad recoge lo que hacen los usuarios.
El visor de registros te muestra lo que indica el sitio, no cómo funciona. En la pantalla Registros hay tres archivos disponibles para cualquier sitio de MyKinsta:
error.logregistra los errores y advertencias de PHP, y es lo primero que hay que mirar para encontrar la causa de una página que no funciona.kinsta-cache-perf.logregistra el rendimiento de la caché y muestra si las páginas se sirven desde la caché o la omiten.access.logregistra todas las solicitudes HTTP que llegan al sitio, que es donde puedes rastrear los patrones de tráfico y los errores 404 recurrentes.
El visor integrado carga hasta 20.000 líneas y cuenta con un campo de búsqueda para filtrar por cualquier cadena de texto. También puedes descargar los registros a través del Gestor de Archivos de MyKinsta si necesitas trabajar con ellos en una herramienta externa.
El registro de actividad: lo que han hecho los usuarios
El registro de actividad recoge todas las acciones realizadas en MyKinsta para un sitio por cualquier usuario, en orden cronológico.
Encontrarás los registros de actividad en Sitios > nombre del sitio > Actividad del usuario. Cada entrada te permite ver la acción descrita en lenguaje sencillo, el usuario, la fecha y hora, y un icono de estado. Aquí, una marca verde indica éxito y un signo de exclamación rojo indica un fallo.
Te ayuda a diagnosticar problemas cuando lo combinas con otros registros. Por ejemplo, si tienes un archivo error.log con datos, puedes abrir el registro de actividad, filtrarlo para que se muestre solo esa ventana y encontrar las acciones relacionadas.
Cómo la monitorización del tiempo de actividad crea una conciencia compartida
Las herramientas anteriores son reactivas. La monitorización del tiempo de actividad permite una detección proactiva: en lugar de enterarte de un problema por una queja de un cliente, tanto tú como Kinsta os enteráis al mismo tiempo.
Kinsta monitoriza cada sitio de la plataforma unas 480 veces al día. Si tienes activadas las notificaciones de monitorización en Configuración de usuario > Notificaciones, recibirás un correo electrónico según las áreas que requieran atención prioritaria:
- Errores del sitio indican que se ha detectado un problema en el propio sitio.
- Los errores SSL te avisan de un problema con el certificado o la configuración antes de que los visitantes se vayan.
- Caducidad del dominio te avisa de que un dominio está a punto de caducar antes de que caduque.
Los correos se envían tras tres comprobaciones fallidas consecutivas, en lugar de hacerlo tras la primera, lo que filtra esos pequeños fallos momentáneos que, de otro modo, te inundarían de falsas alarmas.
SIX15 Solutions gestiona más de 30 sitios web de clientes con este sistema de monitorización, donde lo valioso no es tanto la comprobación en sí como la frecuencia con la que los problemas se resuelven antes de que el cliente se dé cuenta.
Ahora mismo tengo alojadas más de 30 páginas web de clientes en mi plan de Agencia, desde pequeñas páginas de marketing hasta sitios de Membresía en toda regla con miles de usuarios, sin ningún problema ni tiempo de inactividad.
Sin embargo, no todas las alertas indican un fallo. Las alertas de límites del plan te avisan cuando te estás acercando a los límites de uso de tu plan, lo que supone un eficaz sistema de alerta temprana. Esto te permite averiguar, a través de tus analíticas, por qué estás alcanzando un límite, por ejemplo, si una campaña está generando más tráfico del previsto o si hay actividad de rastreadores o bots.
Compartir datos es lo que pone fin a las discusiones sobre quién tiene la culpa
Un sitio web que no funciona bien te hace perder más tiempo en averiguar quién es el responsable y a quién hay que pedir cuentas que en arreglarlo. Las analíticas de MyKinsta te muestran si un sitio va lento, no funciona o está sobrecargado. Entre la herramienta APM, el visor de registros, el registro de actividad, la monitorización del tiempo de actividad y mucho más, puedes asegurarte de que todo el mundo se entere del problema y se ponga manos a la obra sin tener que esperar en la cola de tickets.
El objetivo es tratar estas vistas como un flujo de trabajo compartido. Si todos los miembros del equipo tienen el acceso adecuado a los datos analíticos, podéis poneros de acuerdo sobre los informes en los que vais a basaros antes de que nadie abra un ticket. Así, la conversación se centra en el diagnóstico en lugar de convertirse en una discusión.
Si gestionas sitios web en los que varios equipos comparten la responsabilidad, el alojamiento administrado de WordPress de Kinsta permite que cada uno de esos equipos participe en el proceso de diagnóstico. Si gestionas sitios web de clientes a gran escala, merece la pena que eches un vistazo al Programa de Socios para Agencias por las herramientas de acceso compartido y cogestión que ofrece.
